Proposal for Interfaces (version 3.0) - C++ language, library and standards

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

Proposal for Interfaces (version 3.0)
Goto page 1, 2 Next

C++Talk.NET Forum Index -> C++ language, library and standards

View previous topic :: View next topic

Author

Message

christopher diggins
Guest

Posted: Fri Apr 16, 2004 9:14 pm Post subject: Proposal for Interfaces (version 3.0)

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 ]

Ioannis Vranos
Guest

Posted: Fri Apr 16, 2004 10:45 pm Post subject: Re: Proposal for Interfaces (version 3.0)

""christopher diggins"" <cdiggins (AT) videotron (DOT) ca> wrote

Quote:

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 ]

tom_usenet
Guest

Posted: Mon Apr 19, 2004 4:08 pm Post subject: Re: Proposal for Interfaces (version 3.0)

On Fri, 16 Apr 2004 21:14:03 +0000 (UTC), [email]cdiggins (AT) videotron (DOT) ca[/email]
("christopher diggins") wrote:

Quote:

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 ]

christopher diggins
Guest

Posted: Tue Apr 20, 2004 6:02 pm Post subject: Re: Proposal for Interfaces (version 3.0)

"tom_usenet" <tom_usenet (AT) hotmail (DOT) com> wrote

Quote:

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.

Quote:

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

Whereever object->struct conversions rank.

Quote:

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.

Quote:

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.

Quote:

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

Yes.

Quote:

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?

Quote:

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

Yes.

Quote:

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.

Quote:

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

No.

Quote:

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.

Quote:

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 ]

tom_usenet
Guest

Posted: Wed Apr 21, 2004 7:32 pm Post subject: Re: Proposal for Interfaces (version 3.0)

On Tue, 20 Apr 2004 18:02:54 +0000 (UTC), [email]cdiggins (AT) videotron (DOT) ca[/email]
("christopher diggins") wrote:

Quote:

"tom_usenet" <tom_usenet (AT) hotmail (DOT) com> wrote in message
news:e76780ps000thnr4iss75lc8g6gf1olsn1 (AT) 4ax (DOT) com...
On Fri, 16 Apr 2004 21:14:03 +0000 (UTC), [email]cdiggins (AT) videotron (DOT) ca[/email]
("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.

Quote:

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

Quote:

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++.

Quote:

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.

Quote:

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?

Quote:

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.

Quote:

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?

Quote:

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"!).

Quote:

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);

Quote:

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 ]

christopher diggins
Guest

Posted: Wed Apr 21, 2004 7:33 pm Post subject: Re: Proposal for Interfaces (version 3.0)

"tom_usenet" <tom_usenet (AT) hotmail (DOT) com> wrote

Quote:

On Fri, 16 Apr 2004 21:14:03 +0000 (UTC), [email]cdiggins (AT) videotron (DOT) ca[/email]
("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 ]

James Kuyper
Guest

Posted: Thu Apr 22, 2004 1:10 am Post subject: Re: Proposal for Interfaces (version 3.0)

[email]cdiggins (AT) videotron (DOT) ca[/email] ("christopher diggins") wrote in message news:<n4bhc.698$Iu5.34558 (AT) weber (DOT) videotron.net>...

Quote:

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;

...

Quote:

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 ]

Steven T. Hatton
Guest

Posted: Fri Apr 23, 2004 7:09 pm Post subject: Re: Proposal for Interfaces (version 3.0)

Ioannis Vranos wrote:

Quote:

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 ]

christopher diggins
Guest

Posted: Sat Apr 24, 2004 5:36 am Post subject: Re: Proposal for Interfaces (version 3.0)

""Steven T. Hatton"" <hattons (AT) globalsymmetry (DOT) com> wrote

Quote:

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.

Quote:

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

Quote:

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.

Quote:

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.

Quote:

Can interfaces implement interfaces?

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

Quote:

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 ]

Bo Persson
Guest

Posted: Sat Apr 24, 2004 9:14 am Post subject: Re: Proposal for Interfaces (version 3.0)

""Steven T. Hatton"" <hattons (AT) globalsymmetry (DOT) com> skrev i meddelandet
news:tPWdncB_3Lu9gRTdRVn-ig (AT) speakeasy (DOT) net...

Quote:

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?

Quote:

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

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

Quote:

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!

Quote:

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 ]

Christopher Diggins
Guest

Posted: Sat Apr 24, 2004 3:59 pm Post subject: Re: Proposal for Interfaces (version 3.0)

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

===================================== END OF MODERATOR'S COMMENT
[email]tom_usenet (AT) hotmail (DOT) com[/email] (tom_usenet) wrote in message news:<mjgc80d8je1jb0lf2d4kl85n3ml9tm6h5k (AT) 4ax (DOT) com>...

Quote:

On Tue, 20 Apr 2004 18:02:54 +0000 (UTC), [email]cdiggins (AT) videotron (DOT) ca[/email]
("christopher diggins") wrote:
"tom_usenet" <tom_usenet (AT) hotmail (DOT) 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 ]

Steven T. Hatton
Guest

Posted: Sat Apr 24, 2004 5:41 pm Post subject: Defined signatures: Forked from: Re: Proposal for Interfaces

christopher diggins wrote:

Quote:

""Steven T. Hatton"" <hattons (AT) globalsymmetry (DOT) com> wrote in message
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.

I believe what I was suggesting is a meta-abstraction. IOW, the mechanism I
was proposing would not have any actual residue in the object code or
executable. It would be a purely compile-time feature. It could be
understood as a user-defined signature check. For the sake of discussion
I'll call it a zero-mass interface. For example one might define such an
interface with the following statement:

// works for functions or classes
signature int zFunct(const int& arg1, const int& arg2);

The programmer would then use zfunct to force a check on a member function.
For example:

class MyClass{
zfunct int myFunct(const int& marg1, const int& marg2); //will compile
zfunct int myFunct(const nonInt& no_go, const int& marg2); //won't compile
}

Or for a class:

signature class zClassSig{
int zFunctA(const int& marg1, const int& marg2);
int zFunctB(const someClass& some_obj, const int& marg2);
}

/* compiles */
class zClass{
int zFunctA(const int& zarg1, const int& zarg2);
int zFunctB(const someClass& some_zobj, const int& zarg2);
}

/* doesn't compile */
class zClass{
int zFunctA(const int& zarg1, const int& zarg2);
}

This idea seems so simple and obvious that I feel there must be something
worng with it that I'm not seeing. Or perhaps something already does this,
and I'm not perceiving it. I'm just presenting it to the newsgroup because
it may actually have some merit.

There seem to be times when people whant to assert that a collection of
class templates exhibit certain features, but inheritance fails to support
the design. Perhaps the ability to literally define a signature would
provide a more deterministic means of enforcing conformance to the
conceptual abstract 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 ]

Dave Harris
Guest

Posted: Sun Apr 25, 2004 1:42 am Post subject: Re: Proposal for Interfaces (version 3.0)

[email]bop (AT) gmb (DOT) dk[/email] ("Bo Persson") wrote (abridged):

Quote:

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 ]

Bob Bell
Guest

Posted: Sun Apr 25, 2004 8:50 pm Post subject: Re: Proposal for Interfaces (version 3.0)

[email]brangdon (AT) cix (DOT) co.uk[/email] (Dave Harris) wrote in message news:<memo.20040424132625.1156B (AT) brangdon (DOT) m>...

Quote:

bop (AT) gmb (DOT) 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.

Quote:

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 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);

Quote:

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 ]

Ioannis Vranos
Guest

Posted: Mon Apr 26, 2004 1:38 am Post subject: Re: Proposal for Interfaces (version 3.0)

""Steven T. Hatton"" <hattons (AT) globalsymmetry (DOT) com> wrote

Quote:

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

Display posts from previous:

	C++Talk.NET Forum Index -> C++ language, library and standards	All times are GMT Goto page 1, 2 Next
Page 1 of 2

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum