Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #8139 > unrolled thread

duct typing and interface in C++

Back to article view | Back to comp.lang.c++

Contents

  duct typing and interface in C++ TP <Tribulations@Paralleles.invalid> - 2011-07-24 17:40 +0200
    Re: duct typing and interface in C++ Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2011-07-24 18:11 +0200
      Re: duct typing and interface in C++ Marcel Müller <news.5.maazl@spamgourmet.org> - 2011-07-25 00:03 +0200
        Re: duct typing and interface in C++ Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2011-07-25 10:11 +0200
        Re: duct typing and interface in C++ Goran <goran.pusic@gmail.com> - 2011-07-25 04:18 -0700
    Re: duct typing and interface in C++ Nobody <nobody@nowhere.com> - 2011-07-24 17:39 +0100
      Re: duct typing and interface in C++ TP <Tribulations@Paralleles.invalid> - 2011-07-24 19:55 +0200
        Re: duct typing and interface in C++ Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2011-07-24 20:11 +0200
          Re: duct typing and interface in C++ TP <Tribulations@Paralleles.invalid> - 2011-07-24 20:23 +0200
            Re: duct typing and interface in C++ Dombo <dombo@disposable.invalid> - 2011-07-24 20:45 +0200
            Re: duct typing and interface in C++ Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2011-07-24 21:10 +0200
            Re: duct typing and interface in C++ Nobody <nobody@nowhere.com> - 2011-07-24 21:21 +0100
              Re: duct typing and interface in C++ TP <Tribulations@Paralleles.invalid> - 2011-07-24 23:50 +0200
                Re: duct typing and interface in C++ Stuart Redmann <DerTopper@web.de> - 2011-07-24 23:33 -0700
                  Re: duct typing and interface in C++ TP <Tribulations@Paralleles.invalid> - 2011-07-25 23:00 +0200
                Re: duct typing and interface in C++ Paavo Helde <myfirstname@osa.pri.ee> - 2011-07-25 01:35 -0500
                Re: duct typing and interface in C++ Goran <goran.pusic@gmail.com> - 2011-07-25 04:10 -0700
            Re: duct typing and interface in C++ James Kanze <james.kanze@gmail.com> - 2011-07-30 11:51 -0700
        Re: duct typing and interface in C++ Dombo <dombo@disposable.invalid> - 2011-07-24 20:21 +0200
          Re: duct typing and interface in C++ Dombo <dombo@disposable.invalid> - 2011-07-24 20:26 +0200
    Re: duct typing and interface in C++ Dombo <dombo@disposable.invalid> - 2011-07-24 18:36 +0200
      Re: duct typing and interface in C++ BGB <cr88192@hotmail.com> - 2011-07-24 10:02 -0700
    Re: duct typing and interface in C++ BGB <cr88192@hotmail.com> - 2011-07-24 09:45 -0700
      Re: duct typing and interface in C++ TP <Tribulations@Paralleles.invalid> - 2011-07-24 20:15 +0200
        Re: duct typing and interface in C++ BGB <cr88192@hotmail.com> - 2011-07-24 14:06 -0700
    Re: duct typing and interface in C++ Thomas Boell <tboell@domain.invalid> - 2011-07-25 02:05 +0200
    Re: duct typing and interface in C++ Qi <no@no.no> - 2011-07-25 09:54 +0800
    Re: duct typing and interface in C++ Werner Erasmus <werasm@gmail.com> - 2011-07-25 23:36 +0200
      Re: duct typing and interface in C++ Leigh Johnston <leigh@i42.co.uk> - 2011-07-25 23:22 +0100
        Re: duct typing and interface in C++ Werner Erasmus <werasm@gmail.com> - 2011-07-26 08:35 +0200

Page 2 of 2 — ← Prev page 1 [2]

#8142

Op 24-Jul-11 17:40, TP schreef:
> Hello,
>
> I convert a Python/Qt program (PyQt) in C++/Qt.
> The programmer has used the duck typing of Python, thus I would like to have
> duck typing in C++, in fact exactly what is described in the "best answer"
> at the following address:
>
> http://stackoverflow.com/questions/289176/how-is-duck-typing-different-from-
> the-old-variant-type-and-or-interfaces
>
> (the "best answer" is the second post of the page, the one with a green
> sign).
>
> Is it possible in C++?

I think the closest you can come to duck typing with C++ is using 
templates. Whether that is a good idea or not is another question.

[toc] | [prev] | [next] | [standalone]

#8144

On 7/24/2011 9:36 AM, Dombo wrote:
> Op 24-Jul-11 17:40, TP schreef:
>> Hello,
>>
>> I convert a Python/Qt program (PyQt) in C++/Qt.
>> The programmer has used the duck typing of Python, thus I would like
>> to have
>> duck typing in C++, in fact exactly what is described in the "best
>> answer"
>> at the following address:
>>
>> http://stackoverflow.com/questions/289176/how-is-duck-typing-different-from-
>>
>> the-old-variant-type-and-or-interfaces
>>
>> (the "best answer" is the second post of the page, the one with a green
>> sign).
>>
>> Is it possible in C++?
>
> I think the closest you can come to duck typing with C++ is using
> templates. Whether that is a good idea or not is another question.

possibly, if one stays within static types.

however, given Python was mentioned, it is possible that "duck typing" 
here was more in reference to the sort of dynamic type-system which 
Python provides, which may be better handled via dynamic types than via 
templates.


an advantage of templates vs dynamic types though is that they may allow 
more compile-time type-verification, as well as higher performance, due 
to a lack of run-time type-checking or dynamic method-dispatch 
mechanisms or similar.

however, in terms of using them, they are very different beasts.

[toc] | [prev] | [next] | [standalone]

#8143

On 7/24/2011 8:40 AM, TP wrote:
> Hello,
>
> I convert a Python/Qt program (PyQt) in C++/Qt.
> The programmer has used the duck typing of Python, thus I would like to have
> duck typing in C++, in fact exactly what is described in the "best answer"
> at the following address:
>
> http://stackoverflow.com/questions/289176/how-is-duck-typing-different-from-
> the-old-variant-type-and-or-interfaces
>
> (the "best answer" is the second post of the page, the one with a green
> sign).
>
> Is it possible in C++?
>

yes, and it is also possible in C, but the "ideal" strategy will differ.

also, IIRC, Boost may offer something like this, if this is relevant.


but, other potential strategies:

using RTTI:
merits: reasonably simple and straightforward in C++, meshes well with 
C++ style, ...
downside: depends on classes and is subject to compiler issues (may be 
disabled by command-line options, or require a command-line option to 
enable), and may potentially have drawbacks related to overhead, on some 
systems (namely Windows), it may break violently across arbitrary 
borders (say, if you make a DLL and then use the DLL from an EXE, the 
RTTI may not actually work).

http://en.wikipedia.org/wiki/RTTI


using tagged references:
merits:
may be reasonably efficient;
very commonly used in implementing VMs (dominant strategy);
relatively C-friendly;
integers or floating point values may be directly encoded into 
references (sometimes called fixnum and flonum);
...

downside:
may be more awkward to use (depending on details, requiring much added 
manual boxing/unboxing/bookkeeping);
bit-twiddly and magic numbers.


using "magic pointers" (where one has a raw pointer, and types are 
identified based on the pointed-to object or memory-address):

merits:
can be made fairly easy to use (depending on implementation details, 
dynamic types in C++ can be made to have a "look and feel" almost as if 
one was them in a dynamically-typed language);
are also relatively C friendly;
generally much easier to manage than tagged references;
it is often easier to extend the type-system in an ad-hoc manner;
may be made cast-compatible with struct or class pointers;
...

downside:
potentially less efficient and more complex to implement than tagged 
references;
they are a less well-known strategy;
generally, fewer bits can be afforded to fixnum and flonum types (mostly 
an issue on 32-bit systems).


or such...

[toc] | [prev] | [next] | [standalone]

#8149

BGB wrote:
 
Thanks BGB for your answer,

> also, IIRC, Boost may offer something like this, if this is relevant.

As I use Qt, I would like to avoid using Boost.

> but, other potential strategies:
> 
> using RTTI:
> merits: reasonably simple and straightforward in C++, meshes well with
> C++ style, ...
> downside: depends on classes and is subject to compiler issues (may be
> disabled by command-line options, or require a command-line option to
> enable), and may potentially have drawbacks related to overhead, on some
> systems (namely Windows), it may break violently across arbitrary
> borders (say, if you make a DLL and then use the DLL from an EXE, the
> RTTI may not actually work).
> 
> http://en.wikipedia.org/wiki/RTTI

Reading this page, if I am right, RTTI has an interest only to know which is 
the true class of an object at run time, amongst all the classes in a given 
hierarchy. I am not sure it is applicable to the example I have tried to 
translate (see my answer to Nobody).
If I am right, the RTTI has an interest in the frame of the "run-time 
polymorphism", also called "subtype polymorphism".

http://en.wikipedia.org/wiki/Polymorphism_(computer_science)
 
> using tagged references:
> merits:
> may be reasonably efficient;
> very commonly used in implementing VMs (dominant strategy);
> relatively C-friendly;
> integers or floating point values may be directly encoded into
> references (sometimes called fixnum and flonum);
> ...
> 
> downside:
> may be more awkward to use (depending on details, requiring much added
> manual boxing/unboxing/bookkeeping);
> bit-twiddly and magic numbers.

I don't know what "tagged references" are. On the web, I find few websites, 
and it seems it is the same as templates:

http://lambda-the-ultimate.org/node/2816

So it seems it is parametric polymorphism (see Wikipedia address above).

> using "magic pointers" (where one has a raw pointer, and types are
> identified based on the pointed-to object or memory-address):
> 
> merits:
> can be made fairly easy to use (depending on implementation details,
> dynamic types in C++ can be made to have a "look and feel" almost as if
> one was them in a dynamically-typed language);
> are also relatively C friendly;
> generally much easier to manage than tagged references;
> it is often easier to extend the type-system in an ad-hoc manner;
> may be made cast-compatible with struct or class pointers;
> ...
> 
> downside:
> potentially less efficient and more complex to implement than tagged
> references;
> they are a less well-known strategy;
> generally, fewer bits can be afforded to fixnum and flonum types (mostly
> an issue on 32-bit systems).

I don't know what "magic pointers" are, and I find few answers on the web.
Is there a link with "smart pointers"?

TP

[toc] | [prev] | [next] | [standalone]

#8156

On 7/24/2011 11:15 AM, TP wrote:
> BGB wrote:
>
> Thanks BGB for your answer,
>
>> also, IIRC, Boost may offer something like this, if this is relevant.
>
> As I use Qt, I would like to avoid using Boost.
>

fair enough.


>> but, other potential strategies:
>>
>> using RTTI:
>> merits: reasonably simple and straightforward in C++, meshes well with
>> C++ style, ...
>> downside: depends on classes and is subject to compiler issues (may be
>> disabled by command-line options, or require a command-line option to
>> enable), and may potentially have drawbacks related to overhead, on some
>> systems (namely Windows), it may break violently across arbitrary
>> borders (say, if you make a DLL and then use the DLL from an EXE, the
>> RTTI may not actually work).
>>
>> http://en.wikipedia.org/wiki/RTTI
>
> Reading this page, if I am right, RTTI has an interest only to know which is
> the true class of an object at run time, amongst all the classes in a given
> hierarchy. I am not sure it is applicable to the example I have tried to
> translate (see my answer to Nobody).
> If I am right, the RTTI has an interest in the frame of the "run-time
> polymorphism", also called "subtype polymorphism".
>

RTTI allows dynamic type-checking, which can be useful for implementing 
dynamic typing and/or duck-typing.

generally, the "duck-typing" would be built as a layer on top of RTTI, 
or potentially used in conjunction with abstract base classes.


> http://en.wikipedia.org/wiki/Polymorphism_(computer_science)
>

polymorphism is polymorphism, if plain old polymorphism and inheritance 
works, then use this.

duck-typing generally is conceptually different from polymorphism 
though, as it implies applying an operation to a range of types which 
are not necessarily related (having a common base-class or implementing 
an interface).

if one is using a common base-class though, then it is not duck-typing.


>> using tagged references:
>> merits:
>> may be reasonably efficient;
>> very commonly used in implementing VMs (dominant strategy);
>> relatively C-friendly;
>> integers or floating point values may be directly encoded into
>> references (sometimes called fixnum and flonum);
>> ...
>>
>> downside:
>> may be more awkward to use (depending on details, requiring much added
>> manual boxing/unboxing/bookkeeping);
>> bit-twiddly and magic numbers.
>
> I don't know what "tagged references" are. On the web, I find few websites,
> and it seems it is the same as templates:
>
> http://lambda-the-ultimate.org/node/2816
>
> So it seems it is parametric polymorphism (see Wikipedia address above).
>

how they work and what they do is almost entirely different though.

templates do things at compile-time, and a variable may still only ever 
be a single type, whereas dynamic typing (implemented as tagged 
references) allow a variable to hold any type at runtime.


in this respect, a tagged reference achieves a similar goal to RTTI, but 
differs in its specifics and in terms of how it would be implemented and 
used.


vague, but maybe relevant:
http://en.wikipedia.org/wiki/Tagged_pointer

and, my own server:
http://cr88192.dyndns.org/wiki/index.php/Dynamic_typing


>> using "magic pointers" (where one has a raw pointer, and types are
>> identified based on the pointed-to object or memory-address):
>>
>> merits:
>> can be made fairly easy to use (depending on implementation details,
>> dynamic types in C++ can be made to have a "look and feel" almost as if
>> one was them in a dynamically-typed language);
>> are also relatively C friendly;
>> generally much easier to manage than tagged references;
>> it is often easier to extend the type-system in an ad-hoc manner;
>> may be made cast-compatible with struct or class pointers;
>> ...
>>
>> downside:
>> potentially less efficient and more complex to implement than tagged
>> references;
>> they are a less well-known strategy;
>> generally, fewer bits can be afforded to fixnum and flonum types (mostly
>> an issue on 32-bit systems).
>
> I don't know what "magic pointers" are, and I find few answers on the web.
> Is there a link with "smart pointers"?
>

no, they are unrelated...


at the level of abstraction you seem to be dealing with, a magic pointer 
can be considered as equivalent to a tagged reference (both do about the 
same thing, but internally work very differently).

given the responses/confusion thus far, this may be a bit too much of an 
advanced topic though.

[toc] | [prev] | [next] | [standalone]

#8159

On Sun, 24 Jul 2011 17:40:02 +0200
TP <Tribulations@Paralleles.invalid> wrote:

> Hello,
> 
> I convert a Python/Qt program (PyQt) in C++/Qt.
> The programmer has used the duck typing of Python, thus I would like to have 
> duck typing in C++, in fact exactly what is described in the "best answer" 
> at the following address:
> 
> http://stackoverflow.com/questions/289176/how-is-duck-typing-different-from-
> the-old-variant-type-and-or-interfaces
> 
> (the "best answer" is the second post of the page, the one with a green 
> sign).
> 
> Is it possible in C++?

Well you could create something where you basically stuff your function
pointers into a std::map (similar in use to a hash), then look them up
by name and call them.

This way, the compiler will not be able to tell you if you make a typo.
The call will then fail (i. e. segfault) at runtime. 

If that's what you want...

[toc] | [prev] | [next] | [standalone]

#8160

On 2011-7-24 23:40, TP wrote:
>
> Is it possible in C++?

As other mentioned, you have two methods to do it in C++,

1, Using template. Unlike the real duck typing, the type is
solved at compile time, not at runtime.
But using template maybe hard to implement OOP hierarchy.

2, Using interface. I think this is how duck typing should
be. If an object looks like a duck, walks like a duck,
even it's not a duck, it must have duck behavior, which
is IDuck.
This is easier to implement OOP hierarchy.


-- 
WQ

[toc] | [prev] | [next] | [standalone]

#8217

TP wrote:
> Hello,
>
> I convert a Python/Qt program (PyQt) in C++/Qt.
> The programmer has used the duck typing of Python, thus I would like to have
> duck typing in C++, in fact exactly what is described in the "best answer"
> at the following address:
>
> http://stackoverflow.com/questions/289176/how-is-duck-typing-different-from-
> the-old-variant-type-and-or-interfaces
>
> (the "best answer" is the second post of the page, the one with a green
> sign).
>
> Is it possible in C++?
>
> Thanks in advance,
>
> TP

I've tried just for fun. This is probably a naive
imitation... I just used codepad therefore had
no other libraries (e.g. boost available).

Output:

Duffy quacked!
Donald quacked!

//code...
#include <iostream>
#include <algorithm>

class Duck
{
     struct QuackIF
     {
       virtual void quack() = 0;
       virtual QuackIF* clone() const = 0;
       virtual ~QuackIF(){}
     };

     template <class T>
     struct QuackImpl : QuackIF
     {
       typedef void (T::*QuackFunc)();
       QuackImpl( T& receiver )
       : receiver_( &receiver ),
         f_( &T::quack )
       {
       }
       virtual QuackIF* clone() const
       {
         return new QuackImpl( *this );
       }

       virtual void quack()
       {
         (receiver_->*f_)();//Quack!!!
       }
       virtual ~QuackImpl(){}
       private:
         T* receiver_;
         QuackFunc f_;
     };
     QuackIF* duck_;

     public:
       Duck( const Duck& other )
       : duck_( other.duck_ ? other.duck_->clone() : 0 )
       {
       }
       ~Duck(){ delete duck_; }

       Duck& operator=( Duck other )
       {
         std::swap( other.duck_, duck_ ); return *this;
       }

       template <class DuckT>
       Duck( DuckT* duck )
       : duck_( new QuackImpl<DuckT>( *duck ) )
       {
       }

       void quack()
       {
         if( duck_ ){ duck_->quack(); }
         else
         {
           std::cout << "Quack!" << std::endl;
         }
       }
};

struct Daffy
{
   void quack(){ std::cout << "Duffy quacked!" << std::endl; }
};

struct Donald
{
   void quack(){ std::cout << "Donald quacked!" << std::endl; }
};

int main()
{
   Duck duck = new Daffy;
   duck.quack();
   duck = new Donald;
   duck.quack();
}

[toc] | [prev] | [next] | [standalone]

#8220

On 25/07/2011 22:36, Werner Erasmus wrote:
> TP wrote:
>> Hello,
>>
>> I convert a Python/Qt program (PyQt) in C++/Qt.
>> The programmer has used the duck typing of Python, thus I would like
>> to have
>> duck typing in C++, in fact exactly what is described in the "best
>> answer"
>> at the following address:
>>
>> http://stackoverflow.com/questions/289176/how-is-duck-typing-different-from-
>>
>> the-old-variant-type-and-or-interfaces
>>
>> (the "best answer" is the second post of the page, the one with a green
>> sign).
>>
>> Is it possible in C++?
>>
>> Thanks in advance,
>>
>> TP
>
> I've tried just for fun. This is probably a naive
> imitation... I just used codepad therefore had
> no other libraries (e.g. boost available).
>
> Output:
>
> Duffy quacked!
> Donald quacked!
>
> //code...
> #include <iostream>
> #include <algorithm>
>
> class Duck
> {
> struct QuackIF
> {
> virtual void quack() = 0;
> virtual QuackIF* clone() const = 0;
> virtual ~QuackIF(){}
> };
>
> template <class T>
> struct QuackImpl : QuackIF
> {
> typedef void (T::*QuackFunc)();
> QuackImpl( T& receiver )
> : receiver_( &receiver ),
> f_( &T::quack )
> {
> }
> virtual QuackIF* clone() const
> {
> return new QuackImpl( *this );
> }
>
> virtual void quack()
> {
> (receiver_->*f_)();//Quack!!!
> }
> virtual ~QuackImpl(){}
> private:
> T* receiver_;
> QuackFunc f_;
> };
> QuackIF* duck_;
>
> public:
> Duck( const Duck& other )
> : duck_( other.duck_ ? other.duck_->clone() : 0 )
> {
> }
> ~Duck(){ delete duck_; }
>
> Duck& operator=( Duck other )
> {
> std::swap( other.duck_, duck_ ); return *this;
> }
>
> template <class DuckT>
> Duck( DuckT* duck )
> : duck_( new QuackImpl<DuckT>( *duck ) )
> {
> }
>
> void quack()
> {
> if( duck_ ){ duck_->quack(); }
> else
> {
> std::cout << "Quack!" << std::endl;
> }
> }
> };
>
> struct Daffy
> {
> void quack(){ std::cout << "Duffy quacked!" << std::endl; }
> };
>
> struct Donald
> {
> void quack(){ std::cout << "Donald quacked!" << std::endl; }
> };
>
> int main()
> {
> Duck duck = new Daffy;
> duck.quack();
> duck = new Donald;
> duck.quack();
> }

It is naive yes; spot the memory leaks.  To fix: wrap receiver_ in a 
shared_ptr (so clone still works).

/Leigh

[toc] | [prev] | [next] | [standalone]

#8234

Leigh Johnston wrote:
> On 25/07/2011 22:36, Werner Erasmus wrote:
>> TP wrote:
>>> Hello,
>>>
>>> I convert a Python/Qt program (PyQt) in C++/Qt.
>>> The programmer has used the duck typing of Python, thus I would like
>>> to have
>>> duck typing in C++, in fact exactly what is described in the "best
>>> answer"
>>> at the following address:
>>>
>>> http://stackoverflow.com/questions/289176/how-is-duck-typing-different-from-
>>>
>>>
>>> the-old-variant-type-and-or-interfaces
>>>
>>> (the "best answer" is the second post of the page, the one with a green
>>> sign).
>>>
>>> Is it possible in C++?
>>>
>>> Thanks in advance,
>>>
>>> TP
>>
>> I've tried just for fun. This is probably a naive
>> imitation... I just used codepad therefore had
>> no other libraries (e.g. boost available).
>>
>> Output:
>>
>> Duffy quacked!
>> Donald quacked!
>>
>> //code...
>> #include <iostream>
>> #include <algorithm>
>>
>> class Duck
>> {
>> struct QuackIF
>> {
>> virtual void quack() = 0;
>> virtual QuackIF* clone() const = 0;
>> virtual ~QuackIF(){}
>> };
>>
>> template <class T>
>> struct QuackImpl : QuackIF
>> {
>> typedef void (T::*QuackFunc)();
>> QuackImpl( T& receiver )
>> : receiver_( &receiver ),
>> f_( &T::quack )
>> {
>> }
>> virtual QuackIF* clone() const
>> {
>> return new QuackImpl( *this );
>> }
>>
>> virtual void quack()
>> {
>> (receiver_->*f_)();//Quack!!!
>> }
>> virtual ~QuackImpl(){}
>> private:
>> T* receiver_;
>> QuackFunc f_;
>> };
>> QuackIF* duck_;
>>
>> public:
>> Duck( const Duck& other )
>> : duck_( other.duck_ ? other.duck_->clone() : 0 )
>> {
>> }
>> ~Duck(){ delete duck_; }
>>
>> Duck& operator=( Duck other )
>> {
>> std::swap( other.duck_, duck_ ); return *this;
>> }
>>
>> template <class DuckT>
>> Duck( DuckT* duck )
>> : duck_( new QuackImpl<DuckT>( *duck ) )
>> {
>> }
>>
>> void quack()
>> {
>> if( duck_ ){ duck_->quack(); }
>> else
>> {
>> std::cout << "Quack!" << std::endl;
>> }
>> }
>> };
>>
>> struct Daffy
>> {
>> void quack(){ std::cout << "Duffy quacked!" << std::endl; }
>> };
>>
>> struct Donald
>> {
>> void quack(){ std::cout << "Donald quacked!" << std::endl; }
>> };
>>
>> int main()
>> {
>> Duck duck = new Daffy;
>> duck.quack();
>> duck = new Donald;
>> duck.quack();
>> }
>
> It is naive yes; spot the memory leaks. To fix: wrap receiver_ in a
> shared_ptr (so clone still works).

Yes, receiver_ was never deleted. I did not have a shared_ptr
available (as I used codepad late at night) but just wanted
to work with the idea. Shared_ptr [would] solve the leak.

"Clone" is also not canonical, but everything is private and not
intended for "extension".

Any suggestions to make it easier extensible for other
function names with variable arguments / return types?

Thanks,

Regards,

Werner

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c++

csiph-web