Ada to C translator ?

Ada to C translator ?

[Eric Labbe]

		We are currently in the process of translating a huge
	application ( > 100000 lines) from Ada to C.  We desesperatly
	seek ways to accelerate the work.
 
		Is there any tools that is able to perform a decent
	job in translating from Ada to C?  By decent, I mean something
	that can understand the semantic of the Ada code before trying
	to translate (not a tool that blindly replace the Ada code by
	C synthax, we already have such a tool, and it does not help).

		Thanks for any help.

		Please reply by e-mail to: ericl@cae.ca

-- 
=======================
 Eric Labbe                       SysOp of Amiga-Zone (514) 482-1339
 Internet:ericl@cae.ca            Montreal, Qc. (Canada)
 Computer-Analyst (B.Sc)          I like Denise, Agnus, Paula, Lisa & Alice

Ada to C translator ?

[Stewart French]

Hello all,

I have about 30,000 lines of Ada code for a DSP that I'd like to convert
to C.
I've done a bunch of net searches without luck.  Do any of you know of
any
Ada to C code translators?  Companies?  Web pages?  etc.

Thanks aBunch,

Stewart French
french@ti.com

PS.  Please email me directly.

Re: Ada to C translator ?

[Gautier]

>I have about 30,000 lines of Ada code for a DSP that I'd like to convert
>to C.
>I've done a bunch of net searches without luck.  Do any of you know of
>any
>Ada to C code translators?  Companies?  Web pages?  etc.

Problem is that it is rather a compilation than a translation...
On complexity/feature scale you have

ASM...C...................Ada

The best to do is to keep the source in Ada!
The GNAT compiler produces an ASM code that you can retreive.

-- 
Gautier

Ada to C++ translator?

[Robert Brantley]

Any recommendations on a Ada to C++ translator?  We have no Ada tasking
constructs to deal
with.

Thanks in advance,

Robert Brantley
robert.brantley@lmco.com

Re: Ada to C++ translator?

[Britt Snodgrass]

Robert Brantley wrote:
> 
> Any recommendations on a Ada to C++ translator?  We have no Ada tasking
> constructs to deal with.

I doubt you'll get much help here. You should probably post this to
comp.lang.really_bad_ideas :)

Britt

Re: Ada to C++ translator?

[Jeffrey Carter]

Robert Brantley wrote:
>
> Any recommendations on a Ada to C++ translator?  We have no Ada tasking
> constructs to deal with.

Why do you want to increase the number of errors in your software?

-- 
Jeff Carter
"Sons of a silly person."
Monty Python & the Holy Grail

Re: Ada to C++ translator?

[Brian Rogoff]

On Fri, 9 Feb 2001, Britt Snodgrass wrote:

> Robert Brantley wrote:
> > 
> > Any recommendations on a Ada to C++ translator?  We have no Ada tasking
> > constructs to deal with.
> 
> I doubt you'll get much help here. You should probably post this to
> comp.lang.really_bad_ideas :)

As much as I agree with the second statement (C++ is rather dreadful from
an Ada perspective, popularity notwithstanding :) I'll have to prove the
first wrong. 

Averstar
http://www.averstar.com/services/IT_consulting.html
has some Ada -> C technology. That may be good enough.

http://www.ada2cc.com/   
offers a program for this. 

I haven't used either of these, nor do I imagine I ever will. Seems like a 
step backwards. 

-- Brian

Re: Ada to C++ translator?

[Gautier]

Robert Brantley:

> Any recommendations on a Ada to C++ translator?  We have no Ada tasking
> constructs to deal with.

Strange... Do you feel you are obliged to use
the Ada tasking just because this is available ?!
Or do you think you don't need Ada just because
there is no tasking in your program ?
In that case, it would be worth to try the
translation a couple of months, just to see the difference.

BTW, I'm looking for a device for transferring
my hard disk's contents onto punched cards. Does anyone
know such a device ?

__________________________________________
Gautier  --  http://www.diax.ch/users/gdm/

Re: Ada to C++ translator?

[Pascal Obry]

Gautier <xxx@yyy.zzz> writes:
> BTW, I'm looking for a device for transferring
> my hard disk's contents onto punched cards. Does anyone
> know such a device ?

I'll be glad to help if you provide the cards :) I don't feel like
handling kilometers of cards... What I do need is to put my swap 
partition onto puched cards and find a fast and automated robot to
automagically put the right cards into the machine to load the 
right page... the page must be laoded in less that 1ms.

Ah the pleasure to start from the wrong technology and start patching
and hacking it until it meets your needs !

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: Ada to C++ translator?

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 423 bytes --]


"Gautier" <xxx@yyy.zzz> a �crit dans le message news: 3A866B28.CE67B4A0@yyy.zzz...
> BTW, I'm looking for a device for transferring
> my hard disk's contents onto punched cards. Does anyone
> know such a device ?
>
Sure...
   cp -R /* /dev/punch
:-)

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: Ada to C++ translator?

[Larry Kilgallen]

In article <3A866B28.CE67B4A0@yyy.zzz>, Gautier <xxx@yyy.zzz> writes:
> Robert Brantley:
> 
>> Any recommendations on a Ada to C++ translator?  We have no Ada tasking
>> constructs to deal with.
> 
> Strange... Do you feel you are obliged to use
> the Ada tasking just because this is available ?!

I presumed he meant that automated translation of software
that did not use Ada tasking would be easier than doing so
for software that did use Ada tasking.

==============================================================================
Great Inventors of our time: Al Gore -> Internet; Sun Microsystems -> Clusters
==============================================================================

Re: Ada to C++ translator?

[Ken Garlington]

"Gautier" <xxx@yyy.zzz> wrote in message news:3A866B28.CE67B4A0@yyy.zzz...
: Robert Brantley:
:
: > Any recommendations on a Ada to C++ translator?  We have no Ada tasking
: > constructs to deal with.
:
: Strange... Do you feel you are obliged to use
: the Ada tasking just because this is available ?!
: Or do you think you don't need Ada just because
: there is no tasking in your program ?
: In that case, it would be worth to try the
: translation a couple of months, just to see the difference.
:
: BTW, I'm looking for a device for transferring
: my hard disk's contents onto punched cards. Does anyone
: know such a device ?

Well, that would be as silly as transferring it to magnetic tape! After all,
your tape drive is probably slower than your hard drive, and the tape is
likely to be less reliable as well!

(Oh, wait, people *do* still do that for backups. Never mind.)

Re: Ada to C++ translator?

[Florian Weimer]

Gautier <xxx@yyy.zzz> writes:

> BTW, I'm looking for a device for transferring
> my hard disk's contents onto punched cards. Does anyone
> know such a device ?

Ask some who is still using a Monotype typesetting machine.  He'll
probably have such a beast.

Re: Ada to C++ translator?

[Aaro Koskinen]

Gautier <xxx@yyy.zzz> writes:
> BTW, I'm looking for a device for transferring
> my hard disk's contents onto punched cards. Does anyone
> know such a device ?

Yes, in *BSD systems you can say "bcd < /dev/hdXd".

-- 
Aaro Koskinen, aaro@iki.fi, http://www.iki.fi/aaro

Re: Ada to C++ translator?

[David C. Hoos, Sr.]

Well, since cp doesn't replicate symbolic links, I think
a better solution would be one of the following:

cd /
tar cvf /dev/punch ./

or, if cards are in short supply:

cd /
tar zcvf /dev/punch ./
;)

"Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote in message
news:5cs569.a83.ln@skymaster.axlog.fr...
>
> "Gautier" <xxx@yyy.zzz> a �crit dans le message news:
3A866B28.CE67B4A0@yyy.zzz...
> > BTW, I'm looking for a device for transferring
> > my hard disk's contents onto punched cards. Does anyone
> > know such a device ?
> >
> Sure...
>    cp -R /* /dev/punch
> :-)
>
> --
> ---------------------------------------------------------
>            J-P. Rosen (Rosen.Adalog@wanadoo.fr)
> Visit Adalog's web site at http://pro.wanadoo.fr/adalog
>
>

Re: Ada to C++ translator?

[Ted Dennison]

In article <Pine.BSF.4.21.0102091527200.6785-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> On Fri, 9 Feb 2001, Britt Snodgrass wrote:
>
> > Robert Brantley wrote:
> > >
> > > Any recommendations on a Ada to C++ translator?  We have no Ada
> > > tasking constructs to deal with.

> Averstar
> http://www.averstar.com/services/IT_consulting.html
> has some Ada -> C technology. That may be good enough.
>
> http://www.ada2cc.com/
> offers a program for this.

Those convert to C, not C++. For instance, neither would convert a
tagged type to a C++ class.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/

Re: Ada to C++ translator?

[Ted Dennison]

In article <3A844255.24A4DBA3@lmco.com>,
  Robert Brantley <robert.brantley@lmco.com> wrote:
> Any recommendations on a Ada to C++ translator?  We have no Ada
> tasking constructs to deal with.

(sigh) Poor guy.

As you have probably gathered from all the snide comments, there isn't a
program to do this. There are some around for C, but none for C++. The
best I can think of would be to use one of those UML reverse-engieering
tools to get UML from Ada, then use its code generator to spit back out
C++. But I wouldn't suggest doing that. Most likely you'll just end up
with the biggest mess the world has seen since my 3-year-old got into my
old wargame boxes.

I'd say we could probably provide more help if you told us what you are
trying to accomplish by doing that, but that would probably just be
opening yourself up to more abuse (when most likely its your managment
that deserves the abuse).

Translation tools can be used successfully in some circumstances, but
they won't generally produce the kind of code you'd want to have to
maintain for years to come. Most of the time some stuff won't translate
very well, and will have to be hand-massaged on the output or on the
input side. The process will probably introduce some new bugs, so you
will have to redo all the code's testing, debugging, and acceptance
phases. If the code is mission-critical, you will also want someone to
go over the output with a fine-toothed comb to mare sure there aren't
any obscure lurking nasties. Odds are any good developer who has to go
through all this is going to be sorely tempted to rewrite the code
anyway to make it into more idomatic C++. So its not going to be easy or
cheap. Thus translation should be used as an emergency last resort, not
as a magic wand.

Now, I hate to join the Greek chorus here, but is it *truly* that much
of an emergency? The only reason I could think of that would ever make
it worth the effort would be if there were a platform out there that I
*had* to use for some reason that had no Ada (or C) compiler available
for it.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/

Re: Ada to C++ translator?

[Brian Rogoff]

On Mon, 12 Feb 2001, Ted Dennison wrote:
> In article <Pine.BSF.4.21.0102091527200.6785-100000@shell5.ba.best.com>,
>   Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> > On Fri, 9 Feb 2001, Britt Snodgrass wrote:
> >
> > > Robert Brantley wrote:
> > > >
> > > > Any recommendations on a Ada to C++ translator?  We have no Ada
> > > > tasking constructs to deal with.
> 
> > Averstar
> > http://www.averstar.com/services/IT_consulting.html
> > has some Ada -> C technology. That may be good enough.
> >
> > http://www.ada2cc.com/
> > offers a program for this.
> 
> Those convert to C, not C++. For instance, neither would convert a
> tagged type to a C++ class.

I already mentioned that the Averstar technology converts to C. And unless 
you know for a fact that the web page lies, www.ada2cc converts to C++ 
NOT C. Whether it does what you want with tagged types or not is
irrelevant; the generated code in their examples uses classes and
namepsaces, and they translate generics to templates. That's not C!

-- Brian

Re: Ada to C++ translator?

[David C. Hoos, Sr.]

Ted,

Have you actually looked at the output of ada2cc?

It _does_ generate classes, even for untagged types,
and it generates templates for generics -- not found in
your everyday C compiler.


"Ted Dennison" <dennison@telepath.com> wrote in message
news:968u79$405$1@nnrp1.deja.com...
> In article <Pine.BSF.4.21.0102091527200.6785-100000@shell5.ba.best.com>,
>   Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> > On Fri, 9 Feb 2001, Britt Snodgrass wrote:
> >
> > > Robert Brantley wrote:
> > > >
> > > > Any recommendations on a Ada to C++ translator?  We have no Ada
> > > > tasking constructs to deal with.
>
> > Averstar
> > http://www.averstar.com/services/IT_consulting.html
> > has some Ada -> C technology. That may be good enough.
> >
> > http://www.ada2cc.com/
> > offers a program for this.
>
> Those convert to C, not C++. For instance, neither would convert a
> tagged type to a C++ class.
>
> --
> T.E.D.
>
> http://www.telepath.com/~dennison/Ted/TED.html
>
>
> Sent via Deja.com
> http://www.deja.com/

UML (Was: Ada to C++ translator?)

[Frode Tennebø]

Ted Dennison wrote:

> In article <3A844255.24A4DBA3@lmco.com>,
>   Robert Brantley <robert.brantley@lmco.com> wrote:
> > Any recommendations on a Ada to C++ translator?  We have no Ada
> > tasking constructs to deal with.
> 
> (sigh) Poor guy.
> 
> As you have probably gathered from all the snide comments, there isn't
> a program to do this. There are some around for C, but none for C++.
> The best I can think of would be to use one of those UML
> reverse-engieering tools to get UML from Ada, then use its code
> generator to spit back out C++. But I wouldn't suggest doing that.
> Most likely you'll just end up with the biggest mess the world has
> seen since my 3-year-old got into my old wargame boxes.

This is indeed a very interesting idea. I have only barely touched a 
UML tool (Rational Rose), so I wouldn't really have any experiences at 
all. However, one of it's selling points is the ability to reverse 
engineer code and draw fancy diagrams for you.

And if it can do Ada -> UML -> Ada, why should it not manage 
Ada -> UML -> C++ (or more desireable, C++ -> UML -> Ada)?

Have you tried this without success before?

 -Frode

-- 
^ Frode Tenneb� | email: frodet@nvg.org | Frode@IRC  ^
| with Standard.Disclaimer; use Standard.Disclaimer; |

Re: Ada to C++ translator?

[Ted Dennison]

In article <Pine.BSF.4.21.0102120745010.11440-100000@shell5.ba.best.com>,
Brian
Rogoff says...
>
>On Mon, 12 Feb 2001, Ted Dennison wrote:

>> Those
convert to C, not C++. For instance, neither would convert a
>> tagged type to a
C++ class.
>
>... unless
>you know for a fact that the web page lies, www.ada2cc
converts to C++

Ahhh, no. I just assmed that their product name didn't lie (I'm
used to "cc"
being the name of the c compiler and "cpp" being the name of the
C++ compiler).
:-) My bad.


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

Re: UML (Was: Ada to C++ translator?)

[Ken Garlington]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 674 bytes --]

"Frode Tenneb�" <frodet@nvg.org> wrote in message news:ddo969.8qa.ln@leia...

: This is indeed a very interesting idea. I have only barely touched a
: UML tool (Rational Rose), so I wouldn't really have any experiences at
: all. However, one of it's selling points is the ability to reverse
: engineer code and draw fancy diagrams for you.
:
: And if it can do Ada -> UML -> Ada, why should it not manage
: Ada -> UML -> C++ (or more desireable, C++ -> UML -> Ada)?
:
: Have you tried this without success before?

My understanding is that Rose will only generate the overall structure of
the code; it's not a complete code generator (or, by extension, a
translator).

Re: UML (Was: Ada to C++ translator?)

[Ray Blaak]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2226 bytes --]

"Ken Garlington" <Ken.Garlington@computer.org> writes:
> "Frode Tenneb�" <frodet@nvg.org> wrote in message news:ddo969.8qa.ln@leia...
> : And if it can do Ada -> UML -> Ada, why should it not manage
> : Ada -> UML -> C++ (or more desireable, C++ -> UML -> Ada)?

One of the realities of modeling in UML is that you can never become completely
independent of the target language.

For example, one tends to name things using the style of the target language
(e.g Do_Something vs DoSomething vs doSomething), and one tends to use when
necessary the primitive types of the target language for attribute types,
return and parameter types (e.g. Integer vs int, empty return type vs "void").

E.g. a UML method destined for Ada might look like this on a UML diagram:

  Do_Something(Right_Now : Integer)

for Java:

  doSomething(rightNow : int) : void

The types especially are the real problem. As the primitive types vary from
language to language, and as UML does not have any such primitive types, there
is no standard with which a code generator or reverse engineering tool could
automatically translate things.

Other nits: default parameters (Java doesn't have them, Ada and C++ do),
overall UML representation (C++ and Java use classes almost exclusively, Ada,
technically speaking has only packages, types, and routines -- the class
structure in UML for Ada has to follow some sort of convention), target
language types that don't map to UML (e.g. Ada's array types also need to have
some sort of convention to map them on to UML classes).

All these things directly affect the contents of the UML model, and the
conventions of representing UML for one language does not necessarily or even
usually apply to the conventions for another language.

The best you can do (and I have done this myself) is to reverse engineer into
UML, and run some sort script on the UML model to translate the primitive types
and conventions over.

--
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: UML (Was: Ada to C++ translator?)

[Nick Williams]

Ken Garlington wrote:

> : And if it can do Ada -> UML -> Ada, why should it not manage
> : Ada -> UML -> C++ (or more desireable, C++ -> UML -> Ada)?
> :
> : Have you tried this without success before?
> 
> My understanding is that Rose will only generate the overall structure of
> the code; it's not a complete code generator (or, by extension, a
> translator).

Certainly, this is backed up by my own experience.

Rose 98i will code generate package specifications and stubbed bodies; 
as well as basic accessor subprograms, but it's quite clear that UML is 
not sufficient to convey the full semantic meaning of a reverse 
engineered program.

Admittedly, we are code generating for a SPARK environment, rather than 
an Ada one, so a great deal of the code that Rose would create (which 
depends heavily on access types, generics, tagged types etc) is out of 
bounds.

I would be very surprised if Rose 2000 were very much different.

Cheers,

Nick.

Re: UML (Was: Ada to C++ translator?)

[Ray Blaak]

Nick Williams <nickw@acm.org> writes:

> Ken Garlington wrote:
> Rose 98i will code generate package specifications and stubbed bodies; 
> as well as basic accessor subprograms, but it's quite clear that UML is 
> not sufficient to convey the full semantic meaning of a reverse 
> engineered program.

Nor should it be. UML is about describing software designs. The full details of
the implementation are ... in the implementation.

One would not even want to describe the full implementation in a UML model. The
level of abstraction is all wrong.

Just consider the work required to put this on some sort of UML diagram:

  for i := 1..10 loop
    Ada.Text_IO.Print(Integer'Image(i));
  end loop;

One would have to tediously draw out all sorts of nit-picky details. The
diagram won't necessarily be comprehensible either.  It is far more succinct
and understandable to simply write and/or look at the code.

The important information to put in a UML model is that which lets the reader
know what the major pieces of a system are, and how they relate. That is, the
reader leaves with a decent understanding of how to go about implementing the
system. The precise realization of the design is more properly described in the
code.

Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: UML (Was: Ada to C++ translator?)

[Pierre Dissaux]

Ray Blaak wrote:
> 
> Nick Williams <nickw@acm.org> writes:
> 
> > Ken Garlington wrote:
> > Rose 98i will code generate package specifications and stubbed bodies;
> > as well as basic accessor subprograms, but it's quite clear that UML is
> > not sufficient to convey the full semantic meaning of a reverse
> > engineered program.
> 
> Nor should it be. UML is about describing software designs. The full details of
> the implementation are ... in the implementation.
> 
> One would not even want to describe the full implementation in a UML model. The
> level of abstraction is all wrong.
> 

HOOD (Hierarchical Object Oriented Design) method offers a better
approach at this level:

- easy to use graphical notation for Architectural Design: based on the
concept of Module which always maps an Ada package (it may represent a
class like UML, or any other software abstraction you can find in an Ada
application). The method helps minimizing dependencies between the
modules.
- comprehensive textual notation for Detailed Design: all design
documentation and code fits into a normalized textual structure (called
ODS).
- program structure (packages, dependencies,...) and behavioural code
(tasking, ...) can be automatically generated whereas procedural code
and more complex declarations are hand written, but within a well
defined framework and under the control of a tool (controlling the
dependencies again).
- supports Ada reverse engineering

for further information:
http://www.tni.fr/tni/offre/stood/index.eng.html

Pierre Dissaux,
TNI

> Just consider the work required to put this on some sort of UML diagram:
> 
>   for i := 1..10 loop
>     Ada.Text_IO.Print(Integer'Image(i));
>   end loop;
> 
> One would have to tediously draw out all sorts of nit-picky details. The
> diagram won't necessarily be comprehensible either.  It is far more succinct
> and understandable to simply write and/or look at the code.
> 
> The important information to put in a UML model is that which lets the reader
> know what the major pieces of a system are, and how they relate. That is, the
> reader leaves with a decent understanding of how to go about implementing the
> system. The precise realization of the design is more properly described in the
> code.
> 
> Cheers,                                        The Rhythm is around me,
>                                                The Rhythm has control.
> Ray Blaak                                      The Rhythm is inside me,
> blaak@infomatch.com                            The Rhythm has my soul.

Re: Ada to C++ translator?

[Robert Brantley]

Wow, I didn't expect this many posts in response.
Thanks to everyone that replied here or by mail, sorry I didn't make it
back to read the responses earlier.

Robert Brantley
robert.brantley@lmco.com

Re: Ada to C++ translator?

[Robert Brantley]

Ted Dennison wrote:

> Most likely you'll just end up
> with the biggest mess the world has seen since my 3-year-old got into my
> old wargame boxes.

I got mine buried in the closet so they can't get at them.

>
> I'd say we could probably provide more help if you told us what you are
> trying to accomplish by doing that, but that would probably just be
> opening yourself up to more abuse (when most likely its your managment
> that deserves the abuse).
>

We are re-using code from a legacy system, and we have spent a lot of
effort on binding this legacy Ada code to the RTOS we are using.  As the
work
has progressed it has become increasing apparent how much work is involved
in mating the Ada code to the RTOS and the RTOS's development tools.  A
great
deal of complexity could be cut out if we move the application code to the
RTOS
native language or it's derivative C++.

There are also other pressures outside software development concerns pushing
us
toward C++.  The quality and price of available tool, hiring, etc.

The ideal was to see if we could automate the process of conversion as much
as
possible, we realize a 100%, or even 90%, mapping from one language to the
other
is impossible.

Robert Brantley
robert.brantley@lmco.com

Re: Ada to C++ translator?

[Robert Brantley]

Gautier wrote:

> Strange... Do you feel you are obliged to use
> the Ada tasking just because this is available ?!
> Or do you think you don't need Ada just because
> there is no tasking in your program ?

No there is a tasking involved.  No Ada tasking keywords to deal with though.

They didn't use the Ada tasking manager when they originally developed the
code,
apparently because it was to slow.

Robert Brantley
robert.brantley@lmco.com

Re: Ada to C++ translator?

[tmoran]

>We are re-using code from a legacy system, and we have spent a lot of
>effort on binding this legacy Ada code to the RTOS we are using.
  I don't quite understand the situation:  You had N lines of Ada running,
using an old RTOS, and now you are moving to a new RTOS and finding there
were M system calls that need changing, and M is a painfully large number.
The proposal is to convert to C/C++, which saves writing "pragma Import"
etc for the system calls.  If the automated conversion handles 90%, you
are left with N/10 things to manually fix, and I would think N/10 >> M.
If the system calls of the new RTOS are even slightly different, which
presumably they are or the problem wouldn't exist, you'll still have to do
work on them, even if they're now written in C.  If the structure of the
RTOS is different, you'll also have to change the structure of the app,
whether it's in C or Ada, and that's almost sure to be worse with a
(semi)mechanically translated C than with the original, lucid(?) Ada.  If
the number of *different* system calls is not high, wouldn't it be easier
to just create a layer that translates old RTOS calls into new RTOS calls?

Re: Ada to C++ translator?

[Lao Xiao Hai]

tmoran@acm.org wrote:

> >We are re-using code from a legacy system, and we have spent a lot of
> >effort on binding this legacy Ada code to the RTOS we are using.
>   I don't quite understand the situation:  You had N lines of Ada running,
> using an old RTOS, and now you are moving to a new RTOS and finding there
> were M system calls that need changing, and M is a painfully large number.
> The proposal is to convert to C/C++, which saves writing "pragma Import"
> etc for the system calls.  [snipped the rest of Tom's message ... ]

This is not an uncommon with Ada 95.  We have several clients using RTOS's
that were supported under Ada 83 but are not supported with Ada 95.  In
particular, the newer version of the RTOS is not supported under Ada 95 and
may be awkward, at best, trying to execute the older Ada 83 code.

For some of these RTOS (e.g.,  HP-RT), the developers have few options except
C or C++.   There simply is no Ada 95 available for the platform.   In the
HP-RT
example, Alsys, the original Ada compiler publisher is gone and its successor,
Aonix,
has no economic incentive to upgrade the compiler to Ada 95 for the new RTOS.

With the abrogation of the Ada "mandate" there are quite a few of these
unsupported
platforms for Ada 95.   Since the DoD contractor is not required to use Ada,
they
have no incentive to purchase a compiler.   Since they have not incentive to
purchase
a compiler, the compiler publisher has no incentive to produce a compiler.
This is
especially true for those small, seldom used platforms that are so specialized
that the
market is lean for them.    We have a lot of specialized  military computers
still in
service (and being upgraded) for which is little likelihood of there ever
being an
Ada 95 compiler.    There ought to be since these are often safety-critical.
However,
many DoD program managers have concluded that Ada is no longer relevant.
With
this kind of stupidity on the increase, compiler publishers are forced to take
the path of
best ROI.

Richard Riehle

Re: Ada to C++ translator?

[Tarjei T. Jensen]

Robert Brantley wrote >
>We are re-using code from a legacy system, and we have spent a lot of
>effort on binding this legacy Ada code to the RTOS we are using.  As the
>work
>has progressed it has become increasing apparent how much work is involved
>in mating the Ada code to the RTOS and the RTOS's development tools.  A
>great
>deal of complexity could be cut out if we move the application code to the
>RTOS
>native language or it's derivative C++.

Perhaps the following table from
http://www.rtcgroup.com/cotsjournal/cots7800/cots7800p60.html might be of
interest when you discuss the costs of using Ada. BTW Don't expect better
numbers from C++.

|language | Lines /| Errors /     | Time /  | Total /       |
|         | Error  | 10,000 Lines | Error   | 10,000 (hours)|
|---------+--------+--------------+---------+---------------|
|  Ada    |  270   |      37      |  20 min |  12.35 hours  |
|---------+--------+--------------+---------+---------------|
|   C     |   80   |     125      | 240 min | 500 hours     |
+-----------------------------------------------------------+

Remember time is subjective. You don't really know how much time you spend
unless you measure.


Greetings,

Re: Ada to C++ translator?

[Ken Garlington]

Don't expect C++ to have better productivity numbers than C? Seems like a
statement that needs to be defended with data to me...

IMO, this thread is one of the reasons why Ada is so hard to sell. There are
so many claims that Ada is "obviously" better than all other options in all
other circumstances that it makes me cringe. Don't get me wrong -- I love
Ada -- but advocates hype it so hard that it sounds like used-car salesmen.
We have built products in both C and Ada; our data doesn't show a *12-to-1*
difference in debug times!


"Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote in message
news:96j1bo$723@news.kvaerner.com...
:
: Robert Brantley wrote >
: >We are re-using code from a legacy system, and we have spent a lot of
: >effort on binding this legacy Ada code to the RTOS we are using.  As the
: >work
: >has progressed it has become increasing apparent how much work is
involved
: >in mating the Ada code to the RTOS and the RTOS's development tools.  A
: >great
: >deal of complexity could be cut out if we move the application code to
the
: >RTOS
: >native language or it's derivative C++.
:
: Perhaps the following table from
: http://www.rtcgroup.com/cotsjournal/cots7800/cots7800p60.html might be of
: interest when you discuss the costs of using Ada. BTW Don't expect better
: numbers from C++.
:
: |language | Lines /| Errors /     | Time /  | Total /       |
: |         | Error  | 10,000 Lines | Error   | 10,000 (hours)|
: |---------+--------+--------------+---------+---------------|
: |  Ada    |  270   |      37      |  20 min |  12.35 hours  |
: |---------+--------+--------------+---------+---------------|
: |   C     |   80   |     125      | 240 min | 500 hours     |
: +-----------------------------------------------------------+
:
: Remember time is subjective. You don't really know how much time you spend
: unless you measure.
:
:
: Greetings,
:
:
:
:

Re: Ada to C++ translator?

[Marin David Condic]

"Ken Garlington" <Ken.Garlington@computer.org> wrote in message
news:e%9j6.251$uU2.28276829@newssvr16.news.prodigy.com...
> Don't expect C++ to have better productivity numbers than C? Seems like a
> statement that needs to be defended with data to me...
>
> IMO, this thread is one of the reasons why Ada is so hard to sell. There
are
> so many claims that Ada is "obviously" better than all other options in
all
> other circumstances that it makes me cringe. Don't get me wrong -- I love
> Ada -- but advocates hype it so hard that it sounds like used-car
salesmen.
> We have built products in both C and Ada; our data doesn't show a
*12-to-1*
> difference in debug times!
>
While I basically agree that hype and exageration do not help "The Cause", I
think it is important to note the YMMV caveat. If you have experienced Ada
developers who are writing code in C/C++, chances are they are going to
avoid the "Stupid C Tricks" and work effectively with the software design to
make sure it is a solid piece of C code. If you are talking about "typical"
C code (especially that which may have been developed several years ago) you
might get drastically different results.

Most C code I have encountered is pretty lousy because your garden variety C
programmer tends to have more of an assembly language mentality and/or is
enamoured with the conciseness and cleverness possible within the language.
They tend to have the attitude that "this ought to be understood by any
*competent* C programmer!!!" with no regard for the economics involved. (You
can't always have a team of "competent" C programmers and it doesn't make
the company any money to have someone stopping in the middle of reading some
code to go delving into C manuals to decrypt your obscure "clever" code. In
other words, clear, simple, idiot-proof code may not be as interesting to
write, but it MAKES MONEY!)

So it may be hard to draw across-the-board conclusions about C/C++ v Ada in
terms of the economics, but I have no trouble believing that within some env
ironments there may very well be a 12/1 ratio. The only way to know for sure
is to measure locally. And of course there are environments wherein bugs
don't matter much so there is less concern over the maintenance cost. One
needs to consider lots of factors in making judgements about the economics
of a given technology.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: Ada to C++ translator?

[Ted Dennison]

In article <3A8C6AA3.3F90043D@lmco.com>, Robert Brantley says...
>They didn't use the Ada tasking manager when they originally developed the
>code, apparently because it was to slow.

Heh. Not likely. Ada tasking execs generally fall into one of two categories:

1) Uses the OS "threading" capabilities.
In this case, it will be pretty much *exactly* the same speed in task 
switching as the OS. The main difference is that the Ada tasking exec is
debugged already, while a custom one you make you will have to debug
yourself.

2) Uses its own tasking code within a single OS process/thread.
This is usually significantly *faster* that OS threads, since it generally
doesn't incur a lot of system call overhead, as well as overhead for all
the extra fancy features an OS process/thread scheduler has to support.

More likely is that they didn't use Ada tasking becuase they needed real-time
performance, and Ada83 didn't support real-time tasking very well (it lacked the
"delay until" feature).

Its a shame you can't just rewite the Ada83 code in Ada95 instead of C++. It is
actually possible to write a *portable* real-time scheduler in Ada95 (no OS
calls whatsoever). The project I'm working on has actually done this. With C++
you are going to have to go through this same painful porting effort every time
you switch platforms. I don't envy you at all.

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

Re: Ada to C++ translator?

[Marin David Condic]

"Lao Xiao Hai" <laoxhai@ix.netcom.com> wrote in message
news:3A8CB3BE.B4DAB0BE@ix.netcom.com...
> With the abrogation of the Ada "mandate" there are quite a few of these
> unsupported
> platforms for Ada 95.   Since the DoD contractor is not required to use
Ada,
> they
> have no incentive to purchase a compiler.   Since they have not incentive
to
> purchase
> a compiler, the compiler publisher has no incentive to produce a compiler.
> This is
> especially true for those small, seldom used platforms that are so
specialized
> that the
> market is lean for them.    We have a lot of specialized  military
computers
> still in
> service (and being upgraded) for which is little likelihood of there ever
> being an
> Ada 95 compiler.    There ought to be since these are often
safety-critical.
> However,
> many DoD program managers have concluded that Ada is no longer relevant.
> With
> this kind of stupidity on the increase, compiler publishers are forced to
take
> the path of
> best ROI.
>
There is definitely a "Catch 22" situation with Ada compilers in this and
other areas. It's tough to generate the critical mass needed to make Ada
more popular - especially in the embedded world where there is such a big
dependency on tools other than the compiler.

One thing that might help considerably would be to get Ada front-ends onto
more of the embedded compilers already available. For example, there are
lots of embedded projects that are using the gcc compiler in some manner.
Last I checked the web site (http://www.gnu.org/software/gcc/gcc.html) for
gcc, they were claiming 6 language front ends built into the compiler. (O.K.
3 of them are C derivatives.) Ada, Pascal, Cobol, et alia are mentioned, but
are not part of the release. It seems to me that if Ada were part of the
standard gcc release, then at least there is the possibility of a project
that uses gcc to find a way to utilize Ada. Maybe one day "Real Soon Now"
this will happen. Until it does, it becomes very hard for embedded projects
to consider Ada if/when some part of the target environment changes and
there is no Ada toolset available to do the job. (And I'm terribly sorry to
inform the vendors that we just can't afford to pay them to rewrite their
compilers & toolsets if there is a less expensive option open to us. :-)

BTW: Green Hills (http://www.ghs.com/products.html) mentions they have
products for C/C++ and Ada development for embedded targets so there is a
choice for some platforms. Why the number of Ada targets is less than the
number of C/C++ targets, I do not know. It would seem that if the compiler
front-end & intermediate code supports Ada, that all the same targets should
work for either language. (Maybe it is the RTK or RTOS?) IMHO, a
proliferation of Ada front-ends would go a long way to gaining that critical
mass. Availability is a necessary (but not sufficient) condition for
success.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: Ada to C++ translator?

[Ted Dennison]

In article <3A8C6843.B46006D6@lmco.com>, Robert Brantley says...
>Ted Dennison wrote:
>
>> Most likely you'll just end up
>> with the biggest mess the world has seen since my 3-year-old got into my
>> old wargame boxes.
>
>I got mine buried in the closet so they can't get at them.

That's what I thought too. :-(

>We are re-using code from a legacy system, and we have spent a lot of
>effort on binding this legacy Ada code to the RTOS we are using.  As the
>work
>has progressed it has become increasing apparent how much work is involved
>in mating the Ada code to the RTOS and the RTOS's development tools.  A
>great
>deal of complexity could be cut out if we move the application code to the
>RTOS
>native language or it's derivative C++.

Out of curiosity, what compiler and RTOS? Your Ada vendor ought to have bindings
to the OS provided with the compiler.

Even without them, C bindings are trivial to write, once you get the hang of it.
Its certianly far less effort than a language port! 

And I don't see how having a C++ port is that going to help you the next time
you port to a new system.  Odds are you are actually *better off* right now with
the Ada sources than you would have been with C++ sources. At least the Ada
language itself is portable. C++ can't even say that much. The C++ porting guide
for Mozilla forbids using quite a few *core* language features (templates,
static constructors, exceptions, namespaces, among others) due to portability
issues. You can see 
http://www.mozilla.org/hacking/portable-cpp.html for the whole list. If you *do*
port to C++, you'd do well to read and follow it. 

>The ideal was to see if we could automate the process of conversion as much
>as possible, we realize a 100%, or even 90%, mapping from one language to the
>other is impossible.

Good. You at least need to be somewhat realistic about what you are getting
yourself into. 

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

Re: Ada to C++ translator?

[tmoran]

>We have built products in both C and Ada; our data doesn't show a *12-to-1*
>difference in debug times!
  Can you make that data public?
It would certainly be much more convincing to see 100 different
organizations' data showing everything from .5-to-1 to 12-to-1 with
an average of, say, 1.2-to-1.  Currently the public data is effectively
a censored distribution, with only the "Ada better" outliers mentioned
on c.l.a. (and perhaps the "C++ better" outliers mentioned there?).
A small N consisting solely of points selected to bolster a case, is
never very convincing.

Re: Ada to C++ translator?

[Ken Garlington]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:%Wvk6.102$aw5.380@www.newsranger.com...
: In article <cyik6.1725$DE.61421700@newssvr10-int.news.prodigy.com>, Ken
: Garlington says...
: >
: >"Ted Dennison" <dennison@telepath.com> wrote in message
: >news:Qybj6.354$a4.1745@www.newsranger.com...
: >: Heh. Not likely. Ada tasking execs generally fall into one of two
: >categories:
: >:
: >: 1) Uses the OS "threading" capabilities.
: >: In this case, it will be pretty much *exactly* the same speed in task
: >: switching as the OS. The main difference is that the Ada tasking exec
is
: >:
: >: 2) Uses its own tasking code within a single OS process/thread.
: >: This is usually significantly *faster* that OS threads, since it
generally
: >
: >This is *definitely* not true for *early* Ada compilers, compared to
: >current-generation RTOSs. (The key phrase in the original statement:
"when
: >they *originally* developed the code...)
:
: I suppose that's possible. In my experience, what I wrote has been
universally
: true. However, my experience with Ada only dates back to about 1989.

To paraphrase my response to another claim that efficient tasking has been
universally true since 1889 (e-mail me if you want the identity of "X", "Y"
and "Z").

"...the last copy of the Xcompiler for the VAX/1750 *still* had
poor tasking behavior (early '90s), as did the last Y one (still in use
today), compared to the lightweight threads available, say, in VxWorks for
the PowerPC. I'd be happy to post the Yassembly code sequences if
you're interested. You might claim that this is comparing apples (PowerPC)
with sour apples (1750A), but so what? It's only been recently (in project
lifetime scales) that modern 32-bit processors with COTS OSs and excellent
thread support has been available to us DoD contractors, so it's not
surprising that our systems reflect the limitations of the available
environment. You might also claim that these are obsolete compilers, and so
it's unfair to use them as a basis for comparison, but so what? We still use
Yon active projects because we can't afford to switch to another 1750
toolset.

"This behavior, by the way, is despite the (literally) millions of dollars
my
company invested in both companies before they went under (and still invest
in Z to maintain the remnants of the Y product). I'd be happy to
post the invoices if you're interested. You might claim that this is unfair
because we didn't making better tasking a priority, but so what? We spent
our money where we had to spend it -- to get the features that were the most
necessary. If we were able to do our job without tasking (but not without a
compiler that, for example, gave us access types now found in Ada95), then
we spent our money where our project needed it....

"How could you possibly have access to every toolset combination still
rattling around today, much less in the entire history of Ada, to run your
benchmarks? This hubris shouldn't be buried in an e-mail, it should be
publicly posted for the world to gaze at in awe! :)"

And now, of course, it is :)

As I've noted before, this sort of attitude makes it very difficult for me
to sell Ada. From the same post:

"There's plenty of blame to go around with respect to Ada...

"6. And the one that got us here: Legitimate issues with the Ada language
are
attacked with religious zeal instead of reason. Compare Ada/Eiffel
discussions with C/C++ discussions, then look at their penetration into the
software engineering community. I think you'll see a correlation....

"This has always been the case with Ada. I remember early X meetings
where we were trying to get a compiler bug fixed for a large package, and
being told that "the problem is that you're not coding it using the
preferred Ada style." I remember A-12 being attacked because we didn't use
tasking. The attackers didn't care about any silly compiler problems, etc.
They just knew we "weren't Ada enough" if we didn't use tasking. After all,
they could get tasking to work on their PC; what's the problem?....

On the projects where we used C++, I don't believe we've ever had anyone say
we weren't "C++ enough" because we constrained the use of templates. Quite
the contrary - there's an active effort to develop a standard C++ subset
(EC++) for use in certain domains, without any fear of being arrested by the
"C++ police" for subsetting the language. Why would someone want to use a
language with a built-in Inquisition?

Re: Ada to C++ translator?

[Ole-Hjalmar Kristensen]

"Ken Garlington" <Ken.Garlington@computer.org> writes:

<interesting stuff snipped>

> "This has always been the case with Ada. I remember early X meetings
> where we were trying to get a compiler bug fixed for a large package, and
> being told that "the problem is that you're not coding it using the
> preferred Ada style." I remember A-12 being attacked because we didn't use
> tasking. The attackers didn't care about any silly compiler problems, etc.
> They just knew we "weren't Ada enough" if we didn't use tasking. After all,
> they could get tasking to work on their PC; what's the problem?....
> 
> On the projects where we used C++, I don't believe we've ever had anyone say
> we weren't "C++ enough" because we constrained the use of templates. Quite
> the contrary - there's an active effort to develop a standard C++ subset
> (EC++) for use in certain domains, without any fear of being arrested by the
> "C++ police" for subsetting the language. Why would someone want to use a
> language with a built-in Inquisition?
> 
> 

If the advantages outweigh the inquistion, I would consider switching
:-)

Seriously, what is your opinion on today's thread support in Ada?  

I'm working on a project (not written in Ada for various reasons),
running on off the shelf workstations/servers.  Our typical response
times are about 1 millisecond, and there will typically be some task
switching involved in servicing a request. 

If we were to use Ada and its tasking mechanism I would not be so
worried about the task switching time, since our system is a soft real
time system, but portability and scaling issues bother me.  We are
currently running up to several hundred tasks (homegrown very
lightweight threads, really) on each processor. My experiments with
Posix threads indicate that this would probably work on some but not
all our platforms.

Of course, we could use FSU threads, but then we risk blocking the
process while we are doing IO, and that is not acceptable.
Perhaps we risk blocking the process anyway ? Who knows? It seems that
this is entirely dependent upon the implementation.

It would be very nice if the language had support for both normal (a
la Posix or OS threads) tasks, and very lightweight tasks (presumably
running within an OS thread)

-- 
Kabelsalat ist gesund.

Ole-Hj. Kristensen

Re: Ada to C++ translator?

[Ken Garlington]

"Ole-Hjalmar Kristensen" <ohk@clustra.com> wrote in message
news:umqlmr09ui2.fsf@gong10.clustra.com...
: "Ken Garlington" <Ken.Garlington@computer.org> writes:
:
: <interesting stuff snipped>
:
: > "This has always been the case with Ada. I remember early X meetings
: > where we were trying to get a compiler bug fixed for a large package,
and
: > being told that "the problem is that you're not coding it using the
: > preferred Ada style." I remember A-12 being attacked because we didn't
use
: > tasking. The attackers didn't care about any silly compiler problems,
etc.
: > They just knew we "weren't Ada enough" if we didn't use tasking. After
all,
: > they could get tasking to work on their PC; what's the problem?....
: >
: > On the projects where we used C++, I don't believe we've ever had anyone
say
: > we weren't "C++ enough" because we constrained the use of templates.
Quite
: > the contrary - there's an active effort to develop a standard C++ subset
: > (EC++) for use in certain domains, without any fear of being arrested by
the
: > "C++ police" for subsetting the language. Why would someone want to use
a
: > language with a built-in Inquisition?
: >
: >
:
: If the advantages outweigh the inquistion, I would consider switching
: :-)
:
: Seriously, what is your opinion on today's thread support in Ada?

Do you mean for a particular compiler/target pair, or tasking at the
language level? As to the former, you'd have to tell me the particular
context before I could give an intelligent answer (which was one of the
points of my previous post :). As to the latter, I don't see anything
inherent in the language that prevents a compiler from doing what you want
(particularly now that protected objects are available). There would likely
have to be some restrictions placed on the form of the task; see section D.7
of the Ada Rationale for examples. Of course, you can usually use
alternatives to Ada tasking, such as direct calls to a POSIX-compliant
run-time a la C as well, so it's certainly no worse that what you'll get in
other languages.

Re: Ada to C++ translator?

[Ole-Hjalmar Kristensen]

"Ken Garlington" <Ken.Garlington@computer.org> writes:

> "Ole-Hjalmar Kristensen" <ohk@clustra.com> wrote in message
> news:umqlmr09ui2.fsf@gong10.clustra.com...
> : "Ken Garlington" <Ken.Garlington@computer.org> writes:

<snip>

> :
> : Seriously, what is your opinion on today's thread support in Ada?
> 
> Do you mean for a particular compiler/target pair, or tasking at the
> language level? As to the former, you'd have to tell me the particular
> context before I could give an intelligent answer (which was one of the
> points of my previous post :). As to the latter, I don't see anything
> inherent in the language that prevents a compiler from doing what you want
> (particularly now that protected objects are available). There would likely
> have to be some restrictions placed on the form of the task; see section D.7
> of the Ada Rationale for examples. Of course, you can usually use
> alternatives to Ada tasking, such as direct calls to a POSIX-compliant
> run-time a la C as well, so it's certainly no worse that what you'll get in
> other languages.
> 
> 

I was thinking at the language level. As you point out yourself, there
is nothing inherent in the language that prevents a compiler from
doing what I want, but the problem is much like garbage
collection. It's allowed, but you cannot count on it being there, so
your programs will not really be portable to another platform or
compiler if you use it.  

I agree that it's no better in other languages.

-- 
Kabelsalat ist gesund.

Ole-Hj. Kristensen

Re: Ada to C++ translator?

[Bob Jacobs]

Ted Dennison wrote:
> 
> And I don't see how having a C++ port is that going to help you the next time
> you port to a new system.  Odds are you are actually *better off* right now with
> the Ada sources than you would have been with C++ sources. At least the Ada
> language itself is portable. C++ can't even say that much. The C++ porting guide
> for Mozilla forbids using quite a few *core* language features (templates,
> static constructors, exceptions, namespaces, among others) due to portability
> issues. You can see
> http://www.mozilla.org/hacking/portable-cpp.html for the whole list. If you *do*
> port to C++, you'd do well to read and follow it.
 

The last time I checked, which was only a few weeks ago, the Mozilla
guide was so dated that it's pretty much useless.

Bob Jacobs

Re: Ada to C++ translator?

[Ted Dennison]

In article <3A93C0DC.37A37955@baesystems.com>, Bob Jacobs says...
>
>The last time I checked, which was only a few weeks ago, the Mozilla
>guide was so dated that it's pretty much useless.

It is almost 3 years old. Has the C++ portability situation drasticly improved
since it was written? Since portability is actively *against* certain large
vendor's interests, I'd be suprised if that were the case. But I don't know the
C++ world enough to judge myself.

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

Re: Ada to C++ translator?

[Bob Jacobs]

Ted Dennison wrote:
> 
> In article <3A93C0DC.37A37955@baesystems.com>, Bob Jacobs says...
> >
> >The last time I checked, which was only a few weeks ago, the Mozilla
> >guide was so dated that it's pretty much useless.
> 
> It is almost 3 years old. Has the C++ portability situation drasticly improved
> since it was written? Since portability is actively *against* certain large
> vendor's interests, I'd be suprised if that were the case. But I don't know the
> C++ world enough to judge myself.
 

The situation has improved greatly over the last 3 years IMHO and
support for the core language features you mentioned is much better than
it was at the time the Mozilla guide was written.

I'm not aware of any C++ compiler which can yet claim to be truly 100%
compliant with the C++ standard but many now come close and are getting
closer.

Bob Jacobs

Re: Ada to C++ translator?

[gautier]

>>The last time I checked, which was only a few weeks ago, the Mozilla
>>guide was so dated that it's pretty much useless.

>It is almost 3 years old. Has the C++ portability situation

Hey boys... it's like the Manual: read till the end of the text

"Last modified February 1, 2001"

;-)

____________________________________
Gautier  --  http://www.diax.ch/gdm/

Re: Ada to C++ translator?

[Martin Dowie]

That's what I thought too when I first went to the page as it has "27 March
1998" at the top.
Look down at the very bottom though and you will descover it is still being
maintained and the
last change was on "2-01-2001" i.e. all rules listed _still_ apply!

"Bob Jacobs" <robert.jacobs@baesystems.com> wrote in message
news:3A93C0DC.37A37955@baesystems.com...
>
>
> Ted Dennison wrote:
> >
> > And I don't see how having a C++ port is that going to help you the next
time
> > you port to a new system.  Odds are you are actually *better off* right
now with
> > the Ada sources than you would have been with C++ sources. At least the
Ada
> > language itself is portable. C++ can't even say that much. The C++
porting guide
> > for Mozilla forbids using quite a few *core* language features
(templates,
> > static constructors, exceptions, namespaces, among others) due to
portability
> > issues. You can see
> > http://www.mozilla.org/hacking/portable-cpp.html for the whole list. If
you *do*
> > port to C++, you'd do well to read and follow it.
>
>
> The last time I checked, which was only a few weeks ago, the Mozilla
> guide was so dated that it's pretty much useless.
>
> Bob Jacobs

Re: Ada to C++ translator?

[Bob Jacobs]

Martin Dowie wrote:
> 
> That's what I thought too when I first went to the page as it has "27 March
> 1998" at the top.
> Look down at the very bottom though and you will descover it is still being
> maintained and the
> last change was on "2-01-2001" i.e. all rules listed _still_ apply!

[ Martin and I discussed this recently in another forum  :-) ]

Granted that the page has been updated but I still assert that the
information contained within it is dated. The revision history suggests
that it has simply been added to, rather than revised, though there is
little to go on.

Bob Jacobs

Re: Ada to C++ translator?

[Ted Dennison]

In article <3A93E9A9.21F2F44F@baesystems.com>, Bob Jacobs says...
>
>[ Martin and I discussed this recently in another forum  :-) ]
>
>Granted that the page has been updated but I still assert that the
>information contained within it is dated. The revision history suggests
>that it has simply been added to, rather than revised, though there is
>little to go on.

I've sent an email to the maintainers asking their opinion on the subject. I'll
report back when I get a response. I'm inclined to accept what they say, as
Mozilla is to my knowledge the largest (and most ported) portable C++ program
for which we are liable to find this kind of public information.

I tried reading it with revisions visible (click "document history" at the
bottom), and that does seem to support Bob's case. I can't find any deletions,
and the only modifications have been updates of URLs. However, another possible
hypothesis is that the situation has indeed not improved in the last 3 years. A
variation on this would be the hypothesis that the need to support older C++
compilers will imply that restrictions can *never* be removed.

We'll see what the maintainers say.

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

Re: Ada to C++ translator?

[Brian Rogoff]

On Wed, 21 Feb 2001, Ken Garlington wrote:
> To paraphrase my response to another claim that efficient tasking has been
> universally true since 1889 (e-mail me if you want the identity of "X", "Y"
> and "Z").

Wow, you've been hacking Ada WAY longer than I have ;-). 

[...snip...]
> As I've noted before, this sort of attitude makes it very difficult for me
> to sell Ada. From the same post:
> 
> "There's plenty of blame to go around with respect to Ada...
> 
> "6. And the one that got us here: Legitimate issues with the Ada language
> are
> attacked with religious zeal instead of reason. Compare Ada/Eiffel
> discussions with C/C++ discussions, then look at their penetration into the
> software engineering community. I think you'll see a correlation....

What I usually get annoyed by is the way that every defect of Ada is 
defended by BS like "Ada favors the reader over the writer, we don't care 
about the writer of code." That all sounds very good, but in the absence
of anything besides someone's opinion on what contributes to readability
and what detracts from it, it's just hot air. 

> On the projects where we used C++, I don't believe we've ever had anyone say
> we weren't "C++ enough" because we constrained the use of templates. Quite
> the contrary - there's an active effort to develop a standard C++ subset
> (EC++) for use in certain domains, without any fear of being arrested by the
> "C++ police" for subsetting the language. Why would someone want to use a
> language with a built-in Inquisition?

I don't understand your complaint in the context of "now", since there are 
Ada subsets (like SPARK) and I don't expect a Spanish Inquisition... 
uh-oh :-)

-- Brian

Re: Ada to C++ translator?

[Marin David Condic]

"Brian Rogoff" <bpr@shell5.ba.best.com> wrote in message
news:Pine.BSF.4.21.0102211030150.7325-100000@shell5.ba.best.com...
> I don't understand your complaint in the context of "now", since there are
> Ada subsets (like SPARK) and I don't expect a Spanish Inquisition...
> uh-oh :-)
>
There have *always* been subsets of Ada - they just couldn't be validated
and were restricted from calling themselves "Ada". I recall early versions
of the RR compiler and the Telesoft compiler being short of generics & doing
I/O in non-standard ways. (And I'm *still* mad at Telesoft after all these
years for continuously lying about when they were going to release software
to me!) So I guess I don't understand the context of "now" when it has
always been thus.

And I just know you're waiting for someone to say "Nobody expects the
Spanish Inquisition!!!" :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: Ada to C++ translator?

[Simon Wright]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:

> "Brian Rogoff" <bpr@shell5.ba.best.com> wrote in message
> news:Pine.BSF.4.21.0102211030150.7325-100000@shell5.ba.best.com...
> > I don't understand your complaint in the context of "now", since there are
> > Ada subsets (like SPARK) and I don't expect a Spanish Inquisition...
> > uh-oh :-)
> >
> There have *always* been subsets of Ada - they just couldn't be validated
> and were restricted from calling themselves "Ada".

There's a difference between a compiler which doesn't support the full
language and a project choosing not to use the full language!

Re: Ada to C++ translator?

[Andrew Berg]

I write a lot of C++, and unless I am writing for a single, known
compiler, I tend to follow their porting rules.  Why is this?  Mainly
because even if I have the latest and greatest tools, or even just gcc,
it is unlikely that everyone else will also.  Besides that:  Templates,
rtti and exceptions, when used in C++ create binaries that are
appreciably larger.  Well, at least they are with g++, which is what I
am currently using for development.

Having said that, I think that I would kick and scream before giving up
the STL now that I've gotten used to it.  It is not so much that it is
that good, rather it is just that much better.

Mozilla is really not written in C++.  It is really written in C, with
classes.

-andrew

Ted Dennison wrote:
> 
> In article <3A93E9A9.21F2F44F@baesystems.com>, Bob Jacobs says...
> >
> >[ Martin and I discussed this recently in another forum  :-) ]
> >
> >Granted that the page has been updated but I still assert that the
> >information contained within it is dated. The revision history suggests
> >that it has simply been added to, rather than revised, though there is
> >little to go on.
> 
> I've sent an email to the maintainers asking their opinion on the subject. I'll
> report back when I get a response. I'm inclined to accept what they say, as
> Mozilla is to my knowledge the largest (and most ported) portable C++ program
> for which we are liable to find this kind of public information.
> 
> I tried reading it with revisions visible (click "document history" at the
> bottom), and that does seem to support Bob's case. I can't find any deletions,
> and the only modifications have been updates of URLs. However, another possible
> hypothesis is that the situation has indeed not improved in the last 3 years. A
> variation on this would be the hypothesis that the need to support older C++
> compilers will imply that restrictions can *never* be removed.
> 
> We'll see what the maintainers say.
> 
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

Re: Ada to C++ translator?

[Martin Dowie]

I suspect for the mainstream of Windows C++ suites (e.g. Visual C++,
Borland), the guide is dated and you could probably delete large chunks
of this guide but only if you knew that was your entire porting range. But
mozilla's porting range is huge and a lot of the rules seem to apply
because of HP and SCO compilers - which I had expected to be fairly
common targets...

This sort of thing isn't limited to C++ though, just now my porting range
includes Green Hills AdaMULTI v2 for PowerPC, which doesn't cope
with 64-bit integers as well as GNAT does. Can't wait for v3 to drop on
my doorstep!..

Also, some compilers don't produce very efficient (in size) code for

package body X is
  ...
  Y : Y_Type := (others => (...));
  ...
end X;

and it is usually necessary to change this to

package body X is
  ...
  Y : Y_Type;
  ...
  procedure Initialise is
  begin
    for Index in Y'Range loop
      Y(Index) := (...);
    end loop;
  end Initialise;
end X;

one could say they were 'irrational' about it ;-)

anyone else got any porting tips - maybe we could start a FAQ for these
sort of things?..

Bob Jacobs <robert.jacobs@baesystems.com> wrote in message
news:3A93E9A9.21F2F44F@baesystems.com...
>
> Martin Dowie wrote:
> >
> > That's what I thought too when I first went to the page as it has "27
March
> > 1998" at the top.
> > Look down at the very bottom though and you will descover it is still
being
> > maintained and the
> > last change was on "2-01-2001" i.e. all rules listed _still_ apply!
>
> [ Martin and I discussed this recently in another forum  :-) ]
>
> Granted that the page has been updated but I still assert that the
> information contained within it is dated. The revision history suggests
> that it has simply been added to, rather than revised, though there is
> little to go on.
>
> Bob Jacobs

Re: Ada to C++ translator?

[Martin Dowie]

Hi Bob! :-)

Bob Jacobs <robert.jacobs@baesystems.com> wrote in message
news:3A93E9A9.21F2F44F@baesystems.com...
>
> [ Martin and I discussed this recently in another forum  :-) ]
>
> Granted that the page has been updated but I still assert that the
> information contained within it is dated. The revision history suggests
> that it has simply been added to, rather than revised, though there is
> little to go on.

Re: Ada to C++ translator?

[gautier]

Martin Dowie:

>Also, some compilers don't produce very efficient (in size) code for

>package body X is
>  ...
>  Y : Y_Type := (others => (...));
>  ...
>end X;

Do you know one that does ? BTW I rather see a problem
in time. The expression "(others => (...))"  is often built
in a nonoptimised manner, in an extra buffer, then copied in to Y.

But, it is not a portability problem : this feature *will work*
on any Ada compiler, although not too efficienty.

____________________________________
Gautier  --  http://www.diax.ch/gdm/

STL for Ada (was: Re: Ada to C++ translator?)

[Stefan Nobis]

Andrew Berg <andrewb@votehere.net> writes:

> Having said that, I think that I would kick and scream before giving up
> the STL now that I've gotten used to it.  It is not so much that it is
> that good, rather it is just that much better.

I'm very new to Ada (but worked quite some time with C++) and 'till now i read
nothing about something like the STL for Ada. Is there a library that gives
Ada all the things the STL gives C++? If not, why? STL is mostly generic
programmic and Ada always claims to do better generics than C++, so why not
put such a lib in the standard?

-- 
Until the next mail...,
Stefan.

Re: Ada to C++ translator?

[Martin Dowie]

that would be Apex - haven't tried it on others

I would say it is a portability problem, if that extra memory requirements
push you over some limit (physical, logical or contractural).

<gautier@club.lemonde.fr> wrote in message
news:mailman.982833940.13855.comp.lang.ada@ada.eu.org...
Martin Dowie:

>Also, some compilers don't produce very efficient (in size) code for

>package body X is
>  ...
>  Y : Y_Type := (others => (...));
>  ...
>end X;

Do you know one that does ? BTW I rather see a problem
in time. The expression "(others => (...))"  is often built
in a nonoptimised manner, in an extra buffer, then copied in to Y.

But, it is not a portability problem : this feature *will work*
on any Ada compiler, although not too efficienty.

____________________________________
Gautier  --  http://www.diax.ch/gdm/

Re: Ada to C++ translator?

[gautier]

>I would say it is a portability problem, if that extra memory requirements
>push you over some limit (physical, logical or contractural).

You're right. Maybe for the "practical protability" part of
the FAQ: "Don't use := for big object, because..."

____________________________________
Gautier  --  http://www.diax.ch/gdm/

Re: Ada to C++ translator?

[Bob Jacobs]

Martin Dowie wrote:
> 
> I suspect for the mainstream of Windows C++ suites (e.g. Visual C++,
> Borland), the guide is dated and you could probably delete large chunks
> of this guide but only if you knew that was your entire porting range. But
> mozilla's porting range is huge and a lot of the rules seem to apply
> because of HP and SCO compilers - which I had expected to be fairly
> common targets...


A weakness of the guide is that in most cases it doesn't provide the
version of the compilers which are mentioned. Since it was first
published there has been a great deal of activity on the part of
compiler writers to implement the standard. This doesn't seem to have
been reflected in the guide.

An example of it being dated is the HP compiler, to which you also
refer. This is identified in 9 of the 33 items; some of these refer to
it being a Cfront compiler, which it says is still shipping. According
to the HP site at:

  http://www.devresource.hp.com/devresource/Tools/cpp/faq.html

the Cfront C++ compiler stopped shipping in August 1999.

One of the few compilers mentioned by version is Visual C++ 1.5 but I
believe this is the old 16-bit compiler which stopped shipping probably
around 4 or 5 years ago now. Fine if you still want to support Windows
3.X.

It may be that Mozilla is still supporting obscure platforms using old
compilers, and all credit to them if they are. On the other hand, it
could just be that the guide is out of date and needs revising.

Bob Jacobs

Re: Ada to C++ translator?

[Ted Dennison]

In article <3a94d54c$1@pull.gecm.com>, Martin Dowie says...
>This sort of thing isn't limited to C++ though, just now my porting range
>includes Green Hills AdaMULTI v2 for PowerPC, which doesn't cope
>with 64-bit integers as well as GNAT does. Can't wait for v3 to drop on

Well yeah, but basic features like generics and exceptions still work portably!

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

Re: STL for Ada (was: Re: Ada to C++ translator?)

[Lutz Donnerhacke]

* Stefan Nobis wrote:
>I'm very new to Ada (but worked quite some time with C++) and 'till now i
>read nothing about something like the STL for Ada. Is there a library that
>gives Ada all the things the STL gives C++?

Yes there is one.

>If not, why? STL is mostly generic programmic and Ada always claims to do
>better generics than C++, so why not put such a lib in the standard?

IIRC the STL war developed using Ada generics. But to be honest: I do not
need the STL, because most of the provided constructs:
  - are already in the language
  - easier to implement than to include
  - already defined in local modules (BOOCH)

Re: STL for Ada (was: Re: Ada to C++ translator?)

[Ted Dennison]

In article <87itm31237.fsf@520075220525-0001.dialin.t-online.de>, Stefan Nobis
says...
>
>I'm very new to Ada (but worked quite some time with C++) and 'till now i read
>nothing about something like the STL for Ada. Is there a library that gives
>Ada all the things the STL gives C++? If not, why? STL is mostly generic
>programmic and Ada always claims to do better generics than C++, so why not
>put such a lib in the standard?

A lot of the lower-level stuff that C++ needs an STL for (eg: decent strings)
*is* actually in the standard. Familiarize yourself the packages in Annex A of
the LRM ( http://www.ada-auth.org/~acats/arm-html/RM-TOC.html ) before you go
any further.

As for the higher-level data structures, there are several competing packages
(just like the C++ STL has competing packages). The one I tend to lean on is the
Booch Components, but others have their own favorites.

The Ada95 Booch Components are available at
http://www.adapower.com/booch/index.html

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

Re: STL for Ada (was: Re: Ada to C++ translator?)

[Brian Rogoff]

On 22 Feb 2001, Stefan Nobis wrote:
> Andrew Berg <andrewb@votehere.net> writes:
> 
> > Having said that, I think that I would kick and scream before giving up
> > the STL now that I've gotten used to it.  It is not so much that it is
> > that good, rather it is just that much better.
> 
> I'm very new to Ada (but worked quite some time with C++) and 'till now i read
> nothing about something like the STL for Ada. Is there a library that gives
> Ada all the things the STL gives C++? 

There's no way you'll get "all" of the things you get in the STL, since 
Ada lacks automatic instantiation of generics. One of the nice things 
about the STL is the way you can change implementations of collections and 
you can get away with changing very little source code. That's partly due 
to automatic instantiation of generic subprograms. 

> If not, why? STL is mostly generic programmic and Ada always claims to
> do better generics than C++, so why not put such a lib in the standard?

Ada does generics differently. An "all generic" library like STL is
possible in Ada, you can do the same tricks of creating an iterator 
interface to a set of predefined collection signatures. You bang into a 
few Ada issues. One of the more vexing is the issue of whether to make 
collections a Controlled type and "inherit" all of the limitations of 
Controlled (tagged) types. 

There should probably be some standard data structure libraries, but I
suspect that in demanding applications you'll write your own anyways. 

-- Brian

Re: Ada to C++ translator?

[Marin David Condic]

"Simon Wright" <simon@pushface.org> wrote in message
news:x7vy9uz3eyd.fsf@smaug.pushface.org...
> "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
>
> > "Brian Rogoff" <bpr@shell5.ba.best.com> wrote in message
> > news:Pine.BSF.4.21.0102211030150.7325-100000@shell5.ba.best.com...
> > > I don't understand your complaint in the context of "now", since there
are
> > > Ada subsets (like SPARK) and I don't expect a Spanish Inquisition...
> > > uh-oh :-)
> > >
> > There have *always* been subsets of Ada - they just couldn't be
validated
> > and were restricted from calling themselves "Ada".
>
> There's a difference between a compiler which doesn't support the full
> language and a project choosing not to use the full language!

And your point would be? :-) Seriously, I understand there is a distinction,
but I don't know that it makes any difference. SPARK is a chosen subset of
Ada and I'd presume that if one bought the SPARK compiler that it would
compile only the SPARK subset. (Or at least someone might choose to
implement a compiler for SPARK that way.)

Other compilers back in '83 and shortly thereafter were also subsets -
albeit the choice was for different reasons. Still, there you have it. A
choice was made that a subset of Ada was desirable for technical reasons -
space/time back then, rather than safety. Subsets of Ada have always been
around and the rules aren't so different today. (SPARK doesn't call itself
"Ada" and isn't validated, right?) The DoD never said that a subset couldn't
exist - just that it couldn't call itself "Ada" and wouldn't be validated.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: Ada to C++ translator?

[Simon Wright]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:

> "Simon Wright" <simon@pushface.org> wrote in message
> news:x7vy9uz3eyd.fsf@smaug.pushface.org...
> > "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
> >
> > > "Brian Rogoff" <bpr@shell5.ba.best.com> wrote in message
> > > news:Pine.BSF.4.21.0102211030150.7325-100000@shell5.ba.best.com...
> > > > I don't understand your complaint in the context of "now", since there
> are
> > > > Ada subsets (like SPARK) and I don't expect a Spanish Inquisition...
> > > > uh-oh :-)
> > > >
> > > There have *always* been subsets of Ada - they just couldn't be
> validated
> > > and were restricted from calling themselves "Ada".
> >
> > There's a difference between a compiler which doesn't support the full
> > language and a project choosing not to use the full language!
> 
> And your point would be? :-) Seriously, I understand there is a
> distinction, but I don't know that it makes any difference. SPARK is
> a chosen subset of Ada and I'd presume that if one bought the SPARK
> compiler that it would compile only the SPARK subset. (Or at least
> someone might choose to implement a compiler for SPARK that way.)

I'm sure it would be possible to produce a compiler switch that said
"only accept the SPARK subset", as GNAT does for the Ravenscar subset;
however, I don't think anyone has.

I may be wrong, but the process is (in part)

  write your code
  check it with the SPARK tools
  compile with your normal compiler

which is very like

  write your code
  inspect it for deviations from your project standards
  compile with your normal compiler

I'm sure we actually agree on this one at heart!

Re: Ada to C++ translator?

[Nick Williams]

Marin David Condic wrote:


>> There's a difference between a compiler which doesn't support the full
>> language and a project choosing not to use the full language!

> And your point would be? :-) Seriously, I understand there is a distinction,
> but I don't know that it makes any difference. SPARK is a chosen subset of
> Ada and I'd presume that if one bought the SPARK compiler that it would
> compile only the SPARK subset. (Or at least someone might choose to
> implement a compiler for SPARK that way.)

You'd have difficulty buying the SPARK compiler; as there isn't one :-)

From the Ada perspective, SPARK is indeed a subset; since whatever is a valid 
SPARK program is also a valid Ada program, but the converse does not hold.

However, just because an Ada program uses the subset of the Ada language which
is valid in SPARK will (most likely) not make that program valid in SPARK: the
SPARK language has a considerable variety of non-compilable statements (which
look to an Ada compiler like comments) which are not optional when constructing
SPARK programs. It also has restrictions on the use of language features which
can make it harder to prove properties of your program.

> (SPARK doesn't call itself "Ada" and isn't validated, right?) 

Well, the 'A' in SPARK does stand for Ada ... and the only validation is 
a relatively detailed and complete formal semantics of the language :-)

Cheers,

Nick.

Re: Ada to C++ translator?

[Marin David Condic]

Thanks for the enlightment. I think my only point was that subsets of Ada existed
back in '83 (or thereabouts) so there isn't something new allowed in Ada that just
became available. As I recall - some of the Ada subset compilers also had the word
"Ada" in them somewhere - nothing wrong with that. I recall the DoD simply having a
concern that someone could start peddaling what they called "Ada" only without a
full implementation. (There were dozens of compilers at the time that called
themselves "Pascal" with no two exactly alike. So what did it mean to call a
compiler a "Pascal" compiler?) They wanted to be sure that if someone sold you a
compiler and called it "Ada" that it in fact implemented the whole of the language.
I don't think the situation is much different today - just maybe not as formal.
People still expect that if you label a compiler "Ada" that it has run the
validation suite and implements the full language.

MDC



Nick Williams wrote:

> Marin David Condic wrote:
>
> >> There's a difference between a compiler which doesn't support the full
> >> language and a project choosing not to use the full language!
>
> > And your point would be? :-) Seriously, I understand there is a distinction,
> > but I don't know that it makes any difference. SPARK is a chosen subset of
> > Ada and I'd presume that if one bought the SPARK compiler that it would
> > compile only the SPARK subset. (Or at least someone might choose to
> > implement a compiler for SPARK that way.)
>
> You'd have difficulty buying the SPARK compiler; as there isn't one :-)
>
> From the Ada perspective, SPARK is indeed a subset; since whatever is a valid
> SPARK program is also a valid Ada program, but the converse does not hold.
>
> However, just because an Ada program uses the subset of the Ada language which
> is valid in SPARK will (most likely) not make that program valid in SPARK: the
> SPARK language has a considerable variety of non-compilable statements (which
> look to an Ada compiler like comments) which are not optional when constructing
> SPARK programs. It also has restrictions on the use of language features which
> can make it harder to prove properties of your program.
>
> > (SPARK doesn't call itself "Ada" and isn't validated, right?)
>
> Well, the 'A' in SPARK does stand for Ada ... and the only validation is
> a relatively detailed and complete formal semantics of the language :-)
>
> Cheers,
>
> Nick.

--
=============================================================
Marin David Condic - Pace Micro - http://www.pacemicro.com/
Send Replies To: m c o n d i c @ a c m . o r g
Visit my web site at:  http://www.mcondic.com/

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
=============================================================

Re: Ada to C++ translator?

[Ken Garlington]

"Marin David Condic" <mcondic.auntie.spam@acm.org> wrote in message
news:3A9809FD.D9194D0E@acm.org...
: Thanks for the enlightment. I think my only point was that subsets of Ada
existed
: back in '83 (or thereabouts) so there isn't something new allowed in Ada
that just
: became available. As I recall - some of the Ada subset compilers also had
the word
: "Ada" in them somewhere - nothing wrong with that. I recall the DoD simply
having a
: concern that someone could start peddaling what they called "Ada" only
without a
: full implementation. (There were dozens of compilers at the time that
called
: themselves "Pascal" with no two exactly alike. So what did it mean to call
a
: compiler a "Pascal" compiler?) They wanted to be sure that if someone sold
you a
: compiler and called it "Ada" that it in fact implemented the whole of the
language.
: I don't think the situation is much different today - just maybe not as
formal.
: People still expect that if you label a compiler "Ada" that it has run the
: validation suite and implements the full language.

With a caveat that the term "full language" could mean (a) the Ada83
dialect, (b) some subset of the Ada95 annexes, or even (c) known cases where
a validation test fails.

The reality is that a vendor can hopefully tell you which tests will pass
for a given environment (compiler switches, etc.), as well as any known
deficiencies. You may or may not be able to derive something useful from
that information with regard to how much of the language is actually
implemented.

Re: Ada to C++ translator?

[Marin David Condic]

Well, yes, in theory. However, in practice, I think that what was intended was
actually achieved. Do you remember Pascal compilers wherein the deviations were
of the form "I think feature X is inefficient or hard to implement, so I
modified the syntax and semantics to give you feature Y and no other compiler
did it the same way." Of course, Pascal was a fairly simple language, yet it
still had deviations from the "standard" definition in most compilers. More
complex languages were worse.

What we have today is a case where compilers purporting to be "Ada Compilers"
don't do screwy things like not implement Tasks (because its too hard) or change
the memory allocation/deallocation scheme from new/Unchecked_Deallocation to
some other scheme like mark/new/delete (because its more efficient). Sure, there
may be missing annexes and you may find some corner-case in the language that
doesn't work right, but mostly you get the full language. At least I know of no
important exceptions.

I think that's a useful improvement that Ada brought along and ought to be a
selling point because AFAIK, C++ is a long way from this goal.

MDC

Ken Garlington wrote:

> With a caveat that the term "full language" could mean (a) the Ada83
> dialect, (b) some subset of the Ada95 annexes, or even (c) known cases where
> a validation test fails.
>
> The reality is that a vendor can hopefully tell you which tests will pass
> for a given environment (compiler switches, etc.), as well as any known
> deficiencies. You may or may not be able to derive something useful from
> that information with regard to how much of the language is actually
> implemented.

--
=============================================================
Marin David Condic - Pace Micro - http://www.pacemicro.com/
Send Replies To: m c o n d i c @ a c m . o r g
Visit my web site at:  http://www.mcondic.com/

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
=============================================================