christopher diggins wrote:
> "Larry Evans" <cppljevans@cox-internet.com> wrote in message
> news:108qi4dc366og23@corp.supernews.com...
[sni]
> There is also the original version at
> http://www.heron-language.com/cpp-iop-example.html which has been linked,
> executed and timed. Is there any reason that using HeronFront to generate
> your interfaces code is unsatisfactory?
>
Not that I know of.  I just haven't tried HeronFront.
Maybe it's time :)

---
[ 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 (abridged):
> There is also the original version at
> http://www.heron-language.com/cpp-iop-example.html which has been
> linked, executed and timed.

It seems more complex than either the others. For example it needs extra
types like DUMMY_ITABLE_IFuBar.

Also, I hadn't thought it was intended to be portable. It uses casts
between unrelated objects. Specifically between the template:

  template<typename SELF> struct ITABLE_IFuBar {
    void(SELF::*Fu)();
    void(SELF::*Bar)();
  };

instantiated on different types. As I understand it, the representation of
a pointer to member function can depend on the type it is a member of. Eg:

    struct A {
        void Foo();
        void Bar();
    };

because we know at compile time that A has only 2 member functions, a void
(A::*pFn)() can be stored in a single bool. If there were 255 more
functions (with the same signature), we'd need 9 bits. So:
    assert( sizeof(ITABLE_IFuBar<A>) == sizeof(ITABLE_IFuBar<A255>) );

may fail. Further, your code uses the objects without casting them back to
their proper types. I had thought your implementation was just to show
proof of concept, not a real, practical solution.


> Is there any reason that using HeronFront to generate
> your interfaces code is unsatisfactory?

Personally I don't think the benefit over standard C++ justifies the more
complex build process.

-- Dave Harris, Nottingham, UK

---
[ 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                       ]

On Mon, 26 Apr 2004 01:40:18 +0000 (UTC), cdiggins@videotron.ca
(Christopher Diggins) wrote:

>My apologies for sounding off earlier. I realize in hindsight that you
>have been genuinely making an effort to help me to get a decent
>proposal together, and that you are not attacking my ideas nor
>character.

Apologies for the unnecessarily derogatory tone of the term
"half-baked"! The idea behind interfaces is in general interesting,
and you've taken it as far as providing an implementation, which is
laudable.

>There has been a change to the proposal relatively recently that you
>have not have taken into account, a type does not explicitly declare
>the interfaces it implements.

Right, I've just checked it out.

>I would then address the ambiguity issue by giving the interface
>conversions precedence just over user defined operators. Without the
>implements declaration this is easier to justify.

Without the implements declaration there seems to be a problem with
the compiler knowing which classes to build function tables for. You
end up with a situation very similar to template instantiation. If a
class->interface conversion is used, the corresponding function table
is "instantiated". This seems to require much the same infrastructure
as template instantiation - function tables from different translation
units should be merged, etc. etc.

>It would seem like a reasonable thing to allow the lifetime extension,
>unless you have some suggestions why this might not be a good thing.

Your new proposal appears to modify interface references away from
pointer semantics and towards reference semantics, which seems to fit
their usage a bit better.

>> const volatile qualified. e.g. can you have:
>>
>> const myinterface myref = foo;
>> myref.bar(); //bar must be a const member function
>>
>> But how do you declare a myinterface reference that can't be modified?
>> e.g.
>>
>> const myinterface myref = foo;
>> myref = bar; //want a compiler error
>>
>> IOW, you can't have be both ways, either const applies to the
>> referenced object or the reference itself.
>
>This is an excellent point. I did in fact take the approach in the
>Heron language of interpreting this to mean both simultaneously,
>though I don't think this would be an acceptable interpretation for
>C++ given its history and current meaning of const. One thing seems
>clear, it would be unacceptable to have interfaces break constness
>implicitly. The path of least resistance may be to have const apply to
>the reference, and never allow an interface to refer to a const
>object. Another solution could be to make an interface reference
>unassignable, hence it is always const.

That seems to be the approach you've taken in the new proposal.

>> This causes other problems:
>>
>> void f(const int);
>> is the same function as
>> void f(int);
>> since top level cv-qualifiers are not part of the type of a function.
>> However,
>> void f(const myinterface);
>> can't realistically be the same type as
>> void f(myinterface);
>> since otherwise you can't have const correctness with interfaces.
>> However, you can see the syntatic inconsistency with the rest of the
>> language. Perhaps an interface reference needs its own denoter. e.g.
>>
>> myinterface^ ref;
>
>This troubles me, because the idea of adding a new denoter alone seems
>enough to get the proposal rejected. The other thing is that we are
>implying that ^ is what makes ref an interface and can be applied to
>any type.

There is already a popular proposal for the next standard that adds a
new denoter (&& denotes an rvalue reference IIRC). See
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1377.htm

Actually, the ^ has already been proposed for "managed references" as
part of the interface between C++ and CLI (a Microsoft extension to
C++). See
http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1557.pdf

So how about "~"? ;)

>> or similar, to avoid confusion (since an interface won't have the
>> usual value or reference semantics - it looks like a pointer with
>> reference syntax to me). Then you can do:
>>
>> myinterface const^ ref; //interface reference to const
>> myinterface^ const ref; //const interface reference to non-const
>>
>> This also impinges on template argument deduction. e.g.
>>
>> template <class T>
>> void (T^ t);
>
>This would imply incorrectly that any type can be treated as an
>interface.

Perhaps you'd need:

template <interface T>
void f(T^ t);

Still, it would still be synonymous to some other situations:

template <class T>
void f(T& t); //T can be any type *except* a reference.

>
>> Or, without the ^, how would you declare a template that took any
>> interface reference?
>
>To this one point I would suggest:
>template<interface T> void(T t);

That looks better, yes. It does bring up the old thing of:

template<struct T>
vs
template<class T>
vs
template<union T>

that has been discussed before. "class T" doesn't mean any class T,
but any type T that works with the rest of the template. Introducing
interface as a template parameter denoter might open a can of worms.

>> >Via "." (using -> would imply that a struct can be dereferenced and that
>> >*interface_reference has meaning). I don't see any affect on the rest of the
>> >language.
>>
>> Syntatically you are making your interface reference like a value or
>> reference, but semantically it operates much more like a pointer. This
>> might be confusing to some (it does the same things as Java - call a
>> pointer a reference, although Java gives the game away with the "null
>> pointer exception"!).
>
>I don't see how the interface reference is semantically like a pointer
>more than it is like a reference.

In the new proposal it isn't. But in the old proposal it could be
assigned to, and converting to an interface reference was conceptually
similar to taking the address of your variable (i.e. you seemed to
need an lvalue). With the changes, you've gone down the reference
semantics route.

If you were to go for pointer semantics instead, you would have to
consider memory management (how would one manage the lifetime of the
referenced object). One possibility would be to allow optional garbage
collection!

>> >> Lvalue
>> >> Can you obtain an lvalue referring to the original object from an
>> >> interface reference. e.g. is "*reference" valid?
>> >
>> >No.
>>
>> How about with dynamic_cast? e.g.
>>
>> dynamic_cast<Foo&>(myref) = Foo(5);
>
>I do think this should be allowed though.

Yes, it should.

>I wish to again express my apologies for flying off the handle, and my
>gratitude for bringing up intelligent and insightful responses to my
>post.

My apologies for causing you to fly off the handle! I have a few more
comments from your new proposal...

>  SomeInterface i = x;
>Interpretation of the above statement:
>if x is a pointer to a class or struct then i stores internally
>the value of x

Is this necessary? How about just:

A* p;
MyInterface i = *p;

and avoid giving pointers any special treatment?

>Interface Comparison
>An interface variable can be compared using == to another interface
>variable with the result being equivalent to a comparison of the
>internal object pointers.

Are those pointers compared in a typesafe manner, or as pointers
converted to void*? e.g.

B b;
A& aref = b;
I ib = b;
I ia = aref;

assert (ib == ia);

Does the assertion above always succeed, regardless of the inheritence
relation (multiple, virtual, etc.) between A and B? Note that
(void*)&b and (void*)&aref won't necessarily be equal.

>Interface Arguments to Template Parameters
>Parameters to templates can be restricted to only interface types
>through the following syntax:
>  template<interface argument_name> // ...

As mentioned above, I'm slightly wary of this, but without an
interface reference denoter, I can't think of an alternative solution.

>Visibility Modifiers
>All interfaces functions are always public therefore no visibility
>modifers are allowed.

When assigning to an interface reference, do the signature functions
of the class in question have to be public, or just accessible. e.g.

interface I
{
  void f();
};

class A
{
public:
  I getI()
  {
    return *this; //f is accessible here
    //so here A *is-a* I, isn't it?
  }

private:
  void f();
};

The above might allow some nice idioms.

On a more general note, there's only one place in C++ where I've seen
wide inheritence heirarchies: in the Visitable and similar classes
generated by the Loki library. (This is described in the book Modern
C++ Design - http://www.moderncppdesign.com/ well worth buying if you
haven't already). I'd be interested to see whether your interfaces
would allow usage of these heirarchy generation algorithms with much
less code bloat than is currently available, by using non-virtual
functions and interfaces. My guess is that they probably would help.

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

---
[ 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                       ]

cppljevans@cox-internet.com (Larry Evans) wrote (abridged):
> I was thinking of using David Abraham's code as posted at:
>
> http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&group=co
> mp.std.c%2B%2B&selm=8a638f47.0404250644.438ff224%40posting.google.com
>
> but while I was trying to understand it, I see yours might be better.
> Could you or David provide a comparison for others that might need
> to decide between the two?

His uses pointers to member functions. I expect that saves a level of
indirection, so it might be faster. However, it needs a bit more code
to initialise the table - he has:

    template <class T>
    baz::table const
    baz::functions<T>::table = {
        &baz::functions<T>::foo
      , &baz::functions<T>::bar
    };

which I don't need. I think mine is more straightforward, slightly
higher level as a result. Apart from that they are very similar.

He makes his functions template a private member, which I think makes
it harder to allow a binding which uses non-member functions -
something I especially wanted to provide.

I tried to factor out some of the code into a reusable library class,
to minimise the work of creating a new kind of interface without
using macros. He seems to have some macro magic in mind - I wouldn't
have thought it was possible, and anyway I dislike macros.

-- Dave Harris, Nottingham, UK

---
[ 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 (abridged):
> If an interface is indeed a special case of a delegation could
> you demonstrate how you could use a delegation in order to implement
> the interfaces proposal fully?

See the implementation I posted earlier. It revolves around code like:

        void stringify( ostream &out ) {
            pVTable->stringify( self, out );
        }

which is what I meant by "delegation". It is not simple because the
self member variable is inserted into the parameter list. It's the
kind of thing which would be easier with the code rewriting tools
of Dylan or Lisp.


> If we had interfaces then wouldn't it make it easier to introduce a
> delegation mechanism akin to:
>
> class some_class : public Delegator<some_interface, member_variable>
> {
>    // ...
>    some_type member_variable;
>    // ...
> };

I don't see how the delegation mechanism would be any easier than
with abstract base classes.

-- Dave Harris, Nottingham, UK

---
[ 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                       ]

"Larry Evans" <cppljevans@cox-internet.com> wrote in message
news:108qi4dc366og23@corp.supernews.com...
> Dave Harris wrote:
> [snip]
>
> >Here is my current version of the code without language changes. (This
has
> >been compiled with http://www.comeaucomputing.com/tryitout/ but not
linked
> >or executed.)
> >
> >
> >
> I was thinking of using David Abraham's code as posted at:
>
>
http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&group=comp.std.c%2B%2B&selm=8a638f47.0404250644.438ff224%40posting.google.com
>
> but while I was trying to understand it, I see yours might be better.
> Could you
> or David provide a comparison for others that might need to decide
> between the two?


There is also the original version at
http://www.heron-language.com/cpp-iop-example.html which has been linked,
executed and timed. Is there any reason that using HeronFront to generate
your interfaces code is unsatisfactory?

--
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                       ]

===================================== MODERATOR'S COMMENT:
 Approved with reservations.  Please consider this subthread closed.


===================================== END OF MODERATOR'S COMMENT
tom_usenet@hotmail.com (tom_usenet) wrote in message news:<mjgc80d8je1jb0lf2d4kl85n3ml9tm6h5k@4ax.com>...
> On Tue, 20 Apr 2004 18:02:54 +0000 (UTC), cdiggins@videotron.ca
> ("christopher diggins") wrote:
> >"tom_usenet" <tom_usenet@hotmail.com> wrote in message
[snip]
> It is *much* more work that defining a type in the standard library -
> it is a language modification, and to get it seriously considered, it
> can't be half-baked. You need to consider how to integrate it properly
> into the language, not how to write a quick hack to get it working for
> your heron front end.

My goal is to generate some interest and find a proponent or two
before I spend my time and energy to make a full and complete language
proposal. If there is no interest, then there is no point in working
out the time intensive yet relatively insignificant details. Your
implication that my proposal is "half-baked" and simply "a quick hack"
is an insult.

Christopher Diggins
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                       ]

bop@gmb.dk ("Bo Persson") wrote (abridged):
> When you have a operations like string formatting and an ostream access,
> what difference does a single virtual call make??

I think space efficiency is an issue here. If we have a class like:

    struct Point {
        int x;
        int y;
        void stringify(ostream& out);
    };

then making stringify virtual will probably increase sizeof(Point) by
50%.

Moving the polymorphism support into the pointer class lets the
individual objects be smaller. It also potentially lets you be less
intrusive, require less from Point. It would be nice if interfaces
could work with something like:

    struct Point {
        int x;
        int y;
    };
    void stringify(ostream& out, const Point &p);

where stringify is not only not virtual, but not even a member
function. Or even:

    interface Stringable {
        void stringify(ostream& out);
    };

    inline void output(ostream& out, Stringable s){
        s.stringify(out);
    }

    void stringify(ostream& out, int i);

    int i = 0;
    Stringable s( &i );
    output( cout, s );

Allowing us to use dynamic polymorphism with int. This can be done
within the current language, but it's a bit clumsy. It feels like it
should be possible to produce a library solution for which the user
code looks like:

    #include "Interface.h"

    struct Stringable_ {
        virtual void stringify( ostream &out ) = 0;
    };
    typedef Interface<Stringable_> Stringable;

    inline void output( ostream &out, Stringable s ) {
        s.stringify(out);
    }

    template <>
    struct Implements<Stringable, int> {
        static void stringify( int i, ostream &os ) {
            os << i;
        }
    };

where Stringable_ declares the functions we want the interface to have
and Implements declares a binding to concrete classes. The problem is
that we need delegating functions, and it's hard to generate them
automatically.

In my view, any language extensions in this area should focus on
making delegation easier. Interfaces should be just a special case
of that.

-- Dave Harris, Nottingham, UK

---
[ 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                       ]

brangdon@cix.co.uk (Dave Harris) wrote in message news:<memo.20040424132625.1156B@brangdon.m>...
> bop@gmb.dk ("Bo Persson") wrote (abridged):
> > When you have a operations like string formatting and an ostream access,
> > what difference does a single virtual call make??
>
> I think space efficiency is an issue here. If we have a class like:
>
>     struct Point {
>         int x;
>         int y;
>         void stringify(ostream& out);
>     };
>
> then making stringify virtual will probably increase sizeof(Point) by
> 50%.
>
> Moving the polymorphism support into the pointer class lets the
> individual objects be smaller. It also potentially lets you be less
> intrusive, require less from Point. It would be nice if interfaces
> could work with something like:
>
>     struct Point {
>         int x;
>         int y;
>     };
>     void stringify(ostream& out, const Point &p);
>
> where stringify is not only not virtual, but not even a member
> function.

You can do something like this with templates:

// interface:

template<typename T>
void stringify(ostream& out, const T& obj); // no implementation

// usage:

template<>
void stringify<Point>(ostream& out, const Point& obj)
{
   /* ... */
}

template<typename T>
void output(ostream& out, const T& obj)
{
   stringify(out, obj);
}

Point pt;

output(std::cout, pt);

Because there is no default implementation of stringify(), the code
fails to compile unless a user provides an implementation.

> Or even:
>
>     interface Stringable {
>         void stringify(ostream& out);
>     };
>
>     inline void output(ostream& out, Stringable s){
>         s.stringify(out);
>     }
>
>     void stringify(ostream& out, int i);
>
>     int i = 0;
>     Stringable s( &i );
>     output( cout, s );
>
> Allowing us to use dynamic polymorphism with int. This can be done
> within the current language, but it's a bit clumsy. It feels like it
> should be possible to produce a library solution for which the user
> code looks like:
>
>     #include "Interface.h"
>
>     struct Stringable_ {
>         virtual void stringify( ostream &out ) = 0;
>     };
>     typedef Interface<Stringable_> Stringable;
>
>     inline void output( ostream &out, Stringable s ) {
>         s.stringify(out);
>     }
>
>     template <>
>     struct Implements<Stringable, int> {
>         static void stringify( int i, ostream &os ) {
>             os << i;
>         }
>     };
>
> where Stringable_ declares the functions we want the interface to have
> and Implements declares a binding to concrete classes. The problem is
> that we need delegating functions, and it's hard to generate them
> automatically.

It's a little harded to satisfy this one, but how about something like
this?

// interface:
// any type T must provide a member function like
// void T::stringify(ostream&) const;

template<typename T>
class Stringable {
   public:
      static void stringify(ostream& out, const T& obj)
         { obj.stringinfy(out); }
};

// usage:

template<typename T>
void output(ostream& out, const T& obj)
{
   Stringable<T>::stringify(out, obj);
}

struct Point2 {
   int x, y;
   void stringify(ostream& out) const;
};

struct Point3 {
   int x, y, z;
   void stringify(ostream& out) const;
};

Point2 pt2;
Point3 pt3;

output(std::cout, pt2);
output(std::cout, pt3);

> In my view, any language extensions in this area should focus on
> making delegation easier. Interfaces should be just a special case
> of that.

I agree that delegation support would be an interesting addition to
the language. However, how do you think these templates do as far as
satisfying the goals of the proposal? Do template tricks like these go
far enough, or is a language change needed?

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                       ]

""Steven T. Hatton"" <hattons@globalsymmetry.com> wrote in message
news:tPWdncB_3Lu9gRTdRVn-ig@speakeasy.net...
>
> /*------------------ begin excerpt -------------------*/
> 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 ).


Yes but an interface class means providing no member function implementtions
in this class, but to all derived classes and thus virtual functions is very
nice default.

If he wants to provide an interface with no virtual member functions (which
means no real use of interface pointers), he can define a class with no
virual functions. Nice and simple:

class interface
{
 // ...
 public:
 void somefun() const {}
 void some_other_fun(int) {}
// ...
};


class someclass: public base, public interface
{
 // ...
 public:
 void somefun() const { /* ... */ }
 void some_other_fun(int) { /* ... */ }
 // ...
};






Ioannis Vranos

---
[ 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                       ]

My apologies for sounding off earlier. I realize in hindsight that you
have been genuinely making an effort to help me to get a decent
proposal together, and that you are not attacking my ideas nor
character.

There has been a change to the proposal relatively recently that you
have not have taken into account, a type does not explicitly declare
the interfaces it implements.

tom_usenet@hotmail.com (tom_usenet) wrote in message news:<mjgc80d8je1jb0lf2d4kl85n3ml9tm6h5k@4ax.com>...
> On Tue, 20 Apr 2004 18:02:54 +0000 (UTC), cdiggins@videotron.ca
> ("christopher diggins") wrote:
[snip]
>  The interface reference
> >type is simply a struct with a set of public functions, and is assignable
> >and constructible from any interface reference of the same type, or any
> >object which corresponds to the same signature.
>
> A interface reference may be implemented as a struct with a set of
> public functions in your front end, but that isn't what it *is*, or at
> least what it should be were it to be formally added to C++.

I fully agree. The rationale for the statement was that the proposal
should behave very closely to the current implementation as a struct,
with several exceptions.

> >> Overloading
> >> How does the object->interface conversion rank in overload resolution?
> >
> >Whereever object->struct conversions rank.
>
> What is an "object->struct" conversion? Do you mean derived->base? Or
> a user defined conversion (e.g. operator std::string())?

I do mean a user defined conversion, but I stand corrected by your
example, see below.

> If you mean the latter, that will produce surprising results. e.g.
>
> interface myinterface{};
>
> void f(myinterface i);
> void f(int c);
>
> class Foo: public myinterface
> {
> public:
>   operator int() const;
> };
>
> Foo foo;
>
> f(foo); //what does this call?
>
> With your suggestion above, it will be ambiguous, but clearly the
> interface version should be called.

I would then address the ambiguity issue by giving the interface
conversions precedence just over user defined operators. Without the
implements declaration this is easier to justify.

> >> Conversions
> >> Can you convert all of A*, A& and A to an interface reference that A
> >> implements? Or which ones?
> >
> >A, A& and A* only if you dereference it.
>
> Does an interface reference extend the lifetime of a temporary as
> normal references do? e.g.
>
> myinterface i = Foo(); //can you assign an rvalue to it?
> //or const myinterface i = Foo(); if it works similarly to normal
> //references
> i.f(); //is this legal - does the temporary Foo still exist?

It would seem like a reasonable thing to allow the lifetime extension,
unless you have some suggestions why this might not be a good thing.

> >> Non-type template parameters
> >> Can an interface reference be a non-type template parameter (as a
> >> pointer and reference can)? If not, why not?
> >
> >I am not sure I understand this question. If you mean something like :
> >template<typename T*> class FuBar() { ... }; Then I would have to say no,
> >because an interface is not a classification of type but a type in of
> >itself.
>
> This is legal:
>
> class Foo{} foo;
>
> template <Foo& f>
> class FooRef
> {
> };
>
> FooRef<foo> f;
>
> Is:
>
> interface I{};
> class Foo: public I{} foo;
> template <I i>
> class FooRef
> {
> };
> FooRef<foo> f;
>
> legal? It is analagous to the normal reference version.

I would say no. I do not see the Foo->I type conversion as being
analagous to inheritance, I see it as being a kind of built-in user
defined conversion. This is one of the reasons for having removed the
": interface" implementation declarations.

> >> References and pointers
> >> Can you have a reference to an "interface reference"? A pointer?
> >
> >Yes.
> >
> >> Interface reference semantics
> >> Is there a default value for an interface reference (i.e. is there a
> >> "default constructor" that initializes it to null)? Can it be cv
> >> qualified?
> >
> >To the first part: I would personally implement it as so, but in keeping
> >with the tradition of C++ it wouldn't be. What is cv qualified?
>
> const volatile qualified. e.g. can you have:
>
> const myinterface myref = foo;
> myref.bar(); //bar must be a const member function
>
> But how do you declare a myinterface reference that can't be modified?
> e.g.
>
> const myinterface myref = foo;
> myref = bar; //want a compiler error
>
> IOW, you can't have be both ways, either const applies to the
> referenced object or the reference itself.

This is an excellent point. I did in fact take the approach in the
Heron language of interpreting this to mean both simultaneously,
though I don't think this would be an acceptable interpretation for
C++ given its history and current meaning of const. One thing seems
clear, it would be unacceptable to have interfaces break constness
implicitly. The path of least resistance may be to have const apply to
the reference, and never allow an interface to refer to a const
object. Another solution could be to make an interface reference
unassignable, hence it is always const.

> This causes other problems:
>
> void f(const int);
> is the same function as
> void f(int);
> since top level cv-qualifiers are not part of the type of a function.
> However,
> void f(const myinterface);
> can't realistically be the same type as
> void f(myinterface);
> since otherwise you can't have const correctness with interfaces.
> However, you can see the syntatic inconsistency with the rest of the
> language. Perhaps an interface reference needs its own denoter. e.g.
>
> myinterface^ ref;

This troubles me, because the idea of adding a new denoter alone seems
enough to get the proposal rejected. The other thing is that we are
implying that ^ is what makes ref an interface and can be applied to
any type.

> or similar, to avoid confusion (since an interface won't have the
> usual value or reference semantics - it looks like a pointer with
> reference syntax to me). Then you can do:
>
> myinterface const^ ref; //interface reference to const
> myinterface^ const ref; //const interface reference to non-const
>
> This also impinges on template argument deduction. e.g.
>
> template <class T>
> void (T^ t);

This would imply incorrectly that any type can be treated as an
interface.

> Or, without the ^, how would you declare a template that took any
> interface reference?

To this one point I would suggest:
template<interface T> void(T t);

> >> dynamic_cast
> >> How do interface references interact with dynamic_cast? Can you
> >> dynamic_cast to an interface type? From an interface object?
> >
> >Yes.
> >
> >> syntax
> >> How do you call a member through an interface reference? Via "." or
> >> "->"? How does this fit in with the other semantics and syntax, and
> >> the rest of the language?
> >
> >Via "." (using -> would imply that a struct can be dereferenced and that
> >*interface_reference has meaning). I don't see any affect on the rest of the
> >language.
>
> Syntatically you are making your interface reference like a value or
> reference, but semantically it operates much more like a pointer. This
> might be confusing to some (it does the same things as Java - call a
> pointer a reference, although Java gives the game away with the "null
> pointer exception"!).

I don't see how the interface reference is semantically like a pointer
more than it is like a reference.

> >> Lvalue
> >> Can you obtain an lvalue referring to the original object from an
> >> interface reference. e.g. is "*reference" valid?
> >
> >No.
>
> How about with dynamic_cast? e.g.
>
> dynamic_cast<Foo&>(myref) = Foo(5);

I do think this should be allowed though.

I wish to again express my apologies for flying off the handle, and my
gratitude for bringing up intelligent and insightful responses to my
post.

Christopher Diggins

---
[ 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                       ]

""Steven T. Hatton"" <hattons@globalsymmetry.com> wrote in message
news:tPWdncB_3Lu9gRTdRVn-ig@speakeasy.net...
>
> /*------------------ begin excerpt -------------------*/
> 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 ).


Yes but an interface class means providing no member function implementtions
in this class, but to all derived classes and thus virtual functions is very
nice default.

If he wants to provide an interface with no virtual member functions (which
means no real use of interface pointers), he can define a class with no
virual functions. Nice and simple:

class interface
{
 // ...
 public:
 void somefun() const {}
 void some_other_fun(int) {}
// ...
};


class someclass: public base, public interface
{
 // ...
 public:
 void somefun() const { /* ... */ }
 void some_other_fun(int) { /* ... */ }
 // ...
};






Ioannis Vranos

---
[ 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                       ]

""Steven T. Hatton"" <hattons@globalsymmetry.com> wrote in message
news:tPWdncB_3Lu9gRTdRVn-ig@speakeasy.net...
>
> /*------------------ begin excerpt -------------------*/
> 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 ).


Yes but an interface class means providing no member function implementtions
in this class, but to all derived classes and thus virtual functions is very
nice default.

If he wants to provide an interface with no virtual member functions (which
means no real use of interface pointers), he can define a class with no
virual functions. Nice and simple:

class interface
{
 // ...
 public:
 void somefun() const {}
 void some_other_fun(int) {}
// ...
};


class someclass: public base, public interface
{
 // ...
 public:
 void somefun() const { /* ... */ }
 void some_other_fun(int) { /* ... */ }
 // ...
};






Ioannis Vranos

---
[ 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                       ]

""Steven T. Hatton"" <hattons@globalsymmetry.com> wrote in message
news:tPWdncB_3Lu9gRTdRVn-ig@speakeasy.net...
>
> /*------------------ begin excerpt -------------------*/
> 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 ).


Yes but an interface class means providing no member function implementtions
in this class, but to all derived classes and thus virtual functions is very
nice default.

If he wants to provide an interface with no virtual member functions (which
means no real use of interface pointers), he can define a class with no
virual functions. Nice and simple:

class interface
{
 // ...
 public:
 void somefun() const {}
 void some_other_fun(int) {}
// ...
};


class someclass: public base, public interface
{
 // ...
 public:
 void somefun() const { /* ... */ }
 void some_other_fun(int) { /* ... */ }
 // ...
};






Ioannis Vranos

---
[ 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                       ]

""Ioannis Vranos"" <ivr@guesswh.at.emails.ru> wrote in message
news:c6ctii$2mn2$1@ulysses.noc.ntua.gr...
> ""Steven T. Hatton"" <hattons@globalsymmetry.com> wrote in message
> news:tPWdncB_3Lu9gRTdRVn-ig@speakeasy.net...
> >
> > /*------------------ begin excerpt -------------------*/
> > 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 ).
>
>
> Yes but an interface class means providing no member function
implementtions
> in this class, but to all derived classes and thus virtual functions is
very
> nice default.
>
> If he wants to provide an interface with no virtual member functions
(which
> means no real use of interface pointers), he can define a class with no
> virual functions. Nice and simple:
>
> class interface
> {
>  // ...
>  public:
>  void somefun() const {}
>  void some_other_fun(int) {}
> // ...
> };
>
>
> class someclass: public base, public interface
> {
>  // ...
>  public:
>  void somefun() const { /* ... */ }
>  void some_other_fun(int) { /* ... */ }
>  // ...
> };


There is a difference between dynamic dispatch and virtual functions. As per
 your example:

someclass c;
interface& i = c;
i.somefun(); // would call interfaces::somefun() which is a no-op.

An interface pointer as per the proposal would allow the following code:

interface someinterface {
    void somefun() const;
};

class someclass
{
    // ...
    public:
    void somefun() const { std::cout << "base somefun" << std::endl; }
    // ...
};

class somederivedclass : public someclass
{
    // ...
    public:
    void somefun() const { std::cout << "derived somefun" << std::endl;  }
    // ...
};

// ...
somederivedclass derived
someclass& base = derived;
SomeInterface i = base;
i.somefun(); // calls someclass::somefun() and outputs "base somefun"
// ...

So this dispatches to the correct function, but binds to the function
version according to
the type given. Notice though that if you do really want virtual functions,
the following works perfectly well.

class someclass2
{
    // ...
    public:
    virtual void somefun() const { std::cout << "base somefun" <<
std::endl; }
    // ...
};

class somederivedclass2 : public someclass2
{
    // ...
    public:
    virtual void somefun() const { std::cout << "derived somefun" <<
std::endl;  }
    // ...
};

// ...
somederivedclass2 derived;
someclass2& base = derived;
someinterface i = base;
i.somefun(); // runtime at runtime to somederivedclass2::somefun so outputs
"derived somefun"
// ...

I hope this makes the intention of the proposal more clear.

--
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                       ]

"Dave Harris" <brangdon@cix.co.uk> wrote in message
news:memo.20040424132625.1156B@brangdon.m...
> bop@gmb.dk ("Bo Persson") wrote (abridged):
[snip]
> where Stringable_ declares the functions we want the interface to have
> and Implements declares a binding to concrete classes. The problem is
> that we need delegating functions, and it's hard to generate them
> automatically.
>
> In my view, any language extensions in this area should focus on
> making delegation easier. Interfaces should be just a special case
> of that.

It seems to me, just the opposite, that delegation would be easier to
introduce if you already have a concept of interfaces. If an interface is
indeed a special case of a delegation could you demonstrate how you could
use a delegation in order to implement the interfaces proposal fully?

If we had interfaces then wouldn't it make it easier to introduce a
delegation mechanism akin to:

class some_class : public Delegator<some_interface, member_variable>
{
   // ...
   some_type member_variable;
   // ...
};

or perhaps:

class some_class
{
    // ...
    some_type member_variable;
    DELEGATE_MACRO(some_interface, member_variable);
    // ...

};


--
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                       ]

belvis@pacbell.net (Bob Bell) wrote (abridged):
> I agree that delegation support would be an interesting addition to
> the language. However, how do you think these templates do as far as
> satisfying the goals of the proposal?

I don't think they do. As I understand it, the proposal is supposed
to provide dynamic polymorphism. Your templates only provide compile-
time polymorphism. Also, you haven't shown how to support int in
your last one. See below for the kind of infrastructure I think is
needed.


> Do template tricks like these go far enough, or is a language
> change needed?

I think, as I said, that delegation is at the root of the problem. This
kind of external polymorphism won't become popular until the language is
changed to better support delegation. Whether the change is needed depends
partly on whether this is a style of programming we want to encourage.

Here is my current version of the code without language changes. (This has
been compiled with http://www.comeaucomputing.com/tryitout/ but not linked
or executed.)

    ////////////////////////////////////////////////////////////////
    // Library support.

    // Forward declare concrete vtable implementation.
    // There will be a specialisation for every Self type.
    template <typename Self, typename AbstractVTable>
    struct VTable;

    // Base class for interfaces.
    template <typename AbstractVTable>
    struct Interface {
        // Templated constructor with shared, static vtable.
        template <typename Self>
        Interface( Self *self ) {
            static VTable<Self,AbstractVTable> selfBinding;
            this->self = reinterpret_cast<void *>(self);
            this->pVTable = &selfBinding;
        }

    protected:
        ~Interface() {
        }

        void *self;
        AbstractVTable *pVTable;
    };

    ////////////////////////////////////////////////////////////////
    // User code to declare Stringable interface.

    #include <ostream>
    using namespace std;

    // Declare the Stringable functions.
    struct StringableVTable {
        virtual void stringify( void *self, ostream &out ) = 0;
    };

    // The interface class itself. It inherits two pointers. It is a
    // concrete type with no virtual functions.
    struct Stringable : Interface<StringableVTable> {
        // Templated constructor.
        template <typename Self>
        Stringable( Self *self ) : Interface<StringableVTable>( self ) {
        }

        // First forwarding function.
        void stringify( ostream &out ) {
            pVTable->stringify( self, out );
        }
    };

    // Default binding, to member functions.
    template <typename Self>
    struct VTable<Self,StringableVTable> : StringableVTable {
        // Second forwarding function.
        virtual void stringify( void *self, ostream &out ) {
             reinterpret_cast<Self *>( self )->stringify( out );
        }
    };

    ////////////////////////////////////////////////////////////////
    // User code for uses of Stringable.

    // An example class. It has a member function so it uses the
    // default interface.
    struct Point {
        int x, y;
        Point() : x(0), y(0) {}
        void stringify( ostream &out ) {
            out << x << "," << y;
        }
    };

    // A binding of Stringable to int. We need this because int
    // does not have the necessary member function.
    template <>
    struct VTable<int,StringableVTable> : StringableVTable {
        virtual void stringify( void *self, ostream &out ) {
            int *i = reinterpret_cast<int *>( self );
            out << *i;
        }
    };

    // Example of use of the interface, Stringable.
    // Note this is /not/ a template. It uses dynamic
    // polymorphism.
    inline void output( ostream &out, Stringable s ){
        s.stringify( out );
    }

    // Example invoking the interface.
    void demo() {
        Point p;
        Stringable s( &p );
        output( cout, s );
        int i = 0;
        s = Stringable( &i );
        output( cout, s );

    }
If we just want it for occasional use, or in a few key places, the above
isn't too bad. Declaring the Stringable interface takes 3 classes instead
of 1, and we have to write casts by hand. Most of the extra code is the
delegating functions.

Using the interface takes no extra code if the pointed-to type has the
right member functions already. If not, we have to write an adaptor, as I
did with int. If that is a common case we can make it easier with some
kind of traits template.

-- Dave Harris, Nottingham, UK

---
[ 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                       ]

Dave Harris wrote:
[snip]

>Here is my current version of the code without language changes. (This has
>been compiled with http://www.comeaucomputing.com/tryitout/ but not linked
>or executed.)
>
>
>
I was thinking of using David Abraham's code as posted at:

http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&group=comp.std.c%2B%2B&selm=8a638f47.0404250644.438ff224%40posting.google.com

but while I was trying to understand it, I see yours might be better.
Could you
or David provide a comparison for others that might need to decide
between the two?

TIA

---
[ 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                       ]

Ioannis Vranos wrote:

> I haven't seen your previous interface proposals, why do we need an
> interface in C++ since it already supports multiple inheritance?
> Interfaces are a workaround for the lack of multiple inheritance support.
> If you want to use interfaces in your C++ programs you can do:

There are some problems with MI Christopher actually addresses these in his
proposal documents.  I don't have a strong enough background in C++ to
evaluate the details of his arguments, and consider alternatives.  It does
seem fair to him that we take a bit of time to examine his work before we
challenge his proposal.  This is what I found on his page:

http://www.heron-language.com/cpp-iop.html

/*------------------ begin excerpt -------------------*/
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 ).

/*------------------ end excerpt -------------------*/


I'm staying neutral regarding the assertion that ABCs aren't proper
interfaces.

My questions are these:

What happens if I want to extend a class that implements his interface?  My
understanding it the implementation of the interface is 'final', and cannot
be overridden in a derived class.

Is the interface inherited by derived classes of implementing classes.  IOW,
can I use the derived class everywhere I could use the interface. (Assuming
the overriding in the previous item is not an issue.)

Are there any diamond DAG problems?  I.e., what happens when two classes
derive from the same implementing class, and a third derives from the first
two derived classes?

Can the same thing be accomplished with a purely template approach.  This
seems to be answered by Christophers example of generated code.  It's
templates, alright, and you're welcome to write them by hand if you like. I
kind of like the idea of the computer doing that for me.

Could the same thing be accomplished simply by having the compiler compare
the signature of an implementing class to that of an interface without
actually creating any extra runtime residue?  That is, treat the interface
as a contract that the compiler verifies for all implementing classes.  As
long as conformance is verified, no matter if it's through inheritance,
hiding, or local definition, the interface is considered implemented, and
the code is compiled as if there were no interface.

Can interfaces implement interfaces?

This is an example of an ABC interface approach I'm playing with:

  /**
     ABC Interface: Implementing classes can be passed to operator<<()
   */
  class Stringable {
  public:
    virtual void stringify(ostream& out)=0;
  };

  /**
    stringifies an object implementing Stringable onto the ostream;
  */
  inline ostream& operator<<(ostream& out, Stringable& s){
    s.stringify(out);
  }

How would this be implemented as an HF interface?
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ 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                       ]

""Steven T. Hatton"" <hattons@globalsymmetry.com> wrote in message
news:tPWdncB_3Lu9gRTdRVn-ig@speakeasy.net...
> Ioannis Vranos wrote:
>
> > I haven't seen your previous interface proposals, why do we need an
> > interface in C++ since it already supports multiple inheritance?
> > Interfaces are a workaround for the lack of multiple inheritance
support.
> > If you want to use interfaces in your C++ programs you can do:
>
> There are some problems with MI Christopher actually addresses these in
his
> proposal documents.  I don't have a strong enough background in C++ to
> evaluate the details of his arguments, and consider alternatives.  It does
> seem fair to him that we take a bit of time to examine his work before we
> challenge his proposal.  This is what I found on his page:

Thank you for not being as quick as others to dismiss my work.

> http://www.heron-language.com/cpp-iop.html
>
> /*------------------ begin excerpt -------------------*/
> 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 ).
>
> /*------------------ end excerpt -------------------*/
>
>
> I'm staying neutral regarding the assertion that ABCs aren't proper
> interfaces.
>
> My questions are these:
>
> What happens if I want to extend a class that implements his interface?
My
> understanding it the implementation of the interface is 'final', and
cannot
> be overridden in a derived class.
>
> Is the interface inherited by derived classes of implementing classes.
IOW,
> can I use the derived class everywhere I could use the interface.
(Assuming
> the overriding in the previous item is not an issue.)
>
> Are there any diamond DAG problems?  I.e., what happens when two classes
> derive from the same implementing class, and a third derives from the
first
> two derived classes?

You don't derive from an inteface. If your method signatures form a precise
superset of those of the interface's contract then you implement the
interface. Those functions can be declared as virtual if you want so nothing
changes. I think there has been some confusion with an older version of the
proposal, please check again http://www.heron-language.com/heronfront.html
and http://www.heron-language.com/cpp-iop.html

> Can the same thing be accomplished with a purely template approach.  This
> seems to be answered by Christophers example of generated code.  It's
> templates, alright, and you're welcome to write them by hand if you like.
I
> kind of like the idea of the computer doing that for me.

You can of course write it by hand, but in order to achieve acceptable
performance and the correct behaviour it ends up rather verbose and
convoluted, see http://www.heron-language.com/cpp-iop-example.html and look
at struct IFuBar. This is the best that I can do by hand, but surely someone
else can do better, and I would love to see an improvement on that.

> Could the same thing be accomplished simply by having the compiler compare
> the signature of an implementing class to that of an interface without
> actually creating any extra runtime residue?  That is, treat the interface
> as a contract that the compiler verifies for all implementing classes.  As
> long as conformance is verified, no matter if it's through inheritance,
> hiding, or local definition, the interface is considered implemented, and
> the code is compiled as if there were no interface.

I believe this is what I do, I don't see how that is different from the
proposal.

> Can interfaces implement interfaces?

Yes an interface object for instance always implements its own interface.

> This is an example of an ABC interface approach I'm playing with:
>
>   /**
>      ABC Interface: Implementing classes can be passed to operator<<()
>    */
>   class Stringable {
>   public:
>     virtual void stringify(ostream& out)=0;
>   };
>
>   /**
>     stringifies an object implementing Stringable onto the ostream;
>   */
>   inline ostream& operator<<(ostream& out, Stringable& s){
>     s.stringify(out);
>   }
>
> How would this be implemented as an HF interface?

interface Stringable {
    contract:
        stringify(ostream& out);
};

// any class that has a stringify(ostream& out) function is then said to
implement Stringable

inline ostream& operator<<(ostream& out, Stringable s){
    // notice the removal of the & on the Stringable parameter
    s.stringify(out);
}

I hope I have helped answer some of your questions, and I appreciate the
support.

--
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                       ]

""Steven T. Hatton"" <hattons@globalsymmetry.com> skrev i meddelandet
news:tPWdncB_3Lu9gRTdRVn-ig@speakeasy.net...
> Ioannis Vranos wrote:
>
> /*------------------ begin excerpt -------------------*/
> 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 ).
>
> /*------------------ end excerpt -------------------*/

You might wonder how "a popular C++ compiler" became so popular, when it
cannot handle some obvious optimizations. Why not ask the implementors
to just fix that problem, instead of adding another language construct?

>
> I'm staying neutral regarding the assertion that ABCs aren't proper
> interfaces.

That, of course, depends heavily on the definition of "proper".  :-)

>
> My questions are these:
>
> What happens if I want to extend a class that implements his
interface?  My
> understanding it the implementation of the interface is 'final', and
cannot
> be overridden in a derived class.

Yes, that's how you get rid of the virtual functions in the first place!


>
> This is an example of an ABC interface approach I'm playing with:
>
>   /**
>      ABC Interface: Implementing classes can be passed to operator<<()
>    */
>   class Stringable {
>   public:
>     virtual void stringify(ostream& out)=0;
>   };
>
>   /**
>     stringifies an object implementing Stringable onto the ostream;
>   */
>   inline ostream& operator<<(ostream& out, Stringable& s){
>     s.stringify(out);
>   }
>
> How would this be implemented as an HF interface?

Who cares?  :-)

When you have a operations like string formatting and an ostream access,
what difference does a single virtual call make??

Some more "unpopular" compilers can even remove the virtual call when
the actual type of you "implementation class" is known.



Bo Persson


---
[ 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 have updated the interfaces proposal ( at:
http://www.heron-language.com/cpp-iop.html ) by removing the unecessary
requirements for an implements declaration. I have also written out a
comparable example implementation of interfaces in C++ without virtual
functions at http://www.heron-language.com/cpp-iop-example.html .

The proposal is now looking more than ever like the old GCC signatures
proposal that members of this group brought to my attention. Despite that
proposal having been abandoned [rejected?] previously, there is, to my
knowledge no practically usable solution to implementing designs that
represent implementation of multiple interfaces. Proposed alternative
techniques that I have encountered thus far are either lacking in run-time
polymorphism, or have unacceptable penalties of size, performance or
verbosity.

I wish to also express my gratitude to everyone so far, who have been
participating in the lively and intelligent discussions on the topic.

--
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                       ]

""christopher diggins"" <cdiggins@videotron.ca> wrote in message
news:NTWfc.1127$MZ2.105711@weber.videotron.net...
> I have updated the interfaces proposal ( at:
> http://www.heron-language.com/cpp-iop.html ) by removing the unecessary
> requirements for an implements declaration. I have also written out a
> comparable example implementation of interfaces in C++ without virtual
> functions at http://www.heron-language.com/cpp-iop-example.html .
>
> The proposal is now looking more than ever like the old GCC signatures
> proposal that members of this group brought to my attention. Despite that
> proposal having been abandoned [rejected?] previously, there is, to my
> knowledge no practically usable solution to implementing designs that
> represent implementation of multiple interfaces. Proposed alternative
> techniques that I have encountered thus far are either lacking in run-time
> polymorphism, or have unacceptable penalties of size, performance or
> verbosity.
>
> I wish to also express my gratitude to everyone so far, who have been
> participating in the lively and intelligent discussions on the topic.


I haven't seen your previous interface proposals, why do we need an
interface in C++ since it already supports multiple inheritance? Interfaces
are a workaround for the lack of multiple inheritance support. If you want
to use interfaces in your C++ programs you can do:


class base1
{
  // ...
};


class your_interface
{
  // ...

 public:

virtual void whatever_function1() =0;
 // ...
};


class derived_class: public base1, your_interface
{
  // ...
  void whatever_function1()
 {
   // ...
 }
};



You can already do what you want. "Interfaces" are already supported since
"interfaces" are a (small) subset of multiple inheritance.






Ioannis Vranos

---
[ 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                       ]

On Fri, 16 Apr 2004 21:14:03 +0000 (UTC), cdiggins@videotron.ca
("christopher diggins") wrote:

>I have updated the interfaces proposal ( at:
>http://www.heron-language.com/cpp-iop.html ) by removing the unecessary
>requirements for an implements declaration. I have also written out a
>comparable example implementation of interfaces in C++ without virtual
>functions at http://www.heron-language.com/cpp-iop-example.html .

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

There seem to me to be a lot of repercussions:

Overloading
How does the object->interface conversion rank in overload resolution?

Conversions
Can you convert all of A*, A& and A to an interface reference that A
implements? Or which ones?

Non-type template parameters
Can an interface reference be a non-type template parameter (as a
pointer and reference can)? If not, why not?

References and pointers
Can you have a reference to an "interface reference"? A pointer?

Interface reference semantics
Is there a default value for an interface reference (i.e. is there a
"default constructor" that initializes it to null)? Can it be cv
qualified?

dynamic_cast
How do interface references interact with dynamic_cast? Can you
dynamic_cast to an interface type? From an interface object?

syntax
How do you call a member through an interface reference? Via "." or
"->"? How does this fit in with the other semantics and syntax, and
the rest of the language?

Lvalue
Can you obtain an lvalue referring to the original object from an
interface reference. e.g. is "*reference" valid?

I'm sure there are a lot more too...

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

---
[ 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                       ]

"tom_usenet" <tom_usenet@hotmail.com> wrote in message
news:e76780ps000thnr4iss75lc8g6gf1olsn1@4ax.com...
> On Fri, 16 Apr 2004 21:14:03 +0000 (UTC), cdiggins@videotron.ca
> ("christopher diggins") wrote:
>
> >I have updated the interfaces proposal ( at:
> >http://www.heron-language.com/cpp-iop.html ) by removing the unecessary
> >requirements for an implements declaration. I have also written out a
> >comparable example implementation of interfaces in C++ without virtual
> >functions at http://www.heron-language.com/cpp-iop-example.html .
>
> >"There are no repercussions to the language above and beyond the
> >syntactic changes required to allow declaration of interfaces and
> >implementation of interface. "
>
> There seem to me to be a lot of repercussions:

The reason I say this is that there aren't changes required beyond the
limited scope of interface reference interactions with existing constructs,
i.e. it is as harmless as defining a new type. No other part of the language
has to change how it deals with anything else.

I overlooked the exact semantics of the Interface reference type in the
proposal, considering it as being somewhat trivial. The interface reference
type is simply a struct with a set of public functions, and is assignable
and constructible from any interface reference of the same type, or any
object which corresponds to the same signature.

> Overloading
> How does the object->interface conversion rank in overload resolution?

Whereever object->struct conversions rank.

> Conversions
> Can you convert all of A*, A& and A to an interface reference that A
> implements? Or which ones?

A, A& and A* only if you dereference it.

> Non-type template parameters
> Can an interface reference be a non-type template parameter (as a
> pointer and reference can)? If not, why not?

I am not sure I understand this question. If you mean something like :
template<typename T*> class FuBar() { ... }; Then I would have to say no,
because an interface is not a classification of type but a type in of
itself.

> References and pointers
> Can you have a reference to an "interface reference"? A pointer?

Yes.

> Interface reference semantics
> Is there a default value for an interface reference (i.e. is there a
> "default constructor" that initializes it to null)? Can it be cv
> qualified?

To the first part: I would personally implement it as so, but in keeping
with the tradition of C++ it wouldn't be. What is cv qualified?

> dynamic_cast
> How do interface references interact with dynamic_cast? Can you
> dynamic_cast to an interface type? From an interface object?

Yes.

> syntax
> How do you call a member through an interface reference? Via "." or
> "->"? How does this fit in with the other semantics and syntax, and
> the rest of the language?

Via "." (using -> would imply that a struct can be dereferenced and that
*interface_reference has meaning). I don't see any affect on the rest of the
language.

> Lvalue
> Can you obtain an lvalue referring to the original object from an
> interface reference. e.g. is "*reference" valid?

No.

> I'm sure there are a lot more too...

Yes, probably (as much as defining a type in a standard libary), but I do
greatly appreciate you flushing out these issues.

> Tom
> --

I am not sure if you have seen the code example which mimics the proposed
behaviour of the interface reference type at
http://www.heron-language.com/cpp-iop-example.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                       ]

On Tue, 20 Apr 2004 18:02:54 +0000 (UTC), cdiggins@videotron.ca
("christopher diggins") wrote:

>"tom_usenet" <tom_usenet@hotmail.com> wrote in message
>news:e76780ps000thnr4iss75lc8g6gf1olsn1@4ax.com...
>> On Fri, 16 Apr 2004 21:14:03 +0000 (UTC), cdiggins@videotron.ca
>> ("christopher diggins") wrote:
>>
>> >I have updated the interfaces proposal ( at:
>> >http://www.heron-language.com/cpp-iop.html ) by removing the unecessary
>> >requirements for an implements declaration. I have also written out a
>> >comparable example implementation of interfaces in C++ without virtual
>> >functions at http://www.heron-language.com/cpp-iop-example.html .
>>
>> >"There are no repercussions to the language above and beyond the
>> >syntactic changes required to allow declaration of interfaces and
>> >implementation of interface. "
>>
>> There seem to me to be a lot of repercussions:
>
>The reason I say this is that there aren't changes required beyond the
>limited scope of interface reference interactions with existing constructs,
>i.e. it is as harmless as defining a new type. No other part of the language
>has to change how it deals with anything else.

That's generally true, but interfaces interact with a lot of C++, so
there are a lot of details to work out if they are to be a serious
proposal.

>I overlooked the exact semantics of the Interface reference type in the
>proposal, considering it as being somewhat trivial.

It's likely to be far from it if it's to be a fully integrated part of
C++ rather than a tacked on "heron-front" extension.

 The interface reference
>type is simply a struct with a set of public functions, and is assignable
>and constructible from any interface reference of the same type, or any
>object which corresponds to the same signature.

A interface reference may be implemented as a struct with a set of
public functions in your front end, but that isn't what it *is*, or at
least what it should be were it to be formally added to C++.

>> Overloading
>> How does the object->interface conversion rank in overload resolution?
>
>Whereever object->struct conversions rank.

What is an "object->struct" conversion? Do you mean derived->base? Or
a user defined conversion (e.g. operator std::string())?

If you mean the latter, that will produce surprising results. e.g.

interface myinterface{};

void f(myinterface i);
void f(int c);

class Foo: public myinterface
{
public:
  operator int() const;
};

Foo foo;

f(foo); //what does this call?

With your suggestion above, it will be ambiguous, but clearly the
interface version should be called.

>
>> Conversions
>> Can you convert all of A*, A& and A to an interface reference that A
>> implements? Or which ones?
>
>A, A& and A* only if you dereference it.

Does an interface reference extend the lifetime of a temporary as
normal references do? e.g.

myinterface i = Foo(); //can you assign an rvalue to it?
//or const myinterface i = Foo(); if it works similarly to normal
//references
i.f(); //is this legal - does the temporary Foo still exist?

>> Non-type template parameters
>> Can an interface reference be a non-type template parameter (as a
>> pointer and reference can)? If not, why not?
>
>I am not sure I understand this question. If you mean something like :
>template<typename T*> class FuBar() { ... }; Then I would have to say no,
>because an interface is not a classification of type but a type in of
>itself.

This is legal:

class Foo{} foo;

template <Foo& f>
class FooRef
{
};

FooRef<foo> f;

Is:

interface I{};
class Foo: public I{} foo;
template <I i>
class FooRef
{
};
FooRef<foo> f;

legal? It is analagous to the normal reference version.

>> References and pointers
>> Can you have a reference to an "interface reference"? A pointer?
>
>Yes.
>
>> Interface reference semantics
>> Is there a default value for an interface reference (i.e. is there a
>> "default constructor" that initializes it to null)? Can it be cv
>> qualified?
>
>To the first part: I would personally implement it as so, but in keeping
>with the tradition of C++ it wouldn't be. What is cv qualified?

const volatile qualified. e.g. can you have:

const myinterface myref = foo;
myref.bar(); //bar must be a const member function

But how do you declare a myinterface reference that can't be modified?
e.g.

const myinterface myref = foo;
myref = bar; //want a compiler error

IOW, you can't have be both ways, either const applies to the
referenced object or the reference itself.

This causes other problems:

void f(const int);
is the same function as
void f(int);
since top level cv-qualifiers are not part of the type of a function.
However,
void f(const myinterface);
can't realistically be the same type as
void f(myinterface);
since otherwise you can't have const correctness with interfaces.
However, you can see the syntatic inconsistency with the rest of the
language. Perhaps an interface reference needs its own denoter. e.g.

myinterface^ ref;

or similar, to avoid confusion (since an interface won't have the
usual value or reference semantics - it looks like a pointer with
reference syntax to me). Then you can do:

myinterface const^ ref; //interface reference to const
myinterface^ const ref; //const interface reference to non-const

This also impinges on template argument deduction. e.g.

template <class T>
void (T^ t);

Or, without the ^, how would you declare a template that took any
interface reference?

>> dynamic_cast
>> How do interface references interact with dynamic_cast? Can you
>> dynamic_cast to an interface type? From an interface object?
>
>Yes.
>
>> syntax
>> How do you call a member through an interface reference? Via "." or
>> "->"? How does this fit in with the other semantics and syntax, and
>> the rest of the language?
>
>Via "." (using -> would imply that a struct can be dereferenced and that
>*interface_reference has meaning). I don't see any affect on the rest of the
>language.

Syntatically you are making your interface reference like a value or
reference, but semantically it operates much more like a pointer. This
might be confusing to some (it does the same things as Java - call a
pointer a reference, although Java gives the game away with the "null
pointer exception"!).

>> Lvalue
>> Can you obtain an lvalue referring to the original object from an
>> interface reference. e.g. is "*reference" valid?
>
>No.

How about with dynamic_cast? e.g.

dynamic_cast<Foo&>(myref) = Foo(5);

>> I'm sure there are a lot more too...
>
>Yes, probably (as much as defining a type in a standard libary), but I do
>greatly appreciate you flushing out these issues.

It is *much* more work that defining a type in the standard library -
it is a language modification, and to get it seriously considered, it
can't be half-baked. You need to consider how to integrate it properly
into the language, not how to write a quick hack to get it working for
your heron front end.

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

---
[ 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                       ]

"tom_usenet" <tom_usenet@hotmail.com> wrote in message
news:e76780ps000thnr4iss75lc8g6gf1olsn1@4ax.com...
> On Fri, 16 Apr 2004 21:14:03 +0000 (UTC), cdiggins@videotron.ca
> ("christopher diggins") wrote:
>
> >I have updated the interfaces proposal ( at:
> >http://www.heron-language.com/cpp-iop.html ) by removing the unecessary
> >requirements for an implements declaration. I have also written out a
> >comparable example implementation of interfaces in C++ without virtual
> >functions at http://www.heron-language.com/cpp-iop-example.html .
>
> >"There are no repercussions to the language above and beyond the
> >syntactic changes required to allow declaration of interfaces and
> >implementation of interface. "
>
> There seem to me to be a lot of repercussions:
>
> Overloading
> How does the object->interface conversion rank in overload resolution?
>
> Conversions
> Can you convert all of A*, A& and A to an interface reference that A
> implements? Or which ones?
>
> Non-type template parameters
> Can an interface reference be a non-type template parameter (as a
> pointer and reference can)? If not, why not?
>
> References and pointers
> Can you have a reference to an "interface reference"? A pointer?
>
> Interface reference semantics
> Is there a default value for an interface reference (i.e. is there a
> "default constructor" that initializes it to null)? Can it be cv
> qualified?
>
> dynamic_cast
> How do interface references interact with dynamic_cast? Can you
> dynamic_cast to an interface type? From an interface object?
>
> syntax
> How do you call a member through an interface reference? Via "." or
> "->"? How does this fit in with the other semantics and syntax, and
> the rest of the language?
>
> Lvalue
> Can you obtain an lvalue referring to the original object from an
> interface reference. e.g. is "*reference" valid?
>
> I'm sure there are a lot more too...
>
> Tom

I have updated HeronFront to match the new form of the proposal and
demonstrate interface inheritance. It might help to answer some of your
questions better than I can. A description and download is available at
http://www.heron-language.com/heronfront.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") wrote in message news:<n4bhc.698$Iu5.34558@weber.videotron.net>...
> "tom_usenet" <tom_usenet@hotmail.com> wrote in message
> news:e76780ps000thnr4iss75lc8g6gf1olsn1@4ax.com...
> > On Fri, 16 Apr 2004 21:14:03 +0000 (UTC), cdiggins@videotron.ca
> > ("christopher diggins") wrote:
..
> > Non-type template parameters
> > Can an interface reference be a non-type template parameter (as a
> > pointer and reference can)? If not, why not?
>
> I am not sure I understand this question. If you mean something like :
> template<typename T*> class FuBar() { ... }; Then I would have to say no,
> because an interface is not a classification of type but a type in of
> itself.

I'm not sure I understand that issue. Both pointers and references
have their own types, yet it's possible to have non-type template
parameters of pointer or reference types. For instance:

template<int *i, int &j> class FuBar() {...};

int count, sum;

FuBar<&count,sum> count_sum;

..
> with the tradition of C++ it wouldn't be. What is cv qualified?

"cv qualified" refers to the two qualifiers: const and volatile. Can
you declare a const or volatile interface reference?

---
[ 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                       ]