cdiggins@videotron.ca ("christopher diggins") wrote in message news:<f1iic.58740$HF5.903202@wagner.videotron.net>...
> "Amir Yantimirov" <amir@sl.iae.nsk.su> wrote in message
> news:97f98cd5.0404221839.17a4dbe1@posting.google.com...
> > cdiggins@videotron.ca ("christopher diggins") wrote in message
>  news:<R_jhc.7933$Iu5.361406@weber.videotron.net>...
> >
> > > Not the answer I was fishing for, I was trying to lead in to the
>  advantage
> > > of interfaces with regards to savings of vtable pointers within objects.
> > >
> > > To summarize, I believe that interfaces have several significant
>  advantages:
> > > 1) low memory footprint for objects with broad inheritance tree
> > > 2) do not require virtualization of functions for runtime polymorphism
> > > 3) a more appropriate method to model behaves-like and looks-like object
> > > relationships

> > I think 1) and 2) are non-significant.
>
> Any reasons why?

1) The object I use in mass either don't have virtual methods or they
have string fields or other buffered data what makes tiny memory
worries pale.

2) Virtualisation of function is merely default convention for caller.
It is not required for interfaces but still is more elegant solution
for down-calls than any interface-based one I tried to think up.

Amir Yantimirov

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

cdiggins@videotron.ca ("christopher diggins") wrote in message news:<R_jhc.7933$Iu5.361406@weber.videotron.net>...

> Not the answer I was fishing for, I was trying to lead in to the advantage
> of interfaces with regards to savings of vtable pointers within objects.
>
> To summarize, I believe that interfaces have several significant advantages:
> 1) low memory footprint for objects with broad inheritance tree
> 2) do not require virtualization of functions for runtime polymorphism
> 3) a more appropriate method to model behaves-like and looks-like object
> relationships
>
> These advantages together hopefully can cause interfaces to merit
> consideration as a language feature. What would it take for the interface
> proposal to be considered seriously?
>
> Besides an attitude adjustment on my part ;-)
>
> --
> Christopher Diggins
> http://www.cdiggins.com
> http://www.heron-language.com

I think 1) and 2) are non-significant.
And 3) can be much more advantageous if interfaces would behave alike
multimethod closures (in Borland terminology) or delegations (in .Net
terminology). So object don't have to inherit from an interface to be
able to provide it but should have set of corresponding methods only.
http://www174.pair.com/yamir/programming/interfaces.htm

BTW. I can easily imagine how this things can be realised if C++ has
compile-time object model with imperative scripting language alike
javascript.

Amir Yantimirov

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Amir Yantimirov" <amir@sl.iae.nsk.su> wrote in message
news:97f98cd5.0404221839.17a4dbe1@posting.google.com...
> cdiggins@videotron.ca ("christopher diggins") wrote in message
news:<R_jhc.7933$Iu5.361406@weber.videotron.net>...
>
> > Not the answer I was fishing for, I was trying to lead in to the
advantage
> > of interfaces with regards to savings of vtable pointers within objects.
> >
> > To summarize, I believe that interfaces have several significant
advantages:
> > 1) low memory footprint for objects with broad inheritance tree
> > 2) do not require virtualization of functions for runtime polymorphism
> > 3) a more appropriate method to model behaves-like and looks-like object
> > relationships
> >
> > These advantages together hopefully can cause interfaces to merit
> > consideration as a language feature. What would it take for the
interface
> > proposal to be considered seriously?
> >
> > Besides an attitude adjustment on my part ;-)
> >
> I think 1) and 2) are non-significant.

Any reasons why?

> And 3) can be much more advantageous if interfaces would behave alike
> multimethod closures (in Borland terminology) or delegations (in .Net
> terminology). So object don't have to inherit from an interface to be
> able to provide it but should have set of corresponding methods only.
> http://www174.pair.com/yamir/programming/interfaces.htm

I don't suggest that you "inherit from an interface". The proposed
interfaces, along with the HeronFront implementation are both compatible
with any object matching the signature.

> BTW. I can easily imagine how this things can be realised if C++ has
> compile-time object model with imperative scripting language alike
> javascript.

--
Christopher Diggins
http://www.cdiggins.com
http://www.heron-language.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Joe Greer" <jgreer@nsisoftware.com> wrote in message
news:78d8249b.0404150630.2b1f67e7@posting.google.com...
> I think the interface proposal sounds like a good idea.  I don't
> really know that it's going to revolutionize C++ programming, because
> in many circumstances there are already techniques that work well.
>
> What I really like about the idea is that you don't open the object up
> for user modification via virtual functions just to get interface
> capabilities.  This would seem especially useful in extreme
> programming where you often need to model an object for testing and
> then implement it later.  Using one of these interfaces, you could do
> this without introducing an ABC.
>
> joe
> Software Engineer
> NSI Software

I appreciate the support and the extreme programming possibility is a great
idea for me for potential application of HeronFront.

I would be curious though to if you know of any existing techniques which
can make designs like http://www.heron-language.com/abc-example.html useable
in practice (i.e. without bloating the NaiveInt object up to an unacceptable
32 bytes).

--
Christopher Diggins
http://www.cdiggins.com
http://www.heron-language.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

cdiggins@videotron.ca ("christopher diggins") writes:

> I would be curious though to if you know of any existing techniques which
> can make designs like http://www.heron-language.com/abc-example.html useable
> in practice (i.e. without bloating the NaiveInt object up to an unacceptable
> 32 bytes).

Well, that looks like a perfect application of CRTP.  Do you really
want to use (and pay for) runtime polymorphism on something as trivial
as an arithmetic type?  Yes, friends, it's time to accept compile-time
polymorphism as your personal savior.

;-)

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"David Abrahams" <dave@boost-consulting.com> wrote in message
news:ud666enmu.fsf@boost-consulting.com...
> cdiggins@videotron.ca ("christopher diggins") writes:
>
> > I would be curious though to if you know of any existing techniques
which
> > can make designs like http://www.heron-language.com/abc-example.html
useable
> > in practice (i.e. without bloating the NaiveInt object up to an
unacceptable
> > 32 bytes).
>
> Well, that looks like a perfect application of CRTP.  Do you really
> want to use (and pay for) runtime polymorphism on something as trivial
> as an arithmetic type? Yes, friends, it's time to accept compile-time
> polymorphism as your personal savior.

My point is that using interfaces allows for run-time polymorphism without
extra costs on the type when not using it in a polymorphic scenario. I don't
discount the advantages of CRTP in many scenarios, but it is not a complete
replacement for run-time polymorphism.

--
Christopher Diggins
http://www.cdiggins.com
http://www.heron-language.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

cdiggins@videotron.ca ("christopher diggins") writes:

> "David Abrahams" <dave@boost-consulting.com> wrote in message
> news:ud666enmu.fsf@boost-consulting.com...
>> cdiggins@videotron.ca ("christopher diggins") writes:
>>
>> > I would be curious though to if you know of any existing techniques
> which
>> > can make designs like http://www.heron-language.com/abc-example.html
> useable
>> > in practice (i.e. without bloating the NaiveInt object up to an
> unacceptable
>> > 32 bytes).
>>
>> Well, that looks like a perfect application of CRTP.  Do you really
>> want to use (and pay for) runtime polymorphism on something as trivial
>> as an arithmetic type? Yes, friends, it's time to accept compile-time
>> polymorphism as your personal savior.
>
> My point is that using interfaces allows for run-time polymorphism without
> extra costs on the type when not using it in a polymorphic
> scenario.

Oh, I didn't realize you were making that point.  That optimization is
already allowed for concrete classes if the compiler can detect that
you're not using it in a polymorphic way, though doing that detection
may not be so simple.

> I don't discount the advantages of CRTP in many scenarios, but it is
> not a complete replacement for run-time polymorphism.

Right, but are there enough situations where you want to use a single
type in both ways to make it worth a language feature?  I don't know
the answer.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"David Abrahams" <dave@boost-consulting.com> wrote in message
news:uoeppaquj.fsf@boost-consulting.com...
> cdiggins@videotron.ca ("christopher diggins") writes:
>
> > "David Abrahams" <dave@boost-consulting.com> wrote in message
> > news:ud666enmu.fsf@boost-consulting.com...
> >> cdiggins@videotron.ca ("christopher diggins") writes:
> >>
> >> > I would be curious though to if you know of any existing techniques
> > which
> >> > can make designs like http://www.heron-language.com/abc-example.html
> > useable
> >> > in practice (i.e. without bloating the NaiveInt object up to an
> > unacceptable
> >> > 32 bytes).
> >>
> >> Well, that looks like a perfect application of CRTP.  Do you really
> >> want to use (and pay for) runtime polymorphism on something as trivial
> >> as an arithmetic type? Yes, friends, it's time to accept compile-time
> >> polymorphism as your personal savior.
> >
> > My point is that using interfaces allows for run-time polymorphism
without
> > extra costs on the type when not using it in a polymorphic
> > scenario.
>
> Oh, I didn't realize you were making that point.  That optimization is
> already allowed for concrete classes if the compiler can detect that
> you're not using it in a polymorphic way, though doing that detection
> may not be so simple.

I am well aware of the potential for these optimizations. But as I just
pointed out and you acknowledged (!?) we are talking about run-time
polymorphic scenarios.

> > I don't discount the advantages of CRTP in many scenarios, but it is
> > not a complete replacement for run-time polymorphism.
>
> Right, but are there enough situations where you want to use a single
> type in both ways to make it worth a language feature?  I don't know
> the answer.

Haven't you ever avoided using multiple inheritance of abstract base classes
because it would have made your objects too big? That is the other major
advantage of the interface proposal at
http://www.heron-language.com/cpp-iop.html


--
Christopher Diggins
http://www.cdiggins.com
http://www.heron-language.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

cdiggins@videotron.ca ("christopher diggins") writes:

>> > My point is that using interfaces allows for run-time
>> > polymorphism without extra costs on the type when not using it in
>> > a polymorphic scenario.
>>
>> Oh, I didn't realize you were making that point.  That optimization
>> is already allowed for concrete classes if the compiler can detect
>> that you're not using it in a polymorphic way, though doing that
>> detection may not be so simple.
>
> I am well aware of the potential for these optimizations. But as I
> just pointed out and you acknowledged (!?) we are talking about
> run-time polymorphic scenarios.

I haven't stopped talking about those scenarios (?!)

>> > I don't discount the advantages of CRTP in many scenarios, but it is
>> > not a complete replacement for run-time polymorphism.
>>
>> Right, but are there enough situations where you want to use a single
>> type in both ways to make it worth a language feature?  I don't know
>> the answer.
>
> Haven't you ever avoided using multiple inheritance of abstract base classes
> because it would have made your objects too big?

Never.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"David Abrahams" <dave@boost-consulting.com> wrote in message
news:uisfuwavg.fsf@boost-consulting.com...
> cdiggins@videotron.ca ("christopher diggins") writes:
>
> >> > My point is that using interfaces allows for run-time
> >> > polymorphism without extra costs on the type when not using it in
> >> > a polymorphic scenario.
> >>
> >> Oh, I didn't realize you were making that point.  That optimization
> >> is already allowed for concrete classes if the compiler can detect
> >> that you're not using it in a polymorphic way, though doing that
> >> detection may not be so simple.
> >
> > I am well aware of the potential for these optimizations. But as I
> > just pointed out and you acknowledged (!?) we are talking about
> > run-time polymorphic scenarios.
>
> I haven't stopped talking about those scenarios (?!)

My sincere apologies, I misunderstood. The detection of whether a type is
being used is in a polymorphic way is an undecidable problem which is why I
had mistakenly thought you were steering the conversation away from run-time
polymorphism. The tone of my response in hind-sight also was disrespectful
and I apologize for that.

With interfaces you don't have the compiler trying to solve problem of
having to decide whether or not a type is being used polymorphically or not.

> >> > I don't discount the advantages of CRTP in many scenarios, but it is
> >> > not a complete replacement for run-time polymorphism.
> >>
> >> Right, but are there enough situations where you want to use a single
> >> type in both ways to make it worth a language feature?  I don't know
> >> the answer.
> >
> > Haven't you ever avoided using multiple inheritance of abstract base
classes
> > because it would have made your objects too big?
>
> Never.

Not the answer I was fishing for, I was trying to lead in to the advantage
of interfaces with regards to savings of vtable pointers within objects.

To summarize, I believe that interfaces have several significant advantages:
1) low memory footprint for objects with broad inheritance tree
2) do not require virtualization of functions for runtime polymorphism
3) a more appropriate method to model behaves-like and looks-like object
relationships

These advantages together hopefully can cause interfaces to merit
consideration as a language feature. What would it take for the interface
proposal to be considered seriously?

Besides an attitude adjustment on my part ;-)

--
Christopher Diggins
http://www.cdiggins.com
http://www.heron-language.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
news:wGY1VaOFl5eAFw8W@robinton.demon.co.uk...
> In article <cGyec.59693$KE5.914803@weber.videotron.net>, christopher
> diggins <cdiggins@videotron.ca> writes
> >Motivation
> >==========
> >Interface constructs as found in languages like Java are used to model
> >looks-like and behaves-like object relationships. C++ does not support
> >interfaces.
>
> I think I understand where you are coming from, however long before this
> proposal will get serious air-time the work on C++/CLI under ECMA will
> have completed its first iteration. As I understand it, that C++ dialect
> does need an interface concept and so that is where the idea is most
> likely to be developed and tested. Unless your proposal is fully upward
> compatible with C++/CLI it would be unlikely to be considered.
>
> Unfortunately one of the problems with ECMA as a Standards body is that
> its rules preclude making development documents public (something those
> who are so anti the ISO process might note) so it is very hard for those
> who are not part of the liaison between WG21 and TG5 to follow how work
> in TG5 might impact on their proposals. Personally I think that issue is
> far more serious than simply the issue of whether C++/CLI might pre-empt
> WG21 design decisions.

Thank you very much for this information! Any suggestions on avenues I may
pursue, for instance people to contact, that may help my suggestion get
looked at by people making the decisions?

--
Christopher Diggins
http://www.cdiggins.com
http://www.heron-language.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I think the interface proposal sounds like a good idea.  I don't
really know that it's going to revolutionize C++ programming, because
in many circumstances there are already techniques that work well.

What I really like about the idea is that you don't open the object up
for user modification via virtual functions just to get interface
capabilities.  This would seem especially useful in extreme
programming where you often need to model an object for testing and
then implement it later.  Using one of these interfaces, you could do
this without introducing an ABC.

joe
Software Engineer
NSI Software

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Motivation
==========
Interface constructs as found in languages like Java are used to model
looks-like and behaves-like object relationships. C++ does not support
interfaces.

Common Workaround
=================
What is typically used to compensate for this deficiency are abstract base
class (classes with one or more pure virtual functions).

Deficiency of Workaround
========================
The problem of using an ABC as an interface is that it declares the
functions virtual. This is uneccessary and in fact wrong with regards to
most definitions of an interface. This leads to two major practical
problems: performance penalties due to extra vtable lookups and object size
penalties due to extra vtable pointers within the objects. This is
especially troublesome because design models that use interfaces typically
call for multiple interfaces, thus compounding the penalties, and making
many perfectly acceptable designs unusable in practice. (for an example of
the signficant performance penalty of ABC's versus interfaces using a
popular C++ compiler see http://www.heron-language.com/hfront-test.html )

Proposed Solution
=================
Allow declaration of an interface, like a class/struct but with only
function declarations, i.e.:

  interface IFuBar {
    FuBar();
  };

Allow declaration of intent of implementation by a class, i.e.:

  class CFuBar {
    implements: IFuBar;
  };

Allow variables to be declared of type interface reference type i.e.:

CFuBar x;
IFuBar i = &x;

Interface reference types can be constructed and assigned from any object
that implements the named interface, or from any other like-typed interface
reference. Interface references would provide a set of member functions
equivalent to the functions listed in the interface declaration. Interface
references are assignable with the NULL value, and are comparable to NULL.

Proposed Implementation
=======================

An effective implementation of interface references is to use fat pointers
that refer to an object and a function lookup table. The fat pointer
solution implementation compares favourably with ABC's in many scenarios. An
example implemenation that uses the fat pointer approach has been posted at
http://www.heron-language.com/heronfront.html .

Possible Syntax Changes
=======================

Diggins syntax:
interface FuBar { ... }; // to indicate interface declaration
class CFuBar { implements: FuBar; ... }; // indicates class implementing
interface

Barbati syntax (variant 1):
class IFuBar = 0 { ... }; // to indicate interface declaration
class CFuBar : IFuBar { ... }; // indicates class implementing interface

Barbati syntax (variant 2):
virtual class FuBar  { ... }; to indicate interface declaration
class CFuBar : IFuBar { ... }; // indicates class implementing interface

Thanks to Alberto Barbati for his syntax proposals.

Repercussion of Proposal
========================
There are no repercussions to the language above and beyond the syntactic
changes required to allow declaration of interfaces and implementation of
interface.

--
Christopher Diggins
http://www.cdiggins.com
http://www.heron-language.com



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <cGyec.59693$KE5.914803@weber.videotron.net>, christopher
diggins <cdiggins@videotron.ca> writes
>Motivation
>==========
>Interface constructs as found in languages like Java are used to model
>looks-like and behaves-like object relationships. C++ does not support
>interfaces.

I think I understand where you are coming from, however long before this
proposal will get serious air-time the work on C++/CLI under ECMA will
have completed its first iteration. As I understand it, that C++ dialect
does need an interface concept and so that is where the idea is most
likely to be developed and tested. Unless your proposal is fully upward
compatible with C++/CLI it would be unlikely to be considered.

Unfortunately one of the problems with ECMA as a Standards body is that
its rules preclude making development documents public (something those
who are so anti the ISO process might note) so it is very hard for those
who are not part of the liaison between WG21 and TG5 to follow how work
in TG5 might impact on their proposals. Personally I think that issue is
far more serious than simply the issue of whether C++/CLI might pre-empt
WG21 design decisions.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

cdiggins@videotron.ca ("christopher diggins") wrote in message news:<cGyec.59693$KE5.914803@weber.videotron.net>...
> Repercussion of Proposal
> ========================
> There are no repercussions to the language above and beyond the syntactic
> changes required to allow declaration of interfaces and implementation of
> interface.

It seems that the use of fat pointers and references would have some
repercussions. Can fat pointers be converted to ordinary pointers and
vice versa? Example:

interface Foo { /* ... */ };
class Bar { /* ... */ };

class Baz : public Bar, Foo { /* ... */ };

void F(Foo&);
void G(Bar&);

Baz x;

F(x);
G(x);

Are there issues with casting? Example:

void F(Foo& x)
{
   Bar* b = dynamic_cast<Bar*>(&x);
}

Are there repercussions for pointer-to-member types with member
functions of interfaces?

Bob

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

To me this sound like the old signature proposal from 1995.

This got implemented in old GCC's but were dropped since nobody used it.
Templates made this extension redundant for most purposes.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Bob Bell" <belvis@pacbell.net> wrote in message
news:c87c1cfb.0404130854.492544cf@posting.google.com...
> cdiggins@videotron.ca ("christopher diggins") wrote in message
news:<cGyec.59693$KE5.914803@weber.videotron.net>...
> > Repercussion of Proposal
> > ========================
> > There are no repercussions to the language above and beyond the
syntactic
> > changes required to allow declaration of interfaces and implementation
of
> > interface.
>
> It seems that the use of fat pointers and references would have some
> repercussions. Can fat pointers be converted to ordinary pointers and
> vice versa? Example:
[snip]

An ordinary pointer to an object that explicitly implements an interface can
be cast to an interface reference type (the fat pointer) but the other way
is not allowed, in the same way an ABC pointer should not be cast to a
super-class pointer. The interface reference type is not really a pointer,
and only provides to the public the set of expected functions.

> Are there repercussions for pointer-to-member types with member
> functions of interfaces?
[snip]

None that I can forsee.

--
Christopher Diggins
http://www.cdiggins.com
http://www.heron-language.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Magnus Fromreide" <magfr@comp.std.cpp.magfr.user.lysator.liu.se> wrote in
message news:87r7usbbj1.fsf@comp.std.cpp.magfr.user.lysator.liu.se...
> To me this sound like the old signature proposal from 1995.

It is similar.

> This got implemented in old GCC's but were dropped since nobody used it.

Many people didn't use the GCC signatures because it is generally a bad idea
to include compiler specific extensions in code. At the same time, more
people have since learned the advantages of using interfaces thanks to the
proliferation of interface oriented code in Java.

> Templates made this extension redundant for most purposes.

Not true at all. Comparing templates to interfaces is wrong. Interfaces
would be much more accurately compared with ABC's.

--
Christopher Diggins
http://www.cdiggins.com
http://www.heron-language.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]