Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Warren W. Gay VE3WWG]

Hyman Rosen wrote:
> Richard Riehle wrote:
> 
>> In Ada, used well
> 
> I suspect that you are a Japanese Joiner as well :-)
> 
> I think that any of the regular posters here would be
> able to program as well in C++ as in Ada. I'm pretty
> sure that if I had to work in Ada it wouldn't take me
> very long to get up to expert level.

Well, I can say that for small projects, your statement
is probably true.

But I can speak for my own experience, that in
largish C++ projects, I always spent an incredible amount of
time looking in core files and working with a debugger to
find out why some "strange behaviour" was happening in
those C++ projects. Sometimes it was related to those
automatic type promotions, and at other times, it was
related to memory corruption problems of one sort or
another (and it need not even be your own code! Sometimes
C++ library code does this to you).

On top of all this, once you get your large C++ application
to actually work, you then want to "port it" to another
platform, with sometimes a different compiler (or even
a different/updated gcc compiler). What do you find?

   - Changed behavior in automatic type promotion, leading
     to changed application behavior
   - #include file problems
   - C++ library incompatibilities/limitations

Sure you can say that this occurs due to poor planning,
or design. But the Ada point is that this is not checked,
nor enforced up front by your tools.  My hobby time is
time I hate wasting this way ;-)

In smallish projects, Ada sometimes takes me longer. This
is usually due to library issues and bindings.

The payoff is huge though (for me) in largish projects. In
the last 4 years (I think) of using Ada (since my conversion ;),
I've only encountered memory corruption once (I had freed
an object twice due a logic/design error).  The rest of
my time is "quality time with the compiler", learning how
to avoid certain design errors, and learning how to better
engineer modules so that the dependencies are pure and
correct (C++'s elaboration is pale by comparison). My
debugging time is 25% or less of the C++ debugging time.
(This gives me a much more pleasant use of my hobby time).

When I debug, it is because I am finding out why _I_ made
some logic error. It is not due to corruption, or some
faulty elaboration order; not due to external memory
references that the linker decided were the same (name
collision), not due to #include file sequence, not due
to automatic type promotion surprises etc.

SUMMARY:

I don't agree with your statement for large projects.


> You're probably right about the level of C++ code around.
> It's easy to bludgeon C++ code into submission when it
> won't compile, instead of understanding what is wrong.

I also believe that inexperienced programmers can produce
better code in Ada95. You won't get the same from them
in C++, even if they can wrap their head around the existing
code they must read and customize.

But then, this is just my opinion on the subject.


DON'T TRY THIS AT HOME 8-)

Ada programmers may wince at this, but here is something that
I find really useful about Ada95 for my own Open
Source development:

If I look at a spec of a package I want to "clean up", and
I don't like the way the data type is presented, and want
to make some sort of wholesale change to the package, I'll
first make the necessary tweaks or major changes to the
specs. This may include:

  - Changing constants to enumerated types / vice versa
  - Changing a weak type to a strong type
  - Making types more range specified (subtypes)
  - Changing function/procedure API changes
  - Change a record/tagged type (class) to the other kind
  etc.

Then I jump into emacs, and start invoking "make" and let
the compiler tell me about all of those new errors that will
now spew of the compiler. Using emacs I jump to the source
of the error (using emacs macros) and make all the necessary
changes, until the errors go away. With Ada95 this has
never failed me, though I expect some little case may
bite me some day, doing changes like this.

THIS HAS NEVER WORKED WELL FOR C++. C++ would never identify
all of the necessary changes, because of the number of
"automatic conversions" and so on.  C++ never tells you
that you have a missing case in a switch statement, and
its very forgiving mixing enumerated types with ints etc.
C++ will not tell you when a related constant or #define
needs to be updated.

This Ada95 feature has made it possible for me to very
quickly produce clean library interfaces, because I am
not reluctant to make wholesale changes when I
think it might be beneficial to the client.


CURIOUSITY POLL?

I'd be interested if anyone actually uses this type of
procedure in more "critical" application development roles.
I am sure that others must take advantage of this, if not
secretly so? ;-)  Is this type of thing frowned upon by
DOD projects, or do they even know this type of thing
happens? Just curious.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Robert Spooner]

Warren W. Gay VE3WWG wrote:
> ...
> This Ada95 feature has made it possible for me to very
> quickly produce clean library interfaces, because I am
> not reluctant to make wholesale changes when I
> think it might be beneficial to the client.
> 
> 
> CURIOUSITY POLL?
> 
> I'd be interested if anyone actually uses this type of
> procedure in more "critical" application development roles.
> I am sure that others must take advantage of this, if not
> secretly so? ;-)  Is this type of thing frowned upon by
> DOD projects, or do they even know this type of thing
> happens? Just curious.
> 


I have done this. It's particularly helpful when I haven't gotten the 
design right the first time because of a lack of information early-on. I 
can't imagine doing it in any other language. Ada allows you to use the 
computer for things that computers are good for and humans are not - all 
that consistency checking. When I first was learning Ada I was 
astonished at the percentage of my programs that did exactly what I 
wanted once I had a clean compile. My debugger skills atrophied.

Bob
-- 
                             Robert L. Spooner
                      Registered Professional Engineer
                        Associate Research Engineer
                   Intelligent Control Systems Department

          Applied Research Laboratory        Phone: (814) 863-4120
          The Pennsylvania State University  FAX:   (814) 863-7841
          P. O. Box 30
          State College, PA 16804-0030       rls19@psu.edu

RE: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Beard, Frank Randolph CIV]

-----Original Message-----
From: Warren W. Gay VE3WWG [mailto:ve3wwg@cogeco.ca]

> CURIOUSITY POLL?
>
> I'd be interested if anyone actually uses this type of
> procedure in more "critical" application development roles.
> I am sure that others must take advantage of this, if not
> secretly so? ;-)  Is this type of thing frowned upon by
> DOD projects, or do they even know this type of thing
> happens? Just curious.

I don't know how "critical" you mean, but I've used this
feature of Ada on a number of occasions which stemmed 
multiple projects from running the on ground test chambers 
for the Space Shuttle group, to the onboard Space Station
data storage and retrieval component, to a Naval 
communications project.

Even though our tools usually give us the capability to
see a callers graph, it is still more useful to prototype
changes in the spec and have the compiler reliably show me
the immediate impacts of the changes.  And once the changes
made it to fruition, they required very little debugging.

I don't think I've ever openly shared this information even
with fellow Ada developers, but it sure does make things
easier.

Frank

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[David Botton]

Doesn't every one do this?

Richard Riehle once wrote:

" But the compiler will catch any potential ambiguities.   This is
the key point.  Ada is designed to detect inconsistencies, irregularities,
discontinuities, incongruencies, and unconfirmable constructs earlier in
the software development process than any other language. "

Also, see his article on Ada Power at:
http://www.adapower.com/articles/capsule.html

This is THE reason that Ada should be THE choice for almost every project.
In particular for the free time hack!

David Botton

----- Original Message -----
From: "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>
> DON'T TRY THIS AT HOME 8-)

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Jerry Petrey]

"Warren W. Gay VE3WWG" wrote:

>
>
> CURIOUSITY POLL?
>
> I'd be interested if anyone actually uses this type of
> procedure in more "critical" application development roles.
> I am sure that others must take advantage of this, if not
> secretly so? ;-)  Is this type of thing frowned upon by
> DOD projects, or do they even know this type of thing
> happens? Just curious.
>
> --
> Warren W. Gay VE3WWG
> http://home.cogeco.ca/~ve3wwg

You mean there is another way? :-)
I have always used this method with Ada development.
That is one of the things I love about Ada - you can let the compiler do so
much of the work for you. I have often had people new to Ada come to me
asking "can I do this or that in Ada?" - I usually tell them to try it and see
- let
the compiler tell you if it won't work; you will learn something from the
exercise
in either case.  It is hard to imagine using a language and compiler without
this level of
checking again.

Jerry
--
---------------------------------------------------------------------------------

-- Jerry Petrey
-- Senior Principal Systems Engineer - Navigation (GPS/INS), Guidance, &
Control
-- Raytheon Missile Systems          - Member Team Ada & Team Forth
-- NOTE: please remove <NOSPAM> in email address to reply
---------------------------------------------------------------------------------

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Jeffrey Carter]

Jerry Petrey wrote:
 >
 > I have always used this method with Ada development. That is one of
 > the things I love about Ada - you can let the compiler do so much of
 > the work for you.

 > It is hard to imagine using a language and compiler without this
 > level of checking again.

I agree wholeheartedly. Ada has made me fat and lazy. There is one
caveat: compiler errors. I have (rarely) had things work that shouldn't
have in situations like this because of compiler errors.

-- 
Jeff Carter
"You empty-headed animal-food-trough wiper."
Monty Python & the Holy Grail

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Richard Riehle]

"Warren W. Gay VE3WWG" wrote:

> If I look at a spec of a package I want to "clean up", and
> I don't like the way the data type is presented, and want
> to make some sort of wholesale change to the package, I'll
> first make the necessary tweaks or major changes to the
> specs. This may include:
>
>   - Changing constants to enumerated types / vice versa

One of the things I find useful is to make constants into function
declarations.  As a trivial example,

       package Constants is
           function Ten return Integer;
           pragma Inline(Ten);
           function Avogradro return Float;
           pragma Inline(Avogadro);
       end Constants;

something I cannot do in C++ because of the need to have a full
implementation to create an inlined function.   This allows me
to compile the body separately, have whatever implementation
I wish, and modify the implementation if the need arises without
changing the specification.

>
>  - Changing a weak type to a strong type
>   - Making types more range specified (subtypes)

Not sure you meant that as shown.   Subtypes actually relax
the type model a little.  Also, I have seen problems with declaring
too many different real number types in some programs.

Richard Riehle

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Hyman Rosen]

Richard Riehle wrote:
> something I cannot do in C++ because of the need to have a full
> implementation to create an inlined function.

In Ada, if you have an inline function, the compiler wants to
see its body as well. This isn't particularly different from
C++. Of couse, in C++ you can't "silently" change a constant
into a function because to call a parameterless function in
C++ you still must supply parentheses.

> This allows me to compile the body separately, have whatever
 > implementation I wish, and modify the implementation if the
 > need arises without changing the specification.

If the function is inline and you change its implementation,
the compiler is going to want to recompile all its callers.

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[K]

Richard Riehle <richard@adaworks.com> wrote in message news:<3E432DD4.7F256C85@adaworks.com>...
> "Warren W. Gay VE3WWG" wrote:
> 
> > If I look at a spec of a package I want to "clean up", and
> > I don't like the way the data type is presented, and want
> > to make some sort of wholesale change to the package, I'll
> > first make the necessary tweaks or major changes to the
> > specs. This may include:
> >
> >   - Changing constants to enumerated types / vice versa
> 
> One of the things I find useful is to make constants into function
> declarations.  As a trivial example,
> 
>        package Constants is
>            function Ten return Integer;
>            pragma Inline(Ten);
>            function Avogradro return Float;
>            pragma Inline(Avogadro);
>        end Constants;
> 
> something I cannot do in C++ because of the need to have a full
> implementation to create an inlined function.   This allows me
> to compile the body separately, have whatever implementation
> I wish, and modify the implementation if the need arises without
> changing the specification.

If the function is inlined, won't a change in the function body
force a recompilation of any package that called the function?
And if so, then isn't the effect the same as a specification change?

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Vinzent Hoefler]

slatyb@yahoo.com (K) wrote:

>If the function is inlined, won't a change in the function body
>force a recompilation of any package that called the function?

Yes, of course.

>And if so, then isn't the effect the same as a specification change?

No, because there are no changes needed in the source of the calling
code.


Vinzent.

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[K]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:<3E42A61C.20905@cogeco.ca>...
> But I can speak for my own experience, that in
> largish C++ projects, I always spent an incredible amount of
> time looking in core files and working with a debugger to
> find out why some "strange behaviour" was happening in
> those C++ projects. Sometimes it was related to those
> automatic type promotions, and at other times, it was
> related to memory corruption problems of one sort or
> another (and it need not even be your own code! Sometimes
> C++ library code does this to you).

Ada library code doesn't do this to you because there is none.
But any Ada code that uses new/unchecked_deallocation has the
potential
to corrupt the heap.

> 
> On top of all this, once you get your large C++ application
> to actually work, you then want to "port it" to another
> platform, with sometimes a different compiler (or even
> a different/updated gcc compiler). What do you find?

Why not just port to the same version of gcc?

> 
>    - Changed behavior in automatic type promotion, leading
>      to changed application behavior
>    - #include file problems
>    - C++ library incompatibilities/limitations

I'm guessing that you only use a single Ada compiler, GNAT.
The Ada standard is a few years older than the C++ standard,
so there is less change between compiler versions.
Gcc has tried to track the C++ standard as it evolved from draft
to draft, so naturally there have been language changes from 
version to version.  And every system vendor provides a licensed
C++ compiler, and they have converged on the standard at different
rates.  The obvious solution is to do the same thing you have done
with Ada: build the same version of gcc on every platform.

> 
> Sure you can say that this occurs due to poor planning,
> or design. But the Ada point is that this is not checked,
> nor enforced up front by your tools.  My hobby time is
> time I hate wasting this way ;-)
> 
> In smallish projects, Ada sometimes takes me longer. This
> is usually due to library issues and bindings.
> 
> The payoff is huge though (for me) in largish projects. In
> the last 4 years (I think) of using Ada (since my conversion ;),
> I've only encountered memory corruption once (I had freed
> an object twice due a logic/design error).  The rest of
> my time is "quality time with the compiler", learning how
> to avoid certain design errors, and learning how to better
> engineer modules so that the dependencies are pure and
> correct (C++'s elaboration is pale by comparison). My
> debugging time is 25% or less of the C++ debugging time.
> (This gives me a much more pleasant use of my hobby time).
> 
> When I debug, it is because I am finding out why _I_ made
> some logic error. It is not due to corruption, or some
> faulty elaboration order; not due to external memory
> references that the linker decided were the same (name
> collision), not due to #include file sequence, not due
> to automatic type promotion surprises etc.
> 
> SUMMARY:
> 
> I don't agree with your statement for large projects.
> 
> 
> > You're probably right about the level of C++ code around.
> > It's easy to bludgeon C++ code into submission when it
> > won't compile, instead of understanding what is wrong.
> 
> I also believe that inexperienced programmers can produce
> better code in Ada95. 

Their code may be less prone to crash, but it also is 
less featureful because they have relatively few libraries
to draw upon, and none have a large user base.

> You won't get the same from them
> in C++, even if they can wrap their head around the existing
> code they must read and customize.
> 
> But then, this is just my opinion on the subject.
> 
> 
> DON'T TRY THIS AT HOME 8-)
> 
> Ada programmers may wince at this, but here is something that
> I find really useful about Ada95 for my own Open
> Source development:
> 
> If I look at a spec of a package I want to "clean up", and
> I don't like the way the data type is presented, and want
> to make some sort of wholesale change to the package, I'll
> first make the necessary tweaks or major changes to the
> specs. This may include:
> 
>   - Changing constants to enumerated types / vice versa
>   - Changing a weak type to a strong type
>   - Making types more range specified (subtypes)
>   - Changing function/procedure API changes
>   - Change a record/tagged type (class) to the other kind
>   etc.
> 
> Then I jump into emacs, and start invoking "make" and let
> the compiler tell me about all of those new errors that will
> now spew of the compiler. Using emacs I jump to the source
> of the error (using emacs macros) and make all the necessary
> changes, until the errors go away. With Ada95 this has
> never failed me, though I expect some little case may
> bite me some day, doing changes like this.
> 
> THIS HAS NEVER WORKED WELL FOR C++. 

It works very well for me.  It even works on the fairly large body of
commercial code that I am currently maintaining.  
Recently I needed to delete a business rule, and I started by deleting
an argument from the declaration of the function that enforced the
rule.
Then I just fixed compile errors recursively until there were no more.

> C++ would never identify
> all of the necessary changes, because of the number of
> "automatic conversions" and so on.  C++ never tells you
> that you have a missing case in a switch statement, and
> its very forgiving mixing enumerated types with ints etc.

You can convert enumerated types to int, but can not
convert ints to enumerated types.  Even the first conversion
could be unfortunate if one wanted to change an argument type
from an enumeration to int.  However, I prefer to wrap enumerations
in a typesafe template class.  But switch statements are much safer
in Ada.  I avoid them in C++ because it's too easy to miss one.

> C++ will not tell you when a related constant or #define
> needs to be updated.

Nor will Ada, nor any other language.  If you declare
x = 17, and y = 289, no compiler will divine
that y should be equal to x*x.  But it's certainly
possible in C++ to define the y in terms of x.
This sounds like a comparison of correct Ada practice with
poor C++ practice.

With templates, you can even compute functions
of integer constants at compile time:
    const int x = 8;
    const int y = Factorial<x>::value;

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Ole-Hjalmar Kristensen]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

> Hyman Rosen wrote:
> > Richard Riehle wrote:
> >
> >> In Ada, used well
> > I suspect that you are a Japanese Joiner as well :-)
> > I think that any of the regular posters here would be
> > able to program as well in C++ as in Ada. I'm pretty
> > sure that if I had to work in Ada it wouldn't take me
> > very long to get up to expert level.
> 
> Well, I can say that for small projects, your statement
> is probably true.
> 
> But I can speak for my own experience, that in
> largish C++ projects, I always spent an incredible amount of
> time looking in core files and working with a debugger to
> find out why some "strange behaviour" was happening in
> those C++ projects. Sometimes it was related to those
> automatic type promotions, and at other times, it was
> related to memory corruption problems of one sort or
> another (and it need not even be your own code! Sometimes
> C++ library code does this to you).
> 
> On top of all this, once you get your large C++ application
> to actually work, you then want to "port it" to another
> platform, with sometimes a different compiler (or even
> a different/updated gcc compiler). What do you find?
> 
>    - Changed behavior in automatic type promotion, leading
>      to changed application behavior
>    - #include file problems
>    - C++ library incompatibilities/limitations
> 
> Sure you can say that this occurs due to poor planning,
> or design. But the Ada point is that this is not checked,
> nor enforced up front by your tools.  My hobby time is
> time I hate wasting this way ;-)

I mostly agree with you, but Ada systems may bite you too. I have a
small program which essentially does a test of the speed of the file
system, while running multiple tasks. This program has been unchanged
for years, has run fine on Solaris, NT, Linux. I recently installed
SuSe 8.1, compiled the program and ran it. Result: Segmentation violation, no
other messages. Started gdb, which promptly crashed with an internal
error.  

Turned on stack checking, still same result.  

Decreased the size of the buffer, allocated on the stack, as I
suspected that I had exceeded max stack size for a task, and it
worked fine.

As a last test, increased the buffer size to twice of what it was
originally, and then got the expected exception.

-- 
Ole-Hj. Kristensen

******************************************************************************
* You cannot consistently believe this sentence.
******************************************************************************

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Dmitry A. Kazakov]

On Thu, 06 Feb 2003 13:14:52 -0500, "Warren W. Gay VE3WWG"
<ve3wwg@cogeco.ca> wrote:

[skip]

>CURIOUSITY POLL?
>
>I'd be interested if anyone actually uses this type of
>procedure in more "critical" application development roles.
>I am sure that others must take advantage of this, if not
>secretly so? ;-)  Is this type of thing frowned upon by
>DOD projects, or do they even know this type of thing
>happens? Just curious.

I am using this technique for both C++ and Ada, mostly because the
strategy of our firm and our customers is: "very quick and incredibly
dirty". (:-))

It works perfectly in Ada, but has serious problems in C++, especially
with MS VC++, which is unable to recompile as necessary, even if
precompiled hearders are not used (this feature does not work anyway).
It is disastrous because a recompile-all lasts for 4-hours to see how
thousands compile errors appear on the screen. Add here, that during
compilation one cannot edit because of a "perfect" team work of MS IDE
and the operating system, which block the whole system for 10-15 sec
during code generation and linking. The project is large indeed, and
it seems so that we pushed it to the very limit of what could be done
with C++, probably beyond it.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Richard Riehle]

Hyman Rosen wrote:

> If the function is inline and you change its implementation,
> the compiler is going to want to recompile all its callers.

But no change to corresponding specifications.   The only thing
that needs to be recompiled is the implementating code and that
is compiled separately within package bodies.    This preserves
the integrity of the design.  Also,  there is no need to modify
any code, only to recompile a few of the bodies.

This is substantially different from the C++ model.

Richard Riehle

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Kevin Cline]

Richard Riehle <richard@adaworks.com> wrote in message news:<3E43FA31.9873C5AA@adaworks.com>...
> Hyman Rosen wrote:
> 
> > If the function is inline and you change its implementation,
> > the compiler is going to want to recompile all its callers.
> 
> But no change to corresponding specifications.   The only thing
> that needs to be recompiled is the implementating code and that
> is compiled separately within package bodies.    This preserves
> the integrity of the design.  Also,  there is no need to modify
> any code, only to recompile a few of the bodies.
> 
> This is substantially different from the C++ model.

I don't see the substantial difference, except that in C++ the
same syntax can not be used for data access and a niladic function call.

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Richard Riehle]

Kevin Cline wrote:

> Richard Riehle <richard@adaworks.com> wrote in message news:<3E43FA31.9873C5AA@adaworks.com>...
> > Hyman Rosen wrote:
> >
> > > If the function is inline and you change its implementation,
> > > the compiler is going to want to recompile all its callers.
> >
> > But no change to corresponding specifications.   The only thing
> > that needs to be recompiled is the implementating code and that
> > is compiled separately within package bodies.    This preserves
> > the integrity of the design.  Also,  there is no need to modify
> > any code, only to recompile a few of the bodies.
> >
> > This is substantially different from the C++ model.
>
> I don't see the substantial difference, except that in C++ the
> same syntax can not be used for data access and a niladic function call.

In C++, an inline function must be fully implemented in the class specification.
In Ada, one cannot include an implementation in a specification.   The implementing
code is separately compiled in the body.   This means that one need not
recompile the declarations when changing the implementation, in Ada.  In
C++, any change to the implementation requires recompilation of all
the dependent and derived class declarations.   This is a substantial
difference.

Richard Riehle

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Hyman Rosen]

Richard Riehle wrote:
> In C++, an inline function must be fully implemented in the class specification.
> In Ada, one cannot include an implementation in a specification.   The implementing
> code is separately compiled in the body.   This means that one need not
> recompile the declarations when changing the implementation, in Ada.  In
> C++, any change to the implementation requires recompilation of all
> the dependent and derived class declarations.   This is a substantial
> difference.

This is simply false. C++ requires that if you call an inline function,
the definition of that function must appear in the translation unit that
contains the call. It is not required to appear in the class definition,
nor must it appear when defining derived classes. The stated consequences
are thus also false. Richard, you are confusing typical practice with
actual requirements.

// foo.h
#ifndef FOO_H
#define FOO_H
struct foo { int bar(); };
#endif // FOO_H

// foo.inl
#ifndef FOO_INL
#define FOO_INL
#include "foo.h"
inline int foo::bar() { return 3; }
#endif // FOO_INL

// der.h
#ifndef DER_H
#define DER_H
#include "foo.h"
struct der : foo { int baz(); }
#endif // DER_H

// der.inl
#ifndef DER_INL
#define DER_INL
#include "der.h"
inline int der::baz() { return 7; }
#endif // DER_INL

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Richard Riehle]

Hyman Rosen wrote:

> This is simply false. C++ requires that if you call an inline function,
> the definition of that function must appear in the translation unit that
> contains the call. It is not required to appear in the class definition,
> nor must it appear when defining derived classes. The stated consequences
> are thus also false. Richard, you are confusing typical practice with
> actual requirements.

1) Would you care to comment on why this is typical practice.

2) Can one declare a function as inline, or must one include
     its full definition when it is made inline?

3) In Ada, the equivalent of a declaration can be made inline, in
    the specification.    I believe, if I am reading Stroustrup correctly,
    and, yes, it seems to be typical practice,  any declaration of an
    inline function (as inline) must also be a definition.   If that inline
    function is declared anywhere in the source code, it must be a
    full definition.

Richard Riehle

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Hyman Rosen]

Richard Riehle wrote:
> 1) Would you care to comment on why this is typical practice.

Fewer characters to type, of course. Much less thinking involved.

> 2) Can one declare a function as inline, or must one include
>      its full definition when it is made inline?

The full definition must appear in any translation unit which
calls it. Inline is applied to definitions rather than declarations,
generally; there's not much point to doing otherwise.

> 3) In Ada, the equivalent of a declaration can be made inline, in
>     the specification.    I believe, if I am reading Stroustrup correctly,
>     and, yes, it seems to be typical practice,  any declaration of an
>     inline function (as inline) must also be a definition.   If that inline
>     function is declared anywhere in the source code, it must be a
>     full definition.

You may declare a function to be inline without providing a definition
for it. But any translation unit which uses the function must contain
the definition. (A translation unit is what you get after the preprocessor
has finished doing its work - all the #include files have been merged.)

This all happens as a consequence of C and C++ never having had a module
or package system that would allow the compiler to seek out a separate
file which holds the definition. It's possible to bolt on that sort of
thing; I believe Sun's C++ compilers have such a feature.

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Warren W. Gay VE3WWG]

Beard, Frank Randolph CIV wrote:
> -----Original Message-----
> From: Warren W. Gay VE3WWG [mailto:ve3wwg@cogeco.ca]
>>CURIOUSITY POLL?
>>
>>I'd be interested if anyone actually uses this type of
>>procedure in more "critical" application development roles.
>>I am sure that others must take advantage of this, if not
>>secretly so? ;-)  Is this type of thing frowned upon by
>>DOD projects, or do they even know this type of thing
>>happens? Just curious.
> 
> 
> I don't know how "critical" you mean, but I've used this
> feature of Ada on a number of occasions which stemmed 
> multiple projects from running the on ground test chambers 
> for the Space Shuttle group, to the onboard Space Station
> data storage and retrieval component, to a Naval 
> communications project.
> 
> Even though our tools usually give us the capability to
> see a callers graph, it is still more useful to prototype
> changes in the spec and have the compiler reliably show me
> the immediate impacts of the changes.  And once the changes
> made it to fruition, they required very little debugging.
> 
> I don't think I've ever openly shared this information even
> with fellow Ada developers, but it sure does make things
> easier.
> 
> Frank

I appreciate the comments you and others have made to this
informal "curiosity poll". This confirms the general usefulness
of the Ada compiler in this role. I think this goes a long
way to creating good "APIs", since the programmer is much
more inclined to make sweeping changes if it is seen as
beneficial.

The responses also seem to highlight the fact that C++
programmers think their compiler is doing a
good job of this. I know from personal experience that it
can only be helpful in obvious changes (like adding an
argument to a call). But in my opinion, experienced Ada
programmers are more "enlightened" on this point.

All of the posts were very "interesting". ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Hyman Rosen]

Warren W. Gay VE3WWG wrote:
> All of the posts were very "interesting". ;-)

I remember the days when "keep fixing the code
until it compiles" would have been rank heresy,
and an accusation leveled against C folk :-)

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Larry Kilgallen]

In article <1044900058.276774@master.nyc.kbcfp.com>, Hyman Rosen <hyrosen@mail.com> writes:
> Warren W. Gay VE3WWG wrote:
>> All of the posts were very "interesting". ;-)
> 
> I remember the days when "keep fixing the code
> until it compiles" would have been rank heresy,
> and an accusation leveled against C folk :-)

I was under the impression it was "keep fixing the code until it runs",
since small typographical errors in Ada are more likely to be found.

For Bliss, we (including Bliss programmers) say "keep adding dots until
there is an access violation, then remove the last dot".

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Martin Krischik]

On Fri, 07 Feb 2003 22:49:14 +0000, Richard Riehle wrote:

> Kevin Cline wrote:
 
> 
> In C++, an inline function must be fully implemented in the class
> specification.

This is not true as others have pointed out. In fact you can't do this if
you want virtual inlines. For virtual inlines you have to do it outside
the class definition - and you have to provide a non inline version for
the virtual function table.

usualy you it with some ugly #if #endif:


#if defined (_XXX_CPP_)
#   define inline
#endif

inline void 
MyClass::myFunc ()
  {
  }

#if defined (_XXX_CPP_)
#   undef inline
#endif

And yes: the Ada solution is so much better.

Regards

Martin

-- 
Martin Krischik
mailto://Martin@krischik.com
http://www.martin.krischik.com

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Hyman Rosen]

Martin Krischik wrote:
> In fact you can't do this if you want virtual inlines.

Incorrect as well. You can have a virtual inline with the
definition in the class:
     struct a { virtual void foo() { } };

Perhaps you are thinking of providing an implementation
for an *abstract* method:
     struct a { virtual void foo() = 0; }
     inline void a::foo() { assert(false, "Strange!"); }
It's true in this case that the definition and the '= 0'
cannot appear together.

> For virtual inlines you have to do it outside the class
 > definition and you have to provide a non inline version
 > for the virtual function table.
> usualy you it with some ugly #if #endif:

This is totally wrong - you really should learn more C++
if you are going to make pronouncements about it. Inline
functions don't require any separate definitions for being
called indirectly, whether through the virtual table or by
having their address taken. The compiler takes care of that.

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Martin Krischik]

On Thu, 13 Feb 2003 12:27:32 +0000, Hyman Rosen wrote:

> Martin Krischik wrote:
>> In fact you can't do this if you want virtual inlines.
> 
> Incorrect as well. You can have a virtual inline with the
> definition in the class:
>      struct a { virtual void foo() { } };

I tried that. The compiler won't say a thing - but the linker will be more
then upset. I might uf cource be dependen on the compiler.

> This is totally wrong - you really should learn more C++
> if you are going to make pronouncements about it. Inline
> functions don't require any separate definitions for being
> called indirectly, whether through the virtual table or by
> having their address taken. The compiler takes care of that.

I have 7 Years practical experience programming C++ - programming 8 hours
a day. But prehaps this discussiun shows less about yours and my
experience but more about the fact that no two C++ compilers are the same.

With Regards

Martin 

-- 
Martin Krischik
mailto://Martin@krischik.com
http://www.krischik.com

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Martin Krischik]

On Thu, 13 Feb 2003 12:27:32 +0000, Hyman Rosen wrote:

> Martin Krischik wrote:
>> In fact you can't do this if you want virtual inlines.
> 
> This is totally wrong - you really should learn more C++
> if you are going to make pronouncements about it. Inline
> functions don't require any separate definitions for being
> called indirectly, whether through the virtual table or by
> having their address taken. The compiler takes care of that.

Well, let me elaborate on my previous comment. The problem here is that
the inline method is not attached to any paricular compilation unit (unlike Ada) but,
in worst case need to be elaborated in any compilation unit which includes
the inline. Inline is only a hint, the compiler might or might or might
not honor it.

And most compilers will, of course, optimize here and not elaborate the method
when not used. Anyway, the compiler will need a non inlined version to fill the
virtual function table. And the virtual function table will be needed
wherever the is a contructor. And a contructor might be inline as well or
compiler provided.

That would mean that the virtual inline might be elaborated hundreds of
time - in every compilation unit with a contructor call. With the result
that no two virtual function tables will look the same.

The problem becomes even more interesting when using DLLs.

Some C++ style guides suggest not to use virtual inlines because of it.

Some C++ compiler vendors choose not to automaticly elaborate virtual
inlines because of it. 

And the core statement stays: Ada inlines are superior to C++ inlines.

With Regards

Martin

-- 
Martin Krischik
mailto://Martin@krischik.com
http://www.martin.krischik.com

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Richard Riehle]

OK.  I realize that there is some difference between C++ practice
and what is technically permitted by the language and allowed by
some compilers.    I also note the advice given by various authors
about this kind of thing, many of whom recommend a very conservative
approach since not all compilers behave in the same way.

And after reading all the postings, it seems to me that the Ada model
is still simpler, easier to understand, and more straightforward than
the rather confusing set of rules that characterize C++ inline functions.

Thanks,

Richard Riehle

========================================================

Hyman Rosen wrote:

> Richard Riehle wrote:
> > 1) Would you care to comment on why this is typical practice.
>
> Fewer characters to type, of course. Much less thinking involved.
>
> > 2) Can one declare a function as inline, or must one include
> >      its full definition when it is made inline?
>
> The full definition must appear in any translation unit which
> calls it. Inline is applied to definitions rather than declarations,
> generally; there's not much point to doing otherwise.
>
> > 3) In Ada, the equivalent of a declaration can be made inline, in
> >     the specification.    I believe, if I am reading Stroustrup correctly,
> >     and, yes, it seems to be typical practice,  any declaration of an
> >     inline function (as inline) must also be a definition.   If that inline
> >     function is declared anywhere in the source code, it must be a
> >     full definition.
>
> You may declare a function to be inline without providing a definition
> for it. But any translation unit which uses the function must contain
> the definition. (A translation unit is what you get after the preprocessor
> has finished doing its work - all the #include files have been merged.)
>
> This all happens as a consequence of C and C++ never having had a module
> or package system that would allow the compiler to seek out a separate
> file which holds the definition. It's possible to bolt on that sort of
> thing; I believe Sun's C++ compilers have such a feature.

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Hyman Rosen]

Richard Riehle wrote:
> And after reading all the postings, it seems to me that the Ada model
> is still simpler, easier to understand, and more straightforward than
> the rather confusing set of rules that characterize C++ inline functions.

Yes, of course. Isn't it always? :-)

Still, whenever I can, I want to make sure that on this newsgroup
the C++ facts are gotten straight. That way, we can have proper
discussions, without misinformation distorting the arguments.

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Hyman Rosen]

Martin Krischik wrote:
> That would mean that the virtual inline might be elaborated hundreds of
> time - in every compilation unit with a contructor call. With the result
> that no two virtual function tables will look the same.

Excuse me, but you really are extremely mistaken. I repeat, please
acquaint yourself with the language before making pronouncements
about it, so that you will not spread misinformation.

C++ compilers use a variety of means to decide when to generate
"elaborations" of virtual functions. In general, even if this
happens in multiple compilation units, linker directives are used
to indicate that all of the instantiations must be identical and
they are then merged into a single copy. There is only one virtual
table for a class, merged in the same way if needed, so it "looks
the same" by definition. I have no idea what constructors have to
do with any of this, since constructors are never virtual. You
just seem to be confused.

> Some C++ style guides suggest not to use virtual inlines because of it.

Some C++ style guides are desperately out of date, and others have been
written by people with the same lack of knowledge of C++ that you show.
Some descriptions of Ada report that it's a language designed by a
committee, is bloated, was forced upon people by the military, and is
generally unsuitable for any purpose.

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Hyman Rosen]

Martin Krischik wrote:
> I tried that. The compiler won't say a thing - but the linker will be more
> then upset. I might uf cource be dependen on the compiler.

Here's a nickel, kid. Get yourself a new compiler.

If you are using compiler technology that can't handle simple
code like this, then I think I get to compare C++ to Ada running
on NYU's orginal Ada-ED ompiler, or worse.

> I have 7 Years practical experience programming C++ - programming 8 hours
> a day. But prehaps this discussiun shows less about yours and my
> experience but more about the fact that no two C++ compilers are the same.

Perhaps. Length of service is also not always an indication of level of skill.

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Martin Krischik]

On Thu, 20 Feb 2003 04:08:17 +0000, Hyman Rosen wrote:

> Martin Krischik wrote:

>> I tried that. The compiler won't say a thing - but the linker will be more
>> then upset. I might of cource be dependen on the compiler.

> Here's a nickel, kid. Get yourself a new compiler.

I can't. In real live not the programer decides which compiler to use. He
may make a suggesting and run against a wall with it.

> they are then merged into a single copy. There is only one virtual
> table for a class, merged in the same way if needed, so it "looks
> the same" by definition. any purpose.

I am not shure about that one. Even if compiler and linker work in such
perfect harmony how will they enshure that over DLL borders?

> Perhaps. Length of service is also not always an indication of level of skill.

Just as much a skill in reading books has nothing to do with skill in
practical programing.

Well, you have started to make personal comments. BTW: I am also 39 so I
don't quite qualify for "kid" either.

Still, I find your technical comments quite interesting. They do show me
what I have to expect when I do get to work with a more modern compiler.

With Regards

Martin

-- 
Martin Krischik
mailto://Martin@krischik.com
http://www.krischik.com

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Hyman Rosen]

Martin Krischik wrote:
> I can't. In real live not the programer decides which compiler to use. He
> may make a suggesting and run against a wall with it.

True. When I participate in this group, I'm more concerned with
abstract language issues rather than strictly practical nuts and
bolts. Still, your compilation system seems extremely out of date.
Are you free to say what system it is you are using?

> I am not shure about that one. Even if compiler and linker work in such
> perfect harmony how will they enshure that over DLL borders?

Well, DLLs can have all sorts of symbol information. There is no
reason that a dynamic linker can't do exactly the same kind of
merging that a static linker does.

> Well, you have started to make personal comments. BTW: I am also 39 so I
> don't quite qualify for "kid" either.

Yes you do. I'm 41 :-)

> Still, I find your technical comments quite interesting. They do show me
> what I have to expect when I do get to work with a more modern compiler.

Yep. By the way, if you want to use God's own C++ compiler (although without
linking) to check your code, try <http://www.comeaucomputing.com/tryitout>.

Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[Martin Krischik]

On Mon, 24 Feb 2003 12:00:30 +0000, Hyman Rosen wrote:

> Martin Krischik wrote:
>> I can't. In real live not the programer decides which compiler to use. He
>> may make a suggesting and run against a wall with it.
> 
> True. When I participate in this group, I'm more concerned with
> abstract language issues rather than strictly practical nuts and
> bolts. Still, your compilation system seems extremely out of date.
> Are you free to say what system it is you are using?

IBM C++. It is not only outdated but also out of support. But there are
large Libraries which depend on and so there is fear of change.
 
>> I am not shure about that one. Even if compiler and linker work in such
>> perfect harmony how will they enshure that over DLL borders?
 
> Well, DLLs can have all sorts of symbol information. There is no
> reason that a dynamic linker can't do exactly the same kind of
> merging that a static linker does.

DLL Loaders are usualy supplied from the Operating System and they are
usualy not Object-Orientated.

The IBM Compiler will only create one virtual function table and export it
from the DLL for other DLLs to use. I determines which DLL does the
exporting by the first virtual function encoutered. Woe you is that one is
inlined.  

Thats of course only until you use virtual inheritance - after that the compiler
starts to create virtual function tables left, right and centre.

With regards.

Martin

-- 
Martin Krischik
mailto://Martin@krischik.com
http://www.martin.krischik.com