Teaching new tricks to an old dog (C++ -->Ada)

[Turamnvia Suouriviaskimatta]

I 'm following various posting in "comp.lang.ada, comp.lang.c++ ,
comp.realtime, comp.software-eng" groups regarding selection of a
programming language of C, C++ or Ada for safety critical real-time
applications. The majority of expert/people recommend Ada for safety
critical real-time applications. I've many years of experience in C/C++ (and
Delphi) but no Ada knowledge.

May I ask if it is too difficult to move from C/C++ to Ada?
What is the best way of learning Ada for a C/C++ programmer?

[Hyman Rosen]

Dr. Adrian Wrigley wrote:

It's a pity that the evil wasn't destroyed or fixed
in the design of C++.
That would have taken the "C" out of C++. It might have
made for a better language, but no one would have used it.
Like Ada :-)
Maybe a C++ source code checker (like 'lint') could prohibit the evil(?)
That way, people would be forced out of old C habits.

Never happen.

[Hyman Rosen]

Dr. Adrian Wrigley wrote:

Or to put it another way:
How come "more expressive" templates, "better exception handling",
or "less verbose" syntax is not claimed to improve project success?
Maybe I (still) don't get it.

To claim improved project success, you have to do some pretty difficult
basic research. Most of us here are programmers, not software engineering
researchers, so most of us at best have only anecdotal evidence. Therefore
when we compare languages we do so from the basis of things that affect us
as programmers.

[Jerry Coffin]

jayessay wrote:

[ ... ]

A preprocessor per so, no. The type of capabilities is a different
story. For example, Lisp includes macros. Most assemblers include
(much more extensive) macros as well as an eqiuvalent of C's
#if/#ifdef/#ifndef/#endif.
Lisp macros are _not_ a preprocessor and they are _vastly_ more
capable than what people typically think of when they see/hear
"macros". Lisp macros are full code analyzing and generating
constructs.

I very specifcally said they were not in a preprocessor, and merely
that they provide capabilities similar to those available in the
preprocessor in C++. It's true that they provide considerably more in
addition, but it's more or less beside the point -- which was that Ada
provides substantially less still.

Lisp only came into the conversation at all because it was implied that
the C preprocessor was _so_ unusual that nothing else provided even
vaguely similar capabilities. The substantially more capable Lisp
macros were mentioned only to point out that my comparison was not to
something utterly unique. I certainly did not mean to imply any
particularly strong similarity between C macros and those in Lisp. As
far as that goes, most assemblers have far more macro capability as
well -- but again, it's more or less beside the point.
Robert Duff made a comment a while ago about how silly most (I would
say without much hyperbole 99+%) of the points in these threads would
be to Lisp (and Smalltalk) folks. I couldn't agree more.

As usualy, I disagree -- and I also use Lisp part of the time, and have
not only used Smalltalk, but written a fairly substantial part of a
Smalltalk implementation.

Then again, I also remember watching/listening to arguments between
people using various flavors of Lisp (before CL came along) about
things like whether it was correct to equate an empty list with
"false". IIRC, I probably used Pascal at the time, and compared to the
differences between FORTRAN IV and Pascal, these differences could have
been seen as quite trivial.

Nonetheless, I didn't and don't see the arguments as silly from either
direction. I see people who have chosen particular areas in which to
pursue their vision of perfection. While I consider it perfectly
reasonable to disagree with them, I hope I never become so
self-satisfied or condescending as to pronounce their concerns or
vision as "silly" or anything like it.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Wes Groleau]

Jerry Coffin wrote:

The real measure is not the long term cost of a particular program, but
the long-term cost of carrying out a particular task. Unfortunately,
that's generally much more difficult to measure, and (worse) attempts
at measuring it are much less common.

Indeed. There have been a few times that someone has actually had
an Ada group and a group with another language tackle the same
requirements. This has not happened enough times for a clear
verdict. However, I can state that in AKK the (few) cases I am
aware of, Ada was the winner each time.

--
Wes Groleau
http://freepages.rootsweb.com/~wgroleau/Wes

"Dr. Adrian Wrigley" <am**@linuxchip.demon.co.uk.uk.uk> wrote:

A key point is that C arrays are considered 'evil' to C++ programmers.

C arrays:
1) don't have their subscripts checked
2) often need heap allocation and manual deletion
3) cannot be returned (when 'auto')
4) are rather mixed up with bug-prone pointer based code

And this doesn't even address the issues of multi-dimensional
arrays, which, in Ada, are true multi-dimensional arrays.

type Day is (Mon, Tue, Wed, Thu, Fri, Sat, Sun);
type Index is range 1..31;
type TwoDMatrix is array(Day, Index) of Boolean;

or if you wish,

type DayVector is array(Day) of Boolean;
type Month is array(Index) of DayVector;

and one is not limited to two dimensions for true arrays.

type ThreeDMatrix is array(1..20, 1..400, 1..2000) of Integer;
TDM1 : ThreeDMatrix;

...

for TDM1'Range(1)
loop
for TDM1'Range(2)
loop
for TDM1'Range(3)
loop
-- Do something to Integer element
end loop;
end loop;
end loop;

where the parenthetical values specify which dimension is being
evaluated.

Multi-dimensional array processing in Ada is so easy to do. Moreover,
it is easy, no trivial, to create generic templates to take advantage of
this capability to create portable, generalized, and and easy to use
generic components. Easier, I think, than the equivalent capability
in most other languages, especially C++.

Richard Riehle

[jayessay]

"Dr. Adrian Wrigley" <am**@linuxchip.demon.co.uk.uk.uk> writes:

On Thu, 24 Mar 2005 17:59:39 -0500, jayessay wrote:

...

of _expressive capability_ in either Ada or C++ or Eiffel or ?? is so
_low_ that it again is simply amazing to see people so vehemently
arguing over differences that are almost invisible.
*I* think the evidence is now very strong that programming language
choice *is* massively important for overall success of large projects.

I concur completely. Those who think otherwise largely fall back on
the old "Turing equivalent" argument which, since all the languages
under discussion are TE, is basically irrelevant.
The problem is a lack of scientific method in determining this,
resulting in a big analytical problem with (also massive)
confounding factors.
This is also true, but it is not something that will likely ever
change due to massive economic reasons. I suspect you understand this
by your "(..massive) confounding factors" comment.

one snippet from a Google search:
"Gartner is now saying 70% of all Java projects so far have failed"
but only "40% of all projects fail."
One of the problems here is that the vast majority of Java projects
are handled mostly by a horde (colony?) of "code monkeys".
Personally, I think Java sucks, but I don't think you can conclude
much from those stats though.

and
"C++ programs typically have roughly six times the lifetime ownership
costs of equivalent programs written in C, Ada or Fortran, and fewer
than one third of programming projects begun in C++ are completed."
This is _much_ more believable, but again such stats are intrinsically
suspect.

Can anybody post links quantifying how much better C++ is than C or
Ada (in terms of project cost and outcome)?
Sure, but again all these things are either a) toy examples, or b)
completely uncontrolled experiments leading to c) dodgy information.

Of course I enjoy programming in C/C++ very much, having
C, sure. C++? You have my sympathies.

total debugging time so much shorter in Ada (I've almost

I'm here because I still do follow Ada and cla a bit as I always
thought it was at least reasonbly well thought out. At the moment I
have the great fortune of using Common Lisp.
/Jon

--
'j' - a n t h o n y at romeo/charley/november com

[jayessay]

Jared <no*****@nowhere.nowhere> writes:

And that is why $YOUR_LANGUAGE should allow arbitrary array indices. Or should have all types be anonymous. Or should use structural type
equivalence. Or should combine data and method declarations for object
types. <Looks around guiltily.> Or should have a preprocessor. Or
infer all types. Or whatever. Just like $MY_LANGUAGE.
I don't buy this total "relativism". It smacks of the "Turing
equivalent" arguments.

Robert Duff made a comment a while ago about how silly most (I would
say without much hyperbole 99+%) of the points in these threads would
be to Lisp (and Smalltalk) folks. I couldn't agree more. You are all
arguing over differences that mean almost nothing looked at from these
other perspectives.

This is quite correct, but also largely irrelevant. The general context

I suppose you are correct here. I'm here because I still do follow
(at least in passing) how Ada is doing and what it's followers are up
to. I try not to get into these things, but the comment from J.Coffin
comparing Lisp macros to a "preprocessor" was too much to ignore.
It's sad really how very little people here have even the ghost of an
idea of what something like Common Lisp is, can provide, and can do.

of a language flamewar is that every feature $YOUR_LANGUAGE has that
$MY_LANGUAGE doesn't have is unnecessary, and a clear sign of its
inferiority. Any feature $MY_LANGUAGE has that $YOUR_LANGUAGE lacks
is absolutely essential, and a clear sign of its superiority.
Well, now _that_ is certainly on target.

A functional language like Lisp lacks many of the features being argued
Lisp is not really a functional language, though it can be used as
one. It is very much multiparadigm.

Yes, a person can do all kinds of neat things in Lisp. A good programmer
can do all kinds of neat things elegantly in any language, and a bad
programmer cannot.
This again sounds like a TE argument and so not particularly good.
The key thing aboug Lisp is that it is a programmable programming
language and thus can incorporate at any point any construct from any
language seamlessly and transparently into it. Does that make it
_necessarily_ superior to anything else? No - that typically is
heavily context dependent. But after having analyzed and used all
these "lesser" languages it is clear to me that in _most_ cases it is
definitely superior. Nobody here is going to believe any of this.
Then again, next to nobody here even has the ghost of a clue about the
facts that would undermine their belief.

And the level
of _expressive capability_ in

Aldor?

is so
_low_ that it again is simply amazing to see people so vehemently
arguing over differences that are almost invisible.

I'm sure you meant expressive convenience. Turing completeness ensures

No, I meant expressive capability also called expressivness, or
expressivity. Turing equivalence is totally irrelevant. If it had
any meaning in such discussions we would all be toggling in programs
as 1' and 0's at consoles.

"The sooner we can forget that FORTRAN has ever existed, the better, for
as a vehicle of thought it is no longer adequate: it wastes our
brainpower, is too risky and therefore too expensive to use."
- E.W. Dijkstra, EWD 340

The arguments being carried on here echo this complaint. Implicit in the
arguments for both sides is that the one wastes brainpower while the
other conserves it. That's fairly important, given that brainpower is
the only tool a programmer really has.

Yes, indeed. This is very on target and is at the heart of the issue.
Which brings us full circle to the point here that the differences
being argued, from the perspective of Lisp (or Smalltalk) are so small
as to be meaningless.
/Jon

--
'j' - a n t h o n y at romeo/charley/november com

[jayessay]

"Jerry Coffin" <jc*****@taeus.com> writes:

jayessay wrote:

[ ... ]

A preprocessor per so, no. The type of capabilities is a different
story. For example, Lisp includes macros. Most assemblers include
(much more extensive) macros as well as an eqiuvalent of C's
#if/#ifdef/#ifndef/#endif.
Lisp macros are _not_ a preprocessor and they are _vastly_ more
capable than what people typically think of when they see/hear
"macros". Lisp macros are full code analyzing and generating
constructs.

I very specifcally said they were not in a preprocessor, and merely
that they provide capabilities similar to those available in the
preprocessor in C++.

And this is just _completely_ untrue. Not even close.

but it's more or less beside the point -- which was that Ada
provides substantially less still.
While I agree with you on this, I don't really care.

Lisp only came into the conversation at all because it was implied that
the C preprocessor was _so_ unusual that nothing else provided even
vaguely similar capabilities.
Lisp coming into the conversation here is just a _bad_ thing to do.
Not because you are wrong about "preprocessors" being unusual (you're
right - they aren't.), but because you "equate" (in any sense) Lisp
macros as being a "preprocessor". They aren't. Indeed due to they
way they are defined they _can't_ be. And it is this _way_ in which
they are defined that makes them so totally different and _vastly_
more capable. If you were stupid enough to waste your time doing so,
you could write a C++ compiler _as_ Lisp macros.

something utterly unique. I certainly did not mean to imply any
particularly strong similarity between C macros and those in Lisp. As
far as that goes, most assemblers have far more macro capability as
well
OK, thanks. And I agree with the macro assembler comment as well.

Robert Duff made a comment a while ago about how silly most (I would
say without much hyperbole 99+%) of the points in these threads would
be to Lisp (and Smalltalk) folks. I couldn't agree more.

As usualy, I disagree -- and I also use Lisp part of the time, and have
not only used Smalltalk, but written a fairly substantial part of a
Smalltalk implementation.

Then you don't really understand the fundamental aspect of Lisp. Just
hacking a line or two of Scheme or even CL is not "using" Lisp.

Nonetheless, I didn't and don't see the arguments as silly from either
direction. I see people who have chosen particular areas in which to
pursue their vision of perfection. While I consider it perfectly
reasonable to disagree with them, I hope I never become so
self-satisfied or condescending as to pronounce their concerns or
vision as "silly" or anything like it.

Too late.
/Jon

--
'j' - a n t h o n y at romeo/charley/november com

[Ioannis Vranos]

Georg Bauhaus wrote:

template<class T, const int MIN, const int MAX >

A solution will have this parameterization and checks:

template<class T, class Index>

class Array: public vector
{
// Only provide definitions for operator at() and operator[] that
// really *only* explicitly call the base ones with the proper index.
// And the few constructors doing the same, *only* explicitly passing
// the *same* arguments to the base constructors.

// Check indexing precondition Index::contains(v) in at(v) and
// operator[](v).

};

I think it is *that* simple.

O.K., I'll wait.

Unfortunately, I just tried to do it, however I have to use allocators,
and I do not know allocators yet. It looks like each of my compilers
uses its own one, different from the others, and when I used
allocator_type instead I still got errors.
Anyway, this has been my short progress. I could add run-time checks but
did not proceed since I stuck with allocators.
// Implementation-defined:
// typedef implementation defined iterator; // See 23.1
// typedef implementation defined const_iterator; // See 23.1
// typedef implementation defined size_type; // See 23.1
// typedef implementation defined difference_type;// See 23.1

#include <iostream>

#include <vector>
using namespace std;
template<class T, class A>
class Varray: public std::vector<T>
{
const A MIN, MAX;

public:
explicit Varray(const Allocator &al = Allocator(),
const A min, const A max): vector<T>(al), MIN(min),
MAX(max) {}

explicit Varray(size_type n, const T& value = T(),
const Allocator &al = Allocator(), const A min, const A max):
vector(n, value, al), MIN(min), MAX(max) {}

template <class InputIterator>
Varray(InputIterator first, InputIterator last,
const Allocator &al = Allocator(), const A min, const A max):
vector(first, last, al), MIN(min), MAX(max) {}

// ==> To be implemented
Varray(const Varray<T,Allocator>& x){}

Varray() {}

// ==> All the following to be implemented
// Varray<T,Allocator>& operator=(const Varray<T,Allocator>& x) {}
// template <class InputIterator>
// void assign(InputIterator first, InputIterator last);
// void assign(size_type n, const T& u);
// Allocator get_allocator() const;

// Only provide definitions for operator at() and operator[] that
// really *only* explicitly call the base ones with the proper index.

// Check indexing precondition Index::contains(v) in at(v) and
// operator[](v).
};
int main()
{
using namespace std;
}

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Ioannis Vranos wrote:

Unfortunately, I just tried to do it, however I have to use allocators,
and I do not know allocators yet.

Of course, this does not mean that it can not be done. :-)

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Dmitry A. Kazakov]

On Fri, 25 Mar 2005 19:21:18 +0100, Martin Krischik wrote:

Dmitry A. Kazakov wrote:

On Fri, 25 Mar 2005 13:42:31 +0100, Martin Krischik wrote:

But I think it would be quite a challenge to create rendezvous based
multithreading on top of C++ templates - and yet keep it easy to use for
the programmer.

We did it in our proprietary C++ library, and without any templates, BTW.
The pattern is:

1. A rendezvous queue type either to derive task objects from or to
mix-in. A task periodically polls the queue, it can also wait for a
queuing event.

2. An abstract rendezvous object type to queue. User-defined rendezvous
objects were derived from there. When rendezvous happened a virtual method
was called.

We supported timed calls, and even a kind of re-queuing to mimic this
extremely useful feature of Ada 95.

Of course it is not as easy to use it as Ada's rendezvous, but it is
usable and works fine. The advantages rendezvous have over queues are that
as in Ada there is no need to marshal parameters here and there, no need
in any locks, no problem to have results.

The most difficult problem is exception handling. In Ada, rendezvous
exceptions are propagated in both caller and callee. This is impossible to
mimic in C++, because there seems no way to throw same-as-this exception
in C++. So we had to fuse all exceptions on the caller's side ...

Cool. Sad that it is not open source.

There is Ada for that!

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[Dmitry A. Kazakov]

On Fri, 25 Mar 2005 21:33:36 GMT, Hyman Rosen wrote:

Dr. Adrian Wrigley wrote:

Or to put it another way:
How come "more expressive" templates, "better exception handling",
or "less verbose" syntax is not claimed to improve project success?
Maybe I (still) don't get it.

To claim improved project success, you have to do some pretty difficult
basic research. Most of us here are programmers, not software engineering
researchers, so most of us at best have only anecdotal evidence. Therefore
when we compare languages we do so from the basis of things that affect us
as programmers.

Yes, this is of course true.

Yet it is very difficult to find competent C++ programmers. Even people
with years of practical experience are unable to do very basic things
already at the level of *using* a class/template library in a proper way.
To ask them to write reusable code... Then that evil C heritage, I see it
again and again, people doing some quite silly C-ish micro optimizations in
a loop where they create and destroy 10 string objects. It is not a science
it is just psychology...

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[Martin Krischik]

Jerry Coffin wrote:

I'm the last to attribute these facts directly to C vs. Ada, but it
doesn't seem to indicate that using Ada is particularly crucial to
either economic or technical success in this market, which places about
as high an emphasis on reliability as any. I'd also note that SCADE is
routinely used in other high-reliability markets as well, including
other transportation and nuclear plant control.

You are aware that SCADE supports more then one target programming language?

http://www.esterel-technologies.com/...eneration.html

On the one hand this supports you claim - If you use SCADE then programming
language is indeed irrelevant.

On the other hand, looking at the code sample I guess no one ever need to do
any editing inside the generated code. I suspect that programming is done
in "SCADE" not C or Ada.

Martin

PS: I find the order they give in there drop-down box quite telling with
SPARK-Ada at the top and Standart C at the bottom while at the same time
all marketing texts say first C then Ada. I supports my suspicion that
languages are more often chosen marketing effort then by actual facts.
--
mailto://kr******@users.sourceforge.net
Ada programming at: http://ada.krischik.com

[Jerry Coffin]

jayessay wrote:

[ ... ]

I very specifcally said they were not in a preprocessor, and merely
that they provide capabilities similar to those available in the
preprocessor in C++.
And this is just _completely_ untrue. Not even close.

I see. So what is it that (you incorrectly believe) the C preprocessor
can do that a Lisp macro can't do?
Lisp coming into the conversation here is just a _bad_ thing to do.
Not because you are wrong about "preprocessors" being unusual (you're
right - they aren't.), but because you "equate" (in any sense) Lisp
macros as being a "preprocessor".

I never made such an "equation" -- if you saw such a thing in what I
said, it's entirely your own delusion.

[ ... ]

As usual, I disagree -- and I also use Lisp part of the time, and
have not only used Smalltalk, but written a fairly substantial part
of a Smalltalk implementation.

Then you don't really understand the fundamental aspect of Lisp.

I wish I was still sufficiently young and inexperienced to draw such
solid conclusions based on such a complete lack of evidence or
knowledge.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Martin Krischik]

Georg Bauhaus wrote:

Ioannis Vranos wrote:

Georg Bauhaus wrote: Again, one can easily define an array container that accepts user
defined indexes.
I have not seen one so far, only some handcoded range checking
which is not the point.

I have got one:

http://cvs.sourceforge.net/viewcvs.p....H?view=markup
The compiler will use the information present in Index
to establish properties of the Adalike::vector type such that
Adalike::vector indexing (an operation) is based on properties
of Index (Index is a type! It is not an algorithm base on min
and max int parameters).

This has something to do with making the base types int, long, etc.
class types. When they are class types, you can invoke their
methods, derive other number types, and then you can use
their interface to build an array that is using the information
provided by int or provided by a type derived from int.

That's on my TODO list. Using the following class:

http://cvs.sourceforge.net/viewcvs.p...pp?view=markup

Martin

Disclaimer: Both sources might not be in working order - everytime I switch
compiler (IBM C++ -> MS-C++ -> G++) the code need reworking and the switch
to GNU is not finished yet.

--
mailto://kr******@users.sourceforge.net
Ada programming at: http://ada.krischik.com

[Ludovic Brenta]

Robert A Duff writes:

Well, actually, during the Ada 9X design I tried to push for a
class-hierarchy of exceptions. I don't like every detail of the way
C++ does it, but at least in *this* regard, it's better than Ada.

Jerry Coffin is wrong that Ada does not allow attaching information
to exception, by the way. Ada allows attaching Strings, which is
admittedly a kludge. Using the class-hierarchy, as Jerry advocates,
would be cleaner, and type safe.

I kind of like Ada exceptions as they are now. Because one cannot
carry much information in them (apart from the kluge you mentioned),
one tends not to rely on them for the normal flow of operations. I
have seen Java programs that would rely on exceptions for all kinds of
things, leading to spaghetti code. In C++ I find it a bit odd that I
can throw and catch an entire hash table as an exception if I want to.

The C++ way of catching all exceptions of a class and its derived
classes can lead to confusion. One can have multiple exception
handlers for the same exception and it may not be immediately obvious
to the reader which one is called. I see this as a maintenance
problem.

Another concern of mine with exception classes is that they'd have to
be allocated on the heap. There are situations where there is no heap
to allocate from, or where dynamic allocation is forbidden. I think
it necessary to provide a simple exception mechanism that does not
require any dynamic allocation, much less dynamic dispatching.

Perhaps a good middle-ground would be an addition to Ada along the
lines of:

package Ada.Exceptions.Extra is
type Extra_Information is abstract tagged null record;

procedure Raise_Exception (E : in Exception_Id;
Information : in Extra_Information'Class);

function Exception_Information (X : Exception_Occurrence)
return Extra_Information'Class;
end Ada.Exceptions.Extra;

Programs that want to carry rich information with exceptions would be
allowed to do so, while "pragma Restrictions (No_Dispatch)" or
"No_Dynamic_Allocation" would guarantee, to those interested, that no
such thing happens.

I am aware that all this would require the compiler to provide two
exception mechanisms and two kinds of Exception_Occurrences, so I may
have opened a can of worms here. Just thinking out loud :)

--
Ludovic Brenta.

[Dmitry A. Kazakov]

On Sat, 26 Mar 2005 11:19:18 +0100, Ludovic Brenta wrote:

Robert A Duff writes:

Well, actually, during the Ada 9X design I tried to push for a
class-hierarchy of exceptions. I don't like every detail of the way
C++ does it, but at least in *this* regard, it's better than Ada.

Jerry Coffin is wrong that Ada does not allow attaching information
to exception, by the way. Ada allows attaching Strings, which is
admittedly a kludge. Using the class-hierarchy, as Jerry advocates,
would be cleaner, and type safe.
I kind of like Ada exceptions as they are now. Because one cannot
carry much information in them (apart from the kluge you mentioned),
one tends not to rely on them for the normal flow of operations. I
have seen Java programs that would rely on exceptions for all kinds of
things, leading to spaghetti code. In C++ I find it a bit odd that I
can throw and catch an entire hash table as an exception if I want to.

The C++ way of catching all exceptions of a class and its derived
classes can lead to confusion. One can have multiple exception
handlers for the same exception and it may not be immediately obvious
to the reader which one is called. I see this as a maintenance
problem.

Another concern of mine with exception classes is that they'd have to
be allocated on the heap. There are situations where there is no heap
to allocate from, or where dynamic allocation is forbidden. I think
it necessary to provide a simple exception mechanism that does not
require any dynamic allocation, much less dynamic dispatching.

Perhaps a good middle-ground would be an addition to Ada along the
lines of:

package Ada.Exceptions.Extra is
type Extra_Information is abstract tagged null record;

procedure Raise_Exception (E : in Exception_Id;
Information : in Extra_Information'Class);

function Exception_Information (X : Exception_Occurrence)
return Extra_Information'Class;
end Ada.Exceptions.Extra;

Programs that want to carry rich information with exceptions would be
allowed to do so, while "pragma Restrictions (No_Dispatch)" or
"No_Dynamic_Allocation" would guarantee, to those interested, that no
such thing happens.

I am aware that all this would require the compiler to provide two
exception mechanisms and two kinds of Exception_Occurrences, so I may
have opened a can of worms here.

You had. (:-))
Just thinking out loud :)

A pair of simple questions:

1. Dispatching to non-existing methods of Extra_Information?

2. Accessibility rules for members of Extra_Information. Technically
Extra_Information is a sort of result value. As such it requires special
handling of all access values (pointers) it may do to local objects.

3. Extra_Information should probably be controlled, what about finalization
rules?

4. Two copies of Extra_Information if the exception was raised in a
rendezvous? Protected type Extra_Information? (protected types are still
untagged)

5. When and where Extra_Information gets deallocated?

I think that before making any detailed proposals we should consider a
contract model of exceptions. Points 1..5 might look very different if
there were exception contracts.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[Georg Bauhaus]

Dmitry A. Kazakov wrote:

On Sat, 26 Mar 2005 11:19:18 +0100, Ludovic Brenta wrote:

Perhaps a good middle-ground would be an addition to Ada along the
lines of:

package Ada.Exceptions.Extra is
type Extra_Information is abstract tagged null record;

procedure Raise_Exception (E : in Exception_Id;
Information : in Extra_Information'Class);

function Exception_Information (X : Exception_Occurrence)
return Extra_Information'Class;
end Ada.Exceptions.Extra;

How about

declare
...
procedure bounce is
begin
set_up_information_to_pass;
end;
begin
raise with bounce'access;
end;
Programs that want to carry rich information with exceptions would be
allowed to do so, while "pragma Restrictions (No_Dispatch)" or
"No_Dynamic_Allocation" would guarantee, to those interested, that no
such thing happens.

A pair of simple questions:

[Jerry Coffin]

Martin Krischik wrote:

[ ... ]

You are aware that SCADE supports more then one target programming
language?
Yes, I'm aware that Ada is mentioned in their marketing information,
but looking through several 3rd-party web sites, I haven't been able to
find any mention of anybody ever having actually used this ability. I
was talking specifically about Airbus' use, and looking at:

http://www.esil.univ-mrs.fr/~spc/rcs.../Baufreton.pdf
and:
http://www.systemes-critiques.org/js...ier_Dormoy.ppt

indicates that they're consistently using C, not Ada. I also mentioned
use in other transport, and if you look at slide 12 of the second link
above, you'll notice where it specifically says this was done with C
code as well.

So far, I've found several references that mention generating C code,
some that don't specify the language, zero that mention having
generated Ada.
On the one hand this supports you claim - If you use SCADE then
programming language is indeed irrelevant.
First of all, I don't recall having made any such claim. What I have
said is that choice of programming language is but one factor among
many, and that I believe it's only rarely the single most important
factor.

Second, this seems to assume that all the code is generated by SCADE,
and none written directly. This does NOT seem to be the case -- if you
look at page 6 of:

http://scilabsoft.inria.fr/events/05_11_03/ESTEREL.pdf

you'll see that they only claim 70% of the code was generated by SCADE.
Given the size of project we're talking about, the remaining 30% is a
_significant_ amount of code. It seems likely to me that if they were
using Ada for the hand-written code, they'd generate Ada as well.

[ ... ]
PS: I find the order they give in there drop-down box quite telling
with SPARK-Ada at the top and Standart C at the bottom while at the
same time all marketing texts say first C then Ada. I supports my
suspicion that languages are more often chosen marketing effort
then by actual facts.

Even if we assume that all the references I've found that didn't
specify a programming language were using Ada, it still appears that C
is being used considerably more than Ada.

What I find telling is that somebody is so desparate to find _anything_
to favor their position that they'll read the order of strings in a
listbox as really meaning something -- especially when they're
apparently just in alphabetical order!

I think it's also worth noting that SCADE itself appears to be written
in C++. While they don't specify this directly, the API they supply to
make it programmable is specifically stated as being for C++ (e.g.
http://www.liveware.com.br/pdf/telelogic_scade.pdf
page 23). While they could undoubtedly provide a C++ API from Ada, it
seems most likely to me that if it was written in Ada, use from Ada
would be supported (and mentioned). I'm sure writing in Ada and ONLY
supporting C++ is a theoretical possibility, but it strikes me as quite
unlikely.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[jayessay]

"Jerry Coffin" <jc*****@taeus.com> writes:

jayessay wrote:

[ ... ]

I very specifcally said they were not in a preprocessor, and merely
that they provide capabilities similar to those available in the
preprocessor in C++.

And this is just _completely_ untrue. Not even close.

I see. So what is it that (you incorrectly believe) the C preprocessor
can do that a Lisp macro can't do?

Nothing, but then I never indicated otherwise. The point was (not as
clear as it should have been indicated) that the phrase "they provide
capabilities _similar_ to those available in the preprocessor"
(emphasis added) is wrong. They don't. For many reasons. They are
in no way anything like a preprocessor.

Lisp coming into the conversation here is just a _bad_ thing to do.
Not because you are wrong about "preprocessors" being unusual (you're
right - they aren't.), but because you "equate" (in any sense) Lisp
macros as being a "preprocessor".

I never made such an "equation" -- if you saw such a thing in what I
said, it's entirely your own delusion.

Yeah right. You specifically state otherwise in the quote at the
start (please note the "in any sense").

As usual, I disagree -- and I also use Lisp part of the time, and
have not only used Smalltalk, but written a fairly substantial part
of a Smalltalk implementation.

Then you don't really understand the fundamental aspect of Lisp.

I wish I was still sufficiently young and inexperienced to draw such
solid conclusions based on such a complete lack of evidence or
knowledge.

You have provided a mass of evidence to support the conclusion. The
fact that you don't understand this is actually even more evidence.
/Jon

--
'j' - a n t h o n y at romeo/charley/november com

[Ioannis Vranos]

Ludovic Brenta wrote:

I kind of like Ada exceptions as they are now. Because one cannot
carry much information in them (apart from the kluge you mentioned),
one tends not to rely on them for the normal flow of operations. I
have seen Java programs that would rely on exceptions for all kinds of
things, leading to spaghetti code. In C++ I find it a bit odd that I
can throw and catch an entire hash table as an exception if I want to.

Being able to do whatever you want can certainly cause confusion for
anyone who is used to be helped how to program.

However, if you know the language, you know what to do and what to not
do. Also this way is more powerful.

The C++ way of catching all exceptions of a class and its derived
classes can lead to confusion. One can have multiple exception
handlers for the same exception and it may not be immediately obvious
to the reader which one is called. I see this as a maintenance
problem.

:-) Being able to walk alone can also lead to confusion. Isn't it better
if you walk with assistance?
Another concern of mine with exception classes is that they'd have to
be allocated on the heap.

No, they do not have to. One can (and in most times does) throw an
exception object on the stack.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Owen Jacobson]

On Thu, 24 Mar 2005 00:01:20 +0000, adaworks wrote:

I am suggesting that the code will be less-than obvious to many C++
programmers. Certainly, after careful study, the experienced C++
programmer might be able to read your example, but there is room for
misinterpretation unless one is supplied a fair amount of documentation.

I haven't read this entire thread, but I just paged back up to your Ada
example and read both it and Ioannis' C++ example. I'm a C++ developer by
trade, and don't know Ada, but, yes, the Ada example was extremely
readable. So was the C++ example: the intent of both programs was
immediately clear.

This doesn't mean either example is inherently clear, just that a random
passer-by found both of them to be clear.

[Jerry Coffin]

jayessay wrote:

"Jerry Coffin" <jc*****@taeus.com> writes:

jayessay wrote:

[ ... ]

> I very specifcally said they were not in a preprocessor, and
> merely that they provide capabilities similar to those
> available in the preprocessor in C++.

And this is just _completely_ untrue. Not even close.
I see. So what is it that (you incorrectly believe) the C
preprocessor can do that a Lisp macro can't do?

Nothing, but then I never indicated otherwise.

You clearly don't understand even the simplest logic. Being able to do
all the same things directly implies having similar capabilities.

[ ... ]
Yeah right. You specifically state otherwise in the quote at the
start (please note the "in any sense").
[ ... ]
You have provided a mass of evidence to support the conclusion. The
fact that you don't understand this is actually even more evidence.

100% pure, triple distilled nonsense.

I might be a bit worried by your condemnation, but looking through your
posts elsewhere makes it clear that even on cll you're known primarily
for flaming. e.g.:

http://groups-beta.google.com/group/...02a7e69b52ca77

My reaction is about the same as theirs: run along now, child.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[jayessay]

"Jerry Coffin" <jc*****@taeus.com> writes:

jayessay wrote:

"Jerry Coffin" <jc*****@taeus.com> writes:

jayessay wrote:

[ ... ]

> > I very specifcally said they were not in a preprocessor, and
> > merely that they provide capabilities similar to those
> > available in the preprocessor in C++.
>
> And this is just _completely_ untrue. Not even close.

I see. So what is it that (you incorrectly believe) the C
preprocessor can do that a Lisp macro can't do?
Nothing, but then I never indicated otherwise.

You clearly don't understand even the simplest logic. Being able to do
all the same things directly implies having similar capabilities.

You don't understand plain English. What you are saying is just
irrelevant.

You have provided a mass of evidence to support the conclusion. The
fact that you don't understand this is actually even more evidence.

100% pure, triple distilled nonsense.

Hardly. Your problem is simple. You made an incorrect statement but
for reasons that are beyond me you can't come to grips with that fact.
Your technique here is just to keep reiterating your mistake and
posturing as if you had a clue. You don't. And it is becoming
painfully clear.

posts elsewhere makes it clear that even on cll you're known primarily
for flaming. e.g.:

Hardly. But if it soothes your ego to think so, I'm fine with that.
I don't really understand why you are so obsessed with trying to not
come to grips with your mistake here. It's not as if it's that big a
deal.
/Jon

--
'j' - a n t h o n y at romeo/charley/november com

[Martin Krischik]

Jerry Coffin wrote:

Martin Krischik wrote: So far, I've found several references that mention generating C code,
some that don't specify the language, zero that mention having
generated Ada.
IMHO: One of the greatest mistakes Ada using companies do is keep quite
about it. It hurts the language a lot. Of course that means we never know.

But I am not a dreamer: There will be more C then Ada out there. It's just
the way it is.

PS: I find the order they give in there drop-down box quite telling
with SPARK-Ada at the top and Standart C at the bottom while at the
same time all marketing texts say first C then Ada. I supports my
suspicion that languages are more often chosen marketing effort
then by actual facts.

Even if we assume that all the references I've found that didn't
specify a programming language were using Ada, it still appears that C
is being used considerably more than Ada.

I know :-( .
What I find telling is that somebody is so desparate to find _anything_
to favor their position that they'll read the order of strings in a
listbox as really meaning something -- especially when they're
apparently just in alphabetical order!

No, I was making a different point here. You are right: they are
alphabetical and I have overlooked that. But the important part of my
question was: but why didn't marketing use an alphabetical order when
writing the web side?

So my point stands: marketing effort or perhaps "coolness" has more to
influence then actual technical facts. Which I find sad, but is true for as
long I can think back for all sorts of technologies.

With Regards

Martin

--
mailto://kr******@users.sourceforge.net
Ada programming at: http://ada.krischik.com

[Ioannis Vranos]

Martin Krischik wrote:

IMHO: One of the greatest mistakes Ada using companies do is keep quite
about it. It hurts the language a lot. Of course that means we never know.

The same complaint exists in C++ community, that the companies do not advertise the
language that they use. :-)

But I am not a dreamer: There will be more C then Ada out there. It's just
the way it is.

Well, if it becomes more freely available, no permission from any ministry for making a
compiler or something is required, I think it can become mainstream. I think it would make
more sense if Delphi was based on Ada than Object Pascal for example.

No, I was making a different point here. You are right: they are
alphabetical and I have overlooked that. But the important part of my
question was: but why didn't marketing use an alphabetical order when
writing the web side?

It is about the audience numbers I guess. But trust me this doesn't do any harm in
reality. As it wouldn't make any difference for C++ if some site mentions a library
"suitable for Java, Cobol and C++". :-)

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[I am using 90 characters word-wrapping - (800/640) *72= 90. If someone finds it
inconvenient, please let me know].

[Jerry Coffin]

Martin Krischik wrote:

[ ... ]

What I find telling is that somebody is so desparate to find
_anything_ to favor their position that they'll read the order
of strings in a listbox as really meaning something --
especially when they're apparently just in alphabetical order!
No, I was making a different point here. You are right: they are
alphabetical and I have overlooked that. But the important part of my
question was: but why didn't marketing use an alphabetical order when
writing the web side?

Look at it from their perspective for a moment: why would they?
So my point stands: marketing effort or perhaps "coolness" has more
to influence then actual technical facts. Which I find sad, but is
true for as long I can think back for all sorts of technologies.

Marketing people generally think none of this stuff is even sligtly
"cool" or anything like it. They are influenced very strongly by facts,
but under the circumstances, the facts they care about almost certainly
come from their accounting department. IOW, they emphasize C over Ada
not because they think it's cool but because it makes money.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Dmitry A. Kazakov]

On 27 Mar 2005 06:38:30 -0800, Jerry Coffin wrote:

they emphasize C over Ada
not because they think it's cool but because it makes money.

Rather they think it would make more money because it is cool ...

----
There is no scientifically strong data about language influence on either
project success or financial success. Though unscientific belief is that
one can sell almost any rubbish.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

"Ioannis Vranos" <iv*@remove.this.grad.com> wrote in message
news:1111919334.573846@athnrd02...

Well, if it [Ada] becomes more freely available, no permission from any ministry for making a compiler or something is required, I think it can become mainstream. I think it would make more sense if Delphi was based on Ada than Object Pascal for example.

It is rather odd that, after all these years, many people still think Ada is
the property of the U.S. Government. The Ada Language Reference
Manual contains the specification for the language. Anyone who wants
to create a compiler is free to do so. Ada is being used for military
and non-military projects all over the world. One of the largest military
projects in the world that uses Ada is in Mainland China. In fact, the
Chinese have created their own Ada compilers. My book, Ada Distilled,
has been downloaded by people in places such as Oman, Cuba,
Iran, France, Sweden, and many other places. I'm pretty sure that
any downloading my book is also downloading the GNAT Ada
compiler.

Certain Ada libraries, such as the Common Ada Missiles Package
(CAMP) are classified. The software written in Ada for weapons
systems is classified. But the language itself is free for everyone to
use, in any way they wish.

Richard Riehle

[Martin Krischik]

Jerry Coffin wrote:

Look at it from their perspective for a moment: why would they?
Indeed why would they :-( .
IOW, they emphasize C over Ada
not because they think it's cool but because it makes money.

For marketing people that's the same: Cool is only what makes money - but
that does not make the world a better place, don't it.

Martin

--
mailto://kr******@users.sourceforge.net
Ada programming at: http://ada.krischik.com

[Chad R. Meiners]

Jerry Coffin wrote

I was talking specifically about Airbus' use, and looking at:
http://www.esil.univ-mrs.fr/~spc/rcs.../Baufreton.pdf
and:
http://www.systemes-critiques.org/js...oisXavier_Dorm...
indicates that they're consistently using C, not Ada.

No the slides do not indicate this. For all we know the project that
the slides are talking about has to target hardware for which there is
only a C compiler. It could be that Airbus only uses such tools on
such hardware.

Using presentation slides as such an indicator is usually a bad idea.
Presentation slides are made for a specific context, and time frame.
They often lack full and complete information. The slides don't
explicitly support your claim.

[Chad R. Meiners]

Jerry Coffin wrote:

Second, this seems to assume that all the code is generated by SCADE,
and none written directly. This does NOT seem to be the case -- if you look at page 6 of:
http://scilabsoft.inria.fr/events/05_11_03/ESTEREL.pdf
you'll see that they only claim 70% of the code was generated by SCADE.Given the size of project we're talking about, the remaining 30% is a
_significant_ amount of code. It seems likely to me that if they were
using Ada for the hand-written code, they'd generate Ada as well.

First, this nine slide sales pitch doesn't actually mention any
language other than SCADE. Second, the 70% could have been the user
interface, which communicated with a seperate subsystem that made up
the bulk of the the remaining 30%. If a language like SCADE can't
generate 95-99% of the code that it needs for a project, it isn't a
very good formal tool. 30% is an aweful lot of room to invalidate any
assurances that SCADE provided about the 70%. It would be my educated
guess that SCADE was used in a subsystem which represented about 70% of
the total code of the complete system. Anyway, when you deal with code
generators size is deceptive. Generated code can be bloated very
easily.

As I mentioned previously, you are jumping to conclusions that are not
supported by your evidence

[Chad R. Meiners]

Jerry Coffin wrote

You clearly don't understand even the simplest logic. Being able to do
all the same things directly implies having similar capabilities.

If we were using that destinction, discussing the differences being
Turing-complete languages would be pretty pointless. That would be the
logical conclusion of what you just said. ;-)

[Hyman Rosen]

Martin Krischik wrote:

Disclaimer: Both sources might not be in working order - everytime I switch
compiler (IBM C++ -> MS-C++ -> G++) the code need reworking and the switch
to GNU is not finished yet.

I looked at Ada Array and immediately found errors
(eg., in 'typename TheIndex const First;' the 'typename'
keyword is not permitted). I suggest you try out your
code on Comeau, God's Own C++ Compiler (they ought to
trademark that phrase :-) It's available on the web at
<http://www.comeaucomputing.com/tryitout/>.

[Hyman Rosen]

Jerry Coffin wrote:

I see. So what is it that (you incorrectly believe) the C preprocessor
can do that a Lisp macro can't do?

Can Lisp macros manipulate the text of the macro arguments?
For example,

#define cat1(a, b) a ## b
#define cat2(a, b) cat1(a, b)

#define A x
#define B y
cat1(A, B) // produces AB
cat2(A, B) // produces xy

[Jerry Coffin]

Martin Krischik wrote:

[ ... ]

For marketing people that's the same: Cool is only what makes money -
but that does not make the world a better place, don't it.

I'd say rather the opposite: a large part of the reason capitalism is
so successful is that there really _is_ a fairly strong correlation
between making money and making the world better -- and no need to
point out the multitudes of exceptions -- I'm aware of them, which is
why I said "fairly strong."

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Jerry Coffin]

Chad R. Meiners wrote:

Second, this seems to assume that all the code is generated by SCADE, and none written directly. This does NOT seem to be the case -- if
you look at page 6 of:
http://scilabsoft.inria.fr/events/05_11_03/ESTEREL.pdf
you'll see that they only claim 70% of the code was generated by
SCADE. Given the size of project we're talking about, the remaining
30% is a _significant_ amount of code. It seems likely to me that if they were using Ada for the hand-written code, they'd generate Ada
as well.
First, this nine slide sales pitch doesn't actually mention any
language other than SCADE.

And so? What part of "it seems likely" don't you understand?
Second, the 70% could have been the
user interface, which communicated with a seperate subsystem that
made up the bulk of the the remaining 30%.
And so? The point is that picking the language for that 70% seems to
take one choice in one list box -- i.e. the most utterly trivial amount
of work possible. With that given, are you honestly suggesting that
it's particularly likely that they'd choose to generate C if they were
planning to write the remainder in Ada?
If a language like
SCADE can't generate 95-99% of the code that it needs for a
project, it isn't a very good formal tool.
I don't recall anybody here having suggested that SCADE is the be-all
and end-all of format tools. OTOH, I have to point out that unless
their claims are flat-out falsehoods, it's been selected by people
you'd expect to be reasonably well-qualified to be used in some
projects that give every appearance of being quite important to those
involved.
30% is an aweful lot
of room to invalidate any assurances that SCADE provided about
the 70%. It would be my educated guess that SCADE was used in
a subsystem which represented about 70% of the total code of
the complete system. Anyway, when you deal with code
generators size is deceptive. Generated code can be bloated very
easily.

As I mentioned previously, you are jumping to conclusions that are not supported by your evidence

I drew exactly two conclusions: 1) that 100% minus 70% leaves 30%, and
2) that these _seem_ to be sufficiently large projects that 30% of them
still constitutes a substantial amount of code.

Since you claim that my conclusions (plural) are unsupported by the
evidence, and I only drew two conclusions to start with, your claim
must apply to both. So, let's start with the first: please expound on
your form of math in which 100 minus 70 doesn't equal 30.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Dave Thompson]

On 21 Mar 2005 16:00:23 -0500, Robert A Duff
<bo*****@shell01.TheWorld.com> wrote:

az****@yahoo.es (Alberto) writes:

"Dmitry A. Kazakov" <ma*****@dmitry-kazakov.de> wrote in message news:<1l******************************@40tude.net> ... <snip>

2. C++ is unable to allocate objects of indefinite size on the stack.
Well, we have alloca() for this ;)

Is alloca part of the C++ standard? I thought not, but I could be
wrong. Anyway, alloca doesn't really do all that Ada can do in this

No, nor standard C either.
regard (avoiding heap usage for dynamic-sized things). In this case,
the Ada feature is both more efficient and safer than alloca.

Where available, alloca does allocate on the stack. AFAICS this can
do, at a lower/less-safe level, everything Ada can do at function
scope. It can't do allocation _and deallocation_ for a block within a
function, nor cross-function like function-return-unconstrained. It
almost has to be special-cased/inlined so it should be efficient.
- David.Thompson1 at worldnet.att.net

[Paul Mensonides]

Hyman Rosen wrote:

Jerry Coffin wrote:

I see. So what is it that (you incorrectly believe) the C
preprocessor can do that a Lisp macro can't do?

Can Lisp macros manipulate the text of the macro arguments?
For example,

#define cat1(a, b) a ## b
#define cat2(a, b) cat1(a, b)

#define A x
#define B y
cat1(A, B) // produces AB
cat2(A, B) // produces xy

Lisp macros cannot produce partial syntax either, whereas C/C++ macros can (e.g.
on macro can create a '{' and another separate invocation can create the closing
'}'). In the general case (obviously) Lisp (and Scheme) macros are far more
powerful than C/C++ macros.

As an aside, given suitable input, it is possible to create a compiler or
interpreter with the C/C++ preprocessor--with a relatively small number of
macros.

Jerry is correct to say that they do similar things--they parametize code with
code. The main differences is that in Lisp (etc.) their are syntactic
constraints (which is both good and bad in various scenarios) and that Lisp
executes in an environment (even when compiled) that can interpret code created
at runtime.

Regards,
Paul Mensonides

[Jerry Coffin]

Chad R. Meiners wrote:

Jerry Coffin wrote

I was talking specifically about Airbus' use, and looking at:
http://www.esil.univ-mrs.fr/~spc/rcs.../Baufreton.pdf
and:
http://www.systemes-critiques.org/js...oisXavier_Dorm...

indicates that they're consistently using C, not Ada.

No the slides do not indicate this. For all we know the project that
the slides are talking about has to target hardware for which there
is only a C compiler. It could be that Airbus only uses such tools
on such hardware.

First of all, at least in my dictionary, "indicate" is defined with
words like "points to" and "suggests", NOT "proves" or anything very
similar.

Second, I have to wonder whether you really have a good idea of the
size of project we're talking about. Just for example, Airbus is
currently working on the A350, which is fairly based fairly closely on
the A340, to the point that it's expected to share a common type rating
with the 340 (meaning as far as flying them goes, they're considered
the same plane).

Despite that derivation, the A350 is expected to take about 6 years and
cost (at least) 3,500,000,000 Euros to develop. Developing an entirely
new plane runs in the vicinity of twice that.

This leads to two points: first of all, neither Airbus nor anybody else
is designing hundreds or even dozens of these at a time -- IOW, knowing
what they're doing in only one or two projects really _does_ tell you a
lot about what the company as a whole is doing, and for an extended
period of time at that.

Second, unless porting Ada compilers is a LOT more expensive than
porting C++ compilers, pre-existing availability of a particular
compiler is NOT much of a consideration for this size of project. Just
for the sake of argument, let's assume a compiler port costs a half
million US dollars. If you figure that up in terms of how time spent on
the project, it comes to a matter of hours -- i.e. the compiler port
would only have to save them a couple of hours overall to pay for
itself.

Now, it's certainly true that software alone doesn't account for nearly
all the expenditure -- but it's significant enough to figure in the
same basic terms. The compiler might have to save a whole day to pay
for itself, but almost certainly would not have to save (say) a whole
month to pay off.
Using presentation slides as such an indicator is usually a bad idea.
Presentation slides are made for a specific context, and time frame.
They often lack full and complete information. The slides don't
explicitly support your claim.

I'll openly admit that the slides don't absolutely _prove_ nearly as
much as we'd like to know. They're generally vague, lacking detail,
definition or rigor -- but despite that they still constitute roughly
95% of the hard evidence presented so far in this entire thread!

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Jerry Coffin]

Chad R. Meiners wrote:

Jerry Coffin wrote

You clearly don't understand even the simplest logic. Being able to
do all the same things directly implies having similar capabilities.

If we were using that destinction, discussing the differences being
Turing-complete languages would be pretty pointless. That would be
the logical conclusion of what you just said. ;-)

If I ever teach a class, anybody who tries to abuse Turing completeness
like this will be requird to write his entire treatise on the
blackboard several times as punishment.

Turing's theorem shows, in essence, that a programming language can
implement any algorithm, but that's about it.

If you look at the percentage of a typical program that's devoted
strictly to implementing the fundamental algorithms, you'll quickly
realize that this is FAR from the entire set of capabilities of a real
language.

I should also point out that while C++'s templates are Turing complete,
C's macros are not, so Turing completeness is clearly misplaced as a
consideration here.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Ludovic Brenta]

"Dmitry A. Kazakov" writes:

Ludovic Brentawrites: [...]

package Ada.Exceptions.Extra is
type Extra_Information is abstract tagged null record;

procedure Raise_Exception (E : in Exception_Id;
Information : in Extra_Information'Class);

function Exception_Information (X : Exception_Occurrence)
return Extra_Information'Class;
end Ada.Exceptions.Extra;

[...]
A pair of simple questions:

1. Dispatching to non-existing methods of Extra_Information?
You'd have to "down-cast", which would raise Constraint_Error if the
Extra_Information was not of the expected type.
2. Accessibility rules for members of Extra_Information. Technically
Extra_Information is a sort of result value. As such it requires special
handling of all access values (pointers) it may do to local objects.
I would say that the actual type (that extends Exra_Information) must
be visible in the exception handler and at the point of
Raise_Exception.
3. Extra_Information should probably be controlled, what about
finalization rules?
I hadn't thought about that. For the mechanism to be useful, I
suppose that finalization would have to occur at the end of the
exception handler. However it may not be desirable that
Extra_Information be controlled, as this would make it possible for
Deallocate to raise an exception.
4. Two copies of Extra_Information if the exception was raised in a
rendezvous? Protected type Extra_Information? (protected types are
still untagged)
The Extra_Information doesn't have to be protected, it can contain an
access to a protected object. This would make it quite easy to raise
two copies of it in two tasks.
5. When and where Extra_Information gets deallocated?
I would say, at the end of the last exception handler (i.e. the one
that doesn't reraise the exception).
I think that before making any detailed proposals we should consider a
contract model of exceptions. Points 1..5 might look very different if
there were exception contracts.

What do you have in mind?

--
Ludovic Brenta.

[Ludovic Brenta]

Georg Bauhaus writes:

How about

declare
...
procedure bounce is
begin
set_up_information_to_pass;
end;
begin
raise with bounce'access;
end;

You mean that the "Extra_Information" I was contemplating would be
replaced with an access-to-procedure, and the exception handler would
be free to call the procedure?

Maybe this would address Dmitry's concerns about accessibility and
finalization. The existing accessibility rules are quite clear on
what procedure Bounce can see, and also prevent passing an access to
it to places where Bounce does not exist.

Your proposal is quite interesting.

--
Ludovic Brenta.

[Ludovic Brenta]

Ioannis Vranos writes:

Ludovic Brenta wrote:

I kind of like Ada exceptions as they are now. Because one cannot
carry much information in them (apart from the kluge you
mentioned), one tends not to rely on them for the normal flow of
operations. I have seen Java programs that would rely on
exceptions for all kinds of things, leading to spaghetti code. In
C++ I find it a bit odd that I can throw and catch an entire hash
table as an exception if I want to.

Being able to do whatever you want can certainly cause confusion for
anyone who is used to be helped how to program.

However, if you know the language, you know what to do and what to
not do. Also this way is more powerful.

Ah, that same old argument again. I don't know about you; you may be
the Perfect Programmer Who Knows What They're Doing, in which case I
don't know excactly why you are even condescending to read mere
mortals' babbling. As for me, I have been programming in 10 languages
or so for 15 years, and I still appreciate all the help I can get. In
fact, the more experience I get, the more I appreciate it.

But my point was not just about being helped; it was also about the
mathematical purity of the concept of exceptions. If an exception can
be anything at all, then what is so exceptional about it? I'm not
entirely decided on this point (being a mere engineer and not a
mathematician), I'm just uneasy at the thought, and I remember
badly-written programs I've seen before.

Pascal Obry once made an interesting remark: what is important for the
safety of a language is not what it allows but what it forbids.

The C++ way of catching all exceptions of a class and its derived
classes can lead to confusion. One can have multiple exception
handlers for the same exception and it may not be immediately
obvious to the reader which one is called. I see this as a
maintenance problem.

:-) Being able to walk alone can also lead to confusion. Isn't it
better if you walk with assistance?

Ah but *I* am the one assisting people, not to walk but to fly
aircraft. To some extent, they depend on me for their lives, and I
take that seriously. So, yes, as a program maintainer, I appreciate
any and all help, assurance and guarantees I can get.

A C++ program that throws a Window or a Button object or a
Database_Connection object violates the Law of Least Astonishment. If
I read C++ code, I must be prepared to see such things happen, and be
astonished. If I read Ada code, I know that this cannot happen, so I
can move on to more interesting considerations.

Another concern of mine with exception classes is that they'd have
to be allocated on the heap.

No, they do not have to. One can (and in most times does) throw an
exception object on the stack.

Please explain. I am not a compiler writer, and I fail to understand
how the compiler can allocate on the stack, and then propagate the
exception up the stack.

--
Ludovic Brenta.

[Ioannis Vranos]

Ludovic Brenta wrote:

But my point was not just about being helped; it was also about the
mathematical purity of the concept of exceptions. If an exception can
be anything at all, then what is so exceptional about it?
As a means of error handling.
Pascal Obry once made an interesting remark: what is important for the
safety of a language is not what it allows but what it forbids.

You can't protect a bad programmer from doing bad programming, unless you forbid him to
continue programming. :-)

Ah but *I* am the one assisting people, not to walk but to fly
aircraft. To some extent, they depend on me for their lives, and I
take that seriously. So, yes, as a program maintainer, I appreciate
any and all help, assurance and guarantees I can get.

So if you like to be as much constrained as possible, I think VB is much better for this.
Or even Logo. Plus it provides a turtle to help you.

A C++ program that throws a Window or a Button object or a
Database_Connection object violates the Law of Least Astonishment. If
I read C++ code, I must be prepared to see such things happen, and be
astonished.
I have never seen code that throws a button as an exception, although it is feasible to do
that. The language is supposed to provide some protection from accidental mistakes, not
from intentional coding or irrational minds.

Please explain. I am not a compiler writer, and I fail to understand
how the compiler can allocate on the stack, and then propagate the
exception up the stack.

#include <iostream>
class SomeException: public std::exception
{
const char *errorMessage;

public:
SomeException(const char *error):errorMessage(error) {}

const char *what( ) const throw()
{
return errorMessage;
}
};
int main() try
{
throw SomeException("Something is wrong!");
}
catch(std::exception &e)
{
std::cerr<<e.what()<<"\n";
}
C:\c>temp
Something is wrong!

C:\c>

The exception gets copied as it is propagated up to the stack (with the use of the copy
constructor). I am not a compiler writer either.
--
Ioannis Vranos

http://www23.brinkster.com/noicys

[I am using 90 characters word-wrapping - (800/640) *72= 90 or better described as:
(800/640) *80 - 10 for quotation= 90. If someone finds it inconvenient, please let me know].

[Ludovic Brenta]

Ioannis Vranos writes:

So if you like to be as much constrained as possible, I think VB is
much better for this. Or even Logo. Plus it provides a turtle to
help you.
Ah yes, embedded, real-time, certified Logo :) Come on.
#include <iostream>
class SomeException: public std::exception
{
const char *errorMessage;

public:
SomeException(const char *error):errorMessage(error) {}

const char *what( ) const throw()
{
return errorMessage;
}
};
int main() try
^
Isn't there a missing { here?
{
throw SomeException("Something is wrong!");
}
catch(std::exception &e)
{
std::cerr<<e.what()<<"\n";
}
And a missing } here? In which case I don't see any propagation of
your exception up the stack, as there is only one stack frame.
C:\c>temp
Something is wrong!

C:\c>

The exception gets copied as it is propagated up to the stack (with
the use of the copy constructor). I am not a compiler writer either.

Since you don't provide a copy constructor, only a shallow copy takes
place. Where is the message string allocated, and how do you know it
is still accessible when you catch the exception in a location remote
from the throw statement?

Also, copying the exception once for each stack frame seems quite
inefficient to me. I doubt that compiler writers would do that,
especially in the general case of C++ where the exception object can
be arbitrarily large.

--
Ludovic Brenta.

[Dmitry A. Kazakov]

On Mon, 28 Mar 2005 12:24:56 +0200, Ludovic Brenta wrote:

"Dmitry A. Kazakov" writes:

Ludovic Brentawrites: [...]

package Ada.Exceptions.Extra is
type Extra_Information is abstract tagged null record;

procedure Raise_Exception (E : in Exception_Id;
Information : in Extra_Information'Class);

function Exception_Information (X : Exception_Occurrence)
return Extra_Information'Class;
end Ada.Exceptions.Extra; [...]

A pair of simple questions:

1. Dispatching to non-existing methods of Extra_Information?

You'd have to "down-cast", which would raise Constraint_Error if the
Extra_Information was not of the expected type.

What if Extra_Information is extended:

type My_Extra_Information is new Extra_Information with private;
procedure Say (Info : My_Extra_Information);

At some non-library level Say gets overridden. Then this new object is
attached to an exception which is propagated out of the scope of the
override. A handler then makes a dispatching call to Say. What happens?

One possible solution is to force the attached object to the base class
when the child type gets out of scope. But then things become even more
interesting, because Say might be abstract! Then object need to be
partially finalized etc. That would be quite sort of C++! (:-))

Another solution is to route the exception to Program_Error when anything
from My_Extra_Information gets out of scope. This would be bullet proof,
but I don't believe many would enjoy it.
2. Accessibility rules for members of Extra_Information. Technically
Extra_Information is a sort of result value. As such it requires special
handling of all access values (pointers) it may do to local objects.

I would say that the actual type (that extends Exra_Information) must
be visible in the exception handler and at the point of
Raise_Exception.

But how would you check it? The exception handler knows nothing about any
derived types. Yet it can dispatch ... to something that no more exists.

3. Extra_Information should probably be controlled, what about
finalization rules?

I hadn't thought about that. For the mechanism to be useful, I
suppose that finalization would have to occur at the end of the
exception handler.

I thought about controlled components and pointers to controlled objects.
They may get out of scope before a handler catches the exception.
However it may not be desirable that
Extra_Information be controlled, as this would make it possible for
Deallocate to raise an exception.

4. Two copies of Extra_Information if the exception was raised in a
rendezvous? Protected type Extra_Information? (protected types are
still untagged)

The Extra_Information doesn't have to be protected, it can contain an
access to a protected object. This would make it quite easy to raise
two copies of it in two tasks.

Also it will be two copies of Extra_Information? I definitely do not like
it. This would mean that the behavior will vary depending on where
exception was raised.

I do prefer present by-value semantics of Ada model. But if it gets
extended, and the direction is tagged types, then that is another
semantics: tagged types are by-reference. The only possible logical
consequence of this is that user-defined exception objects have to be
protected.

5. When and where Extra_Information gets deallocated?

I would say, at the end of the last exception handler (i.e. the one
that doesn't reraise the exception).

OK that means that the mechanics will be pretty inefficient. Upon
Raise_Exception, the object will always be copied.

I think that before making any detailed proposals we should consider a
contract model of exceptions. Points 1..5 might look very different if
there were exception contracts.

What do you have in mind?

Let's consider a model based on [sub]types. If there are exception
contracts then all possible exception types are known in each handler
context. If you don't allow open-end things like exception'Class in
contracts then there is nothing to surprise you in any handler. OK, that
would probably be too rigid. We could relax it by allowing classes
constrained to ranges of types: sort of

type E1 is new exception with ...;
....
type EN is new EN-1 with ...;

procedure Foo
exception E1'Class (EN) | Constraint_Error | ...;

or

procedure Foo
exception E1..EN | Constraint_Error | ...;

The point is that Foo knows what it will raise, the handler knows if the
body may call Foo. Further Foo cannot raise anything defined within Foo.
Same is applicable to any scope. If I try

declare
My_Exception is new exception;
begin
...
end;

Then I'll get compile error telling that My_Exception may propagate out of
the scope.

declare
My_Exception is new exception;
Old_Style_Exception : exception; -- That's OK, no new type here
begin
...
exception
when My_Exception =>
... -- Alright now
end;

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[Ioannis Vranos]

Ludovic Brenta wrote:

int main() try

^
Isn't there a missing { here?

No.

{
throw SomeException("Something is wrong!");
}
catch(std::exception &e)
{
std::cerr<<e.what()<<"\n";
}

And a missing } here? In which case I don't see any propagation of
your exception up the stack, as there is only one stack frame.

The code is ISO C++ compliant as it is. The exception on the stack works in whatever stack
depth as far as the copy constructor is accessible (exists and is public).

Since you don't provide a copy constructor, only a shallow copy takes
place.

Which is the copying of the pointer value.

Where is the message string allocated, and how do you know it
is still accessible when you catch the exception in a location remote
from the throw statement?

The string literal exists in an implementation defined space and is guaranteed to be
accessible as long as it gets accessed.

Also, copying the exception once for each stack frame seems quite
inefficient to me. I doubt that compiler writers would do that,
especially in the general case of C++ where the exception object can
be arbitrarily large.

Yes the compiler writers are free and do optimise this. However the copy constructor is
required to be accessible for those who do not optimise it.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[I am using 90 characters word-wrapping - (800/640) *72= 90 or better described as:
(800/640) *80 - 10 for quotation= 90. If someone finds it inconvenient, please let me know].

[Ioannis Vranos]

Dave Thompson wrote:

Where available, alloca does allocate on the stack. AFAICS this can
do, at a lower/less-safe level, everything Ada can do at function
scope. It can't do allocation _and deallocation_ for a block within a
function, nor cross-function like function-return-unconstrained. It
almost has to be special-cased/inlined so it should be efficient.

In C++ you can always do:

#include <new>
class SomeClass
{
};
void somefunc()
{
unsigned char obj[sizeof(SomeClass)];

SomeClass *p= new(obj)SomeClass;

delete p;
}
as also:
#include <new>
class SomeClass
{
};
SomeClass *somefunc()
{
static unsigned char obj[sizeof(SomeClass)];

return new(obj)SomeClass;
}
int main()
{
SomeClass *p= somefunc();

delete p;
}
Here the object is created in the stack.
--
Ioannis Vranos

http://www23.brinkster.com/noicys

[I am using 90 characters word-wrapping - (800/640) *72= 90 or better described as:
(800/640) *80 - 10 for quotation= 90. If someone finds it inconvenient, please let me know].

[Ioannis Vranos]

Ioannis Vranos wrote:

In C++ you can always do:

#include <new>
class SomeClass
{
};
void somefunc()
{
unsigned char obj[sizeof(SomeClass)];

SomeClass *p= new(obj)SomeClass;

delete p;
}
as also:
#include <new>
class SomeClass
{
};
SomeClass *somefunc()
{
static unsigned char obj[sizeof(SomeClass)];

return new(obj)SomeClass;
}
int main()
{
SomeClass *p= somefunc();

delete p;
}
Here the object is created in the stack.

Of course, one can also do:

#include <iostream>
#include <new>
class SomeClassA
{
int array[1024];
};

class SomeClassB
{
public:
SomeClassB() { std::cout<<"Constructor called!\n"; }
~SomeClassB() { std::cout<<"Destructor called!\n"; }
};
void somefunc()
{
SomeClassA objA;

SomeClassB *p= new(&objA) SomeClassB;

delete p;
}

int main()
{
somefunc();
}
corrupting objA in this way and invoking undefined behaviour.

But C++ is an enabling language, and not a prohibiting language. You can really do
whatever you want, and provides some protection from accidental mistakes only, and not
from intentional coding.


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[I am using 90 characters word-wrapping - (800/640) *72= 90 or better described as:
(800/640) *80 - 10 for quotation= 90. If someone finds it inconvenient, please let me know].