ada vs. cpp

ada vs. cpp

[Richard Pinkall-Pollei]

The discussion of the relative merits of both languages has so far
centered on basic language features.  With the adoption of the C++
STL into the standard, the differences in these features are a
reflection of the basic syntax and semantic philosophies of each
language, with secondary effects on development time and maintain-
ability.

What I haven't seen discussed is the situation I encountered when
trying to implement a multi-tasking application.  Here, I had to
go outside the C++ standard for thread and resource control,
either by developing my own code using OS calls (albeit POSIX
defined) and STL containers, or using someone else's code for such.
With Ada, the constructs were all defined within the language
standard.  A similar case occurs with distributed systems, but in
this case, the Ada standard does not require a compiler to include
the features in the Distributed Computing Annex.

In this case, then, my language choice was based not only on devel-
opment and maintenance time, but on whether I wanted to develop my
own multi-tasking and resource control code, or let the compiler
do it.  The former might be fun, but the latter is easier.

---
I'm screwing up.  Why?  What does it *look* like I'm doing?
______________________________________________________________________________
Posted Via Binaries.net = SPEED+RETENTION+COMPLETION = http://www.binaries.net

Re: ada vs. cpp

[Vector..]

In article <slrn9semrm.4l2.whraven@raven.wri>, whraven@usenet-access.com says...
 
What is wrong with pthreads?

Yes, it is not part of the language, but it is a standard (POSIX), and
available in all platforms (except may on windows, I am not sure, but
who cares about widnows anyway).

So, simply do

#include <pthreads.h>

and you are all set.

btw, I agree that having threads implemented in the language is better, but
with pthreads around for C/C++ to use, this argument is not very strong.

Re: ada vs. cpp

[Dale Stanbrough]

Vector..@ <Vector.._member@newsguy.com> wrote:

> What is wrong with pthreads?

No proper monitor model (and not just a wimpy java monitor, but
one that actually -monitors- conditions). No rendezvous mechanism.


> Yes, it is not part of the language, but it is a standard (POSIX), and
> available in all platforms (except may on windows, I am not sure, but
> who cares about widnows anyway).

With varying degrees of success. Apple's threads are apparently 
a bit ordinary.
I think a very large % of the market cares about windows. If
you want transportable threaded programs, you can use tools
like Doug Schmidt's C++ ACE environment which includes thread
based bindings, or you could use a language that supports 
threading.

> So, simply do
> 
> #include <pthreads.h>
> 
> and you are all set.

Not quite. You forget #define _REENTRANT. And don't forget the
compile options.

Dale

Re: ada vs. cpp

[Jean-Marc Bourguet]

"Vector..@" wrote:
> 
> In article <slrn9semrm.4l2.whraven@raven.wri>, whraven@usenet-access.com says...
> 
> What is wrong with pthreads?

Wrong level of abstraction, not portable.

> Yes, it is not part of the language, but it is a standard (POSIX), and
> available in all platforms (except may on windows, I am not sure, but
> who cares about widnows anyway).

I don't use Windows but would never call something not available on
Windows portable.
 
> So, simply do
> 
> #include <pthreads.h>
> 
> and you are all set.

You miss:
   - add some defines,
   - check the compiler support this correctly (try once exceptions with
     gcc 2.95 and threads for one thing for which you need compiler support)
     and add the corresponding compiler options
   - check all libraries you use are thread save, included OS libraries and
     language libraries, and that protecting by mutex the one which are not
     is enough.

> btw, I agree that having threads implemented in the language is better, but
> with pthreads around for C/C++ to use, this argument is not very strong.

Well, stronger than you think (look up the threads on c.l.c++.m where one
speak on threads).

-- Jean-Marc

Re: ada vs. cpp

[Nexus]

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

Do you guys think it would be complicated to port th pthread PART programm
to Intel platforms?


"Vector..@" <Vector.._member@newsguy.com> a �crit dans le message de news:
9q7na102nqn@drn.newsguy.com...
> In article <slrn9semrm.4l2.whraven@raven.wri>, whraven@usenet-access.com
says...
>
> What is wrong with pthreads?
>
> Yes, it is not part of the language, but it is a standard (POSIX), and
> available in all platforms (except may on windows, I am not sure, but
> who cares about widnows anyway).
>
> So, simply do
>
> #include <pthreads.h>
>
> and you are all set.
>
> btw, I agree that having threads implemented in the language is better,
but
> with pthreads around for C/C++ to use, this argument is not very strong.
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.286 / Virus Database: 152 - Release Date: 09/10/01

Re: ada vs. cpp

[Lutz Donnerhacke]

* Vector..@ wrote:
>What is wrong with pthreads?
>
>Yes, it is not part of the language, but it is a standard (POSIX), and
>available in all platforms (except may on windows, I am not sure, but
>who cares about widnows anyway).

My NEXTSTEP can't even compile zlib (needed by openssh-portable), so I'm
pretty disilusionated from Posix. OTOH one of my DSPs has Character'Size = 32,
a pretty common problem to almost all C based programs, because they tend to
use constructs like
   for (unsigned char c = 0; c < UCHAR_MAX + 1; c++) { ... }
instead of the correct idiom
   unsigned char c = 0; do { ... } while (c++ != UCHAR_MAX);
for
   for c in Character'Range loop ... end loop;

This DSP is always funny because sizeof(int[8]) == 4. This causes several
memory reservation problems.

But even with Linux on x86 you may run into common idiom problems:
  int fd = open (...);
fails if you compile with -mshort (some programs do this), because the
kernel limits NR_OPEN to 1024*1024.

...

Re: ada vs. cpp

[Florian Weimer]

lutz@iks-jena.de (Lutz Donnerhacke) writes:

> OTOH one of my DSPs has Character'Size = 32,


> a pretty common problem to almost all C based programs, because they tend to
> use constructs like
>    for (unsigned char c = 0; c < UCHAR_MAX + 1; c++) { ... }

This code is never correct, "c < UCHAR_MAX + 1" is always true, I
think.

> This DSP is always funny because sizeof(int[8]) == 4.

Funny indeed.  Is this really legal C?

Re: ada vs. cpp

[David Thompson]

Florian Weimer <fw@deneb.enyo.de> wrote :
> lutz@iks-jena.de (Lutz Donnerhacke) writes:
>
> > OTOH one of my DSPs has Character'Size = 32,
>
>
> > a pretty common problem to almost all C based programs, because they tend to
> > use constructs like
> >    for (unsigned char c = 0; c < UCHAR_MAX + 1; c++) { ... }
>
> This code is never correct, "c < UCHAR_MAX + 1" is always true, I
> think.
>
Yep.  I think Lutz meant int /* or unsigned int */ c = 0; c<...; c++.
Which he is right is the usual idiom.

Most of the arithmetic operators in C promote their operands
to at least (signed or unsigned) int before doing the operation.
On most machines int is wider than unsigned char,
so UCHAR_MAX + 1 can be computed as int without
overflow or wraparound, and as long as the index variable
is a type that can be incremented to that it terminates.

But on a machine with 32-bit char and 32-bit (or smaller?!) int,
this promotion no longer happens, so UCHAR_MAX + 1 is
always zero, and the loop never executes.

Another, arguably even clever/trickier, solution is to
rely on the modular behavior of unsigned:
  unsigned char c = 0; do{ ... } while(++c /*!=0*/ );

(BTW- the syntax of declaring the loop variable in the for statement
was not in C89; it is in C++ and C99.  Workaround is obvious.)

> > This DSP is always funny because sizeof(int[8]) == 4.
>
> Funny indeed.  Is this really legal C?

No.  sizeof(char) is defined to be 1, and sizeof any other
type must be at least 1; the common error is assuming
strictly greater.  sizeof(int[8]) = 8*sizeof(int) >= 8.
The only C thing that can be smaller than char is a bit-field
member of a struct, but that does not have its own type
and cannot have its sizeof (or offsetof or address) taken.

Even bool/_Bool occupies one "char" of space even though
its value fits in one bit, and arrays of them are not packed.
(But C++ std::vector<bool> _may_ be.)

--
- David.Thompson 1 now at worldnet.att.net

Re: ada vs. cpp

[Florian Weimer]

"David Thompson" <david.thompson1@worldnet.att.net> writes:

> But on a machine with 32-bit char and 32-bit (or smaller?!) int,
> this promotion no longer happens, so UCHAR_MAX + 1 is
> always zero, and the loop never executes.

Is it always zero?  I don't think so.  For example, UCHAR_MAX itself
could equal zero when cast to an unsigned integer type (on a ones
complement machine).

>> > This DSP is always funny because sizeof(int[8]) == 4.
>>
>> Funny indeed.  Is this really legal C?
>
> No.  sizeof(char) is defined to be 1, and sizeof any other
> type must be at least 1; the common error is assuming
> strictly greater.

But where's this requirement in the C standard?

Re: ada vs. cpp

[Lutz Donnerhacke]

* Florian Weimer wrote:
>"David Thompson" <david.thompson1@worldnet.att.net> writes:
>> No.  sizeof(char) is defined to be 1, and sizeof any other
>> type must be at least 1; the common error is assuming
>> strictly greater.
>
>But where's this requirement in the C standard?

X3J11:1999-6.2.6.1(4)

Re: ada vs. cpp

[David Thompson]

(This is getting pretty far offtopic.)

Florian Weimer <fw@deneb.enyo.de> wrote :
> "David Thompson" <david.thompson1@worldnet.att.net> writes:
>
> > But on a machine with 32-bit char and 32-bit (or smaller?!) int,
> > this promotion no longer happens, so UCHAR_MAX + 1 is
> > always zero, and the loop never executes.
>
> Is it always zero?  I don't think so.  For example, UCHAR_MAX itself
> could equal zero when cast to an unsigned integer type (on a ones
> complement machine).
>
"Always" under the (rather restrictive) environment I stated, yes.
More precisely, if unsigned char does not "fit" in signed int.

UCHAR_MAX (and all the other integer MAX and MIN macros)
cannot equal zero.  They have "the same type as would an
expression that is an object of the corresponding type converted
according to the integer promotions"  5.2.4.2.1p1 and those
promotions are value-preserving 6.3.1.1p2,3.  The representation
used for unsigned integer types must be "pure binary" 6.2.6.2p1;
the possibly ones-complement representation of signed integers
only applies to a signed integer type, which in this environment
UCHAR_MAX is not.  If you (explicitly) cast it to signed int,
_then_ it might be zero (and is certainly implementation-defined).

And in this environment, where UCHAR_MAX promotes to
unsigned int not signed, this also means (which I elided)
the addition UCHAR_MAX + 1 is done in unsigned int;
this is a specific width (not universal) and in C unsigned
integer overflow is required to wrap modulo 2 up W while
signed or floating overflow is Undefined Behavior (erroneous).
Therefore in this environment the result is zero (with
the undesirable consequences already discussed).

--
- David.Thompson 1 now at worldnet.att.net

Re: ada vs. cpp

[Jean-Marc Bourguet]

Lutz Donnerhacke wrote:
> This DSP is always funny because sizeof(int[8]) == 4. This causes several
> memory reservation problems.

This is not a standard conforming implementation which requires:

sizeof(char) = 1
sizeof(int) >= sizeof(char) 
sizeof(int[8]) = 8 * sizeof(int)

so sizeof(int[8]) >= 8

Yours.

-- Jean-Marc

Re: ada vs. cpp

[Lutz Donnerhacke]

* Jean-Marc Bourguet wrote:
>Lutz Donnerhacke wrote:
>> This DSP is always funny because sizeof(int[8]) == 4. This causes several
>> memory reservation problems.
>
>This is not a standard conforming implementation which requires:
>
>sizeof(char) = 1

Ack.

>sizeof(int) >= sizeof(char)

Ack. Implementation holds, because sizeof(int) == 1.

>sizeof(int[8]) = 8 * sizeof(int)

Nack. Or are packed arrays unsupported? Even, if the addressing granularity
is finer than the character size?
  
>so sizeof(int[8]) >= 8

No necessary.

Let's have a look at X3-J11 (C99): 6.5.3.4  The sizeof operator
:  Semantics
:
:2 The sizeof operator yields the size (in bytes) of its operand, ...
:
:3 When applied to an operand that has type char, unsigned char, or signed
:  char (...) the result is 1. When applied to an operant that hast array
:  type, the result is the total number of bytes in the array. ...

Consequence: No compiler is a conforming one when a char is not a byte?!

And look! 3.7.1 says:
: character:  single-byte character:  bit representation that fits in a byte.
But oops! That's not a char.

6.2.5 says
:3 An object declared as type char is large enough to store any member of the
:  basic execution character set. If a member of the basic execution set is
:  stored in a char object, its value is guaranteed to be positive. If any
:  other character is stored in a char object, the resulting value is
:  implementation-defined but shall be within the range of values that can be
:  represented in that type.

There is no reason for a byte limited character.

But 6.2.6.1 contains an interesting note:
:3 Values stored in unsigned bit-fields and objects of type unsigned char
:  shall be represented using a pure binary notation. 40)
:
:4 Values stored in non-bit-field objects of any other object type consits of
:  n x CHAR_BIT bits, where n is the size of an object of that type, in bytes.
:  ...
:40) ... A byte contains CHAR_BIT bits ...

Ah I see: C requires (by a footnote) that Storage_Units are similar to a char.

Unfortunly this DSP addresses 32bit objects and is able to deal efficiently
with 16bit registers. An other DSP I have changes the Storage_Unit over the
address range: Starting with 8 bit bytes from 0 .. 16#f_ffff#, 16 bit bytes
from 16#10_0000# .. 16#1f_ffff#, and 32 bit bytes from 16#2f_ffff# ..
16#ffff_ffff#.

*gna*

Re: ada vs. cpp

[Jean-Marc Bourguet]

Lutz Donnerhacke wrote:
> >sizeof(int[8]) = 8 * sizeof(int)
> 
> Nack. Or are packed arrays unsupported? Even, if the addressing granularity
> is finer than the character size?

By definition in C and C++, the adressing granularity is the character
size.
Yes, they are unifying/confusing two different things.

-- Jean-Marc

Re: ada vs. cpp

[Lutz Donnerhacke]

* Jean-Marc Bourguet wrote:
>Lutz Donnerhacke wrote:
>> >sizeof(int[8]) = 8 * sizeof(int)
>> 
>> Nack. Or are packed arrays unsupported? Even, if the addressing granularity
>> is finer than the character size?
>
>By definition in C and C++, the adressing granularity is the character
>size.

Noticed this a few hours ago.

>Yes, they are unifying/confusing two different things.

Definitly. OTOH the CPU manufactures don't care about this nifty braindamage.

Re: ada vs. cpp

[Darren New]

Jean-Marc Bourguet wrote:
> By definition in C and C++, the adressing granularity is the character
> size.
> Yes, they are unifying/confusing two different things.

This is why internet standards use the term "octet", which means 8 bits.
:-)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
                   Who is this Dr. Ibid anyway, 
                  and how does he know so much?

Re: ada vs. cpp

[Florian Weimer]

lutz@iks-jena.de (Lutz Donnerhacke) writes:

> :3 When applied to an operand that has type char, unsigned char, or signed
> :  char (...) the result is 1. When applied to an operant that hast array
> :  type, the result is the total number of bytes in the array. ...
>
> Consequence: No compiler is a conforming one when a char is not a byte?!

Yes, of course.  Unfortunately, this way, a low-level concept (storage
unit) and a high-level one (character set) are strongly linked, which
is a rather bad idea.

> Ah I see: C requires (by a footnote) that Storage_Units are similar
> to a char.

I don't think footnotes are normative.  There has to be a way to
derive this from the main text.

Re: ada vs. cpp

[Stephen Leake]

Florian Weimer <fw@deneb.enyo.de> writes:

> lutz@iks-jena.de (Lutz Donnerhacke) writes:
> 
> > :3 When applied to an operand that has type char, unsigned char, or signed
> > :  char (...) the result is 1. When applied to an operant that hast array
> > :  type, the result is the total number of bytes in the array. ...
> >
> > Consequence: No compiler is a conforming one when a char is not a byte?!
> 
> Yes, of course.  Unfortunately, this way, a low-level concept (storage
> unit) and a high-level one (character set) are strongly linked, which
> is a rather bad idea.

Actually, a C compiler with a 16 bit char is conforming; this
statement in the C standard simply tells you that a size 1 for this
compiler means 16 bits.

Remember, there is nothing "standard" about an 8 bit byte. In fact,
ISO uses the term "octet" to mean 8 bits; "byte" often means "smallest
addressable unit", which is commonly 8 bits, often 16 bits, and
sometimes some other number.

> > Ah I see: C requires (by a footnote) that Storage_Units are
> > similar to a char.

Yes; in C, a 'char' is the smallest addressable unit of memory.

-- 
-- Stephe

Re: ada vs. cpp

[Florian Weimer]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:

> Florian Weimer <fw@deneb.enyo.de> writes:
>
>> lutz@iks-jena.de (Lutz Donnerhacke) writes:
>> 
>> > :3 When applied to an operand that has type char, unsigned char, or signed
>> > :  char (...) the result is 1. When applied to an operant that hast array
>> > :  type, the result is the total number of bytes in the array. ...
>> >
>> > Consequence: No compiler is a conforming one when a char is not a byte?!
>> 
>> Yes, of course.  Unfortunately, this way, a low-level concept (storage
>> unit) and a high-level one (character set) are strongly linked, which
>> is a rather bad idea.
>
> Actually, a C compiler with a 16 bit char is conforming; this
> statement in the C standard simply tells you that a size 1 for this
> compiler means 16 bits.
>
> Remember, there is nothing "standard" about an 8 bit byte.

The revision of POSIX.1 will require 8 bit bytes, I think, but of
course, there's no such requirement in the C language (except that the
size must be greater than 7 bits).

Re: ada vs. cpp

[Stephen Leake]

Florian Weimer <fw@deneb.enyo.de> writes:

> The revision of POSIX.1 will require 8 bit bytes, I think, but of
> course, there's no such requirement in the C language (except that the
> size must be greater than 7 bits).

Interesting. So there will be no implementations of POSIX.1 on 16 bit
addressable machines? I guess that's not a big loss.

-- 
-- Stephe

Re: ada vs. cpp

[Florian Weimer]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:

> Florian Weimer <fw@deneb.enyo.de> writes:
> 
> > The revision of POSIX.1 will require 8 bit bytes, I think, but of
> > course, there's no such requirement in the C language (except that the
> > size must be greater than 7 bits).
> 
> Interesting. So there will be no implementations of POSIX.1 on 16 bit
> addressable machines?

Probably.  But you could write C compilers with CHAR_BIT == 8 even for
such architectures.

> I guess that's not a big loss.

It's suddenly much easier to write POSIX-compliant applications. ;-)

Re: ada vs. cpp

[Lutz Donnerhacke]

* Florian Weimer wrote:
>Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:
>> Florian Weimer <fw@deneb.enyo.de> writes:
>> > The revision of POSIX.1 will require 8 bit bytes, I think, but of
>> > course, there's no such requirement in the C language (except that the
>> > size must be greater than 7 bits).
>> 
>> Interesting. So there will be no implementations of POSIX.1 on 16 bit
>> addressable machines?
>
>Probably.  But you could write C compilers with CHAR_BIT == 8 even for
>such architectures.

You can't do this at least on systems where the machine character set
requires 15 bit. So you need 16bit characters to embed the required
characters with positive values. You even can't map the machine character
set to an ASCII representation, because C99 requires a transparent mapping
f�r unsigned char. *baff*

Re: ada vs. cpp

[Ted Dennison]

In article <3BCBF40A.BBDD4FE6@free.fr>, Jean-Marc Bourguet says...
>This is not a standard conforming implementation which requires:
>
>sizeof(char) = 1

Which standard are you talking about? I'm pretty sure there is no such
requirement for K&R C compilers.

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

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: ada vs. cpp

[Jean-Marc Bourguet]

Ted Dennison wrote:
> 
> In article <3BCBF40A.BBDD4FE6@free.fr>, Jean-Marc Bourguet says...
> >This is not a standard conforming implementation which requires:
> >
> >sizeof(char) = 1
> 
> Which standard are you talking about? I'm pretty sure there is no such
> requirement for K&R C compilers.

ISO-IEC 14882 (Programming languages -- C++) 5.3.3/1 says 

... sizeof(char), sizeof(signed char) and sizeof(unsigned char) are 1
...

and I'm quite sure this is something inherited from C.

Yours,

-- Jean-Marc

Re: ada vs. cpp

[Lutz Donnerhacke]

* Ted Dennison wrote:
>In article <3BCBF40A.BBDD4FE6@free.fr>, Jean-Marc Bourguet says...
>>This is not a standard conforming implementation which requires:
>>
>>sizeof(char) = 1
>
>Which standard are you talking about? I'm pretty sure there is no such
>requirement for K&R C compilers.

I already quoted the C99 (X3J11) requirement.

Re: ada vs. cpp

[Marin David Condic]

"Vector..@" <Vector.._member@newsguy.com> wrote in message
news:9q7na102nqn@drn.newsguy.com...
>
> Yes, it is not part of the language, but it is a standard (POSIX), and
> available in all platforms (except may on windows, I am not sure, but
> who cares about widnows anyway).
>
Only a few million users. :-)

You can't ignore Windows as a platform even if you don't like it. There are
also lots of other systems out there needing to be programmed that may or
may not have an OS at all, much less one that implements Posix. The world
does not begin and end with Unix, so there is a *big* advantage to being
able to build threaded apps from within the language rather than depend on
some external standard that may or may not be present on platforms of
interest. If I build in Ada, I *know* I have multitasking available to me
and that it will work as advertised in a portable way.

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/

ada vs. cpp

[Ralph M�ritz]

Greetings,

I've spent sbout 2 months learning cpp, and now I've discovered ada!
I can't decide whether to carry on dev. my project ic cpp or rewrite in 
ada, because it means ppl dev. with me will have to learn ada.(sigh)

Is it worthwhile to rewrite, if so, why?
Could I save the cpp code somehow so that I don't have to maybe rewrite?

Thanks ;-)

Re: ada vs. cpp

[Preben Randhol]

On 3 Oct 2001 20:42:29 GMT, Ralph M�ritz wrote:
> Greetings,
> 
> I've spent sbout 2 months learning cpp, and now I've discovered ada!
> I can't decide whether to carry on dev. my project ic cpp or rewrite in 
> ada, because it means ppl dev. with me will have to learn ada.(sigh)

I would say; learn Ada, without knowing more about your project. I find
Ada much more elegant than C++. For me Ada is also easier to
learn/understand than C++ was.

> Is it worthwhile to rewrite, if so, why?

Please tell a bit about your project.

Preben Randhol

Re: ada vs. cpp

[Ralph M�ritz]

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

Preben Randhol <randhol+abuse@pvv.org> wrote in 
news:slrn9rn660.uu.randhol+abuse@kiuk0156.chembio.ntnu.no:

> On 3 Oct 2001 20:42:29 GMT, Ralph M�ritz wrote:
>> Greetings,
>> 

<snip>

> 
> Please tell a bit about your project.
> 
> Preben Randhol
> 

It's a text-based (roguelike) rpg, I haven't yet gotten far but it's going 
to be big! Uses objects (thus cpp instead C) to eliminate much repetitive 
code for stats storage and access. A header file for each component 
(dungeon.cpp --> dungeon.h etc.)

Re: ada vs. cpp

[Pi]

Ralph M�ritz wrote :

> Preben Randhol <randhol+abuse@pvv.org> wrote in
> news:slrn9rn660.uu.randhol+abuse@kiuk0156.chembio.ntnu.no:
> 
> > On 3 Oct 2001 20:42:29 GMT, Ralph M�ritz wrote:
> >> Greetings,
> >> 
> 
> <snip>
> 
> > 
> > Please tell a bit about your project.
> > 
> > Preben Randhol
> > 
> 
> It's a text-based (roguelike) rpg, I haven't yet gotten far but it's going
> to be big! Uses objects (thus cpp instead C) to eliminate much repetitive
> code for stats storage and access. A header file for each component
> (dungeon.cpp --> dungeon.h etc.)

Hmm, Objects ...

1st : Ada will help you find more bugs at compile time than C++
So your developpement time tends to be faster.
But consider that interactions with the OS are more difficult.
Not much more, but slightly.

Remember that Ada is at his very best if you give him few
input, billions of calculations on numbers and than few output.

You say that it's text-based.
Do you have to parse the text-input?
In this case I would consider using Perl[1] for the parsing
and than the actual treatement in Ada.
(Strings aren't Ada's strength)

2nd : Objects : 
as long as you dont need special features you're fine with Ada.
Just consider a package like an object and you're cool.

3rd : Heritage
Hmm, package heritage is ok, tagged types work too

4th : Polymorphism
Argh, only possible with tagged type and true crap, so stick with C++
Or you can try to hand-code it, but it's far less flexible and
error-prone. But IMNSHO still better than Ada's tagged type variant.

5th : Multiple Heritage
Not possible with Ada.

[1] Perl is your worst nightmare for big project,
but the best language for text parsing out there,
so if you use it, use it *only* for the parsing.

-- 
3,14159265359
who suffered Ada's "polymorphism" at university

Re: ada vs. cpp

[Ed Falis]

Pi wrote:

> 4th : Polymorphism
> Argh, only possible with tagged type and true crap, so stick with C++
> Or you can try to hand-code it, but it's far less flexible and
> error-prone. But IMNSHO still better than Ada's tagged type variant.

Well, I guess we're all entitled to our opinions.  Yes, compared to
perhaps Eiffel, tagged types can occasionally be a bit clumsy, but not
particularly compared to C++.  And yes, it is far less error-prone than
..., but certainly no less flexible ;-)

> 
> 5th : Multiple Heritage
> Not possible with Ada.

"Bull-Hockey", to quote someone I can't remember.  Aside from various
idioms for common cases laid out in the Ada 95 Rationale, you can do
fully general multiple inheritance using access discriminants (also
described in the Rationale).  It's just that it's a bit more clumsy than
in some other languages.  

- Ed

Re: ada vs. cpp

[David Starner]

On Thu, 4 Oct 2001 01:08:42 -0400, Pi <pi3_1415926536@yahoo.ca> wrote:
> Remember that Ada is at his very best if you give him few
> input, billions of calculations on numbers and than few output.

"her" very best. I guess it's very debatable, though . . .

> You say that it's text-based.
> Do you have to parse the text-input?
> In this case I would consider using Perl[1] for the parsing
> and than the actual treatement in Ada.
> (Strings aren't Ada's strength)

Strings aren't Ada's strength, but Ada isn't terribly weak in strings. I
don't see any problem in parsing the input using Ada. 

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I saw a daemon stare into my face, and an angel touch my breast; each 
one softly calls my name . . . the daemon scares me less."
- "Disciple", Stuart Davis

Re: ada vs. cpp

[Preben Randhol]

On 4 Oct 2001 05:13:44 GMT, David Starner wrote:
> Strings aren't Ada's strength, but Ada isn't terribly weak in strings. I
> don't see any problem in parsing the input using Ada. 

Wouldn't you be able to mix it with enumerates too to make the parsing
even easier? I don't see any need for Perl.

-- 
Preben Randhol ------------------- http://www.pvv.org/~randhol/ --
                 �For me, Ada95 puts back the joy in programming.�

Re: ada vs. cpp

[Marin David Condic]

While Ada isn't particularly a string manipulation language, it has a lot of
support in the Ada.Strings.* packages. I think strings are better supported
in Ada than in C++. Given that it isn't especially weak - and as you say,
use of enumerals may be a big help - I wouldn't see any reason to make one's
life harder by mixing languages and using Perl. Making a project
multi-lingual is unwise unless one has a compelling reason to do so.

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/


"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrn9rondp.tn.randhol+abuse@kiuk0156.chembio.ntnu.no...
>
> Wouldn't you be able to mix it with enumerates too to make the parsing
> even easier? I don't see any need for Perl.
>

Re: ada vs. cpp

[Pascal Obry]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> While Ada isn't particularly a string manipulation language, it has a lot of
> support in the Ada.Strings.* packages. I think strings are better supported
> in Ada than in C++. 

Are you saying that C and C++ has support for strings ?

I see there only pointers to a serie of bytes in memory terminated to '\0' ! 
Is that a string definition ? :)

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 vs. cpp

[Marin David Condic]

Well, you're point is taken. Both C and C++ do tend to treat strings as just
a bunch of bytes. But if we're fair about it, C does have some standard
functions for string manipulation and C++ does have a string class that
provides some support for string manipulation, so it isn't as if the
language designers never considered that you might want to find occurrences
of "David" in the string "Marin David Condic", right? I think the Ada
support is more "industrial strength" but obviously Ada wasn't designed to
be a text processing language. So criticism could be leveled at Ada for not
treating strings as nicely as something like SNOBOL. Could be a case of the
Pot calling the Kettle black?

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/


"Pascal Obry" <p.obry@wanadoo.fr> wrote in message
news:uadz7nza7.fsf@wanadoo.fr...
>
> Are you saying that C and C++ has support for strings ?
>
> I see there only pointers to a serie of bytes in memory terminated to '\0'
!
> Is that a string definition ? :)
>
> Pascal.
>

Re: ada vs. cpp

[Mike Mohr]

"Pascal Obry" <p.obry@wanadoo.fr> wrote in message
news:uadz7nza7.fsf@wanadoo.fr...
>
> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
>
> > While Ada isn't particularly a string manipulation language, it has a
lot of
> > support in the Ada.Strings.* packages. I think strings are better
supported
> > in Ada than in C++.
>
> Are you saying that C and C++ has support for strings ?
>
> I see there only pointers to a serie of bytes in memory terminated to '\0'
!
> Is that a string definition ? :)


C++ has a string class.

Re: ada vs. cpp

[Pascal Obry]

"Mike Mohr" <nospam@nowhere.com> writes:

> C++ has a string class.

I know. Yet in C/C++ it is hard to beat

        V1 : constant String := "1234567890";
        V2 : constant String := "AAA" & V1 (3 .. V1'Last - 2) & "BBB";

in readability and ease of use.

I have done many text processing code in both C/C++ and Ada and from
experience I found the Ada code far more readable. There is may examples.

Another one that come to mind:

        V1 : constant String := "0123/zzz";

        subtype Code is Positive range 1 .. 4;
        subtype Arg  is Positive range 6 .. 8;

        V2 : constant String := V1 (Arg) & '-' & V1 (Code);

This is not theory, I have used these kinds of code many many times. And again
I don't see how we could have a better readability !

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 vs. cpp

[MM]

In article <u8zepgmea.fsf@wanadoo.fr>, Pascal says...
>
 

>
>I know. Yet in C/C++ it is hard to beat
>
>        V1 : constant String := "1234567890";
>        V2 : constant String := "AAA" & V1 (3 .. V1'Last - 2) & "BBB";
>
>in readability and ease of use.
>
>I have done many text processing code in both C/C++ and Ada and from
>experience I found the Ada code far more readable. There is may examples.
>
>Another one that come to mind:
>
>        V1 : constant String := "0123/zzz";
>
>        subtype Code is Positive range 1 .. 4;
>        subtype Arg  is Positive range 6 .. 8;
>
>        V2 : constant String := V1 (Arg) & '-' & V1 (Code);
>
>This is not theory, I have used these kinds of code many many times. And again
>I don't see how we could have a better readability !
 

Ada is good at the nity gritty stuff. The above shows the value of attributes
that comes with the language, and being able to use subranges. Neither 
of which is part of c/c++ nor java. But all these languages are much more
popular than Ada. go figure.

May be what we need is a new language, which has the good stuff
of Ada (strong typing, ranges, attributes, separation of interface and
implementation, generics, tasks, etc...), but with a more modern OO 
look and feel (as in Java), maybe even garbage collection thrown in 
(although I have mixed feeling on GC).  Delphi now comes the 
closest thing to this (it is sort of Ada like, but also has Java like 
classes in terms of syntax and feel to it).

Combine those togother and call it  Ada++ or better, jAda, and you will
have a real winner. 

Any language designer out there wants to take this on? 
 

Re: ada vs. cpp

[Marc A. Criley]

"MM@MM" wrote:
> 
> May be what we need is a new language, which has the good stuff
> of Ada (strong typing, ranges, attributes, separation of interface and
> implementation, generics, tasks, etc...), but with a more modern OO
> look and feel (as in Java), maybe even garbage collection thrown in
> (although I have mixed feeling on GC).  Delphi now comes the
> closest thing to this (it is sort of Ada like, but also has Java like
> classes in terms of syntax and feel to it).
> 
> Combine those togother and call it  Ada++ or better, jAda, and you will
> have a real winner.
> 
> Any language designer out there wants to take this on?
> 

I've occasionally toyed with the idea of recasting Ada's syntax into a
"C style", then having a preprocessor that simply and quietly converts
it back into Ada and compiles it.  Any error messages are trapped and
translated appropriately.

Call it Jade or something, and promote as the industrial-strength
successor to Java--full generics, enums, intrinsic concurrency, OO,
etc.  No one need ever know... :-)

Marc A. Criley

Re: ada vs. cpp

[James Rogers]

"MM@MM" wrote:
> 
> Ada is good at the nity gritty stuff. The above shows the value of attributes
> that comes with the language, and being able to use subranges. Neither
> of which is part of c/c++ nor java. But all these languages are much more
> popular than Ada. go figure.

You express a common assumption in your paragraph above. That assumption
is that most programmers have knowledge of Ada. 

My experience is quite the opposite of this assumption. I spend my days
teaching new skills to software professionals. Most of my students want
to learn Java for a number of reasons. Most frequently the reason is
that their jobs will require them to use Java in the near future, or
they need to know it NOW.

When I casually mention work I have done in Ada, the overwhelming
response is "I have never heard of that language."

My conclusion is that Ada is a stealth language. It is one of the
major languages in terms of usage, but the majority of software
developers have never even heard of it.

Nobody is going to choose a language they have never heard of.
At a minimum they must encounter some reference to it first.

The developments in recent years which have made Ada one of the
languages included in some Linux distributions is very good for
overall exposure to Ada.

I am also hopeful that Western countries will develop a stronger
cultural awareness to the possibilities of cyber terrorism.
Such an awareness is needed to protect all forms of government
and financial systems. When security becomes a primary concern
Ada will become a welcome tool to achieve more secure results.

Jim Rogers
Colorado Springs, Colorado USA

Re: ada vs. cpp

[Marin David Condic]

I don't think this would help. Most of the C++/Java guys don't specifically
hate Ada syntax nearly as much as they hate the strong typing and error
checking and other semantic features of Ada. They *want* a language that is
loose. I suppose you could give them a language that is "loose" using Ada
syntax, but then why bother? It wouldn't be Ada anymore. (They'd still
object to its wordiness - you'd be better off developing a language where
every non-alpha character represented some operation or language feature.
:-)

As for GC - I'd rather leave that implementation defined. Ada would lose a
lot of usefulness in embedded/realtime work if it was mandatory that GC be
in it. As it stands, an implementation *could* provide GC if there was a
demand for it. So far, most users aren't screaming for it.

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/


"MM@MM" <MM_member@newsguy.com> wrote in message
news:9pmpk00a53@drn.newsguy.com...
>
> May be what we need is a new language, which has the good stuff
> of Ada (strong typing, ranges, attributes, separation of interface and
> implementation, generics, tasks, etc...), but with a more modern OO
> look and feel (as in Java), maybe even garbage collection thrown in
> (although I have mixed feeling on GC).  Delphi now comes the
> closest thing to this (it is sort of Ada like, but also has Java like
> classes in terms of syntax and feel to it).
>

Re: ada vs. cpp

[James Rogers]

Marin David Condic wrote:
> 
> I don't think this would help. Most of the C++/Java guys don't specifically
> hate Ada syntax nearly as much as they hate the strong typing and error
> checking and other semantic features of Ada. They *want* a language that is
> loose. I suppose you could give them a language that is "loose" using Ada
> syntax, but then why bother? It wouldn't be Ada anymore. (They'd still
> object to its wordiness - you'd be better off developing a language where
> every non-alpha character represented some operation or language feature.
> :-)

There seem to be at least two camps in the C++ community.
comp.lang.c++.moderated has a long thread discussing "Safe C++".
The overall idea from most proponents is the addition of array bounds
checking and numeric range checking.

The moderators have had enough references to Ada in this thread.
If you want to mention Ada, you must also include significant C++
content.

Some related discussions have been occuring in another thread
"Is C++ too complicated?". The most recent topic discussed in this
thread is whether or not C++ would benefit from the development of a
reference implementation. This topic was inspired by input from some
Ada people.

> As for GC - I'd rather leave that implementation defined. Ada would lose a
> lot of usefulness in embedded/realtime work if it was mandatory that GC be
> in it. As it stands, an implementation *could* provide GC if there was a
> demand for it. So far, most users aren't screaming for it.
> 

I would, however, like to see some publicly available GC
implementations for Ada.

Jim Rogers
Colorado Springs, Colorado USA

Re: ada vs. cpp

[Marin David Condic]

It would be interesting to see *some* implementations that provided garbage
collection. If for no other reason than to be able to compare overhead for
programs/algorithms with/without GC. I think we are in agreement that it
should not be made mandatory by the language standard.

I believe I recall posts from language vendors whenever the issue of GC
comes up to the efect that while there appears to be some casual interest in
GC, nobody seems to want it so bad that it gets moved to the top of their
priority lists. Maybe people want it more as an intellectual curiosity, but
it appears it isn't essential for getting most jobs done.

Do you think there might be some body of potential Ada users out there who
would be enticed to use Ada if it had an implementation with garbage
collection? Just wondering if there might be some unexplored demand out
there...

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/


"James Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
news:3BC30621.BDF74138@worldnet.att.net...
> Marin David Condic wrote:
> > As for GC - I'd rather leave that implementation defined. Ada would lose
a
> > lot of usefulness in embedded/realtime work if it was mandatory that GC
be
> > in it. As it stands, an implementation *could* provide GC if there was a
> > demand for it. So far, most users aren't screaming for it.
> >
>
> I would, however, like to see some publicly available GC
> implementations for Ada.
>

Re: ada vs. cpp

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

> It would be interesting to see *some* implementations that provided garbage
> collection. If for no other reason than to be able to compare overhead for
> programs/algorithms with/without GC. I think we are in agreement that it
> should not be made mandatory by the language standard.
>...

> Do you think there might be some body of potential Ada users out there who
> would be enticed to use Ada if it had an implementation with garbage
> collection? Just wondering if there might be some unexplored demand out
> there...
> 
> MDC

There is/was a whole community of small businesses that ran on a form
of "business BASIC". Micos BASIC and UNIX hosted "BASIX" comes to mind.
While these are inferior languages for today's business programming,
they served a real need -- that is, provided small business with simple
to use/program "environments" in order to host database and business related
processes in.

I would dearly love to see an Ada based solution along this line, which
not only included garbage collection, but also included easy to
read/program database and GUI.  I know the right IDE can go a long way
towards this goal, but GC needs to be there, IMO. I also think that an
interpreted Ada "subsystem" might better match a small business (or SOHO)
situation.

So I would think in the business/SOHO case (where Java is being tried
these days), GC makes a lot of sense. Ada already supports sensible
treatment for pointers, and GC just makes life that much easier
for those that are only concerned about accounts, and not rocket
science.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: ada vs. cpp

[Robert*]

In article <3BC30621.BDF74138@worldnet.att.net>, James says...
>
 
>I would, however, like to see some publicly available GC
>implementations for Ada.
 
Unless all Ada implementations provide GC (as an option), you will have
broken Ada.

Why?

Becuase if I write an Ada program on a GC enabled compiler/run-time, and later
on
take the code and build on another Ada compiler/run-time which does not 
support GC, then my program will not work (opps, forgot to free my own
memory, But I though the run-time will do it for me?)

THis makes Ada source code much less portable across Ada systems.

Re: ada vs. cpp

[James Rogers]

"Robert*@" wrote:
> 
> In article <3BC30621.BDF74138@worldnet.att.net>, James says...
> >
> 
> >I would, however, like to see some publicly available GC
> >implementations for Ada.
> 
> Unless all Ada implementations provide GC (as an option), you will have
> broken Ada.
> 
> Why?
> 
> Becuase if I write an Ada program on a GC enabled compiler/run-time, and later
> on
> take the code and build on another Ada compiler/run-time which does not
> support GC, then my program will not work (opps, forgot to free my own
> memory, But I though the run-time will do it for me?)
> 
> THis makes Ada source code much less portable across Ada systems.

Not necessarily. If the GC is defined in its own package, then all
packages requiring GC will have to state a dependency upon that
package.

This is no different than using any other package with non-standard
dependencies.

Jim Rogers
Colorado Springs, Colorado USA

Re: ada vs. cpp

[David Botton]

If you are looking to support the GC through external packages then much GC
can be done already using Storage Pools.

See an example of this at http://www.adapower.com/lang

David Botton

----- Original Message -----
From: "James Rogers" <jimmaureenrogers@worldnet.att.net>
> Not necessarily. If the GC is defined in its own package, then all
> packages requiring GC will have to state a dependency upon that
> package.

Re: ada vs. cpp

[Robert*]

In article <9puvdc$225$1@nh.pace.co.uk>, "Marin says...
 
>They *want* a language that is loose. 

can GNAT implement a pragma

pragma LOOSE_MODE_START

?

this will solve all of Ada popularity problems. Maybe even C programmers
will use it then with such a pragma in place?

:)







 

Re: ada vs. cpp

[Wes Groleau]

> pragma LOOSE_MODE_START
> ?
> 
> this will solve all of Ada popularity problems. Maybe even C programmers
> will use it then with such a pragma in place?

Naah - the pragma is too verbose.

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

Re: ada vs. cpp

[Marin David Condic]

Maybe the syntax needs to be:

*&%{}":{><}^(^*&^)^ ((&(*&^) ;

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/


"Wes Groleau" <wwgrol@sparc01.ftw.rsc.raytheon.com> wrote in message
news:3BC31532.8CB51290@sparc01.ftw.rsc.raytheon.com...
>
> Naah - the pragma is too verbose.
>

Re: ada vs. cpp

[James Rogers]

Marin David Condic wrote:
> 
> Maybe the syntax needs to be:
> 
> *&%{}":{><}^(^*&^)^ ((&(*&^) ;
> 

Nah, that's the statement you make while trying to debug your program.

Jim Rogers
Colorado Springs, Colorado USA

Re: ada vs. cpp

[James Rogers]

"Robert*@" wrote:
> 
> In article <9puvdc$225$1@nh.pace.co.uk>, "Marin says...
> 
> >They *want* a language that is loose.
> 
> can GNAT implement a pragma
> 
> pragma LOOSE_MODE_START
> 
> ?
> 
> this will solve all of Ada popularity problems. Maybe even C programmers
> will use it then with such a pragma in place?

Why not simply use pragma Suppress(All_Checks) ?

That option does currently exist.

Jim Rogers
Colorado Springs, Colorado USA

Re: ada vs. cpp

[Lutz Donnerhacke]

* James Rogers wrote:
>Why not simply use pragma Suppress(All_Checks) ?
>That option does currently exist.

But the semantics for types needs to be changed.
So you also need "pragma" "Autoconvert" ["("<subtype> {"," <subtype>}")"] ";"

Re: ada vs. cpp

[Richard Riehle]

"Robert*@" wrote:

> can GNAT implement a pragma
>
> pragma LOOSE_MODE_START

Such a pragma is not necessary.   There are two main issues
that annoy people who are accustomed to more loosely formed
languages:  the type model, and the visibility model.   Both of
these can be easily suppressed if one wishes to do so.

The default for every Ada construct is "type safe."   The default
for visibility is "visibility safe."    One may start with a language,
such as Ada, in which the defaults are "safe" and relax those
defaults through a variety of mechanisms.   In fact, we can quite
easily relax those defaults to the point that Ada becomes as
precarious as standard C or C++.

On the other hand, it is more difficult to start with a language where
the defaults are "unsafe" and increase the safety.   Such is the predicament

of the C and C++ programmer.   However diligently they may strive to
improve the safety of their code, the underlying default, "unsafe",
continues
to bedevil them.   Unfortunately, many of these attempts to make
the code more safe produces exactly the opposite result.

So, if you want unsafe Ada code, simply be liberal with use clauses,
don't define new data types (use the types in package Standard), make
everything a subtype of something else, use 'unchecked_access everywhere,
along with lots of other tricks to make Ada more like C.  Not very hard,
actually.   Stupid, yes.  Difficult, no.

Richard Riehle

Re: ada vs. cpp

[Marin David Condic]

Yeah, but even if you use just the types in Standard, you still miss out on
all the behind-the-scenes implicit conversions and the ability to treat just
about anything as if it was just about anything else. You also aren't
required to grab pointers to everything in sight and do your own
determination about parameter passing modes and stuff like that. In short,
Ada isn't going to be a high-level assembler for you so there will always be
a crowd that doesn't like it because at heart they want to program in
assembler.

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/


"Richard Riehle" <richard@adaworks.com> wrote in message
news:3BC3DA0A.267D4302@adaworks.com...
>
> So, if you want unsafe Ada code, simply be liberal with use clauses,
> don't define new data types (use the types in package Standard), make
> everything a subtype of something else, use 'unchecked_access everywhere,
> along with lots of other tricks to make Ada more like C.  Not very hard,
> actually.   Stupid, yes.  Difficult, no.
>

Re: ada vs. cpp

[Wes Groleau]

Richard Riehle wrote:
> So, if you want unsafe Ada code, simply be liberal with use clauses,
> don't define new data types (use the types in package Standard), make
> everything a subtype of something else, use 'unchecked_access everywhere,

Why bother with a subtype if you're going to suppress range checks?

> along with lots of other tricks to make Ada more like C.  Not very hard,
> actually.   Stupid, yes.  Difficult, no.

At least one thing is still missing: Automatic conversions between
Integer, Float, Character, Address, access, and Boolean.

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

Re: ada vs. cpp

[David Thompson]

Wes Groleau <wwgrol@sparc01.ftw.rsc.raytheon.com> wrote :
> Richard Riehle wrote:
...
> > along with lots of other tricks to make Ada more like C.  ...
>
> At least one thing is still missing: Automatic conversions between
> Integer, Float, Character, Address, access, and Boolean.
>
There are no implicit conversions between pointer types
and arithmetic types in (standard) C, nor in C++ for the
same (C-equivalent) types.  They require a cast, and are
(at best) implementation-defined.  (For a user-written
numeric class in C++, of course you can and must
write whatever conversion operators you want.)

The only exception is the integer constant zero,
or only in C constant zero cast to pointer-to-void,
which is/are used to mean the null/nil pointer value.
Technically this is not a conversion, just a kludgy
special case left over from BCPL/B and "paleolithic"
(pre-K&R1) C where pointers truly were just integers.

The rest of your list -- arithmetic types (which in C and C++
includes char and wchar_t) and boolean -- stands.  Plus
enumerations in C, but only from not to them in C++.

--
- David.Thompson 1 now at worldnet.att.net

Re: ada vs. cpp

[Wes Groleau]

David Thompson wrote:
> There are no implicit conversions between pointer types
> and arithmetic types in (standard) C, nor in C++ for the

True.  But there is pointer [+*-] number, which is
nearly the same thing.

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

Re: ada vs. cpp

[Ole-Hjalmar Kristensen]

Wes Groleau <wwgrol@sparc01.ftw.rsc.raytheon.com> writes:

> David Thompson wrote:
> > There are no implicit conversions between pointer types
> > and arithmetic types in (standard) C, nor in C++ for the
> 
> True.  But there is pointer [+*-] number, which is
> nearly the same thing.
> 
> -- 
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau

Not really. Pointer artihmetic in C is very closely related to array
indexing, and just as (un)safe. In fact the following always holds:

some_array[i] == *(some_array +i) == i[some_array]
Both array expressions are implicitly converted to the pointer
arihmetic expression. 

In fact, the following expression is completely legal, but perhaps
strange C:

17[some_array] = x;

-- 
Kabelsalat ist gesund.

Ole-Hj. Kristensen

Re: ada vs. cpp

[Richard Riehle]

David Thompson wrote:

> Wes Groleau <wwgrol@sparc01.ftw.rsc.raytheon.com> wrote :
> > Richard Riehle wrote:
> ...
> > > along with lots of other tricks to make Ada more like C.  ...
> >
> > At least one thing is still missing: Automatic conversions between
> > Integer, Float, Character, Address, access, and Boolean.
> >
> There are no implicit conversions ...

I should have been more precise and referred to type promotions.

Richard Riehle

Re: ada vs. cpp

[Ole-Hjalmar Kristensen]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> I don't think this would help. Most of the C++/Java guys don't specifically
> hate Ada syntax nearly as much as they hate the strong typing and error
> checking and other semantic features of Ada. They *want* a language that is
> loose. I suppose you could give them a language that is "loose" using Ada
> syntax, but then why bother? It wouldn't be Ada anymore. (They'd still
> object to its wordiness - you'd be better off developing a language where
> every non-alpha character represented some operation or language feature.
> :-)
> 
> As for GC - I'd rather leave that implementation defined. Ada would lose a
> lot of usefulness in embedded/realtime work if it was mandatory that GC be
> in it. As it stands, an implementation *could* provide GC if there was a
> demand for it. So far, most users aren't screaming for it.
> 

I think it should be mandatory in the implementation, but not
mandatory to use. The problem with implementation defined GC is that
you cannot write portable software if you rely on it. I like the
approach taken by Modula-3, where a reference type can be either
traced or untraced in the same program. I cannot see anything in this
approach that would make it impossible to leave out the GC code from
the executable if no traced reference types were used, so there would
be no penalty for having GC in the language if you didn't want to use
it.

Personally, I would not like GC in something even like our soft real
time DBMS kernel(NOT written in Ada, btw), but for things like the
backup/restore server or DB applications it would surely simplify the
programming.


> 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/
> 
> 
> "MM@MM" <MM_member@newsguy.com> wrote in message
> news:9pmpk00a53@drn.newsguy.com...
> >
> > May be what we need is a new language, which has the good stuff
> > of Ada (strong typing, ranges, attributes, separation of interface and
> > implementation, generics, tasks, etc...), but with a more modern OO
> > look and feel (as in Java), maybe even garbage collection thrown in
> > (although I have mixed feeling on GC).  Delphi now comes the
> > closest thing to this (it is sort of Ada like, but also has Java like
> > classes in terms of syntax and feel to it).
> >
> 
> 
> 

-- 
Kabelsalat ist gesund.

Ole-Hj. Kristensen

Re: ada vs. cpp

[Simon Wright]

James Rogers <jimmaureenrogers@worldnet.att.net> writes:

> Why not simply use pragma Suppress(All_Checks) ?

But doesn't that only suppress runtime checks? I thought the main
complaint was much earlier in the lifecycle.

  X : Integer := Integer ("hello world");

Re: ada vs. cpp

[Frode Tennebø]

On Saturday 06 October 2001 11:15 Pascal Obry wrote:

[snip]

>         V2 : constant String := V1 (Arg) & '-' & V1 (Code);
> 
> This is not theory, I have used these kinds of code many many times.
> And again I don't see how we could have a better readability !

V2 : constant String := "zzz-0123"; 

? ;-)

 -Frode
-- 
^ Frode Tenneb� | email: frode@tennebo.com | Frode@IRC ^
|  with Standard.Disclaimer; use Standard.Disclaimer;  |

Re: ada vs. cpp

[mike]

In article <851op9.a05.ln@leia>, Frode says...
>

>On Saturday 06 October 2001 11:15 Pascal Obry wrote:
>
>[snip]
>
>>         V2 : constant String := V1 (Arg) & '-' & V1 (Code);
>> 
>> This is not theory, I have used these kinds of code many many times.
>> And again I don't see how we could have a better readability !
>
>V2 : constant String := "zzz-0123"; 
>
>? ;-)
>
 
You are missing the whole point.

Re: ada vs. cpp

[Pascal Obry]

mike@nospam <mike_member@newsguy.com> writes:

> In article <851op9.a05.ln@leia>, Frode says...
> >
> 
> >On Saturday 06 October 2001 11:15 Pascal Obry wrote:
> >
> >[snip]
> >
> >>         V2 : constant String := V1 (Arg) & '-' & V1 (Code);
> >> 
> >> This is not theory, I have used these kinds of code many many times.
> >> And again I don't see how we could have a better readability !
> >
> >V2 : constant String := "zzz-0123"; 
> >
> >? ;-)
> >
>  
> You are missing the whole point.

Well I think it was a joke... there was a smiley...

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 vs. cpp

[Mike Mohr]

"Pascal Obry" <p.obry@wanadoo.fr> wrote in message
news:u8zepgmea.fsf@wanadoo.fr...
>
> "Mike Mohr" <nospam@nowhere.com> writes:
>
> > C++ has a string class.
>
> I know.

I doubt you did because you had indicated otherwise.

>Yet in C/C++ it is hard to beat
>
>         V1 : constant String := "1234567890";
>         V2 : constant String := "AAA" & V1 (3 .. V1'Last - 2) & "BBB";
>
> in readability and ease of use.

const string V1 = "0123456789";
const string V2 = "AAA" + V1.substr(3, V1.size() - 2) + "BBB";

The indices may be off because I am not too familiar with Ada
but as you can see, the C++ version mirrors the Ada version
pretty closely.

>
> I have done many text processing code in both C/C++ and Ada and from
> experience I found the Ada code far more readable. There is may examples.

Of course you do (find Ada more readable), you are an Ada programmer.

I doubt that this

V1 (3 .. V1'Last - 2)

is intuitive or readable to non-Ada programmers.

>
> Another one that come to mind:
>
>         V1 : constant String := "0123/zzz";
>
>         subtype Code is Positive range 1 .. 4;
>         subtype Arg  is Positive range 6 .. 8;
>
>         V2 : constant String := V1 (Arg) & '-' & V1 (Code);
>
> This is not theory, I have used these kinds of code many many times. And
again
> I don't see how we could have a better readability !

const string V1 = "0123/zzz";
const string V2 = V1.substr(0, 4) + "-" + V1.substr(5,7);

Even though your efforts to describe something easy for Ada
and hard for C++ have failed, you should know that I can play
these C++-strings-can-do-this-in-2-lines-and-Ada-can't
games as well.

Isolated examples which measure LOC are not a basis
to claim that Ada strings are superior to C++ strings or
that C++ strings are superior to Ada strings, or Java
Strings etc...

Completely unrelated issue; does anyone know
the cost of ObjectAda for windows?

I have the free download version and I like it.

>
> 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 vs. cpp

[Mike Mohr]

I have just noticed in my attempt to mirror your second example
of readable Ada I missed the fact that you swapped the
position of the front and back of the source string, to get
the correct result do this.

const string V2 = V1.substr(5, 7) + "-" + V1.substr(0,4);

Re: ada vs. cpp

[Robert*]

In article <d7jw7.172545$w7.26206237@news02.optonline.net>, "Mike says...
>
 

>>
>>         subtype Code is Positive range 1 .. 4;
>>         subtype Arg  is Positive range 6 .. 8;
>>
>>         V2 : constant String := V1 (Arg) & '-' & V1 (Code);
 
>const string V1 = "0123/zzz";
>const string V2 = V1.substr(0, 4) + "-" + V1.substr(5,7);
>
>Even though your efforts to describe something easy for Ada
>and hard for C++ have failed, you should know that I can play
>these C++-strings-can-do-this-in-2-lines-and-Ada-can't
>games as well.
>
 
The difference is that in Ada the range itself is a separate type declaration.
So, one can change the range type in one place and have it propgate all
over. With your attempt, you hardcoded the range using magic numbers in
the variable declaration itself, so if the same range is to be used 
somewhere else in the code, or in different variable declaration, you 
need to type it there too manually. 


There is nothing equivelant in C++ to declaring a new type integer 
with restricted range. It is simply not in the C++ language.

Re: ada vs. cpp

[Mike Mohr]

"Robert*@" <Robert_member@newsguy.com> wrote in message
news:9pski60j31@drn.newsguy.com...
> In article <d7jw7.172545$w7.26206237@news02.optonline.net>, "Mike says...
> >
>
>
> >>
> >>         subtype Code is Positive range 1 .. 4;
> >>         subtype Arg  is Positive range 6 .. 8;
> >>
> >>         V2 : constant String := V1 (Arg) & '-' & V1 (Code);
>
> >const string V1 = "0123/zzz";
> >const string V2 = V1.substr(0, 4) + "-" + V1.substr(5,7);
> >
> >Even though your efforts to describe something easy for Ada
> >and hard for C++ have failed, you should know that I can play
> >these C++-strings-can-do-this-in-2-lines-and-Ada-can't
> >games as well.
> >
>
> The difference is that in Ada the range itself is a separate type
declaration.
> So, one can change the range type in one place and have it propgate all
> over. With your attempt, you hardcoded the range using magic numbers in
> the variable declaration itself, so if the same range is to be used
> somewhere else in the code, or in different variable declaration, you
> need to type it there too manually.

struct range {
    int first;
    int last;
  };

range code  = { 0, 4 };
range arg = { 5, 7 };

const string V2 = V1.substr(code.first, code.last) + "-" +
V1.substr(arg.first,srg.last);

> There is nothing equivelant in C++ to declaring a new type integer
> with restricted range. It is simply not in the C++ language.

I have shown you I can get the same functionality
without breaking a sweat.

What kind of support for string transformations does Ada have?

How does it stack up against <algorithms>?

random_shuffle(), next_permutation(), rotate(), etc...

If you want to play my-language-can-do-this-in-1-line-and-yours-cant
games, I'll be happy to oblige.

Since we are discussing orthogonal language features
which constitute string defects if not present, how
do I explicitly pass Ada strings by value or reference?

Re: ada vs. cpp

[Robert*]

In article <dFlw7.173483$w7.26404906@news02.optonline.net>, "Mike says...
>
 
>
>> There is nothing equivelant in C++ to declaring a new type integer
>> with restricted range. It is simply not in the C++ language.
>

>I have shown you I can get the same functionality
>without breaking a sweat.
 
You did not even come close.

In ada, when you declare a type of a restricted range, the compiler and run-time
will check that variables of such type can have values in that range only.

There is no such thing in C++ (nor in Java for that matter). Unless you 
code it yourself for every case and condition to do what the Ada compiler
and run-time allready does automatically.

Re: ada vs. cpp

[Mike Mohr]

"Robert*@" <Robert_member@newsguy.com> wrote in message
news:9psrqv016j9@drn.newsguy.com...
> In article <dFlw7.173483$w7.26404906@news02.optonline.net>, "Mike says...
> >
>
> >
> >> There is nothing equivelant in C++ to declaring a new type integer
> >> with restricted range. It is simply not in the C++ language.
> >

Your original reply didn't say anything about type checking,
your original reply objected to the fact that the ranges were
hardcoded so I responded with that in mind.

I fixed the exact problem you cited.

  "The difference is that in Ada the range itself is a separate type
declaration.
   So, one can change the range type in one place and have it propgate all
   over. With your attempt, you hardcoded the range using magic numbers in
   the variable declaration itself, so if the same range is to be used
   somewhere else in the code, or in different variable declaration, you
   need to type it there too manually."

In my response, I have shown how to "change the range in one place
and have it propagate all over." yet in the popular style of this newsgroup
you have added additional requirements to the problem only after I
have presented a complete answer to the original problem :)

> In ada, when you declare a type of a restricted range, the compiler and
run-time
> will check that variables of such type can have values in that range only.
>

      subtype Code is Positive range 1 .. 4;
      subtype Arg  is Positive range 6 .. 8;

      V2 : constant String := V1 (Arg) & '-' & V1 (Code);

By all accounts I am a new Ada programmer, so I am a little confused
by the syntax.  It isn't clear to me how Code, and Arg function in the
expression.

Do strings effectively have a ( ) operator which takes a range as an
argument?

I read V1 (Arg) as V1.substring(Arg) in pseudo code.

Arg seems to be a value rather than a type.
Is range effectively a parameterized type?

Perhaps this is wrong, if so please show me what is
really happening.  If my guess is accurate please show
me how static/dynamic checking would be done in the
first (Ada) case.  What I want is a description or
examples of those cases which would raise an error.

You also point out that

"There is nothing equivelant in C++ to declaring a new
type integer with restricted range"

I understand your point, yet it isn't clear to me in the
original example, what specifically is an integer.

Re: ada vs. cpp

[Wes Groleau]

Mike Mohr wrote:
> and have it propagate all over." yet in the popular style of this newsgroup
> you have added additional requirements to the problem only after I
> have presented a complete answer to the original problem :)

Correction -- the standard working conditions for programmers
(not the popular style of this newsgroup) is incomplete statement
of requirements.

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

RE: ada vs. cpp

[Steven Deller]

> -----Original Message-----
> From: comp.lang.ada-admin@ada.eu.org
> [mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Mike Mohr
> ...
> By all accounts I am a new Ada programmer, so I am a little confused
> by the syntax.  It isn't clear to me how Code, and Arg function in the
> expression.
>
> Do strings effectively have a ( ) operator which takes a range as an
> argument?
>
> I read V1 (Arg) as V1.substring(Arg) in pseudo code.
>
> Arg seems to be a value rather than a type.
> Is range effectively a parameterized type?

The range constraints of Arg have values.  Arg is a subtype.

When referring to an array:

The form
  Array_Name(X)
  -- where X is an object whose type matches the array's index type
means element X of Array_Name.

The form
  Array_Name(X..Y) ;
  -- where X and Y are objects and
  -- their types match that of the array's index type
means the elements of Array_Name starting with X and ending with Y.

This is called array slicing.

The form
  Array_Name(Subtype) ;
  -- where Subtype is a subtype of the array's index type
means the elements of the array bounded by the Subtype range.

Another way to express array slicing.

>From the Ada Reference Manual 3.6.1 Index Constraints and Discrete Ranges
(2)
       index_constraint ::=  (discrete_range {, discrete_range})
(3)
       discrete_range ::= discrete_subtype_indication | range

The way I look at it is that when indexing an array,
  subtype_name
is a shorthand for
  subtype_name'range

Not everyone would agree with how I look at it :-).

> Perhaps this is wrong, if so please show me what is
> really happening.  If my guess is accurate please show
> me how static/dynamic checking would be done in the
> first (Ada) case.  What I want is a description or
> examples of those cases which would raise an error.
>
> You also point out that
>
> "There is nothing equivalent in C++ to declaring a new
> type integer with restricted range"
>
> I understand your point, yet it isn't clear to me in the
> original example, what specifically is an integer.

The integer comes in by the definition within Standard of a "string":

 -- Declarations from "Standard" -- always "part" of a unit
 subtype Positive is Integer range 1 .. Integer'Last;
 type String is array(Positive range <>) of Character;

An example that will raise a constraint_error is:

 -- Application code
 V1 : constant string := "abcdefghij" ; -- Has range 1..10 per ARM
 subtype Code is Positive range 1 .. 4 ;
 subtype Arg  is Positive range 6 .. 8 ;
 V2 : constant String := V1 (Arg) & '-' & V1 (Code);
 -- No problem, ranges are within 1..10
 subtype Bad is Positive range 4 .. 11 ;
 V3 : constant String := V1(Bad) ;
 -- Raises constraint error because 11 is outside 1..10

This is contrived and will always raise a constraint_error.  But if V1 were
read in at run-time, then its length would vary, with the possibility that
if the entry was too short, then the creation of V3 would raise a
constraint_error, but not if it was long enough (run-time checking).

Regards,
Steve
"Then, after a second or so, nothing continued to happen."
Steven Deller        Smooth Sailing LLC
410 757 6924         deller@smsail.com

Re: ada vs. cpp

[Pascal Obry]

"Mike Mohr" <nospam@nowhere.com> writes:

>       subtype Code is Positive range 1 .. 4;
>       subtype Arg  is Positive range 6 .. 8;
> 
>       V2 : constant String := V1 (Arg) & '-' & V1 (Code);
> 
> By all accounts I am a new Ada programmer, so I am a little confused
> by the syntax.  It isn't clear to me how Code, and Arg function in the
> expression.
> 
> Do strings effectively have a ( ) operator which takes a range as an
> argument?

Not an operator. For every string you can take a slice with a range,
for example with:

        S  : constant String := "1234567890";

This
        S (2 .. 4)

will get the slice starting a position 2 and ending at position 1. In the case
above S'First (first index) is 1 and S'Last (last index) is 10.

        S (2 .. 4) is the string "234".

The same can be achieve with a subtype having a specific range. The same slice
can be coded:
        
        subtype Card_ID is Positive range 2 .. 4;

        S (Card_ID)

This case is more readable in many cases because you have named the range.

What is nice when using subtype is that the range checks can be removed by the
compiler in some cases. For example, with the definitions:

   subtype Ref_Range is Positive range 1 .. 10;

   type Ref is new String (Ref_Range);

   subtype Ref_Code is Ref_Range range 2 .. 5;

No need to check for constraint error here:

   R (Ref_Code)

as Ref_Code is known to be in the range of Ref_Range!

> I read V1 (Arg) as V1.substring(Arg) in pseudo code.
> 
> Arg seems to be a value rather than a type.

Arg is a type (subtype). In this example the range of this subtype is used.

Hope this is clear.

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 vs. cpp

[James Rogers]

Mike Mohr wrote:
> 
> Since we are discussing orthogonal language features
> which constitute string defects if not present, how
> do I explicitly pass Ada strings by value or reference?

Why do you care if it is by value or by reference? Is it not more
important to ensure that is passed as a constant or non-constant
value? 

Giving the explicit capacity to pass by value or reference requires
you to know the underlying architecture and word size. For 
instance, passing by reference may not be more efficient than a
two-way copy of items that can fit in a word. Ada places the
responsibility for this knowledge on the compiler vendor and not on
the application programmer. Use of such knowledge may make your
program less portable. Use of the Ada approach does not sacrifice
portability.

Jim Rogers
Colorado Springs, Colorado USA

Re: ada vs. cpp

[Pascal Obry]

"Mike Mohr" <nospam@nowhere.com> writes:

> If you want to play my-language-can-do-this-in-1-line-and-yours-cant
> games, I'll be happy to oblige.

pragma Remote_Call_Interface;

:)

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 vs. cpp

[Ted Dennison]

In article <dFlw7.173483$w7.26404906@news02.optonline.net>, Mike Mohr says...
>
>Since we are discussing orthogonal language features
>which constitute string defects if not present, how
>do I explicitly pass Ada strings by value or reference?

Since its fairly easy for the compiler to figure out which will be more
efficient at compile time (which is what Ada does), the only reason you would
need for doing this would be if you want to do it *less* efficiently. Odly,
noone has really found that need that I have heard of. :-)

Well, there is one other use: in interfacing to external routines. That's where
Ada's interface support comes in.

I'm curious how you think you do this in C++ though. An array of chars is
essentially a pointer, and thus will always get passed by reference no matter
what you do. "string" is an opaque type defined in the STL almost certianly
using pointers, and is thus in the same boat. So how do you force value?

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

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: ada vs. cpp

[Mike Mohr]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:KZEw7.21653$ev2.29994@www.newsranger.com...
> In article <dFlw7.173483$w7.26404906@news02.optonline.net>, Mike Mohr
says...
> >
> >Since we are discussing orthogonal language features
> >which constitute string defects if not present, how
> >do I explicitly pass Ada strings by value or reference?
>
> Since its fairly easy for the compiler to figure out which will be more
> efficient at compile time (which is what Ada does), the only reason you
would
> need for doing this would be if you want to do it *less* efficiently.
Odly,
> noone has really found that need that I have heard of. :-)

I don't believe Ada needs a specific pass-by-value or pass-by-reference
mechanism, and I don't think C++ strings a better than Ada strings.
I was just playing along ;)

It isn't strictly necessary for a C++ programmer to have
the identical facilities available to an Ada programmer to
complete a task.  My examples showed this (yet challenges
continue :).

I would rather see high level comparison between implementations
which make heavy use of string operations.  Then one could get
an idea of how complex, how readible, and how efficient each
version is.

Speaking of high level comparisons, I would really like to
see how Ada does in the great language shootout.

http://www.bagley.org/~doug/shootout/

I don't have the skill level in Ada to do it
justice but perhaps someone in this newsgroup
can give it a try.

> Well, there is one other use: in interfacing to external routines. That's
where
> Ada's interface support comes in.
>
> I'm curious how you think you do this in C++ though. An array of chars is
> essentially a pointer, and thus will always get passed by reference no
matter
> what you do. "string" is an opaque type defined in the STL almost
certianly
> using pointers, and is thus in the same boat. So how do you force value?

That is an interesting question.

Typically, in C++ copy by value is done on an any invocation of the copy
constructor.

One could argue that reference counted implementations (or COW) may
not do actual copies, despite the fact that a copy constructor is invoked.
In such cases copy by value is only deferred until the point that a
condition arises which forces a write, given the value semantics
originally specified.

For example in this call

function(V1);

void function(string arg);
{
    arg[4] = 'a';
    cout << arg;
}

A value copy of V1 must be made, the only thing that is
indeterminate is at what point that copy occurs.

It is a peculiar footnote that the allowance for COW
string implementations in C++ led to a subtle bug
in the language specification which led to a call
by some to ban the mad cow :)

Since C++ operates on an abstract machine any non-detectable
behavior may be elided and I will venture to guess that the same
is true for Ada.  This kind of language implementation transparency
is common but it does not invalidate the semantics of commands
or their value when used in ordinary programs.

Re: ada vs. cpp

[Ted Dennison]

In article <WzGw7.186001$w7.28407353@news02.optonline.net>, Mike Mohr says...
>I don't believe Ada needs a specific pass-by-value or pass-by-reference
>mechanism, and I don't think C++ strings a better than Ada strings.
>I was just playing along ;)

Ahh, sorry. I missed the tounge-in-cheek. My bad.

>It isn't strictly necessary for a C++ programmer to have
>the identical facilities available to an Ada programmer to
>complete a task.  My examples showed this (yet challenges
>continue :).

I'm actually with you on that. C++'s problems are, for the most part, not in
lack of capability.

>Speaking of high level comparisons, I would really like to
>see how Ada does in the great language shootout.
>
>http://www.bagley.org/~doug/shootout/

Considering that he's mostly interested in execution time and memory usage, the
numbers are totally bogus. That issue's come up here several times. If I compile
the "same algorithm" with compiler X and compiler Y, and X is faster, then all
that tells you is that compiler X makes faster executables for this problem than
Y does. It *doesn't* tell you that the language X compiles is somehow inherently
faster than Y's language. Most likely, I could pick compilers W and Z that would
reverse your results language results.

I also find in odd that he refuses to use optimization options. That will
produce atrocious code using gcc (no matter what the front-end).


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

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: ada vs. cpp

[Ted Dennison]

In article <u8zepgmea.fsf@wanadoo.fr>, Pascal Obry says...
>
>
>"Mike Mohr" <nospam@nowhere.com> writes:
>
>> C++ has a string class.
>
>I know. Yet in C/C++ it is hard to beat
>
>        V1 : constant String := "1234567890";
>        V2 : constant String := "AAA" & V1 (3 .. V1'Last - 2) & "BBB";
>
>in readability and ease of use.

In C++ that would be:

string V1 = "1234567890";
string V2 = "AAA" + V1.substr (2, V1.length() - 3) + "BBB";


It isn't better, but I don't really think its much worse either. The only real
problem is that we are working with stack objects in Ada, whereas the C++
version is almost certianly involving dynamic allocation and deallocation.

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

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: ada vs. cpp

[David Thompson]

Pascal Obry <p.obry@wanadoo.fr> wrote :
...
> Are you saying that C and C++ has support for strings ?
>
> I see there only pointers to a serie of bytes in memory terminated to '\0' !
> Is that a string definition ? :)
>
In C that is the support for (and definition of) strings, yes.
In C++ (here as in other areas) you still have the C features
but there is also the standard library class std::string
which is actually a specialization of basic_string for char,
and similarly std::wstring for wchar_t, which automatically
manage storage like Java String or Ada.Strings.Unbounded .

--
- David.Thompson 1 now at worldnet.att.net

Re: ada vs. cpp

[Ted Dennison]

In article <9pgr68$7pu1@news.cis.okstate.edu>, David Starner says...
>
>Strings aren't Ada's strength, but Ada isn't terribly weak in strings. I
>don't see any problem in parsing the input using Ada. 

Actually, if you don't mind using the Gnat-specific SNOBOL packages, Ada's
string support is right up there with any scripting language. Even without it,
it still beats C++.

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

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: ada vs. cpp

[Dmitry Kazakov]

On 4 Oct 2001 05:13:44 GMT, David Starner
<dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote:

>On Thu, 4 Oct 2001 01:08:42 -0400, Pi <pi3_1415926536@yahoo.ca> wrote:
>> Remember that Ada is at his very best if you give him few
>> input, billions of calculations on numbers and than few output.
>
>"her" very best. I guess it's very debatable, though . . .
>
>> You say that it's text-based.
>> Do you have to parse the text-input?
>> In this case I would consider using Perl[1] for the parsing
>> and than the actual treatement in Ada.
>> (Strings aren't Ada's strength)
>
>Strings aren't Ada's strength, but Ada isn't terribly weak in strings. I
>don't see any problem in parsing the input using Ada. 

Sorry, but Ada is one of rare languages which are able to manipulate
strings allocated on the stack. IMO strings are indeed one of Ada
strengths, especially if you need an efficient parsing code. [Usually
parsing does not require strings allocated on the heap. But I you
want, well, Ada has them too.]

In any case, as many have pointed, it is a bit ridiculous to compare
Ada's strings with C++ having no strings at all.

Regards,
Dmitry Kazakov

Re: ada vs. cpp

[David Starner]

On Fri, 05 Oct 2001 07:50:09 GMT, Dmitry Kazakov <dmitry@elros.cbb-automation.de> wrote:
> In any case, as many have pointed, it is a bit ridiculous to compare
> Ada's strings with C++ having no strings at all.

What's with Ada people going "they designed foo differently, so they
don't have foo at all"? C/C++ people can certainly input and process
string data, and that's what matters, not whether it's a null-terminated
array or a double-linked list of pointers to characters.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I saw a daemon stare into my face, and an angel touch my breast; each 
one softly calls my name . . . the daemon scares me less."
- "Disciple", Stuart Davis

Re: ada vs. cpp

[Ted Dennison]

In article <9pkco7$9qe1@news.cis.okstate.edu>, David Starner says...
>
>On Fri, 05 Oct 2001 07:50:09 GMT, Dmitry Kazakov <dmitry@elros.cbb-automation.de> wrote:
>> In any case, as many have pointed, it is a bit ridiculous to compare
>> Ada's strings with C++ having no strings at all.
>
>What's with Ada people going "they designed foo differently, so they
>don't have foo at all"? C/C++ people can certainly input and process
>string data, and that's what matters, not whether it's a null-terminated
>array or a double-linked list of pointers to characters.

Well, in Dmitry's defense, I'd certianly be willing to defend the statement that
Ada's string support is superior to C++'s. (In fact, I have defended it on
occasion). I think for *dynamic* string support its a wash. But for dealing with
fixed-size stack-based strings, Ada has it all over C++. Since this is generally
much faster than dealing with dynamic strings, this isn't an insignificant
point.

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

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: ada vs. cpp

[David Starner]

On Fri, 05 Oct 2001 15:34:18 GMT, Ted Dennison <dennison@telepath.com> wrote:
> In article <9pkco7$9qe1@news.cis.okstate.edu>, David Starner says...
>>
>>On Fri, 05 Oct 2001 07:50:09 GMT, Dmitry Kazakov <dmitry@elros.cbb-automation.de> wrote:
>>> In any case, as many have pointed, it is a bit ridiculous to compare
>>> Ada's strings with C++ having no strings at all.
>>
>>What's with Ada people going "they designed foo differently, so they
>>don't have foo at all"? C/C++ people can certainly input and process
>>string data, and that's what matters, not whether it's a null-terminated
>>array or a double-linked list of pointers to characters.
> 
> Well, in Dmitry's defense, I'd certianly be willing to defend the statement that
> Ada's string support is superior to C++'s. 

But that's not what he said. He said that C++ didn't have strings. And
whether or not you like the way C++ handles it, it does have strings.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I saw a daemon stare into my face, and an angel touch my breast; each 
one softly calls my name . . . the daemon scares me less."
- "Disciple", Stuart Davis

Re: ada vs. cpp

[Wes Groleau]

David Starner wrote:
> But that's not what he said. He said that C++ didn't have strings. And
> whether or not you like the way C++ handles it, it does have strings.

Matter of mismatching definitions.  C has what C defines as strings.
It does not have what many languages define as strings.

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

Re: ada vs. cpp

[James Rogers]

Wes Groleau wrote:
> 
> David Starner wrote:
> > But that's not what he said. He said that C++ didn't have strings. And
> > whether or not you like the way C++ handles it, it does have strings.
> 
> Matter of mismatching definitions.  C has what C defines as strings.
> It does not have what many languages define as strings.

Yes, and C++ has both the C string and an equivalent to the 
Ada.Strings.Unbounded.Unbounded_String, which is what many languages
use for strings.

It is just not appropriate to equate C and C++. Since the latest
standards for both there is less reason than ever to equate the
two languages. The so-called compatibility with C which C++ so
loudly claimed has been badly reduced by the fact that C produced
a new standard in 1999, after the C++ standard. C++ is very
much incompatible with many features in the current C standard.

Jim Rogers
Colorado Springs, Colorado USA

Re: ada vs. cpp

[Wes Groleau]

James Rogers wrote:
> It is just not appropriate to equate C and C++. Since the latest

Oops, I didn't mean to equate them.  Was was focusing on "string"
and didn't see the ++

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

Re: ada vs. cpp

[David Starner]

On Fri, 05 Oct 2001 13:54:35 -0500, Wes Groleau <wwgrol@sparc01.ftw.rsc.raytheon.com> wrote:
> 
> 
> David Starner wrote:
>> But that's not what he said. He said that C++ didn't have strings. And
>> whether or not you like the way C++ handles it, it does have strings.
> 
> Matter of mismatching definitions.  C has what C defines as strings.
> It does not have what many languages define as strings.


 From The Free On-line Dictionary of Computing (06 Jun 01) [foldoc]:

  string
  
     <programming> A sequence of {data} values, usually {bytes},
     which usually stand for {characters} (a "character string").
     [...]

I'm sure other definitions can be offered, but when they're offered
_here_ in order to say that C/C++ doesn't have strings, it just sounds
like language bigotry. C has string literals, and C has character arrays
that map to strings and a set of functions that treat them like strings.
For the programmer, C has strings, no matter what a computer science
theoretician might say. Honest evidence will get us a lot farther than
random slams at other languages.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I saw a daemon stare into my face, and an angel touch my breast; each 
one softly calls my name . . . the daemon scares me less."
- "Disciple", Stuart Davis

Re: ada vs. cpp

[Dmitry Kazakov]

On 5 Oct 2001 13:31:51 GMT, David Starner
<dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote:

>On Fri, 05 Oct 2001 07:50:09 GMT, Dmitry Kazakov <dmitry@elros.cbb-automation.de> wrote:
>> In any case, as many have pointed, it is a bit ridiculous to compare
>> Ada's strings with C++ having no strings at all.
>
>What's with Ada people going "they designed foo differently, so they
>don't have foo at all"? C/C++ people can certainly input and process
>string data, and that's what matters, not whether it's a null-terminated
>array or a double-linked list of pointers to characters.

This is true, but it does not mean that C++ has strings. We do can
process string data using Turing machine. What we can is not what we
have.

Yes, in C++ one may develop a string class, as well as an integer
class that checks overflows, and a fixed-point numeric class etc. It
is nice. Moreover it is a clear advantage to have as little predefined
types as possible. But, IFF those particular user-defined types could
be made as efficient as built-in ones and have the same application
area. Unfortunately this is not the case. There are lot of things you
cannot do if strings are user-defined. Inevitable heap use is only one
problem. Lack of compile time string constants is another. An
inability to have comprehensive string slices is a third one etc.

Regards,
Dmitry Kazakov

Re: ada vs. cpp

[David Starner]

On Mon, 08 Oct 2001 08:18:15 GMT, Dmitry Kazakov <dmitry@elros.cbb-automation.de> wrote:
> This is true, but it does not mean that C++ has strings. We do can
> process string data using Turing machine. What we can is not what we
> have.

Ada doesn't have integers. What does that say about Ada?

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I saw a daemon stare into my face, and an angel touch my breast; each 
one softly calls my name . . . the daemon scares me less."
- "Disciple", Stuart Davis

Re: ada vs. cpp

[Wes Groleau]

> Ada doesn't have integers. What does that say about Ada?

Is this a troll or genuine ignorance?

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

Re: ada vs. cpp

[David Starner]

On Tue, 09 Oct 2001 08:36:20 -0500, Wes Groleau <wwgrol@sparc01.ftw.rsc.raytheon.com> wrote:
> 
>> Ada doesn't have integers. What does that say about Ada?
> 
> Is this a troll or genuine ignorance?

The post to which I was responding claimed that C++ doesn't have
strings. By just as valid logic, Ada doesn't have integers; there are no
types (even library types) that can represent all of the integers.
Somehow, Ada people don't like the idea; it seems to be less than
conducive to communication.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I saw a daemon stare into my face, and an angel touch my breast; each 
one softly calls my name . . . the daemon scares me less."
- "Disciple", Stuart Davis

Re: ada vs. cpp

[Dmitry Kazakov]

On 9 Oct 2001 15:29:17 GMT, David Starner
<dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote:

>On Tue, 09 Oct 2001 08:36:20 -0500, Wes Groleau <wwgrol@sparc01.ftw.rsc.raytheon.com> wrote:
>> 
>>> Ada doesn't have integers. What does that say about Ada?
>> 
>> Is this a troll or genuine ignorance?
>
>The post to which I was responding claimed that C++ doesn't have
>strings. By just as valid logic, Ada doesn't have integers; there are no
>types (even library types) that can represent all of the integers.

1. If you mean that Ada has no type to represent the whole set of all
integers, yes it is true. [as well as it is for all other languages
designed for finite discrete machines]

2. If you mean that Ada does not have an integer type that acts like
C's unsigned int, then you are wrong. [see modular numeric types in
Ada, which are far more generic and comfortable than their limited
equivalents in C]

3. If you mean that Ada has no int-like numeric type with an undefined
reaction on overflows. Well, is an undefined behaviour good?

4. If your point is that a language *has* all types [all programs, all
whatsoever] one could develop using the language then well, all
languages are more or less equivalent. What is not equivalent is the
developing and maintenance costs [which possibly could  be interesting
for customers. Less interesting for them of course, is a kind of
perplexity a programmer might feel when he/she must to switch from Ada
to C++]

>Somehow, Ada people don't like the idea; it seems to be less than
>conducive to communication.

Regards,
Dmitry Kazakov

Re: ada vs. cpp

[Lutz Donnerhacke]

* Dmitry Kazakov wrote:
>1. If you mean that Ada has no type to represent the whole set of all
>integers, yes it is true. [as well as it is for all other languages
>designed for finite discrete machines]

man Haskell. (or any other lazy evaluation language with unlimited arithmetics)

>3. If you mean that Ada has no int-like numeric type with an undefined
>   reaction on overflows. Well, is an undefined behaviour good?

gnat without -gnato will produce erronous code. So we are close.

>4. If your point is that a language *has* all types [all programs, all
>   whatsoever] one could develop using the language then well, all
>   languages are more or less equivalent.

There is no equivalent for an oracle or true randomness.

OTOH C++ source is a type 0 language. Ada source a type 1 language. So they
are different.

Re: ada vs. cpp

[Robert*]

In article <slrn9s8bnv.11k.lutz@taranis.iks-jena.de>, lutz@iks-jena.de says...
>
 
>
>man Haskell. (or any other lazy evaluation language with unlimited arithmetics)
>

but you can implement this in a package. There is the BigNumber package in
Ada. Java has the BigInteger class where you can as big number as you
have memory and swap space. clearly any language has
to implement such a thing using something other than primitive types, so
what is the point of all of this? 

>>3. If you mean that Ada has no int-like numeric type with an undefined
>>   reaction on overflows. Well, is an undefined behaviour good?
>

>gnat without -gnato will produce erronous code. So we are close.
>

Ok, so use -gnato, add it to the makefile so you do not forget about it.
At least Ada tells one (when using a switch) about an overflow. Other
languages is silent about this and will refuse to tell the user, 
even if you put a gun to the compiler head.  (and people still use
C for doing floating point computation, go figure).

>OTOH C++ source is a type 0 language. Ada source a type 1 language. So they
>are different.
>

never heared of type 0 and type 1 languages, must be a new theory, but
I believe you. is it bad or good to be a type 1 vs type 0 language by the way?
which is better?

Re: ada vs. cpp

[Lutz Donnerhacke]

* Robert*@ wrote:
>In article <slrn9s8bnv.11k.lutz@taranis.iks-jena.de>, lutz@iks-jena.de says...
>>OTOH C++ source is a type 0 language. Ada source a type 1 language. So
>>they are different.
>
>never heared of type 0 and type 1 languages, must be a new theory,

Not really.

The word problem for type 2 languages can be solved by a finite automaton.
The word problem for type 1 languages can be solved by a finite automaton
with a unlimited stack.
The word problem for type 0 languages can be solved by a finite automaton
with two unlimited stacks (a tape).

RE: ada vs. cpp

[Steven Deller]

> -----Original Message-----
> From: comp.lang.ada-admin@ada.eu.org
> [mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Lutz Donnerhacke
> Sent: Wednesday, October 10, 2001 7:21 AM
> To: comp.lang.ada@ada.eu.org
> Subject: Re: ada vs. cpp
>
> * Dmitry Kazakov wrote:
> >1. If you mean that Ada has no type to represent the whole set of all
> >integers, yes it is true. [as well as it is for all other languages
> >designed for finite discrete machines]
>
> man Haskell. (or any other lazy evaluation language with
> unlimited arithmetics)

Of course that is limited by the machine memory, so it is unlimited, but not
infinite and thus doesn't cover all integers either.

Numerous unlimited arithmetic packages have been defined in Ada for
integers, for rational's and for floating point.  Any type derived from
those packages have the unlimited aspect you are looking for.  And they are
used "naturally", e.g.

  with unlimited_integers;
  use unlimited_integers ; -- I personally think this is justified for
arithmetic packages
  procedure test is
     a,b,c : unlimited_integer ;
  begin
     a := unlimited_integer(100);  -- a := 100; -- if mixed arith defined in
the package
     b := unlimited_integer(100);
     c := a**b ;  -- not your ordinary integer :-)
     a := c**c ;  -- likely to overflow machine memory :-(
  exception
     when storage_error =>
         -- code to handle machine limits
  end test ;

I also believe one could create a symbolic processing type, which just
collected operators without evaluation, and doing symbolic simplification
before assignments.  True lazy evaluation.  Hmmm -- might be interesting to
define, since there would have to be symbolic literals.

Regards,
Steve
"Then, after a second or so, nothing continued to happen."
Steven Deller        Smooth Sailing LLC
410 757 6924         deller@smsail.com

Re: ada vs. cpp

[Wes Groleau]

Steven Deller wrote:
> Numerous unlimited arithmetic packages have been defined in Ada for
> integers, for rational's and for floating point.  Any type derived from
> those packages have the unlimited aspect you are looking for.  And they are
> used "naturally", e.g.

If "naturally" means they can be used like regular integers, not quite.
No 'first 'last 'range etc. attributes
For "integers," can't use as indexes, case selectors, in for-loops

(then again, why would anyone _want_ to use an unlimited_integer for
these?)

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

Re: ada vs. cpp

[Lutz Donnerhacke]

* Steven Deller wrote:
>> * Dmitry Kazakov wrote:
>> >1. If you mean that Ada has no type to represent the whole set of all
>> >integers, yes it is true. [as well as it is for all other languages
>> >designed for finite discrete machines]
>>
>> man Haskell. (or any other lazy evaluation language with
>> unlimited arithmetics)
>
>Of course that is limited by the machine memory, so it is unlimited, but not
>infinite and thus doesn't cover all integers either.

That's not my point.

In Haskell you write down an algorithms assuming unlimited ressources.
Due to lazy evaluation in a concrete situation with defined input data
the program executes in limited space (and time).

>Numerous unlimited arithmetic packages have been defined in Ada for
>integers, for rational's and for floating point.  Any type derived from
>those packages have the unlimited aspect you are looking for.  And they are
>used "naturally",

Of course. But Ada does not allow to use them as real scalars. You can't use
them as array indices or slides or even subtypes. Haskell does not limit this.
You can even define and work with the infinite entity 'all natural numbers'.

>I also believe one could create a symbolic processing type, which just
>collected operators without evaluation, and doing symbolic simplification
>before assignments.

Every language discussed so far is computionally equivalent to Brainfuck.
A language with an oracle or random source convers much more.

Re: ada vs. cpp

[Dmitry Kazakov]

On Wed, 10 Oct 2001 10:36:01 -0400, "Steven Deller"
<deller@smsail.com> wrote:

>I also believe one could create a symbolic processing type, which just
>collected operators without evaluation, and doing symbolic simplification
>before assignments.  True lazy evaluation.  Hmmm -- might be interesting to
>define, since there would have to be symbolic literals.

[OT]

Maybe for Ada 2100 (:-)). It could be interesting to add lazy
evaluation mode. Something like Algol's by-name parameters. If an
object is of lazy subtype it is evaluated each time one accesses it.
When the actual parameter is converted to a lazy subtype a
coresponding parameterless function is generated from its expression. 

Two main advantages would be definition of short-circuit operations in
the language terms thus making "and then" / "or else" overloadable
operations, and [of course (:-))] closures .

Regards,
Dmitry Kazakov

Re: ada vs. cpp

[Florian Weimer]

dmitry@elros.cbb-automation.de (Dmitry Kazakov) writes:

> Maybe for Ada 2100 (:-)). It could be interesting to add lazy
> evaluation mode. Something like Algol's by-name parameters.

Lazy evaluation and side effects do not mix well, so this is not going
to happen (unless Ada becomes a purely applicative language, which is,
uhm, very unlikely).

Re: ada vs. cpp

[Dmitry Kazakov]

On Wed, 10 Oct 2001 18:10:42 +0200, Florian Weimer <fw@deneb.enyo.de>
wrote:

>dmitry@elros.cbb-automation.de (Dmitry Kazakov) writes:
>
>> Maybe for Ada 2100 (:-)). It could be interesting to add lazy
>> evaluation mode. Something like Algol's by-name parameters.
>
>Lazy evaluation and side effects do not mix well, so this is not going
>to happen (unless Ada becomes a purely applicative language, which is,
>uhm, very unlikely).

I believe it is generally the same problem as with pointers to
subroutines. A possible solution (maybe too restrictive) is to forbid
lazy objects and only allow lazy formal parameters.

Regards,
Dmitry Kazakov

Re: ada vs. cpp

[Brian Rogoff]

On Wed, 10 Oct 2001, Lutz Donnerhacke wrote:
> * Dmitry Kazakov wrote:
> >1. If you mean that Ada has no type to represent the whole set of all
> >integers, yes it is true. [as well as it is for all other languages
> >designed for finite discrete machines]
>
> man Haskell. (or any other lazy evaluation language with unlimited arithmetics)

This issue is not related to lazy evaluation. Haskell's Integer is a plain
old arbitrary precision integer, just like the ones provided by C, Ada,
and OCaml libraries. I'm pretty sure that some versions of SML (a strict
language) use a similar approach for the default integer type.

This is one of those few cases where I think the "safe" choice (arbitrary
precision integers) is the wrong default.

-- Brian

Re: ada vs. cpp

[David Starner]

On Wed, 10 Oct 2001 15:59:53 GMT, Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> This is one of those few cases where I think the "safe" choice (arbitrary
> precision integers) is the wrong default.

Why? It seems to me you wouldn't lose much in Ada if you let Integer be
an arbitrary precision integer, and forced people to use subtypes with
restricted ranges to get access to hardware types. It may not be the
best trade-off for Ada, but for a higher-level language, I don't see why
not.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I saw a daemon stare into my face, and an angel touch my breast; each 
one softly calls my name . . . the daemon scares me less."
- "Disciple", Stuart Davis

Re: ada vs. cpp

[Lutz Donnerhacke]

* David Starner wrote:
>On Wed, 10 Oct 2001 15:59:53 GMT, Brian Rogoff <bpr@shell5.ba.best.com> wrote:
>> This is one of those few cases where I think the "safe" choice (arbitrary
>> precision integers) is the wrong default.
>
>Why? It seems to me you wouldn't lose much in Ada if you let Integer be
>an arbitrary precision integer, and forced people to use subtypes with
>restricted ranges to get access to hardware types. It may not be the
>best trade-off for Ada, but for a higher-level language, I don't see why
>not.

I was really confused noting that GNAT does restrict the range of
univeral_integer.

Re: ada vs. cpp

[David Starner]

On Wed, 10 Oct 2001 11:01:01 GMT, Dmitry Kazakov <dmitry@elros.cbb-automation.de> wrote:
> 1. If you mean that Ada has no type to represent the whole set of all
> integers, yes it is true. [as well as it is for all other languages
> designed for finite discrete machines]

Many languages - Common Lisp, for one - have integers that can represent
the full range of integers, as far as memory will allow.
 
> 4. If your point is that a language *has* all types [all programs, all
> whatsoever] one could develop using the language then well, all
> languages are more or less equivalent. 

My point is, that C has those ordered sets of characters we call
strings. To slap extra requirements on, and claim it doesn't, isn't
conductive to good communication, any more than me claiming Ada doesn't
have integers. Algol 60 didn't have strings; C does.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I saw a daemon stare into my face, and an angel touch my breast; each 
one softly calls my name . . . the daemon scares me less."
- "Disciple", Stuart Davis

Re: ada vs. cpp

[Ted Dennison]

In article <9q1ker$aik1@news.cis.okstate.edu>, David Starner says...
>
>My point is, that C has those ordered sets of characters we call
>strings. To slap extra requirements on, and claim it doesn't, isn't
>conductive to good communication, any more than me claiming Ada doesn't
>have integers. Algol 60 didn't have strings; C does.

I'm with you on that one. However, I came across this interesting quote from
Bjarne Stroustrup in the second edition of his "The C++ Programming Language"
(section 1.3, for those interested):
---
For example, the C++ language does not provide a matrix type with an inversion
operator or a string type with a concatenation operator. If a user wants such a
type, it can be defined in the language itself.
---

But of course that is really an acedemic issue to your average C++ user, as they
will always have access to the stl, which *does* have such a type.

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

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: ada vs. cpp

[Pascal Obry]

David Starner <dvdeug@x8b4e53cd.dhcp.okstate.edu> writes:

> My point is, that C has those ordered sets of characters we call
> strings. 

With this definition every language support string. For example assembly
language do have string. I'm sorry to insist but "char *" is a pointer not a
string. Ok, C++ has a string class, and this could have been done with
assembly macro, will you say that x86-asm has strings ?

Anyway this is not an important issue :) Just that I have spent too much time
debuging programs with C strings...

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 vs. cpp

[David Starner]

On 10 Oct 2001 19:53:11 +0200, Pascal Obry <p.obry@wanadoo.fr> wrote:
> With this definition every language support string. 

Pretty much. Algol 60 doesn't support them. It's one of the fundamental
data types; any programming language that didn't support them would be
seriously deficent.

> I'm sorry to insist but "char *" is a pointer not a
> string. 

A pointer to *what*? 

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I saw a daemon stare into my face, and an angel touch my breast; each 
one softly calls my name . . . the daemon scares me less."
- "Disciple", Stuart Davis

Re: ada vs. cpp

[James Rogers]

David Starner wrote:
> 
> On 10 Oct 2001 19:53:11 +0200, Pascal Obry <p.obry@wanadoo.fr> wrote:
> > With this definition every language support string.
> 
> Pretty much. Algol 60 doesn't support them. It's one of the fundamental
> data types; any programming language that didn't support them would be
> seriously deficent.
> 
> > I'm sorry to insist but "char *" is a pointer not a
> > string.
> 
> A pointer to *what*?

The real problem is that a "char *" is simply a pointer to **A**
character. It may be used as a pointer to the first of a set of
contiguous characters but you can never tell from its definition.

Not all "char *" actually equate to a string. If you want to call
a C function and pass a single character out as a parameter, that
parameter must be defined as a "char *". If you want to deal with
a contiguous set of characters, you also define the parameter as
a "char *". A "char *" at best holds the address of a single
character. It may be a null pointer, in which case it points to
nothing useful.

C has a similar problem with all arrays. The name of the array is
merely a constant pointer to the first element of the array. No
other information about the array is available, such as the upper
bounds, or the end of useful data in the array. Function parameters
for int arrays are passed as "int *". If you want to return a single
int from an array, through the parameter list, you must pass it as
"int *".

C's basic problem is not really strings. Its fundamental problem is
that arrays are not a first class type.

Jim Rogers
Colorado Springs, Colorado USA

Re: ada vs. cpp

[David Thompson]

James Rogers <jimmaureenrogers@worldnet.att.net> wrote :
...
> C has a similar problem with all arrays. The name of the array is
> merely a constant pointer to the first element of the array. No
> other information about the array is available, such as the upper
> bounds, or the end of useful data in the array. Function parameters
> for int arrays are passed as "int *". If you want to return a single
> int from an array, through the parameter list, you must pass it as
> "int *".
>
<PEDANTIC=MAX> Very close but not quite.  In BCPL and B
an array name truly was (or more precisely designated) a pointer,
which wasn't actually constant although changing it was rare.
In C the name does actually designate the array lvalue, which
in _almost_ all contexts immediately and silently _converts_
to a pointer to the first element, with the results you describe.
This conversion (also for functions) is usually called "decay".
The same in C++ for C-style arrays but not for std::vector etc.

This was done originally so that arrays would work in structures.
See the 2HOPL paper at http://cm.bell-labs.com/cm/cs/who/dmr/ .
And most of section 6 of the C (comp.lang.c) FAQ.

You're right that an array cannot be passed as such, only
as a pointer (or within a struct, or in C++ as a reference),
but to further confuse people unfamiliar with this feature
you _can_ write the declaration of a function parameter as
an array and it is (again silently) "adjusted" to a pointer.

And the limitation is really on returning _any type_ from
_anywhere_ through a parameter, not just int from array.

> C's basic problem is not really strings. Its fundamental problem is
> that arrays are not a first class type.
>
Well, I'd say its fundamental problem is that it was designed
as a tolerably good SIL and has been stretched out of shape
into a general application and especially GUI language.
Different parts of the elephant, maybe.

--
- David.Thompson 1 now at worldnet.att.net

Re: ada vs. cpp

[James Rogers]

Dmitry Kazakov wrote:
> 
> In any case, as many have pointed, it is a bit ridiculous to compare
> Ada's strings with C++ having no strings at all.

That is almost true. C++ now has a standard String class. This puts
its string capabilities on a par with Java's string capabilities.

The C++ String class provides some safety in the use of strings.
For instance, it checks for an attempt to access a string
element beyond the end of the string.

On the other hand, the C++ string is much less efficient than the
Ada string. It is also incompatible with many of the other standard
C++ functions. Those functions require the primitive "string"
defined by C. You know that string; a block of memory terminated
by a binary 0.

Jim Rogers
Colorado Springs, Colorado USA

Re: ada vs. cpp

[Larry Kilgallen]

In article <3BBDBB4B.523FDC82@worldnet.att.net>, James Rogers <jimmaureenrogers@worldnet.att.net> writes:

> The C++ String class provides some safety in the use of strings.
> For instance, it checks for an attempt to access a string
> element beyond the end of the string.

Wow !!!   Isn't science wonderful ?   :-)

Yes, I realize the statement was a serious and relevant response
to another comment.  But I couldn't resist.

Re: ada vs. cpp

[Ted Dennison]

In article <3bbd6287.346843109@news.cis.dfn.de>, Dmitry Kazakov says...
>
>In any case, as many have pointed, it is a bit ridiculous to compare
>Ada's strings with C++ having no strings at all.

That's not entirely true; it has the string class in the STL. However, that's
roughly akin to using Ada.Strings.Unbounded.

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

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: ada vs. cpp

[David Thompson]

Dmitry Kazakov <dmitry@elros.cbb-automation.de> wrote :
...
> Sorry, but Ada is one of rare languages which are able to manipulate
> strings allocated on the stack. IMO strings are indeed one of Ada
> strengths, especially if you need an efficient parsing code. ...

COBOL, post-1977 (IIRC) versions of Fortran, and (standard) Pascal
support ordinary local (or global/static) variables containing some
(fixed) number of characters treated (to greater or lesser extent)
as character strings.  Many Pascals support counted strings
(that is, variable up to a declared limit) as an extension.  Fortran
and later Pascal allow a subprogram parameter to accept string
arguments of different (fixed) sizes, a limited kind of genericity.
(On most separate-compilation implementations and even some
without you can cheat and access outside the declared bound(s)
or length of a parameter and it always works right as long as it
is within the actual argument, but this is not formally a feature
except in the BCPL-C lineage where an array parameter is
_defined_ to actually be a pointer with the bound discarded.)
PL/1 supports CHAR(n) fixed-length and VARYING variables,
and generic-length parameters.  FWIW SQL also has fixed
and variable length character string data types; true SQL has
no local or "stack" variables of any type, but SQLoid PLs
like Sybase/M$ T-SQL and Oracle PL/SQL do.

C (and C++) can locally or statically allocate a char array
and treat it as a string given the null-termination convention;
in C++ a user or 3rdparty class could do fixed and/or variable
strings like all those above, including generic-length using a
templated proxy, though none are provided by the standard.
In C99 (not yet widely implemented) or GNU C a local array
variable (char or otherwise) can have a bound determined at
the equivalent of elaboration, and PL/1 has always had this.

Perhaps you meant to say C is the only widespread 3GL
(besides arguably FORTH and maybe early BASIC?) that
_didn't_ have character strings as an "official" datatype :-?
In this area (as others) Ada did a good job of collecting,
organizing, and making uniform pretty much all the functions
available in other 3GLs, but did not break significant new ground.
Which I hasten to say is still a valuable and even vital contribution.

>
> In any case, as many have pointed, it is a bit ridiculous to compare
> Ada's strings with C++ having no strings at all.
>
As previously noted C++ std::string is closely comparable
to Ada.Strings.Unbounded (and dynamically allocated).

--
- David.Thompson 1 now at worldnet.att.net

Re: ada vs. cpp

[Dmitry Kazakov]

On Tue, 16 Oct 2001 04:52:02 GMT, "David Thompson"
<david.thompson1@worldnet.att.net> wrote:

>Dmitry Kazakov <dmitry@elros.cbb-automation.de> wrote :
>...
>> Sorry, but Ada is one of rare languages which are able to manipulate
>> strings allocated on the stack. IMO strings are indeed one of Ada
>> strengths, especially if you need an efficient parsing code. ...

[..] Strings in COBOL, PL/1, FORTRANs etc

>Perhaps you meant to say C is the only widespread 3GL
>(besides arguably FORTH and maybe early BASIC?) that
>_didn't_ have character strings as an "official" datatype :-?

No, said that Ada has excellent strings. It is true that many
languages have strings. Even FORTRAN IV arrays of LOGICAL*1 could be
counted as strings (:-)). However, to have an excellent string support
one should fulfil some requrements, which include IMO:

1. There are stack allocated strings
2. There are in, out, inout parameters and returns of the string type
3. The string bounds are not a part of the type
4. Bounds can be obtained from any string object
5. There are constrained string subtypes
6. String slices

The rest follows.

>In this area (as others) Ada did a good job of collecting,
>organizing, and making uniform pretty much all the functions

Yes

>available in other 3GLs, but did not break significant new ground.

Maybe. However, I would like to see an example of such new ground
breaking. Some people here have argued that C++ has strings because
one can develop them. Very well, to follow this logic I expect that
there is something extr-r-r-emely important and new for strings that
cannot be [efficiently] implemented in Ada 95. And?

BTW did char * break something other than programmers' heads? (:-))

>Which I hasten to say is still a valuable and even vital contribution.

Yes

>> In any case, as many have pointed, it is a bit ridiculous to compare
>> Ada's strings with C++ having no strings at all.
>>
>As previously noted C++ std::string is closely comparable
>to Ada.Strings.Unbounded (and dynamically allocated).

As I have pointed in other post I disagree with this logic. What can
be expressed in the language terms is *not* a part of the language.

Yes, in C++ one may have what bounded or unbounded Ada strings are.
Then there are ready to use string implementations like STL or MFC.
But C++ have nothing comparable with the type String in Ada.

Regards,
Dmitry Kazakov

Re: ada vs. cpp

[David Thompson]

Dmitry Kazakov <dmitry@elros.cbb-automation.de> wrote :
> On Tue, 16 Oct 2001 04:52:02 GMT, "David Thompson"
> <david.thompson1@worldnet.att.net> wrote:
...
> >> Sorry, but Ada is one of rare languages which are able to manipulate
> >> strings allocated on the stack. IMO strings are indeed one of Ada
> >> strengths, especially if you need an efficient parsing code. ...
>
> [..] Strings in COBOL, PL/1, FORTRANs [,Pascal] etc
...
> No, said that Ada has excellent strings. It is true that many
> languages have strings. Even FORTRAN IV arrays of LOGICAL*1 could be
> counted as strings (:-)). However, to have an excellent string support
> one should fulfil some requrements, which include IMO:
>
I think the fair measure is whether strings are supported to the same
or an equivalent extent as other data types in the same language.
(Equivalence is of course a judgement call.)

> 1. There are stack allocated strings
Yes for all of the above.

> 2. There are in, out, inout parameters and returns of the string type
Modern Fortran yes.  Older FORTRAN, COBOL, and PL/1 have
all parameters by reference with no modes (for all data types).
Pascal distinguishes by-value and by-reference, and ExtdPascal
adds nonmodifiable, but not out vs inout (again for all types).
Fortran PL/1 and Pascal do support string return values;
COBOL does not support return values of any data type.

> 3. The string bounds are not a part of the type
I think you have to distinguish between parameters and
actual variables/objects.  Even in Ada except for Unbounded
an actual string object has a type constrained by (max) size,
but for Bounded the current (valid) contents may be <= size;
the same is true for PL/1 and ExtdPascal.  For COBOL,
Fortran, and basicPascal a string object is a fixed size
(although COBOL can have a DEPENDING array).

Fortran and basicPascal (level 1) in addition to PL/1 do
support _parameters_ with size determined at runtime
by the actual argument.  (Most?) COBOL implementations
(like C) actually work for any size actual argument
but this is not a defined feature of the language.

In all except Pascal a string lower bound is always 1,
only the upper bound varies.  (PL/1 supports other lower
bounds for _arrays_ but strings are not arrays there.)

> 4. Bounds can be obtained from any string object
(Or upper bound, where the lower bound is fixed.)
Again I think there are several cases:  for actual objects
(except Ada Unbounded, which is not stack allocated
at least not in general) the size is determined either
explicitly or implicitly in the declaration, so this is
"only" a convenience (though sometimes a useful one).
For parameters whose (argument) size is known only
at runtime, Fortran, PL/1, and Pascal yes.

For Bounded strings whose current contents are distinct
from the object size, the current bound is available in
PL/1 and ExtdPascal, the only ones that have this type.

> 5. There are constrained string subtypes
Yes, as above.

> 6. String slices
Yes except basic Pascal.  In COBOL and Fortran using
an array-like syntax, in PL/1 and ExtdPascal using a
function-like syntax but usable as an lvalue.

...
> Maybe. However, I would like to see an example of such new ground
> breaking. [by Ada in string handling]

You mean you would like to find something that is in Ada already
that was/is not in other languages?  I don't see anything major.
Or you want to propose adding new features to Ada that other
languages don't have?  That's a different question.  I don't see
anything I consider vitally needed that I would push for, but
I can imagine many things I wouldn't mind having.

> ... Some people here have argued that C++ has strings because
> one can develop them. Very well, to follow this logic I expect that
> there is something extr-r-r-emely important and new for strings that
> cannot be [efficiently] implemented in Ada 95. And?
>
I for one have argued that one can easily implement in C++
the equivalent of Strings.Fixed and Bounded, although this is
not as convenient (for integration, reuse, etc.) as having them
standard.  It already has the equivalent of Unbounded.
I don't understand the rest of your statement.

...
> >As previously noted C++ std::string is closely comparable
> >to Ada.Strings.Unbounded (and dynamically allocated).
>
> As I have pointed in other post I disagree with this logic. What can
> be expressed in the language terms is *not* a part of the language.
>
Then Annex A is not part of Ada?  Nor loops because they can
be constructed from goto?  I think the the language definition defines
the language.  One could argue that early versions of C++ were
deficient in this respect, but not now; std::string is required to be
present (and provide the same functionality) on all implementations.

> Yes, in C++ one may have what bounded or unbounded Ada strings are.
> Then there are ready to use string implementations like STL or MFC.
> But C++ have nothing comparable with the type String in Ada.
>
MFC is a very different matter.  It is NOT standard.  Neither is STL
as such, although it has a _big_ overlap with the C++ standard library.

--
- David.Thompson 1 now at worldnet.att.net

Re: ada vs. cpp

[Dmitry A. Kazakov]

On Tue, 13 Nov 2001 02:12:01 GMT, "David Thompson"
<david.thompson1@worldnet.att.net> wrote:

>Dmitry Kazakov <dmitry@elros.cbb-automation.de> wrote :
>> On Tue, 16 Oct 2001 04:52:02 GMT, "David Thompson"
>> <david.thompson1@worldnet.att.net> wrote:
>...
>> >> Sorry, but Ada is one of rare languages which are able to manipulate
>> >> strings allocated on the stack. IMO strings are indeed one of Ada
>> >> strengths, especially if you need an efficient parsing code. ...
>>
>> [..] Strings in COBOL, PL/1, FORTRANs [,Pascal] etc
>...
>> No, said that Ada has excellent strings. It is true that many
>> languages have strings. Even FORTRAN IV arrays of LOGICAL*1 could be
>> counted as strings (:-)). However, to have an excellent string support
>> one should fulfil some requrements, which include IMO:
>>
>I think the fair measure is whether strings are supported to the same
>or an equivalent extent as other data types in the same language.
>(Equivalence is of course a judgement call.)
>
>> 1. There are stack allocated strings
>Yes for all of the above.
>
>> 2. There are in, out, inout parameters and returns of the string type
>Modern Fortran yes.  Older FORTRAN, COBOL, and PL/1 have
>all parameters by reference with no modes (for all data types).
>Pascal distinguishes by-value and by-reference, and ExtdPascal
>adds nonmodifiable, but not out vs inout (again for all types).
>Fortran PL/1 and Pascal do support string return values;
>COBOL does not support return values of any data type.
>
>> 3. The string bounds are not a part of the type
>I think you have to distinguish between parameters and
>actual variables/objects.  Even in Ada except for Unbounded
>an actual string object has a type constrained by (max) size,
>but for Bounded the current (valid) contents may be <= size;
>the same is true for PL/1 and ExtdPascal.  For COBOL,
>Fortran, and basicPascal a string object is a fixed size
>(although COBOL can have a DEPENDING array).
>
>Fortran and basicPascal (level 1) in addition to PL/1 do
>support _parameters_ with size determined at runtime
>by the actual argument.  (Most?) COBOL implementations
>(like C) actually work for any size actual argument
>but this is not a defined feature of the language.
>
>In all except Pascal a string lower bound is always 1,
>only the upper bound varies.  (PL/1 supports other lower
>bounds for _arrays_ but strings are not arrays there.)

I didn't mean the actual bounds of an object. I meant that the bounds
are not used for type checks. So objects of *same* type may have
different bounds. Consider, in C++:

template <int From, int To> class String {...};

Here the string bounds identify the type. Which has a nasty
consequence that String<1,10> and String<1,80> are two different
types.

>> 4. Bounds can be obtained from any string object
>(Or upper bound, where the lower bound is fixed.)
>Again I think there are several cases:  for actual objects
>(except Ada Unbounded, which is not stack allocated
>at least not in general) the size is determined either
>explicitly or implicitly in the declaration, so this is
>"only" a convenience (though sometimes a useful one).

It is not so simply. Consider:

procedure Foo (X : Time; Y : Fuzzy;  Z : ManaFlux) is
   Internal : String (1..SomethingAwfulComplex (X, Y, Z));
begin
   ...
 
>For parameters whose (argument) size is known only
>at runtime, Fortran, PL/1, and Pascal yes.

It is also a simplification. Consider an inline subroutine. If the
bounds of a string parameter are statically known, then the compiler
might optimize the routine code.

>For Bounded strings whose current contents are distinct
>from the object size, the current bound is available in
>PL/1 and ExtdPascal, the only ones that have this type.
>
>> 5. There are constrained string subtypes
>Yes, as above.
>
>> 6. String slices
>Yes except basic Pascal.  In COBOL and Fortran using
>an array-like syntax, in PL/1 and ExtdPascal using a
>function-like syntax but usable as an lvalue.
>
>...
>> Maybe. However, I would like to see an example of such new ground
>> breaking. [by Ada in string handling]
>
>You mean you would like to find something that is in Ada already
>that was/is not in other languages?  I don't see anything major.
>Or you want to propose adding new features to Ada that other
>languages don't have?  That's a different question.  I don't see
>anything I consider vitally needed that I would push for, but
>I can imagine many things I wouldn't mind having.

Just, I see nothing that Ada should borrow for string handling from
other languages. There might be some problems, when for instance, one
implements pattern matching in Ada, but they are not string problems.

>> ... Some people here have argued that C++ has strings because
>> one can develop them. Very well, to follow this logic I expect that
>> there is something extr-r-r-emely important and new for strings that
>> cannot be [efficiently] implemented in Ada 95. And?
>>
>I for one have argued that one can easily implement in C++
>the equivalent of Strings.Fixed and Bounded, although this is
>not as convenient (for integration, reuse, etc.) as having them
>standard.  It already has the equivalent of Unbounded.
>I don't understand the rest of your statement.

If there is something (let denote it as ***) that Ada 95 does not
have, then according to the logic: "C++ has strings", Ada 95 indeed
has ***, because ***  can be implemented in Ada 95. Thus to say that
Ada 95 does not have ***, one should prove that *** cannot be
[efficently] implemented in Ada 95...

>...
>> >As previously noted C++ std::string is closely comparable
>> >to Ada.Strings.Unbounded (and dynamically allocated).
>>
>> As I have pointed in other post I disagree with this logic. What can
>> be expressed in the language terms is *not* a part of the language.
>>
>Then Annex A is not part of Ada? 

No, it is: "A.1(8) type Integer is range implementation-defined;".
"Implementation-defined" cannot be expressed in Ada terms.

>Nor loops because they can be constructed from goto? 

One always can write an equivalent program that uses gotos instead of
loops, but it is not so that Ada loops can be expressed using gotos.
There are lot of problems here. Declaration of the loop variable. A
unique label is required, exit statements, the requirement that a loop
can be entered only through its header etc.

Consider the language constructs as axioms, and programs as theorems.
Any [provable] theorem can be deduced from axioms. It is of course
useless to compare axiom sets by analyzing theorems, provided (as we
all know) that the sets of theorems are more or less equivalent.

>I think the the language definition defines
>the language.

The opposite is also true: the language defines a language definition
(:-))

>One could argue that early versions of C++ were
>deficient in this respect, but not now; std::string is required to be
>present (and provide the same functionality) on all implementations.

Well, if we would define "language definition" as "a pile of paper
sheets with something written upon them", then of course, from such
sort of definition will follow anything. [Please do not consider this
a blame on C++ standard (:-))].

The fact that the name of a program containing definition of a type
called "std::string" is written on some sheets from that "pile" proves
nothing [or anything, depending on the point of view (:-))].

>> Yes, in C++ one may have what bounded or unbounded Ada strings are.
>> Then there are ready to use string implementations like STL or MFC.
>> But C++ have nothing comparable with the type String in Ada.
>>
>MFC is a very different matter.  It is NOT standard.  Neither is STL
>as such, although it has a _big_ overlap with the C++ standard library.

Regards,
Dmitry Kazakov

Re: ada vs. cpp

[Ted Dennison]

In article <3bf0e265.74480421@News.CIS.DFN.DE>, Dmitry A. Kazakov says...
>template <int From, int To> class String {...};
>
>Here the string bounds identify the type. Which has a nasty
>consequence that String<1,10> and String<1,80> are two different
>types.

It should be noted that this is a *theoretical* example Dmitry is presenting.
C++'s "string" class is *not* defined this way. It is rather a single
instantiation of another template, and thus all objects of this class *are* the
same type.

Another thing I noticed with C++ templates is that instantiations that use the
same parameters appear to actually *be* the same object, unlike how Ada generics
work. That actually would help alleviate this problem a bit more than if you had
the same problem in Ada.

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

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: ada vs. cpp

[Dmitry A. Kazakov]

On Tue, 13 Nov 2001 16:05:41 GMT, Ted Dennison<dennison@telepath.com>
wrote:

>In article <3bf0e265.74480421@News.CIS.DFN.DE>, Dmitry A. Kazakov says...
>>template <int From, int To> class String {...};
>>
>>Here the string bounds identify the type. Which has a nasty
>>consequence that String<1,10> and String<1,80> are two different
>>types.
>
>It should be noted that this is a *theoretical* example Dmitry is presenting.
>C++'s "string" class is *not* defined this way. It is rather a single
>instantiation of another template, and thus all objects of this class *are* the
>same type.

Yes. It was just an example of strings with bounds as a part of the
type.

Another thing is that there is no other way (I believe) to do it if
stack allocation is a requirement.

>Another thing I noticed with C++ templates is that instantiations that use the
>same parameters appear to actually *be* the same object, unlike how Ada generics
>work. That actually would help alleviate this problem a bit more than if you had
>the same problem in Ada.

This is the problem of generics per se. They are inherently harmful. I
like to view dispatching polymorphism in OO as an attempt to get rid
of generics [and still have generic programming].

That C++ uses "by-value matching" solves nothing, though the errors it
may induce are very hard to track down. So I think Ada is in a better
position here.

Regards,
Dmitry Kazakov

Re: ada vs. cpp

[mike]

In article <tTRu7.25751$S_6.2879078@news20.bellglobal.com>, Pi says...
>
 
>
>You say that it's text-based.
>Do you have to parse the text-input?
>In this case I would consider using Perl[1] for the parsing
>and than the actual treatement in Ada.
>(Strings aren't Ada's strength)
>


first, perl is ugly. it is write-only language.

second, I think Ada is brilliant for strings, I used only standard
Ada packages for strings, and the standard Ada library strings are quite
good. and even though I have worked much in it, I understand that GNAT 
has now snobol-like package (and you can't say sbitbol aint for strings) 
and GNAT also has perl like reqular expressions package too. (even
Java 1.4 has now a reqular expression classes, so there is no reason
to use perl anymore :)

>2nd : Objects : 
>as long as you dont need special features you're fine with Ada.
>Just consider a package like an object and you're cool.
>

I think the confusion comes from this: In java, the most popular OO 
language these days, a package is really nothing but a directory where
files exist in it. Each file represents a class (not considering inner and
private classes for the moment).

i.e. in Java

class  <---> own file

In Ada, a package is declared/defined in a file. i.e. 

Ada package <--> own File

very loosely put. 

So, the object in Ada sits in a file that "belong" to a 
package. This is the core difficulity many face when trying to use Ada 
OO features I think.


Now DELPHI has the same thing as Ada, but in DELPHI,
an object has it own 'class' key work inside a package, which makes it
less confusing to some.  It is all syntax suger, and at the end it all
comes down to the same thing, but in Ada it does take a little more time
to get used to doing OO if one comes from Java or C++. It is all about the
object.method() vs. method(object) notation.

>
>4th : Polymorphism
>Argh, only possible with tagged type and true crap, so stick with C++

I do not understand the above. a tagged record is a record you can extend,
what is so hard about it? think of a tagged record + its operations as a class.

>5th : Multiple Heritage
>Not possible with Ada.
>

big deal. MI is not possible in Java too, but I do not see it stopping
people from using Java (2.5 million programmers use Java these days and
counting). 

>[1] Perl is your worst nightmare for big project,
>but the best language for text parsing out there,
>so if you use it, use it *only* for the parsing.
 
Untill you get to have to fix the code, then you are stuck wasting hours
and hours trying to figure what the code does.

There is no perfect language. May be someone should invent a language which
looks like Java, but acts like Ada, then it will be a real winner :)

Java has nice global features, but week at the core languge level (it is
like an enterprise version of VB). Ada is best engineered language, but not
much window dressing on it to attract the industry.

Try to do an enumeration type in Java with the same features that comes
with Ada per-build, and you'll see what I mean. (one simple example). There
is a whole section (2-3 pages) in 'effective Java' book on how to make
an enumeration type safe in Java, and at the end, it does not give you
5% of what Ada enumeration does in one line.  

Re: ada vs. cpp

[Pi]

mike@nospam wrote :

> In article <tTRu7.25751$S_6.2879078@news20.bellglobal.com>, Pi says...
> >
>  
> >
> >You say that it's text-based.
> >Do you have to parse the text-input?
> >In this case I would consider using Perl[1] for the parsing
> >and than the actual treatement in Ada.
> >(Strings aren't Ada's strength)
> >
> 
> 
> first, perl is ugly. it is write-only language.
> 
> second, I think Ada is brilliant for strings, I used only standard
> Ada packages for strings, and the standard Ada library strings are quite
> good.

I find string parsing with Ada standard library's ugly.

> and even though I have worked much in it, I understand that GNAT
> has now snobol-like package (and you can't say sbitbol aint for strings)
> and GNAT also has perl like reqular expressions package too. 

Didn't know this, just found it ...
forget what I said about Perl and use GNAT.Regpat ;-)

> (even
> Java 1.4 has now a reqular expression classes, so there is no reason
> to use perl anymore :)
> 
> >2nd : Objects :
> >as long as you dont need special features you're fine with Ada.
> >Just consider a package like an object and you're cool.
> >
> 
> I think the confusion comes from this: In java, the most popular OO
> language these days, a package is really nothing but a directory where
> files exist in it. Each file represents a class (not considering inner and
> private classes for the moment).
> 
> i.e. in Java
> 
> class  <---> own file
> 
> In Ada, a package is declared/defined in a file. i.e.
> 
> Ada package <--> own File
> 
> very loosely put.
> 
> So, the object in Ada sits in a file that "belong" to a
> package. This is the core difficulity many face when trying to use Ada
> OO features I think.
> 

Maybe, but I still use one file per "class" in Ada.
I find it much more lisible if I export only one (tagged) type per package.
(plus any convenient enumartion type, subtypes, etc ...)

So you have the class and his methods clearly regrouped.
And you can use package extention + tagged type extention combined.

> 
> Now DELPHI has the same thing as Ada, but in DELPHI,
> an object has it own 'class' key work inside a package, which makes it
> less confusing to some.  It is all syntax suger, and at the end it all
> comes down to the same thing, but in Ada it does take a little more time
> to get used to doing OO if one comes from Java or C++. It is all about the
> object.method() vs. method(object) notation.
> 

But in Ada you have no "end" after the definition of the methods.
The "end" comes after the attributes,
but the position of the methods has a *major* impact,
especially if you want to use polymorphism.

IIRC you have to specify the headers (but *only* the headers)
of all method that you want to use polymorph *directly* after
the declaration of the tagged type.

And this is poorly documented and the compiler warnings are of
no much help either.

> >
> >4th : Polymorphism
> >Argh, only possible with tagged type and true crap, so stick with C++
> 
> I do not understand the above. a tagged record is a record you can extend,
> what is so hard about it? think of a tagged record + its operations as a
> class.
> 

See above why I consider polymorphism in Ada an ugly patchwork.

> >5th : Multiple Heritage
> >Not possible with Ada.
> >
> 
> big deal. MI is not possible in Java too, but I do not see it stopping
> people from using Java (2.5 million programmers use Java these days and
> counting).
> 

He asked if he should port his project from cpp to Ada.
What do I know if he uses MI?

You're right, normally nobody needs it,
but when you need it it causes problems,
so you wont use it anyway.

> >[1] Perl is your worst nightmare for big project,
> >but the best language for text parsing out there,
> >so if you use it, use it *only* for the parsing.
>  
> Untill you get to have to fix the code, then you are stuck wasting hours
> and hours trying to figure what the code does.
> 

It's much easier to write unreadable code in Perl,
but that doesn't mean you have too.

Beside, the parsing of an input line would be very short.
Maybe 10 lines of code + 30 lines of commentary.
(but GNAT.Regpat is still a better choice)

> There is no perfect language. May be someone should invent a language
> which looks like Java, but acts like Ada, then it will be a real winner :)
> 

So true, Java has the most beautiful grammar + syntax I've ever seen,
<g> interested in writing an Java to Ada compiler? (only half kidding)

> Java has nice global features, but week at the core languge level (it is
> like an enterprise version of VB). Ada is best engineered language, but
> not much window dressing on it to attract the industry.
> 
> Try to do an enumeration type in Java with the same features that comes
> with Ada per-build, and you'll see what I mean. (one simple example).
> There is a whole section (2-3 pages) in 'effective Java' book on how to
> make an enumeration type safe in Java, and at the end, it does not give
> you 5% of what Ada enumeration does in one line.
> 

Very true (had to do this once), but

if you want an enumeration type you shouldn't use Java.
An enumeration type is not an OO-Concept and therefor isn't included.

Beside, as you have to write it yourself you can also
make it more powerful. (Enumeration of objects?)

But, I admit, I missed enumerations in Java ...

-- 
3,14159265359

Re: ada vs. cpp

[James Rogers]

Pi wrote:
> 
> 
> IIRC you have to specify the headers (but *only* the headers)
> of all method that you want to use polymorph *directly* after
> the declaration of the tagged type.
> 
> And this is poorly documented and the compiler warnings are of
> no much help either.

Poor compiler messages? That is not my experience.
Of course, messages are not part of the language definition.
Each compiler develops its own set of error and warning messages.

The Aonix compiler generates very useful messages, ususally with
references to the corresponding section of the language reference
manual. The GNAT compiler generates truly brilliant error messages.
For instance, if you mistype the keyword "while" it will tell you
"Line XX col YY : Keyword while misspelled", where XX is the line
number and YY is the column number of the beginning of the
detected error.

> 
> He asked if he should port his project from cpp to Ada.
> What do I know if he uses MI?

He may use MI. That is not impossible to convert to Ada.

> if you want an enumeration type you shouldn't use Java.
> An enumeration type is not an OO-Concept and therefor isn't included.
> 
> Beside, as you have to write it yourself you can also
> make it more powerful. (Enumeration of objects?)
> 
> But, I admit, I missed enumerations in Java ...

Integers are not an OO-concept, but they are included in Java.

Sets can be nicely expressed as an OO-concept, but they are not
included in Java.

My point is that Java's design strongly encourages the use of OO
concepts, but neither requires them, nor does it provide a
completely inclusive definition of OO tools and concepts.

Jim Rogers
Colorado Springs, Colorado USA

Re: ada vs. cpp

[Pascal Obry]

Pi <pi3_1415926536@yahoo.ca> writes:

> Hmm, Objects ...
> 
> 1st : Ada will help you find more bugs at compile time than C++
> So your developpement time tends to be faster.
> But consider that interactions with the OS are more difficult.
> Not much more, but slightly.

Ok.

> 
> Remember that Ada is at his very best if you give him few
> input, billions of calculations on numbers and than few output.

Not true.

> You say that it's text-based.
> Do you have to parse the text-input?
> In this case I would consider using Perl[1] for the parsing
> and than the actual treatement in Ada.
> (Strings aren't Ada's strength)

String not, but what about GNAT.Spitbol, GNAT.Spitpat, GNAT.Regpat,
GNAT.Regexp, GNAT.AWK and GNAT.Expect ?

> 2nd : Objects : 
> as long as you dont need special features you're fine with Ada.
> Just consider a package like an object and you're cool.

A package like an object ???? Maybe like a class of objects...!!! Pakckage is
a way to organize things and to build abstractions like ADT and ASM.

> 
> 3rd : Heritage
> Hmm, package heritage is ok, tagged types work too
> 
> 4th : Polymorphism
> Argh, only possible with tagged type and true crap, so stick with C++
> Or you can try to hand-code it, but it's far less flexible and
> error-prone. But IMNSHO still better than Ada's tagged type variant.

My experience differ !

> 5th : Multiple Heritage
> Not possible with Ada.
> 
> [1] Perl is your worst nightmare for big project,
> but the best language for text parsing out there,
> so if you use it, use it *only* for the parsing.

Perl is the worst nightmare for any sized project. The worst nightmare. I
still ask myself how is that possible to "invent" such language ???

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 vs. cpp

[David Botton]

You start with C then......

----- Original Message ----- 
From: "Pascal Obry" <p.obry@wanadoo.fr>

> Perl is the worst nightmare for any sized project. The worst nightmare. I
> still ask myself how is that possible to "invent" such language ???

Re: ada vs. cpp

[Jacob Sparre Andersen]

Pascal:

> Perl is the worst nightmare for any sized project.

I would say that it isn't all that bad for tasks which can
be implemented with less than hundred characters.

Jacob
-- 
"Dansk sprogn�vn er en flok spader!
 Cognac kan kun staves p� �n m�de"
 Henrik Christian Grove

Re: ada vs. cpp

[Wes Groleau]

Jacob Sparre Andersen wrote:
> 
> Pascal:
> > Perl is the worst nightmare for any sized project.
> 
> I would say that it isn't all that bad for tasks which can
> be implemented with less than hundred characters.

Sounds like a job for APL.

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

Re: ada vs. cpp

[Preben Randhol]

On Fri, 05 Oct 2001 00:29:25 +0200, Jacob Sparre Andersen wrote:
> Pascal:
> 
>> Perl is the worst nightmare for any sized project.
> 
> I would say that it isn't all that bad for tasks which can
> be implemented with less than hundred characters.

Problem with Perl is that even with only 100 characters you will run a
great risk of making a lot of errors. Of course a true Perl coder is
more interested in how to write the whole program in as few lines as
possible.

> "Dansk sprogn�vn er en flok spader!
>  Cognac kan kun staves p� �n m�de"

Konjakk ? ;-)

>  Henrik Christian Grove

Re: ada vs. cpp

[Georg Bauhaus]

Preben Randhol <randhol+abuse@pvv.org> wrote:
 
: Problem with Perl is that even with only 100 characters you will run a
: great risk of making a lot of errors.

What kind of, given -w and the 'use strict ...' mechanisms?

Georg

Re: ada vs. cpp

[Preben Randhol]

On Fri, 5 Oct 2001 12:43:02 +0000 (UTC), Georg Bauhaus wrote:
> Preben Randhol <randhol+abuse@pvv.org> wrote:
>  
>: Problem with Perl is that even with only 100 characters you will run a
>: great risk of making a lot of errors.
> 
> What kind of, given -w and the 'use strict ...' mechanisms?

One of the bigger problems is to know exactly how to get the output of an
function into the right variable and not have to rely on the default
every time. But whether -w or not, Perl code still reminds unreadable...

Preben

Re: ada vs. cpp

[Mike Silva]

Pascal Obry <p.obry@wanadoo.fr> wrote in message news:<uelojnzgm.fsf@wanadoo.fr>...
> Pi <pi3_1415926536@yahoo.ca> writes:
> 
> > Hmm, Objects ...
> > 
> > 1st : Ada will help you find more bugs at compile time than C++
> > So your developpement time tends to be faster.
> > But consider that interactions with the OS are more difficult.
> > Not much more, but slightly.
> 
> Ok.

Except for those OS functions that are much easier in Ada, like tasks,
critical sections (protected objects), time, memory pools, ...

BTW, I think Ada would be an excellent language for your roguelike
game.  I was going to do one myself to do some Ada-ing, but decided to
work on a CPU simulator instead.

Mike

Re: ada vs. cpp

[Ted Dennison]

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

In article <Xns912FEBF1DF3EBralphworkcoza@196.25.240.158>, Ralph M�ritz says...
>It's a text-based (roguelike) rpg, I haven't yet gotten far but it's going 
>to be big! Uses objects (thus cpp instead C) to eliminate much repetitive 
>code for stats storage and access. A header file for each component 
>(dungeon.cpp --> dungeon.h etc.)

If it were me, I'd definitely do something like that in Ada. However, an
important part of such projects is keeping your co-developers happy. If Ada is
going to make all of them split, that could be a bit of a problem.

On the other hand, on a C++ project you are going to have a lot more trouble
with folks turning in code that proports to be C++, but is actually C with line
comments. Stuff like that can still happen in Ada, but the language actively
discourages it, so it isn't nearly as big of an issue in practice.

If you are still in the early stages, and it won't cause insurmountable
political problems for you, I'd go with Ada.

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

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: ada vs. cpp

[Marin David Condic]

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

This all depends on how serious your project is and what you want to
accomplish.

In most commercial efforts it is seldom worth throwing out everything to
convert to a new language. Just wait until the next project comes along. By
the time you've committed to building code, its probably not economical to
switch horses in the middle of the stream.

If its a school project - when is it due? Again, I'd think that you're
better off waiting until the next project since you don't want to backtrack
and lose time. Unless it is sufficiently small that switching over doesn't
involve a lot of rewriting of code.

You can always salvage your C++ code since you can call it from an Ada
program. Ada is good at integrating code from other languages. Of course,
you may not want to do this for a lot of reasons. Since Ada has basically
all of the fundamental capabilities of C++, you're overall architecture may
be salvagable - you just need to re-implement your design using Ada. It all
depends on what your goals are and what your timeframe is and how much work
is already done.

Ada will be a lot less painful to deal with long term than will C++.
Converting early is the best bet - but you need to remember that Ada is a
means to an end - not an end in and of itself. Keep your objectives clear
and make your decision on how well Ada helps you get to your objectives.

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/


"Ralph M�ritz" <ralph@work.co.za> wrote in message
news:Xns912FE7C63AC8Dralphworkcoza@196.25.240.158...
> Greetings,
>
> I've spent sbout 2 months learning cpp, and now I've discovered ada!
> I can't decide whether to carry on dev. my project ic cpp or rewrite in
> ada, because it means ppl dev. with me will have to learn ada.(sigh)
>
> Is it worthwhile to rewrite, if so, why?
> Could I save the cpp code somehow so that I don't have to maybe rewrite?
>
> Thanks ;-)

Re: ada vs. cpp

[Jeff]

On 3 Oct 2001 20:42:29 GMT, "Ralph M�ritz" <ralph@work.co.za> wrote:

>Greetings,
>
>I've spent sbout 2 months learning cpp, and now I've discovered ada!
>I can't decide whether to carry on dev. my project ic cpp or rewrite in 
>ada, because it means ppl dev. with me will have to learn ada.(sigh)
>
>Is it worthwhile to rewrite, if so, why?
>Could I save the cpp code somehow so that I don't have to maybe rewrite?
>
>Thanks ;-)

My short answer is to stick with C++.  The best way to learn a
language is to use it.

I have been doing embedded software in the defense industry for 17
years.  While I personally like Ada, I am seeing a number of product
lines being converted from FORTRAN and Ada to C++.  

Java is also an alternative that is similar to C++ but without many of
the gotchas.

The defect rate due to coding errors is higher in C++ than Ada but for
an adventure game this is probably not a critical concern for you.

Other things to consider are your career goals.  

BTW the proper spelling is Ada with a capital A since the language is
the first name of a famous woman.

Jeff

Re: ada vs. cpp

[Adrian Hoe]

"Ralph M?itz" <ralph@work.co.za> wrote in message news:<Xns912FE7C63AC8Dralphworkcoza@196.25.240.158>...
> Greetings,
> 
> I've spent sbout 2 months learning cpp, and now I've discovered ada!
> I can't decide whether to carry on dev. my project ic cpp or rewrite in 
> ada, because it means ppl dev. with me will have to learn ada.(sigh)
> 
> Is it worthwhile to rewrite, if so, why?
> Could I save the cpp code somehow so that I don't have to maybe rewrite?
> 
> Thanks ;-)


Your experience with cpp is relatively new. If you have not gone too
far with cpp, you may want to take a closer look at Ada at the mean
time (You did not mention if you have learnt Ada, just discovered it).

You may want to consider the size of your project and where you are
right now. Than consider your deadline. If you still have plenty of
time, consider Ada.

My company switch to Ada many years ago and we rewrote a completed and
stable project entirely in Ada. We spent months in learning, teaching,
managing and rewriting libraries and project code. It was like hell
but it was fun and we think it is worth all the hardwork, until today.
We use Ada in 99% of all projects today.

Visit http://greenlime.com/Ada-Malaysia for more information.

I would suggest you to look at various aspect of your project and your
team to decide on cpp or Ada. If you need some help especially in
transition and risk management, you can e-mail me.

Adrian Hoe

Re: ada vs. cpp

[mike]

In article <9ff447f2.0110041723.2da8b7aa@posting.google.com>,
byhoe@greenlime.com says...
 
> It was like hell
>but it was fun and we think it is worth all the hardwork, until today.

so, what happened today that makes you come to the conclusion that it was
not worth all the hardwork? something happened today suddenly to change
your mind? 

Re: ada vs. cpp

[mike]

In article <9ff447f2.0110041723.2da8b7aa@posting.google.com>,
byhoe@greenlime.com says...
 
>My company switch to Ada many years ago and we rewrote a completed and
>stable project entirely in Ada. 

I found this on the page you referenced:

"In quarter 3, Mr. Adrian Hoe, now the director of Research and Development
division of Lexical Integration (M) Sdn Bhd, suggested to adopt Ada as the
primary programming language. The motion was immediately approved by the
management and the marketing team"

You guys sure have some englightened and forward thinking management over
where you work! 

here, if you suggest Ada, you have to run for cover quickly to avoid things
being thrown at you from hitting your head :)  

Management only knows C/C++/Java. You could even mention perl and not get
more strange looks than if you had mentiond Ada. But ignorance is a bless,
and we have to put up with such management. Lucky you to have such managers.






 

Re: ada vs. cpp

[Adrian Hoe]

mike@nospam <mike_member@newsguy.com> wrote in message news:<9pjdnv0h2f@drn.newsguy.com>...
> In article <9ff447f2.0110041723.2da8b7aa@posting.google.com>,
> byhoe@greenlime.com says...
>  
> >My company switch to Ada many years ago and we rewrote a completed and
> >stable project entirely in Ada. 
> 
> I found this on the page you referenced:
> 
> "In quarter 3, Mr. Adrian Hoe, now the director of Research and Development
> division of Lexical Integration (M) Sdn Bhd, suggested to adopt Ada as the
> primary programming language. The motion was immediately approved by the
> management and the marketing team"
> 
> You guys sure have some englightened and forward thinking management over
> where you work! 
> 
> here, if you suggest Ada, you have to run for cover quickly to avoid things
> being thrown at you from hitting your head :)  
> 
> Management only knows C/C++/Java. You could even mention perl and not get
> more strange looks than if you had mentiond Ada. But ignorance is a bless,
> and we have to put up with such management. Lucky you to have such managers.


Yeah, you should be jealous about me having such managers. I am the
original founder of company and motioned the merger with some company
to form Lexical Integration. Most importantly is that all managers are
engineers even our guys and gals in business development department.
Even, our administrator has degree in computer science. :,)