Automated conversion to C++?

Automated conversion to C++?

[Jacob Sparre Andersen]

I have been offered to take part in a programming project with a
rather annoying constraint: There should be C++ source available for
the constructed program.

The good part is that I am allowed to do the actual programming in
Ada, and just use an automated translator to generate the C++ code.

I have not been presented with any specific constraints on the
generated C++ code (neither speed, nor quality), except that it should
solve the task (i.e. be semantically equivalent to the Ada master).

A bit of quick googling found me "adatoccpptranslator", which may be
able to handle enough of the task.  Do you know of any other plausible
(and preferably Open Source) solutions?

I have considered the path Ada -> ASIS -> (some)XML -> C++, but I
suspect that the last step may be rather complicated to implement.

Some things which my simplify the task:

 + I don't mind that you need a C++ class to implement an Ada scalar
   type.

 + I don't mind having generic packages/procedures/functions available
   only in their instantiated form in C++.

Greetings,

Jacob
-- 
Who guards the guardians?

Re: Automated conversion to C++?

[Robert A Duff]

Jacob Sparre Andersen <sparre@nbi.dk> writes:

> A bit of quick googling found me "adatoccpptranslator", which may be
> able to handle enough of the task.  Do you know of any other plausible
> (and preferably Open Source) solutions?

SofCheck has such a tool.

- Bob

Re: Automated conversion to C++?

[Jeffrey R. Carter]

Jacob Sparre Andersen wrote:
> 
> The good part is that I am allowed to do the actual programming in
> Ada, and just use an automated translator to generate the C++ code.

Such a thing is impossible, since Ada is a concurrent language, and C++ is a 
sequential language, unless you want to translate the entire concurrency runtime 
and include calls to it.

However, you could use an Ada compiler that produces C as its intermediate 
language (SofCheck has such a thing), since there is a C subset of C++.

-- 
Jeff Carter
"Now look, Col. Batguano, if that really is your name."
Dr. Strangelove
31

Re: Automated conversion to C++?

[Jacob Sparre Andersen]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> Jacob Sparre Andersen <sparre@nbi.dk> writes:

>> A bit of quick googling found me "adatoccpptranslator", which may
>> be able to handle enough of the task.  Do you know of any other
>> plausible (and preferably Open Source) solutions?
>
> SofCheck has such a tool.

Sounds good.

Is it a part of AdaMagic?

How much does it cost?

Greetings,

Jacob
-- 
There really was only one way to make a person unlearn something ...

Re: Automated conversion to C++?

[Maciej Sobczak]

On 15 Lut, 19:24, "Jeffrey R. Carter"

> Such a thing is impossible, since Ada is a concurrent language, and C++ is a
> sequential language, unless you want to translate the entire concurrency runtime
> and include calls to it.
>
> However, you could use an Ada compiler that produces C as its intermediate
> language (SofCheck has such a thing), since there is a C subset of C++.

I don't get it. Do you mean that C is a concurrent language?

Note also that Jacob said nothing about concurrency of the original
problem. If there is none, then objection about concurrency has no
ground.
Note also that Jacob didn't say a word about the target platform. This
target platform might support concurrency, which can be available from
C++ (hint: any mainstream operating system is fine here).

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Automated conversion to C++?

[Robert A Duff]

Jacob Sparre Andersen <sparre@nbi.dk> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>> Jacob Sparre Andersen <sparre@nbi.dk> writes:
>
>>> A bit of quick googling found me "adatoccpptranslator", which may
>>> be able to handle enough of the task.  Do you know of any other
>>> plausible (and preferably Open Source) solutions?
>>
>> SofCheck has such a tool.
>
> Sounds good.
>
> Is it a part of AdaMagic?

Yes.

I believe it has some switches to use C versus C++.

> How much does it cost?

I've no idea.  I suggest you go on their web site
www.sofcheck.com and ask them about it.

- Bob

Re: Automated conversion to C++?

[Jeffrey R. Carter]

Maciej Sobczak wrote:
> 
> I don't get it. Do you mean that C is a concurrent language?

I suspect that SofCheck has written a runtime that it makes calls to to support 
concurrency in the generated C code. But I don't really know, so you'll have to 
ask them.

> Note also that Jacob said nothing about concurrency of the original
> problem. If there is none, then objection about concurrency has no
> ground.

What objection? I said an Ada-to-C++ translator is impossible, unless you want 
to do what SofCheck has done and supply a portable runtime to support 
concurrency in the generated C++. What Jacob's needs are has no bearing on that. 
It may be that he's only using a subset of Ada, and so only really needs a 
translator for that subset, but that's not what he asked about.

> Note also that Jacob didn't say a word about the target platform. This
> target platform might support concurrency, which can be available from
> C++ (hint: any mainstream operating system is fine here).

Really? I'd like to know how to translate Ada tasking into portable C++ that 
will run on "any mainstream operating system".

-- 
Jeff Carter
"Now look, Col. Batguano, if that really is your name."
Dr. Strangelove
31

Re: Automated conversion to C++?

[Pascal Obry]

Jeffrey,

> What objection? I said an Ada-to-C++ translator is impossible, unless 
> you want to do what SofCheck has done and supply a portable runtime to 
> support concurrency in the generated C++. 

Or use your Ada-to-C converter to convert the GNAT runtime written in Ada.

Anyway, starting from the ASIS (XML or not) representation of the 
program may be a very very big task as you loose all the expanded code 
done by the compiler (and the proper sequence of calls to the runtime 
for the tasking support for example). It is probably best to start from 
the expanded tree... At least I would start there if I had to do that.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Automated conversion to C++?

[Peter C. Chapin]

Jeffrey R. Carter wrote:

> Really? I'd like to know how to translate Ada tasking into portable C++ 
> that will run on "any mainstream operating system".

Build a C++ library that wraps the threading primitives of several 
platforms and then generate C++ code that uses that library. Are you 
saying that the semantics of Ada tasking are such that conversion into 
standard C++ is impossible---that is, without resorting to assembly 
language glue here and there? No matter what you do you're pretty much 
going to have to build an operating system specific run-time at some 
point. Whether you do that in C++ or some other way, I don't see that it 
matters. It's all business as usual when one builds a compiler that 
targets a particular system.

Peter

Re: Automated conversion to C++?

[Jacob Sparre Andersen]

Jeffrey R. Carter wrote:
> Jacob Sparre Andersen wrote:

>> The good part is that I am allowed to do the actual programming in
>> Ada, and just use an automated translator to generate the C++ code.
>
> Such a thing is impossible, since Ada is a concurrent language, and
> C++ is a sequential language, unless you want to translate the
> entire concurrency runtime and include calls to it.

It is good enough with POSIX dependent C++ code.  And I don't plan to
do anything which depends critically on the more detailed requirements
on Ada tasking (a "pthreads" based solution is likely to be good
enough).

I have no interest in perfect C++ code.  It should just be able to
pass through a C++ compiler, and give roughly the same answer as the
Ada code.

Greetings,

Jacob
-- 
"I'm going as a barrel of toxic waste!"

Re: Automated conversion to C++?

[Larry Kilgallen]

In article <47b6d324$0$13594$4d3efbfe@news.sover.net>, "Peter C. Chapin" <pchapin@sover.net> writes:
> Jeffrey R. Carter wrote:
> 
>> Really? I'd like to know how to translate Ada tasking into portable C++ 
>> that will run on "any mainstream operating system".
> 
> Build a C++ library that wraps the threading primitives of several 
> platforms and then generate C++ code that uses that library.

The set "several platforms" is quite a bit smaller than "any mainstream
operating system".

Re: Automated conversion to C++?

[Dr. Adrian Wrigley]

On Fri, 15 Feb 2008 14:33:08 +0100, Jacob Sparre Andersen wrote:

> I have been offered to take part in a programming project with a
> rather annoying constraint: There should be C++ source available for
> the constructed program.
> 
> The good part is that I am allowed to do the actual programming in
> Ada, and just use an automated translator to generate the C++ code.

If you have to supply a C++ program semanticly equivalent to the binary
you deliver, the best choice is to write it in pure C (or C++).

You are guaranteed equivalence.  You need find no translators.  You
have no mismatches in runtime. The risk is low.

C++ makes so many Ada capabilities a real nuisance to implement.
Basics like enumerations with constraint checks, fixed point types,
floating point attributes, integer over/underflow exceptions
need loads of messy C++ (often with specialized headers) to implement.

When it comes to rendezvous, elaboration, real-time, ATC and anything
from Annex E,(or D or G), you are really stuck with no obvious mapping.

If you are interfacing to hardware, you hit the limitation that you
can't do representation clauses in C++.  The nearest thing is by
unpacking bit fields manually, making assumtions about the layout
in C++ (which are not part of the language spec).

In short, to deliver a C++ program:

Simple program  => Write it in C because translation takes too much time
Complex program => Write it in C because the translation is impossible

If a customer is paying to get C++ source, don't write it in Ada - they
presumably don't care for a robust, low-defect solution.  If they did,
they would put constraints on the C++ (eg must run at least 80% of the
speed.  Use no more than 1.3x the memory)

Just my opinion.
--
Adrian

Re: Automated conversion to C++?

[Maciej Sobczak]

On 16 Lut, 05:52, "Jeffrey R. Carter"

> > Note also that Jacob didn't say a word about the target platform. This
> > target platform might support concurrency, which can be available from
> > C++ (hint: any mainstream operating system is fine here).
>
> Really? I'd like to know how to translate Ada tasking into portable C++ that
> will run on "any mainstream operating system".

What do you mean by "portable"? That it will compile and run
everywhere? Or that it can be linked with a run-time library prepared
for each target platform?

What kind of problems do you foresee in this area?

Hint: POSIX seems to be a commonly understood target for developing
portable concurrent systems.

Hint2: Whatever was possible for C can be reused for C++ by inclusion.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Automated conversion to C++?

[Maciej Sobczak]

On 16 Lut, 14:41, Kilgal...@SpamCop.net (Larry Kilgallen) wrote:

> The set "several platforms" is quite a bit smaller than "any mainstream
> operating system".

Let's severely limit the set "several platforms" to {POSIX, Windows}.
That's a really small set.

Which members of "any mainstream operating systems" are not yet
covered?
It is also possible that the meaning of "mainstream" is not very
precise.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Automated conversion to C++?

[Jacob Sparre Andersen]

Dr. Adrian Wrigley wrote:
> On Fri, 15 Feb 2008 14:33:08 +0100, Jacob Sparre Andersen wrote:

> If you have to supply a C++ program semanticly equivalent to the
> binary you deliver, the best choice is to write it in pure C (or
> C++).

The requirement for C++ has not been formulated in such strict terms.

If I come to the conclusion that writing directly in one of the
C-languages is the only option, I'll just skip the project.

> You are guaranteed equivalence.  You need find no translators.  You
> have no mismatches in runtime. The risk is low.

But my working environment will be unbearable.

> C++ makes so many Ada capabilities a real nuisance to implement.
> Basics like enumerations with constraint checks, fixed point types,
> floating point attributes, integer over/underflow exceptions need
> loads of messy C++ (often with specialized headers) to implement.

I don't care about how messy the C++ code is going to be.  We'll most
likely be running the Ada version internally.  The C++ code is only a
matter of public perception.  The project lead is of the opinion that
publishing the system with C++ code will make more scientists
interested in the system.

> If a customer is paying to get C++ source, don't write it in Ada -
> they presumably don't care for a robust, low-defect solution.  If
> they did, they would put constraints on the C++ (eg must run at
> least 80% of the speed.  Use no more than 1.3x the memory)

It is not a matter of code quality.  It is a matter of a decent work
environment for myself.

Thanks for the advice.

Jacob
-- 
�It will not be forever. - It will just seem like it.� -- Death

Re: Automated conversion to C++?

[Martin]

On 16 Feb, 16:42, Jacob Sparre Andersen <spa...@nbi.dk> wrote:
> I don't care about how messy the C++ code is going to be.  We'll most
> likely be running the Ada version internally.  The C++ code is only a
> matter of public perception.  The project lead is of the opinion that
> publishing the system with C++ code will make more scientists
> interested in the system.

Would a C++ API do?

Re: Automated conversion to C++?

[Jeffrey R. Carter]

Peter C. Chapin wrote:
> 
> Build a C++ library that wraps the threading primitives of several 
> platforms and then generate C++ code that uses that library. Are you 
> saying that the semantics of Ada tasking are such that conversion into 
> standard C++ is impossible---that is, without resorting to assembly 
> language glue here and there? No matter what you do you're pretty much 
> going to have to build an operating system specific run-time at some 
> point. Whether you do that in C++ or some other way, I don't see that it 
> matters. It's all business as usual when one builds a compiler that 
> targets a particular system.

Since we'd previously, in the same post being replied to, discussed the use of a 
custom library, I thought it obvious that I was referring to doing so without 
having to build one.

-- 
Jeff Carter
"Apart from the sanitation, the medicine, education, wine,
public order, irrigation, roads, the fresh water system,
and public health, what have the Romans ever done for us?"
Monty Python's Life of Brian
80

Re: Automated conversion to C++?

[Jeffrey R. Carter]

Maciej Sobczak wrote:
> 
> Let's severely limit the set "several platforms" to {POSIX, Windows}.
> That's a really small set.

Much smaller than the set of "any mainstream operating systems".

In any case, I was talking about translating Ada to C++, not about building a 
custom library and translating Ada to C++ and the custom library. That would not 
be an Ada-to-C++ translator, but an Ada-to-C++-and-custom-library translator.

-- 
Jeff Carter
"Apart from the sanitation, the medicine, education, wine,
public order, irrigation, roads, the fresh water system,
and public health, what have the Romans ever done for us?"
Monty Python's Life of Brian
80

Re: Automated conversion to C++?

[Jeffrey R. Carter]

Jacob Sparre Andersen wrote:
> 
> It is good enough with POSIX dependent C++ code.  And I don't plan to
> do anything which depends critically on the more detailed requirements
> on Ada tasking (a "pthreads" based solution is likely to be good
> enough).

Then you don't really want an Ada-to-C++ translator, but an Ada-to-C++-and-Posix 
translator. That's a different, simpler, and possible creature.

-- 
Jeff Carter
"Apart from the sanitation, the medicine, education, wine,
public order, irrigation, roads, the fresh water system,
and public health, what have the Romans ever done for us?"
Monty Python's Life of Brian
80

Re: Automated conversion to C++?

[Jeffrey R. Carter]

Maciej Sobczak wrote:
> 
> What do you mean by "portable"? That it will compile and run
> everywhere? Or that it can be linked with a run-time library prepared
> for each target platform?

As I thought was clear, I mean taking Ada source code and translating it into 
C++ source code that can be compiled and run on "any mainstream operating 
system". I was not talking about building a custom library, nor requiring the 
presence on the target of any library not supplied by the OS.

> Hint: POSIX seems to be a commonly understood target for developing
> portable concurrent systems.

Problem 1: There are mainstream operating systems other than POSIX.

Problem 2: This would not be an Ada-to-C++ translator, but an 
Ada-to-C++-and-Posix translator.

> Hint2: Whatever was possible for C can be reused for C++ by inclusion.

Problem 1: This would not be an Ada-to-C++ translator, but an 
Ada-to-C++-and-custom-library translator.

-- 
Jeff Carter
"Apart from the sanitation, the medicine, education, wine,
public order, irrigation, roads, the fresh water system,
and public health, what have the Romans ever done for us?"
Monty Python's Life of Brian
80

Re: Automated conversion to C++?

[tmoran]

>If you have to supply a C++ program semanticly equivalent to the binary
>you deliver, the best choice is to write it in pure C (or C++).
  One of my first substantial uses of Ada was to create a program that had
to be delivered in C.  It was much easier to write, correctly, in Ada and
the manual transliteration to C wasn't that painful.  Of course I was a
faster C typist then, and the source was Ada 83 with no tasks.  It was not
a full, conforming, Ada 2005 to C++ compiler and run time.  I was happy
and the customer was happy.

Re: Automated conversion to C++?

[Maciej Sobczak]

On 16 Lut, 18:12, "Jeffrey R. Carter"

> > Let's severely limit the set "several platforms" to {POSIX, Windows}.
> > That's a really small set.
>
> Much smaller than the set of "any mainstream operating systems".

Again: Which members of "any mainstream operating systems" are not yet
covered?

> In any case, I was talking about translating Ada to C++, not about building a
> custom library and translating Ada to C++ and the custom library. That would not
> be an Ada-to-C++ translator, but an Ada-to-C++-and-custom-library translator.

Is it OK if along the same line of reasoning I say that it is not
possible to compile Ada to machine code?

I agree that this discussion is drifting nowhere.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Automated conversion to C++?

[Maciej Sobczak]

On 16 Lut, 17:42, Jacob Sparre Andersen <spa...@nbi.dk> wrote:

> I don't care about how messy the C++ code is going to be.
[...]
> The project lead is of the opinion that
> publishing the system with C++ code will make more scientists
> interested in the system.

Is the project lead aware of the fact that if anybody is interested in
the source code it is because they want to read/modify/maintain/etc.
it and not just compile it? Is he aware of the fact that the result of
automated translation will certainly prevent anybody from achieving
these goals? You cannot say "I don't care how messy the C++ code is
going to be", because this way you just undermine the purpose of your
work.

If the goal is to attract people interested in the C++ source code,
then the project should be written in C++. Not translated to C++, but
*written* in C++.

An alternative is to write it in Ada (or whatever language you find
convenient) and this way make your users get attracted to the
language, not the other way round. This, however, might require a
technical project lead instead of a salesman.

An optimal solution is to write the project in whatever you want and
expose a couple of interfaces in different languages. This gives
opportunities for both personal satisfaction and marketing hype.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Automated conversion to C++?

[Jeffrey R. Carter]

Maciej Sobczak wrote:
> 
> An optimal solution is to write the project in whatever you want and
> expose a couple of interfaces in different languages. This gives
> opportunities for both personal satisfaction and marketing hype.

Yes. I suspect that if he develops it in Ada, the project will "run out of time" 
once it has a working executable and is looking at spending more for the conversion.

-- 
Jeff Carter
"Apart from the sanitation, the medicine, education, wine,
public order, irrigation, roads, the fresh water system,
and public health, what have the Romans ever done for us?"
Monty Python's Life of Brian
80

Re: Automated conversion to C++?

[Jeffrey R. Carter]

Maciej Sobczak wrote:
> 
> Again: Which members of "any mainstream operating systems" are not yet
> covered?

I'm sure Kilgallen will object if VMS is not included. IBM mainframes are still 
widely used in the business world.

> Is it OK if along the same line of reasoning I say that it is not
> possible to compile Ada to machine code?

If you so choose. Generally a compiler creates executables, so creating the 
runtime is part of creating a compiler. A language-A-to-language-B translator, 
on the other hand, is supposed to be a smaller task and exclude the need for 
such things. Since the SofCheck compiler that outputs C includes the necessary 
runtime, I think it reasonable that they call it a compiler rather than a 
translator.

-- 
Jeff Carter
"Apart from the sanitation, the medicine, education, wine,
public order, irrigation, roads, the fresh water system,
and public health, what have the Romans ever done for us?"
Monty Python's Life of Brian
80

Re: Automated conversion to C++?

[Larry Kilgallen]

In article <5bb30e3a-479b-4feb-be5e-e777edf778c9@q78g2000hsh.googlegroups.com>, Maciej Sobczak <see.my.homepage@gmail.com> writes:
> On 16 Lut, 14:41, Kilgal...@SpamCop.net (Larry Kilgallen) wrote:
> 
>> The set "several platforms" is quite a bit smaller than "any mainstream
>> operating system".
> 
> Let's severely limit the set "several platforms" to {POSIX, Windows}.
> That's a really small set.
> 
> Which members of "any mainstream operating systems" are not yet
> covered?

Limiting it to Windows is a very small set.

Posix is not an environment in which it is possible to fully implement
Ada.

VMS is not in either of those sets, nor is OS400 I believe.

If the original poster has _particular_ operating systems of interest,
they should be listed.

Re: Automated conversion to C++?

[Peter C. Chapin]

Larry Kilgallen wrote:

> Posix is not an environment in which it is possible to fully implement
> Ada.

Why is that?

I'm not disagreeing with you... I'm just curious and would like to know 
more.

Peter

Re: Automated conversion to C++?

[Larry Kilgallen]

In article <47b883a9$0$26403$4d3efbfe@news.sover.net>, "Peter C. Chapin" <pchapin@sover.net> writes:
> Larry Kilgallen wrote:
> 
>> Posix is not an environment in which it is possible to fully implement
>> Ada.
> 
> Why is that?
> 
> I'm not disagreeing with you... I'm just curious and would like to know 
> more.

I am not an expert, but just as a first guess I don't see a way that
Posix could implement "end of line" and "end of page" markers without
using an inline reserved character.  That would make it pretty hard,
for instance, to write a line to a file with a newline character in
the middle of the file.  That might not be a valuable feature to you,
but since I can do it with my Ada compiler today, it would be a limit
to what I can do with my "real" Ada compiler.

I have my suspicious that due to its Unix/C roots, some implementations
of Posix might have trouble writing a file with lines that contain one or
more embedded null.  Unix and C have a habit of acting like no string
would have a null in the middle.

Re: Automated conversion to C++?

[Phaedrus]

I suspect the old rule applies, if you've gotta ask about the price then 
it's probably too much.
For example, has anyone else gotten a price quote from AdaWhore, er, 
AdaCore?  Yikes!

A while ago I was interested in getting a copy of Appletmagic from those 
folks, until I noticed that they don't list prices.   At that point I didn't 
even bother to contact them.

Brian

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccejbd20if.fsf@shell01.TheWorld.com...
> Jacob Sparre Andersen <sparre@nbi.dk> writes:
>
>> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>>> Jacob Sparre Andersen <sparre@nbi.dk> writes:
>>
>>>> A bit of quick googling found me "adatoccpptranslator", which may
>>>> be able to handle enough of the task.  Do you know of any other
>>>> plausible (and preferably Open Source) solutions?
>>>
>>> SofCheck has such a tool.
>>
>> Sounds good.
>>
>> Is it a part of AdaMagic?
>
> Yes.
>
> I believe it has some switches to use C versus C++.
>
>> How much does it cost?
>
> I've no idea.  I suggest you go on their web site
> www.sofcheck.com and ask them about it.
>
> - Bob 

Re: Automated conversion to C++?

[Larry Kilgallen]

In article <13rhddmrkvj8l49@corp.supernews.com>, "Phaedrus" <phaedrusalt@hotmail.com> writes:
> I suspect the old rule applies, if you've gotta ask about the price then 
> it's probably too much.
> For example, has anyone else gotten a price quote from AdaWhore, er, 
> AdaCore?  Yikes!

We got a reasonable price from Sofcheck for our purpose, and purchased.

Re: Automated conversion to C++?

[Martin Krischik]

Robert A Duff schrieb:
> Jacob Sparre Andersen <sparre@nbi.dk> writes:
> 
>> A bit of quick googling found me "adatoccpptranslator", which may be
>> able to handle enough of the task.  Do you know of any other plausible
>> (and preferably Open Source) solutions?
> 
> SofCheck has such a tool.

Have not found anything on there Webside :-(.

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

Re: Automated conversion to C++?

[Martin Krischik]

Robert A Duff schrieb:

> Jacob Sparre Andersen <sparre@nbi.dk> writes:
> 
>> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>>> Jacob Sparre Andersen <sparre@nbi.dk> writes:
>>>> A bit of quick googling found me "adatoccpptranslator", which may
>>>> be able to handle enough of the task.  Do you know of any other
>>>> plausible (and preferably Open Source) solutions?
>>> SofCheck has such a tool.
>> Sounds good.
>>
>> Is it a part of AdaMagic?
> 
> Yes.
> 
> I believe it has some switches to use C versus C++.
> 
>> How much does it cost?

Sometimes I which that SofCheck would also offer a community version - 
the community would really benefit from an Ada -> C or Ada -> C++ converter.

Martin

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

Re: Automated conversion to C++?

[Martin Krischik]

Phaedrus schrieb:

> I suspect the old rule applies, if you've gotta ask about the price then 
> it's probably too much.

I always thought is is: If YOU have to ask for the price then YOU can't 
afford it ;-) .

 > For example, has anyone else gotten a price quote from AdaWhore, er,
 > AdaCore?  Yikes!

Yes I did 15.000,-- for 5 seats - can't quite remember if it was $ or €.

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

Re: Automated conversion to C++?

[Maciej Sobczak]

On 17 Lut, 20:50, Kilgal...@SpamCop.net (Larry Kilgallen) wrote:

> I am not an expert, but just as a first guess I don't see a way that
> Posix could implement "end of line" and "end of page" markers without
> using an inline reserved character.

What is wrong with ASCII 10 and 12 codes (decimal)?
I don't see in what way POSIX can prevent you from implementing this
area of Ada library.

> I have my suspicious that due to its Unix/C roots, some implementations
> of Posix might have trouble writing a file with lines that contain one or
> more embedded null.

This statement is completely nebulous.
The POSIX standard defines the write function (man 2 write) that is a
basic function for doing output operations. C standard library
(stdio.h) is implemented on top of this, and also provides interface
for binary output of arbitrary data.
I don't see in what way POSIX can prevent you from correctly
implementing the Ada library.

> Unix and C have a habit of acting like no string
> would have a null in the middle.

Unix does not take care what you write to the file descriptor; C
allows binary operations without any problem and has nothing to do
when it comes to implementing Ada anyway.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Automated conversion to C++?

[Larry Kilgallen]

In article <bc0f9b78-814e-4599-86cf-6ddd461f1791@e60g2000hsh.googlegroups.com>, Maciej Sobczak <see.my.homepage@gmail.com> writes:
> On 17 Lut, 20:50, Kilgal...@SpamCop.net (Larry Kilgallen) wrote:
> 
>> I am not an expert, but just as a first guess I don't see a way that
>> Posix could implement "end of line" and "end of page" markers without
>> using an inline reserved character.
> 
> What is wrong with ASCII 10 and 12 codes (decimal)?

How would those not be "inline reserved characters" ?

How would you write a line that had an ASCII 10 in the middle
and get back that line that had an ASCII 10 in the middle, as
you can with the Ada compiler I currently use ?

I have no doubt that with Posix one could write a subset of Ada,
but that was not the question posed.

Re: Automated conversion to C++?

[Peter C. Chapin]

Larry Kilgallen wrote:

> How would you write a line that had an ASCII 10 in the middle
> and get back that line that had an ASCII 10 in the middle, as
> you can with the Ada compiler I currently use ?

Does the Ada standard actually *require* end of line indications to be 
represented in the file in a way other than by using a distinguished 
character sequence? If it does not require this than it would seem like 
a standard implementation could in some cases write one line and then 
read back more than one.

It seems a little hard to believe that the standard would be worded in a 
way that would prohibit a correct implementation on POSIX systems. If it 
is, then that seems like a bug in the standard.

Peter

Re: Automated conversion to C++?

[Jeffrey R. Carter]

Larry Kilgallen wrote:
> 
> How would those not be "inline reserved characters" ?
> 
> How would you write a line that had an ASCII 10 in the middle
> and get back that line that had an ASCII 10 in the middle, as
> you can with the Ada compiler I currently use ?
> 
> I have no doubt that with Posix one could write a subset of Ada,
> but that was not the question posed.

I'm sorry, but full Ada does not specify how line termination is implemented, 
nor guarantee that all values of Character may appear in a line that will be 
read back as written. ARM A.10 says they depend on the implementation, and may 
be actual characters, or "inline reserved characters", as you call them. "The 
effect of input (Get) or output (Put) of control characters (other than 
horizontal tabulation) is not specified by the language."

That you have an implementation in which all values of Characters may appear in 
a line does not mean that the standard requires it.

-- 
Jeff Carter
"We'll make Rock Ridge think it's a chicken
that got caught in a tractor's nuts!"
Blazing Saddles
87

Re: Automated conversion to C++?

[Randy Brukardt]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:gAi3fvx3BIHT@eisner.encompasserve.org...
> In article
<bc0f9b78-814e-4599-86cf-6ddd461f1791@e60g2000hsh.googlegroups.com>, Maciej
Sobczak <see.my.homepage@gmail.com> writes:
...
> > What is wrong with ASCII 10 and 12 codes (decimal)?
>
> How would those not be "inline reserved characters" ?
>
> How would you write a line that had an ASCII 10 in the middle
> and get back that line that had an ASCII 10 in the middle, as
> you can with the Ada compiler I currently use ?

Really? I'm not aware of any Ada compilers (for any platform) that support
that; if you expect that to work, it is not portable Ada!

Specifically, A.10(8) says "The effect of input (Get) or output (Put) of
control characters (other than horizontal tabulation) is not specified by
the language." "Unspecified" in language terms means not only that a
compiler can do what it pleases, but also that there is no requirement that
it tell you what it does. The result is that doing I/O of control characters
through Text_IO is not something that is done in a portable Ada program. (It
might work on a particular Ada compiler, but that is irrelevant.)

> I have no doubt that with Posix one could write a subset of Ada,
> but that was not the question posed.

There is no such requirement in Ada, so whether or not you can do it in
POSIX (or in Windows, for that matter), is irrelevant.

                                   Randy.

Re: Automated conversion to C++?

[John W. Kennedy]

Peter C. Chapin wrote:
> Larry Kilgallen wrote:
> 
>> How would you write a line that had an ASCII 10 in the middle
>> and get back that line that had an ASCII 10 in the middle, as
>> you can with the Ada compiler I currently use ?
> 
> Does the Ada standard actually *require* end of line indications to be 
> represented in the file in a way other than by using a distinguished 
> character sequence? If it does not require this than it would seem like 
> a standard implementation could in some cases write one line and then 
> read back more than one.

"The actual nature of terminators is not defined by the language and 
hence depends on the implementation. Although terminators are recognized 
or generated by certain of the procedures that follow, they are not 
necessarily implemented as characters or as sequences of characters. 
Whether they are characters (and if so which ones) in any particular 
implementation need not concern a user who neither explicitly outputs 
nor explicitly inputs control characters. The effect of input (Get) or 
output (Put) of control characters (other than horizontal tabulation) is 
not specified by the language."

So both Unix-style I/O and IBM-mainframe-style I/O are permitted, just 
as one would expect in any modern language.

-- 
John W. Kennedy
"There are those who argue that everything breaks even in this old dump 
of a world of ours. I suppose these ginks who argue that way hold that 
because the rich man gets ice in the summer and the poor man gets it in 
the winter things are breaking even for both. Maybe so, but I'll swear I 
can't see it that way."
   -- The last words of Bat Masterson

Re: Automated conversion to C++?

[Phaedrus]

Too right, I misquoted.  But then, because they force everyone to ask the 
price then it must be too much for everyone, right?  ;)

$15K for 5 seats???  Will they at least respect you in the morning?

Oh well...


"Martin Krischik" <krischik@users.sourceforge.net> wrote in message 
news:47b9304c$1@news.post.ch...
> Phaedrus schrieb:
>
>> I suspect the old rule applies, if you've gotta ask about the price then 
>> it's probably too much.
>
> I always thought is is: If YOU have to ask for the price then YOU can't 
> afford it ;-) .
>
> > For example, has anyone else gotten a price quote from AdaWhore, er,
> > AdaCore?  Yikes!
>
> Yes I did 15.000,-- for 5 seats - can't quite remember if it was $ or ?.
>
> Martin
> -- 
> mailto://krischik@users.sourceforge.net
> Ada programming at: http://ada.krischik.com 

Re: Automated conversion to C++?

[Jean-Pierre Rosen]

Peter C. Chapin a �crit :
> Larry Kilgallen wrote:
> It seems a little hard to believe that the standard would be worded in a 
> way that would prohibit a correct implementation on POSIX systems. If it 
> is, then that seems like a bug in the standard.
> 
Of course, please read A.10(8). It explains that terminators may or may 
not be represented by control characters, and that the effect of 
outputing control characters is not defined by the language - i.e. they 
may or may not create extra terminators.

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

Re: Automated conversion to C++?

[Jacob Sparre Andersen]

Jeffrey R. Carter wrote:
> Maciej Sobczak wrote:

>> Again: Which members of "any mainstream operating systems" are not
>> yet covered?
>
> I'm sure Kilgallen will object if VMS is not included. IBM
> mainframes are still widely used in the business world.

But for the current purpose "any mainstream operating systems" = {Linux
on IA32; Linux on IA64}.

Greetings,

Jacob
-- 
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?

Re: Automated conversion to C++?

[Martin Krischik]

Phaedrus wrote:

> Too right, I misquoted.  But then, because they force everyone to ask the
> price then it must be too much for everyone, right?  ;)

No, the original saying suggest that there are those who are so wealthy that
they are not interested to know the price before they actually open there
checkbook at which time they are told the price.
 
> $15K for 5 seats???  Will they at least respect you in the morning?

They will answer all the questions you will raise at gnat tracker and still
respect you.

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

Subject: POSIX , Ada, Line Feeds, etc (was Automated conversion to C++)

[KarlNyberg]

[Posting for Dave Emery, demery@dsci-usa.com, editor of the early
POSIX-Ada standard, I believe.  Apologies if I inserted this
inappropriately into the hierarchy of the discussion...  -- kan]

Subject: POSIX , Ada, Line Feeds, etc (was Automated conversion to C+
+)

Much bogosity on this topic lately.  Several early Ada compilers,
most
notably Verdix, were implemented on Unix as well-behaved Unix
applications, and of course GNAT is available for Linux.  So any
assertion that POSIX and Ada are incompatible as a development
environment is contradicted by example.

With respect to line feeds, the Ada standard doesn't explain the
interpretation of the line feed characters on POSIX, but the POSIX
Ada
Binding (ISO 14519:2001, originally IEEE 1003.5-1992 most certainly
does.  This is very clearly documented in Clause 8, "Language-
Specific
Services for Ada".  Clause 8.1, entitled "Interoperable Ada I/O
Services" provides a specification of the Text_IO Form parameter to
handle this situation.

As one of the most widely used secondary standards, it's
disappointing
to see how few readers on this list lately are aware of the POSIX/Ada
standard and its success in supporting portable Ada applications
across
conforming POSIX (and Ada compiler) implementations.

          dave

- --
David Emery, DSCI, supporting PdM FCS (BCT) SW Integration
703 298 3473 (office/cell), 703 272 7496 (fax)

Re: Automated conversion to C++?

[Jacob Sparre Andersen]

Martin <martin.dowie@afraidof.co.uk> writes:
> On 16 Feb, 16:42, Jacob Sparre Andersen <spa...@nbi.dk> wrote:

>> I don't care about how messy the C++ code is going to be. �We'll
>> most likely be running the Ada version internally. �The C++ code is
>> only a matter of public perception. �The project lead is of the
>> opinion that publishing the system with C++ code will make more
>> scientists interested in the system.
>
> Would a C++ API do?

It might be a (better) solution.  (But it isn't the "approved"
solution.)

Greetings,

Jacob
-- 
"Any, sufficiently complicated, experiment is indistinguishable from magic."

Re: Subject: POSIX , Ada, Line Feeds, etc

[Jacob Sparre Andersen]

Karl Nyberg wrote:

> [Posting for Dave Emery, demery@dsci-usa.com, editor of the early
> POSIX-Ada standard, I believe.  Apologies if I inserted this
> inappropriately into the hierarchy of the discussion...  -- kan]

> As one of the most widely used secondary standards, it's
> disappointing to see how few readers on this list lately are aware
> of the POSIX/Ada standard and its success in supporting portable Ada
> applications across conforming POSIX (and Ada compiler)
> implementations.

The pricing of the POSIX/Ada standard reduces its visibility and
popularity significantly.

If the POSIX/Ada standard was freely available in electronic form -
like the Ada standard - then I am sure we would see much more use of
the POSIX/Ada API, and not quite as many hand-coded bindings to the
POSIX/C API.

Greetings,

Jacob
-- 
"There are two ways of constructing a software design. One way is to
 make it so simple that there are obviously no deficiencies. And the
 other way is to make it so complicated that there are no obvious
 deficiencies."                                    -- C. A. R. Hoare

Re: Automated conversion to C++?

[vindhya]

On Feb 15, 7:11 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> Jacob Sparre Andersen <spa...@nbi.dk> writes:
>
> > A bit of quick googling found me "adatoccpptranslator", which may be
> > able to handle enough of the task.  Do you know of any other plausible
> > (and preferably Open Source) solutions?
>
> SofCheck has such a tool.
>
> - Bob
Hi,
I need to convert the ada code into C langauge.
Ifound Ada Magic but i am unable to download it.
Is there any software like that to translate code automatically to C.
Thanks and Regards,
vindhya

Re: Automated conversion to C++?

[Robert A Duff]

vindhya <vindhyacse@gmail.com> writes:

> On Feb 15, 7:11�pm, Robert A Duff <bobd...@shell01.TheWorld.com>
> wrote:
>> Jacob Sparre Andersen <spa...@nbi.dk> writes:
>>
>> > A bit of quick googling found me "adatoccpptranslator", which may be
>> > able to handle enough of the task. �Do you know of any other plausible
>> > (and preferably Open Source) solutions?
>>
>> SofCheck has such a tool.
>>
>> - Bob
> Hi,
> I need to convert the ada code into C langauge.
> Ifound Ada Magic but i am unable to download it.
> Is there any software like that to translate code automatically to C.
> Thanks and Regards,
> vindhya

I don't know.  I suggest you contact SofCheck
( www.sofcheck.com ).

- Bob