christopher diggins wrote:
> This is the most recent version of the interfaces proposal, taken from
> http://www.heron-language.com/cpp-iop.html .


Could you please compare and contrast your 'interface' approach to the
'concepts' approach as delineated by Stroustrup & Dos Reis in the
following papers:
1) http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1510.pdf
2) http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1522.pdf
3) http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1536.pdf

I have not studied the papers and proposal in detail but at first glance
it seems that there is some overlap between the concept approach and the
interface approach (although i'm not sure whether the issues raised in
your later sections on assignment etc. are fully addressed in the
concept papers - though a more detailed study of the papers might prove
that they are).

The following:.
concept IFuBar {
   contraints( IFuBar ifb )
   {
     ifb.FuBar();
   }
};

void fun( IFuBar ifb );

regards,
Faisal Vali

---
[ 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 Sun, 25 Apr 2004 20:51:18 +0000 (UTC), cdiggins@videotron.ca
("christopher diggins") wrote:

>This is the most recent version of the interfaces proposal, taken from
>http://www.heron-language.com/cpp-iop.html . The proposal has gone through a
>significant amount of changes since my original post and I would like to
>know what problems exist with the proposal as it stands and whether anyone
>has any interest in seeing the proposal and/or the ideas pursued further.
>Thanks in advance.
>
<snip - proposal>

This proposal seems to have a fighting chance to me.
There is however one big problem that needs to be addressed.
I can not visualise how the compiler determines which function to
call, when you are calling a member function through an interface.

Can you outline how the generated machine instructions eventually wind
up in foo::do_something or bar::do_something?

// file: interface.h

interface baz {
  void do_something(int i);
};

void test(baz);
// eof

// file interface.cpp
#include "interface.h"

void test(baz x)
{
  x.do_something(1);
}
// eof

// file: test.cpp
#include <iostream>
#include "interface.h"

class foo {
  void do_something(int i = 0)
  {
    std::cout << "foo::do_something(" << i << ")" << std::endl;
  }
};

class bar {
  void do_something(int)
  {
    std::cout << "bar::do_something()" << std::endl;
  }
};

int main()
{
  test(foo());
  test(bar());
}
// eof

And another question is, does the class foo defined above also
implement this interface:
  interface foobar {
    void do_something(void);
  };
?

Bart v Ingen Schenau

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

In article <l1ct80140sgbeu2de1fskkv3be7ra79ooh@4ax.com>, Bart van Ingen
Schenau <Bart.van.Ingen.Schenau@ict.nl> writes
>On Sun, 25 Apr 2004 20:51:18 +0000 (UTC), cdiggins@videotron.ca
>("christopher diggins") wrote:
>
>>This is the most recent version of the interfaces proposal, taken from
>>http://www.heron-language.com/cpp-iop.html . The proposal has gone through a
>>significant amount of changes since my original post and I would like to
>>know what problems exist with the proposal as it stands and whether anyone
>>has any interest in seeing the proposal and/or the ideas pursued further.
>>Thanks in advance.
>>
><snip - proposal>
>
>This proposal seems to have a fighting chance to me.

However until the author takes the steps necessary to co-ordinate with
work being done elsewhere he is burning up a lot of energy. I note the
.ca at the end of his email address so perhaps he might enquire from
Herb Sutter as to what he needs to do to become an accredited Canadian
technical expert and thereby have access to the TC39/TG5 papers on
interfaces. He might even co-author a proposal to WG21 with Herb Sutter
himself.


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

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

"Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
news:pO$1toYevujAFwmO@robinton.demon.co.uk...
> In article <l1ct80140sgbeu2de1fskkv3be7ra79ooh@4ax.com>, Bart van Ingen
> Schenau <Bart.van.Ingen.Schenau@ict.nl> writes
> >On Sun, 25 Apr 2004 20:51:18 +0000 (UTC), cdiggins@videotron.ca
> >("christopher diggins") wrote:
> >
> >>This is the most recent version of the interfaces proposal, taken from
> >>http://www.heron-language.com/cpp-iop.html . The proposal has gone
through a
> >>significant amount of changes since my original post and I would like to
> >>know what problems exist with the proposal as it stands and whether
anyone
> >>has any interest in seeing the proposal and/or the ideas pursued
further.
> >>Thanks in advance.
> >>
> ><snip - proposal>
> >
> >This proposal seems to have a fighting chance to me.
>
> However until the author takes the steps necessary to co-ordinate with
> work being done elsewhere he is burning up a lot of energy. I note the
> .ca at the end of his email address so perhaps he might enquire from
> Herb Sutter as to what he needs to do to become an accredited Canadian
> technical expert and thereby have access to the TC39/TG5 papers on
> interfaces. He might even co-author a proposal to WG21 with Herb Sutter
> himself.

Thank you for the suggestion. I did try to contact Herb a while back, but he
didn't return my email, I am hesitant to contact him again. Why are the
TC39/TG5 papers private? Has C++ always been modified behind closed doors?

--
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 wrote:
> This is the most recent version of the interfaces proposal, taken from
> http://www.heron-language.com/cpp-iop.html .


Could you please compare and contrast your 'interface' approach to the
'concepts' approach as delineated by Stroustrup & Dos Reis in the
following papers:
1) http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1510.pdf
2) http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1522.pdf
3) http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1536.pdf

I have not studied the papers and proposal in detail but at first
glance it seems that there is some overlap between the concept
approach and the interface approach (although i'm not sure whether the
issues raised in your later sections on assignment etc. are fully
addressed in the concept papers - though a more detailed study of the
papers might prove that they are).

The following:.
concept IFuBar {
  contraints( IFuBar ifb )
  {
    ifb.FuBar();
  }
};

void fun( IFuBar ifb );

regards,
Faisal Vali

---
[ 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:<XDNjc.141518$2V6.1814715@wagner.videotron.net>...
..
> Thank you for the suggestion. I did try to contact Herb a while back, but he
> didn't return my email, I am hesitant to contact him again. Why are the
> TC39/TG5 papers private? Has C++ always been modified behind closed doors?

If you want to see such documents, you might want to consider joining
the committee. It's not very difficult - they're always glad to have
new volunteers (it is, however, fairly expensive by the standards of
an individual).

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

In article <XDNjc.141518$2V6.1814715@wagner.videotron.net>, christopher
diggins <cdiggins@videotron.ca> writes
>Thank you for the suggestion. I did try to contact Herb a while back, but he
>didn't return my email, I am hesitant to contact him again. Why are the
>TC39/TG5 papers private? Has C++ always been modified behind closed doors?

Because that is the way ECMA works. And no C++ hasn't been modified
behind closed doors but despite the problems WG21 does try to
accommodate to the work of other organisations. Try Herb again. He is a
busy person but...


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

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

This is the most recent version of the interfaces proposal, taken from
http://www.heron-language.com/cpp-iop.html . The proposal has gone through a
significant amount of changes since my original post and I would like to
know what problems exist with the proposal as it stands and whether anyone
has any interest in seeing the proposal and/or the ideas pursued further.
Thanks in advance.

--
Motivation
--
* Problem
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
classes (classes with one or more pure virtual functions) commonly referred
to as ABC's.

*Deficiency of Common Workaround
The principal problem of using an ABC as an interface is that it
automatically declares the functions intended to model the interface as
virtual. This is uneccessary and incorrect with regards to most definitions
of an interface. This also leads to two major practical problems: 1)
performance penalties due to superflous dispatching and inability of the
compiler to inline calls where normally it would be appropriate. 2) object
size penalties which increase linear with the number of interfaces modeled
due to extra vtable pointers within the objects. The second problem 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.

*Writing out Interfaces Manually
Given that the common solution of using ABC's to emulate interfaces may be
deemed unacceptable for various reasons, the programmer is left with the
alternative of writing their own interface types. This requires a
significant amount of coding and is a complex endeavour. The redundnacy of
typing can be overcome to a certain degree through the clever use of macros.
The macro approach is often considered an undesirable solution for many
reasons which leaves us in a position to consider a propsal for a change to
the language.
--
Description of Proposal for non-assignable interface variables

--
Interfaces are an excellent canidate for consideration as a new features for
C++ language due the fact that the represent a clear and well-defined
semantic construct with relatively low impact on other aspects of the
language itself.

*Declaring Interfaces
Allow declaration of an interface type, like a class/struct but with only
function declarations, i.e.:
  interface IFuBar {
    void FuBar();
  };

*Interfaces Implementations
Any object that has definitions for a complete set of functions with
matching signatures as any given interface is said to implement that
interface.

*Interface Variables
An interface variable is a non-assignable variable that can refer to any
object that implements that interface. An interface variable stores a
pointer to an object that implements an interface. An interface variable
allows any function that is part of the interface to be invoked using dot
notation. It is the intention of this proposal that an interface variable
model its behaviour as closely to reference type as can reasonably be
expected.

*Constructing and Initializing Interface Variables
Interface variables must be intialized with a variable which can either be
an instance of a class or struct which implements the corresponding
interface, or can be an interface variable of the same or derived type.
  SomeInterface i = x;

Interpretation of the above statement:
-if x is an instance of a class or struct then i stores internally the
address of x
-if x is a pointer to a class or struct then i stores internally the value
of x
-if x is an instance of another interface variable then i stores the address
of the object referred to by x.

*Assignment
Interface variables can not be assigned to (i.e. treated as an l-value).

*Invalid interface variables
If an interface variable's target object is invalidated (i.e. prematurely
destroyed) then the interface variable exhibits undefined behaviour when a
member function is invoked.

*Const Qualification
Interface variables can be declared as const:
  const SomeInterface i = SomeObject;

Const qualified interface variables behave like const references, only allow
const member functions to be called, etc.

*Extending the Lifetime of temporaries
Using an interface variable as an lvalue extends the lifetime of that
temporary in the same way that assigning a temporary to a reference does.

*Typecasting Precedence
A conversion from object to interface variable has precedence just above
that of a user defined typecast, but less than all other conversions.

*dynamic_cast
Interface variables can be cast to the type of object they refer to using
dynamic_cast, this returns a type-safe pointer to the internal object.

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

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

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

*Inheritance
An interface can inherit from one or more interfaces. Syntax of inheritance
of interfaces is as follows:
  inheritance_list ::= interface_name [, interface_name]*

  interface inteface_name : inheritance_list {
    // ...
  };

Notice that there are no qualifiers allowed before an interface name from
the inheritance list. Interfaces only ever publicly inherit from other
interfaces. Classes or structs can not inherit from interfaces.

--
Christopher Diggins
Licensed under the Open Software License version 2.0
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                       ]