Another good URL for all you C++ haters

Another good URL for all you C++ haters

[Chris M. Moore]

http://www.byte.com/documents/s=1271/byt20010831s0001/0903_nichols.html

Excerpt:

  Even Floyd, who loves the language, admits that, "Its greatest
  weaknesses is a flaw in the interface/implementation separation. A
  class exposes its private data/methods to the world and a programmer
  must use some tricks (that should be supported directly in the
  language) to overcome this."

Whay I'd really like to see which would give Ada a huge lead over Java
would be a tool which takes C++ declarations and produced Ada
bindings.  The GNAT User manual hints that such a tool exists but
states that ACT don't distribute it.  I remember seeing something
somewhere about bindings being generated automatically by SGI.  Are
these tools still available?
 
--
Chris M. Moore
Software engineer
speaking for myself

Re: Another good URL for all you C++ haters

[Gerhard Häring]

Chris M. Moore wrote:
> http://www.byte.com/documents/s=1271/byt20010831s0001/0903_nichols.html
> 
> Excerpt:
> 
>   Even Floyd, who loves the language, admits that, "Its greatest
>   weaknesses is a flaw in the interface/implementation separation. A
>   class exposes its private data/methods to the world and a programmer
>   must use some tricks (that should be supported directly in the
>   language) to overcome this."
> 
> Whay I'd really like to see which would give Ada a huge lead over Java
> would be a tool which takes C++ declarations and produced Ada
> bindings.  The GNAT User manual hints that such a tool exists but
> states that ACT don't distribute it.

Could you tell us where in the manual to find this hint?

> I remember seeing something
> somewhere about bindings being generated automatically by SGI.  Are
> these tools still available?`

You can google for "c2ada" and "cbind".

IMO these tools inevitably suck because complicated C headers with lots 
of #defines (even parts of structs conditionally defined in and out and 
such; nested structs, ...) don't map nicely to Ada (for pyAda, I ended 
up writing all the interfacing stuff by hand).

That's why COM, CORBA, XPCOM and friends where invited. Have an IDL/type 
library describe the interface and create correct bindings for your 
language automatically.

Gerhard
-- 
Gerhard H�ring
skynamics AG
g.haering@skynamics.com
http://www.skynamics.com

Re: Another good URL for all you C++ haters

[Ted Dennison]

In article <3B961909.4020705@___skynamics.com.invalid>, Gerhard
=?ISO-8859-1?Q?H=E4ring?= says...
>
>Chris M. Moore wrote:
>> http://www.byte.com/documents/s=1271/byt20010831s0001/0903_nichols.html
>> would be a tool which takes C++ declarations and produced Ada
>> bindings.  The GNAT User manual hints that such a tool exists but
>> states that ACT don't distribute it.
>
>Could you tell us where in the manual to find this hint?

I can point you to a usenet posting:
http://groups.google.com/groups?q=binding+generator+group:comp.lang.ada+author:dewar&hl=xx-bork&safe=off&rnum=3&selm=7j4lua%242rs%241%40nnrp1.deja.com

I'd paraphrase it, but that always seems to get me in trouble. So I'll quote an
excerpt (Sorry for the confusing header field names. I have my Google set to
Mock-Sweedish. Think Sweedish Chef when you read them.)
----
Frum:Robert Dewar (dewar@gnat.com)
Soobject:Re: Ada and C++; Any Gurus Out There?
Noosgruoops:comp.lang.ada
Dete-a:1999/06/03 

..
As I have noted before, ACT has long term plans to make this
binding generator available, but we do not have any release
data for this product (it is the binding generator that was
used to generate all the SGI C++ bindings that come with the
SGI Ada 95 product).


---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Another good URL for all you C++ haters

[Chris M. Moore]

On Wed, 05 Sep 2001 13:43:05 GMT, Ted Dennison<dennison@telepath.com>
wrote:

>In article <3B961909.4020705@___skynamics.com.invalid>, Gerhard
>=?ISO-8859-1?Q?H=E4ring?= says...
>>
>>Chris M. Moore wrote:
>>> http://www.byte.com/documents/s=1271/byt20010831s0001/0903_nichols.html
>>> would be a tool which takes C++ declarations and produced Ada
>>> bindings.  The GNAT User manual hints that such a tool exists but
>>> states that ACT don't distribute it.
>>
>>Could you tell us where in the manual to find this hint?

Whoops: GNAT *Reference* manual, section on Interfacing to C++.

<snip>

>As I have noted before, ACT has long term plans to make this
>binding generator available, but we do not have any release
>data for this product (it is the binding generator that was
>used to generate all the SGI C++ bindings that come with the
>SGI Ada 95 product).

Interesting. So the tool is owned by ACT.

--
Chris M. Moore
Software engineer
speaking for myself

Re: Another good URL for all you C++ haters

[Robert Dewar]

chris.m.moore@amsjv.com (Chris M. Moore) wrote in message news:<3b97643b.14694078@news.geccs.gecm.com>...
> >>Chris M. Moore wrote:

> Interesting. So the tool is owned by ACT.

No, SGI owns this tool, we have access to the software
but it would require major rewriting (to disentangle it
from its proprietary C++ front end) before it could be
distributed, and at the current time we have no plans
to do this.

Re: Another good URL for all you C++ haters

[Chris M. Moore]

On 6 Sep 2001 12:12:24 -0700, dewar@gnat.com (Robert Dewar) wrote:

>chris.m.moore@amsjv.com (Chris M. Moore) wrote in message news:<3b97643b.14694078@news.geccs.gecm.com>...
>> >>Chris M. Moore wrote:
>
>> Interesting. So the tool is owned by ACT.
>
>No, SGI owns this tool, we have access to the software
>but it would require major rewriting (to disentangle it
>from its proprietary C++ front end) before it could be
>distributed, and at the current time we have no plans
>to do this.

Thanks for this correction Robert; I hoped you were listening.  :-)

I think it would be a huge advantage for Ada to have a tool which
could even semi-automate the generation of bindings to C++ code.
However, I'm not about to volunteer to write one as all my
free-software effort is currently expended on the glacial kUML
project.  (Hmm, reverse engineer C++ code into UML diagrams then
generate Ada bindings from UML?  Once the repository is done and the
XMI input/output is working.  *sigh*)

--
Chris M. Moore
Software engineer
speaking for myself

Re: Another good URL for all you C++ haters

[Larry Kilgallen]

In article <3b989a2c.5346207@news.geccs.gecm.com>, chris.m.moore@amsjv.com (Chris M. Moore) writes:

> I think it would be a huge advantage for Ada to have a tool which
> could even semi-automate the generation of bindings to C++ code.
> However, I'm not about to volunteer to write one as all my
> free-software effort is currently expended on the glacial kUML
> project.  (Hmm, reverse engineer C++ code into UML diagrams then
> generate Ada bindings from UML?  Once the repository is done and the
> XMI input/output is working.  *sigh*)

Perhaps someone would write one as non-free software product.
However, semi-automate is a slippery support slope.

Re: Another good URL for all you C++ haters

[Florian Weimer]

chris.m.moore@amsjv.com (Chris M. Moore) writes:

> I think it would be a huge advantage for Ada to have a tool which
> could even semi-automate the generation of bindings to C++ code.

C++ with its inline functions, preprocessor and other stuff is an
extreme job for a binding generator.  A more practical approach (which
admittedly features some implementation difficulties) would be the
integration of a (partial) C++ compiler into an Ada compiler, so that
you can import C++ declarations into Ada code.

Re: Another good URL for all you C++ haters

[James Rogers]

The author of this article claims he spoke to a lot of C++
programmers. He may have. He also posted a questionnaire on
comp.lang.c++.moderated asking specific questions about C++. The
thread in that newsgroup is titled "Whether C++?".
I know, it should be "Whither", as in the article, but he misspelled
the title in his posting.

I learned a lot from the responses to this article. Mostly I learned
that many C++ programmers know only C, C++, Java, and Perl. They do
not know about any languages not descended from C syntax.

For instance, several responders stated that the primary strength of
C++ is that it is the only language that gives you a choice of 
design paradigms (OO and non-OO) as well as generics and low level
programming capability. This is a clear indication that those
responders have no understanding of Ada.

There was general agreement that C++ is a very complex language.
It is so complex that, four years after its standardization, there
are no compilers fully compliant with the standard. Some people see
this as a problem. Some people see it as a good thing. I only hope
I do not have to work with anybody who thinks it is best to use a
tool that takes years of study before it can be used correctly.

I do not hate C++. I do have an aversion to ignorance masquerading
as knowledge. My conclusion from the thread was that many people
prefer C++ because they are ignorant of any alternatives.

Jim Rogers
Colorado Springs, Colorado USA

"Chris M. Moore" wrote:
> 
> http://www.byte.com/documents/s=1271/byt20010831s0001/0903_nichols.html

Re: Another good URL for all you C++ haters

[Florian Weimer]

chris.m.moore@amsjv.com (Chris M. Moore) writes:

>   Even Floyd, who loves the language, admits that, "Its greatest
>   weaknesses is a flaw in the interface/implementation separation. A
>   class exposes its private data/methods to the world and a programmer
>   must use some tricks (that should be supported directly in the
>   language) to overcome this."

Doesn't have Ada a similar problem?

Re: Another good URL for all you C++ haters

[James Rogers]

Florian Weimer wrote:
> 
> chris.m.moore@amsjv.com (Chris M. Moore) writes:
> 
> >   Even Floyd, who loves the language, admits that, "Its greatest
> >   weaknesses is a flaw in the interface/implementation separation. A
> >   class exposes its private data/methods to the world and a programmer
> >   must use some tricks (that should be supported directly in the
> >   language) to overcome this."
> 
> Doesn't have Ada a similar problem?

Similar but not quite as severe.

Ada private data and subprograms are what C++ calls "protected" 
data/methods. Ada's eqivalent to C++ private data/methods is data and 
methods defined in a package body but not in the specification.
C++ public, private, and protected data and functions are normally
declared in a header file. Functions are then defined in the
.CPP (source) file. 

There is no automatic enforcement of separation of implementation and
interface in C++. The entire implementation can be placed in the C++
header file. As with so many other C++ features, only good practice
can produce good separation of interface and implementation.

Compare both C++ and Ada to Java. Most Java classes are defined
without benefit of an interface. In fact, Java interfaces are
most typically used to define a call-back interface rather than to
define common classes. Java does not even provide you the choice 
of using a header file. Java fans proclaim a lack of separation of
interface and implementation to be an advantage because you have
less code duplication.

Jim Rogers
Colorado Springs, Colorado USA

Re: Another good URL for all you C++ haters

[John McCabe]

On Wed, 05 Sep 2001 21:49:24 GMT, James Rogers
<jimmaureenrogers@worldnet.att.net> wrote:

> Java fans proclaim a lack of separation of
>interface and implementation to be an advantage because you have
>less code duplication.

In my experience, Java fans claim that the Interface/Implementation
separation feature of OO is provided by the Java Interface structure
and Class structure (i.e. the Interface provides the Interface, and
the Class provides the Implementation). This seems a very high level
viewpoint corresponding to something like a pure virtual class (C++),
or abstract tagged type (Ada) rather than what Ada programmers often
see as the separation, i.e. the package spec/body.

Personally I believe it is a combination of both.

Best Regards
John McCabe

Re: Another good URL for all you C++ haters

[James Rogers]

John McCabe wrote:
> 
> On Wed, 05 Sep 2001 21:49:24 GMT, James Rogers
> <jimmaureenrogers@worldnet.att.net> wrote:
> 
> > Java fans proclaim a lack of separation of
> >interface and implementation to be an advantage because you have
> >less code duplication.
> 
> In my experience, Java fans claim that the Interface/Implementation
> separation feature of OO is provided by the Java Interface structure
> and Class structure (i.e. the Interface provides the Interface, and
> the Class provides the Implementation). This seems a very high level
> viewpoint corresponding to something like a pure virtual class (C++),
> or abstract tagged type (Ada) rather than what Ada programmers often
> see as the separation, i.e. the package spec/body.
> 
> Personally I believe it is a combination of both.

Java also allows the definition of abstract classes. They have the
expected restrictions such as not being able to create an instance
of an abstract class. Java interfaces are treated differently by the
language. In Java you can extend (inherit from) only one class,
producing single inheritance similar to Ada's. On the other hand,
you can implement any number of interfaces, and interfaces may
inherit from other interfaces.

In many cases you can program Java entirely without the use of
interfaces. Exceptions to this include the use of event handlers.
Java event handlers are commonly used in GUIs and the reusable
code modules called Java Beans.

Note that, for Java Beans, only the event handler interface is
required. There is no interface requirement for the get and set
methods for Bean properties. Common practice, then, provides only
partial separation of interface and implementation for Java Beans.
Builder tools that use Java Beans employ introspection to evaluate
Bean properties. In this case the implementation must report its
interface at run time. 

Furthermore, there is no way to specify a constructor in a Java
interface. Thus, even if you are diligent about building your Java
classes from interfaces, you must still omit critical parts of the
class definition.

Why is introspection not as good as explicit separation of 
interface and implementation? Not every program uses introspection.
Furthermore, introspection is a run-time activity. This means that
compilers must have access to full implementation code, even though
Java exclusively uses a shared library (aka dll) model for linking.
There is no way in Java to perform an early compilation of just the
interfaces, as can be done in Ada. Lack of separation inhibits large
team development.

Jim Rogers
Colorado Springs, Colorado USA

Re: Another good URL for all you C++ haters

[Tucker Taft]

Florian Weimer wrote:
> 
> chris.m.moore@amsjv.com (Chris M. Moore) writes:
> 
> >   Even Floyd, who loves the language, admits that, "Its greatest
> >   weaknesses is a flaw in the interface/implementation separation. A
> >   class exposes its private data/methods to the world and a programmer
> >   must use some tricks (that should be supported directly in the
> >   language) to overcome this."
> 
> Doesn't have Ada a similar problem?

Ada requires the full definition of a private type to be
in the package spec, but it doesn't require the declaration
of "helper" functions the way C++ does.  Helper functions
can be declared in the package body, without perturbing the spec.

[In C++, one can use a "friend" class to contain the helper
functions, but that is pretty obscure.]

Note that both C++ and Ada allow access/pointer types to be declared
without exposing the full details of the target type.
-- 
-Tucker Taft   stt@avercom.net   http://www.avercom.net
Chief Technology Officer, AverCom Corporation (A Titan Company) 
Bedford, MA  USA (AverCom was formerly the Commercial Division of AverStar:
http://www.averstar.com/~stt)

Re: Another good URL for all you C++ haters

[Florian Weimer]

Tucker Taft <stt@avercom.net> writes:

> Ada requires the full definition of a private type to be
> in the package spec, but it doesn't require the declaration
> of "helper" functions the way C++ does.  Helper functions
> can be declared in the package body, without perturbing the spec.

If you do this, these helper subprograms aren't primitive operations,
are they?  In C++, it is possible to have private virtual member
functions.  I'm not sure if you really need them in C++ (perhaps for
something RTTI-related things?), and you can probably use class-wide
programming to achieve the same effect in Ada.