Re: ada vs. cpp

[dmitry@elros.cbb-automation.de (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