Re: Is the Writing on the Wall for Ada?

[Craig Carey <research@ijs.co.nz>]

On Fri, 26 Sep 2003 02:31:52 GMT, Matthew Heaney wrote:
>"Robert I. Eachus" <rieachus@attbi.com> writes:
>> Hyman Rosen wrote:
>> > Stephen Leake wrote:
>> >> Ada.Strings.Unbounded. Way better than C++ Strings.
>> > How?
>> 
>> For one simple example, an Ada string of any flavor can always contain
>> all possible character literals and control codes.
>
...
>The problem with Ada.Strings.Unbounded is that to do anything useful
>with it requires a conversion to type String, which is grossly
>inefficient, not to mention awkward.
>

Only if the string is large enough, e.g. 3KB or more, at least for GNAT
(and ObjectAda) in Windows. The requirements of the oft revised RM 7.6
(user controlled finalization) guide vendors to get their Unbounded
strings code to be slow.

----

Suppose there was a destructive Assign operator that is fast and
efficient.

It would do this:

Tmp := Rhs.Ptr;
Rhs.Ptr := Lhs.Ptr;
Lhs.Ptr := Tmp;
Lhs.valid := True
Rhs.valid := False

I vaguely recall these two arguments from persons...:

  * Variant fields mismatch

  * Run time crashes in the vendors compiler software and the exceptions
  coming out of Adjust or Finalize have to be correctly handled.

Those feeble arguments are of no obvious importance in connection with
 the issue.

I have not checked to see if GNAT has already got the "Assign(L,R);"
extension that results in a fast ":=" assignment operator.

With big customers requesting features all the time, it is pssible.



>The ACT people added a Aux child (I think that's the name), which
>provides a function to return the underlying String_Access.  This is how
>Ada.Strings.Unbounded should have been designed in the first place.
>


They could change the Aux package. E.g. produce rewritten Unbounded
 strings code.

Also the Aux package exposes a limited implementation.
E.g. there is no spare space in strings. User code might not run
correctly if that changes.

Also, it is not the case that the RM "should" describe something that
is not known to be defined.



>The C++ std::string also has a getline procedure to read from stdin
>directly into a std::string.  A similar function should have been
>provided for Ada.Strings.Unbounded.


GNAT's Get_Line lost the CP/M disk block padding char (in Windows 2000
[ASCI 26 if I recall right]). ASCII 13 is liable to go too. The RM
allows some of that or all of it.

Expanding the problem for that small purpose might not get voted for.

Also the new Get_Line subroutine, returning a line of any length,
would do unnecessary copying. Above this was written:

    "... The problem with Ada.Strings.Unbounded is that ...
    it requires a conversion to type String, ... which is
    inefficient..."

That seems to be saying that unnecessary copying 'should' be avoided
(i.e. it says "to type String" rather than: "from [the Ada String
 type]").



Craig Carey

A replacement for Charles' Strings:
    http://www.ijs.co.nz/code/ada95_strings_pkg.zip

 Likel to be cmpatible with the ACT modified GPL.