[OT] Proposal to add Interfaces to C++

  • Thread starter christopher diggins
  • Start date
C

christopher diggins

The following is a post I recently made to comp.std.c++ that I wanted to
discuss here, due to the horrible lag when trying to have a discussion on
the moderated groups. I would appreciate some feedback on the factual
content, and likelihood of acceptance. Thanks in advance!

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

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

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

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

interface IFuBar {
FuBar();
};

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

class CFuBar {
implements: IFuBar;
};

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

CFuBar x;
IFuBar i = &x;

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

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

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

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

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

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

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

Thanks to Alberto Barbati for his syntax proposals.

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

Claudio Puviani

christopher diggins said:
[latest proposal to add interfaces (and thinly veiled
promotion of heron) snipped]

We get this proposal every two weeks. Here are a few answers to
the proposal:

- NO!

- This is the wrong forum to propose ANY changes to the language.
This newsgroups concerns itself ONLY with the use of C++ AS IT IS
DEFINED IN THE ISO STANDARD. Please read the FAQ.

- Take the time to read previous postings before submitting
off-topic messages. If you had, you would have seen your proposal
written many times before and you would have seen it rejected
every time.

And just what exactly makes you think that reformatting your
message will generate any more interest in heron than your
previous postings did? How many times will you spam us before you
realize that we're just not interested?

Please respect the purpose of the newsgroup.

Claudio Puviani
 
C

christopher diggins

Claudio Puviani said:
christopher diggins said:
[latest proposal to add interfaces (and thinly veiled
promotion of heron) snipped]

We get this proposal every two weeks. Here are a few answers to
the proposal:

That is overstating the case, I didn't repost anything.
- NO!

- This is the wrong forum to propose ANY changes to the language.
This newsgroups concerns itself ONLY with the use of C++ AS IT IS
DEFINED IN THE ISO STANDARD. Please read the FAQ.

There was some disagreement with you on the relevance of this topic. I did
mark it as OT in case there was some frustration at the post being placed
here. I honestly don't know why you have decided to pick on me, despite
there being many other posts that are more off topic than this one, yet you
don't bother blasting them. To top it off here is a small sampling of topics
which you have participated in willing that were off-topic:

Re: CUJ and Microsoft C++
Re: c++ interpreter
Re: [OT]W3C issue: Time to standardize the XML library for C/C++
- Take the time to read previous postings before submitting
off-topic messages. If you had, you would have seen your proposal
written many times before and you would have seen it rejected
every time.

That is simply untrue. Show me the same proposal rejected by someone other
than yourself.
And just what exactly makes you think that reformatting your
message will generate any more interest in heron than your
previous postings did? How many times will you spam us before you
realize that we're just not interested?

I posted very specifically about a serious proposal to add interfaces to
C++. I don't see your accusal of me spamming the newsgroup w.r.t. Heron as
being justified.
Please respect the purpose of the newsgroup.

I believe I have and I am confident others agree. If you don't like my posts
then please put me in your kill file.
 
C

Claudio Puviani

christopher diggins said:
There was some disagreement with you on the
relevance of this topic.

The only disagreement came from someone else who routinely
proposes absurd changes to the language.

But so be it. Just hold your breath for any sign of support other
than from Stephen Hatton. Maybe after being completely ignored or
rejected twice, you'll get the message.

Claudio Puviani
 
C

Claudio Puviani

Claudio Puviani said:
The only disagreement came from someone else who routinely
proposes absurd changes to the language.

But so be it. Just hold your breath for any sign of support other
than from Stephen Hatton. Maybe after being completely ignored or
rejected twice, you'll get the message.

Whoa! Get a load of the flurry of interest and support for this proposal!
Compiler writers to arms! Here come interfaces à la Heron!

ROFL

Claudio Puviani
 
D

David

The following is a post I recently made to comp.std.c++ that I wanted to
discuss here, due to the horrible lag when trying to have a discussion on
the moderated groups. I would appreciate some feedback on the factual
content, and likelihood of acceptance. Thanks in advance!

Yes, this a bit off-topic. It is also incorrect.

C++ can model this behavior. I'm not versed on Java so I can't comment
on ease of implementation wrt that language.

The interface need not be part of the implementation. It is just true
that we normally put it there. I've seen this solved a number of ways
and none have been obvious to the initial user unless they were given
an example.

Consider your favorite Array class template.

Array<int> ArrayOfInt;

Most initial developers of an Array template define the methods
(interface) as part of the template.

Why not indirect this one more time to provide both the Type
and the Interface? Why stop there?

I've been using a C++ compiler that implemented templates of
templates around 1990. We had collection classes that defined
the organization in one template and the desired interface in
another tempate. The end application would define both in
terms of the other to get the desired organization, efficiency,
flexibility, and interface.

The following are organizations:

Array
List
Set
OrderedSet
Relation
Bag
Stack
Queue
...

The following are some implementations:

Array (not the same concept as above)
Linked List
Doubly Linked List
balanced tree
n-tree
...

Some organizations require certain interfaces:

Bag might have: add, remove, includes
Array might have: size, [], get, set
OrderedSet might add relationship operators

So as end user developer I can have an

Array of items
perhaps declare whether the array is bounded or not (its implementation)
its interface -- a simple array, b-tree, OrdereSet, etc.

There is nothing to prevent the implementation from having
multiple interfaces.

This can allow the developer can choose the best design
for a given problem.

Its not perfect, but C++ does support the concept even if
you haven't thought of how to implement it yet. As with most
concepts and enough time and discipline, everything reduces
to the concepts supported by the machine and its derivatives.
C has just as much power as C++; it just may take a little
more work to do it. Java has concepts its suits well and
others it doesn't. Use appropriate tools for the job and
when limited to a set of tools find a way to make due with
what you have. We don't need to change C++ or any other
language.

David
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top