conversion

conversion

[Rick]

how do you convert a string into an integer?
thanks

Re: conversion

[Richard Toy]

Rick wrote:
> 
> how do you convert a string into an integer?
> thanks

Try looking at 'Value or an instanciation of Integer_Io and
"procedure Get (From : in String; Item : out Num; Last : out Positive)"
in the LRM.

-- 
Regards	
Richard Toy

Re: conversion

[Corey Ashford]

Rick wrote in message <35B628C1.F358EAEE@world-net.net>...
>how do you convert a string into an integer?
>thanks
>

the easiest way is to use the 'value attribute.

declare
...
  foo : constant string := integer'value(some_integer_variable);
...
begin

Re: conversion

[Corey Ashford]

Corey Ashford wrote in message <6p5qq9$ifd$1@usenet.rational.com>...
>
>Rick wrote in message <35B628C1.F358EAEE@world-net.net>...
>>how do you convert a string into an integer?
>>thanks
>>
>
>the easiest way is to use the 'value attribute.
>
>declare
>...
>  foo : constant string := integer'value(some_integer_variable);
>...
>begin
>
>
>

oops... I reversed that

foo : integer := integer'value(some_string_value);

conversion

[Andrew]

I am experimenting with Ada as the primary language in our process.  It
seems that
the use of String and Unbounded_String require converting from one to the
other in
order to read a line from a file and then trim it or slice it or tokenize
it.  For now,
regardless of the performance of these conversions it is rather inconvenient
to design
for a language that does not have a "universal" string type.

For instance:  a variable of type char * can be used as char * or as char []
and char []
can be used as char *.  A fixed string in Ada (to me) is like declaring a
char [], you
must specify a size at compile time.  An unbounded_string in Ada is like
char *, it can
take on a different size when it appears on the LHS of an assignment
operator.  The
catch is that unbounded_string can not be used in context of string.  This
posses some
design inconveniences and requires converting back and forth from string to
unbounded_string multiple times.

I defined a string pointer type so that I could dynamically create strings
that are the fixed
string type but I find that 'that' only defers the need to convert from
fixed string to
unbounded_string to different points in the design or that the conversion is
not eliminated.
I am now thinking that for my company we could develop a "library" that has
a "universal"
string type.  If we don't base it on the defined string in package standard
and can use
streams to read from files then we can define our own string type.  I
think...

I'm not real sure whether to extend on the functionality of ada.text_io or
to create new
functionality from the stream package.  Any recommendations?  Has anyone
done
something like this?

Andrew

Re: conversion

[Dmitry A. Kazakov]

On Fri, 27 Jun 2003 04:51:04 -0600, "Andrew" <andrew@carroll-tech.net>
wrote:

>I am experimenting with Ada as the primary language in our process.  It
>seems that
>the use of String and Unbounded_String require converting from one to the
>other in
>order to read a line from a file and then trim it or slice it or tokenize
>it.

Usually you do not need Unbounded_String when you are working with
files. You read into a string buffer and parse the buffer contents
taking into account the number of read characters.
Ada.Text_IO.Get_Line uses this technique:

procedure Get_Line
(  File : in  File_Type;
   Item : out String;
   Last : out Natural
);

When you parse the buffer, the recognized tokens need not to be
copied. You can well use string slices for that.

>For now,
>regardless of the performance of these conversions it is rather inconvenient
>to design
>for a language that does not have a "universal" string type.

Yes, Unbounded_String and String should to be siblings, which is
presently impossible in Ada.

>For instance:  a variable of type char * can be used as char * or as char []
>and char []
>can be used as char *.  A fixed string in Ada (to me) is like declaring a
>char [], you
>must specify a size at compile time.  An unbounded_string in Ada is like
>char *, it can
>take on a different size when it appears on the LHS of an assignment
>operator.  The
>catch is that unbounded_string can not be used in context of string.  This
>posses some
>design inconveniences and requires converting back and forth from string to
>unbounded_string multiple times.

In most cases you can avoid Unbounded_String by using discriminated
types:

type Employee (Name_Length : Positive) is record
   Name : String (1..Name_Length);
   ...
end record;

Truly dynamic string objects are surprisingly rare. Even if you have
such, they will be likely encapsulated in more complex objects, for
which it should be no problem to define an appropriate interface in
terms of Strings not Unbounded_Strings.

>I defined a string pointer type so that I could dynamically create strings
>that are the fixed
>string type but I find that 'that' only defers the need to convert from
>fixed string to
>unbounded_string to different points in the design or that the conversion is
>not eliminated.

I presume that Unbounded_String-->String conversion is very
inexpensive.

>I am now thinking that for my company we could develop a "library" that has
>a "universal"
>string type.  If we don't base it on the defined string in package standard
>and can use
>streams to read from files then we can define our own string type.  I
>think...
>
>I'm not real sure whether to extend on the functionality of ada.text_io or
>to create new
>functionality from the stream package.  Any recommendations?  Has anyone
>done
>something like this?

I never felt any need in something like that. Perhaps others ...

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: conversion

[Stephen Leake]

"Andrew" <andrew@carroll-tech.net> writes:

> I am experimenting with Ada as the primary language in our process.
> It seems that the use of String and Unbounded_String require
> converting from one to the other in order to read a line from a file
> and then trim it or slice it or tokenize it.

The "correct" choice of what to do depends heavily on exactly what
your application is.

If you are writing a tokenizer, you should consider using OpenToken.

> For now, regardless of the performance of these conversions it is
> rather inconvenient to design for a language that does not have a
> "universal" string type.

Yes, it is sometimes difficult to decide which of Ada's many features
to use. It's much easier in C, where you have no choice :).

> For instance: a variable of type char * can be used as char * or as
> char [] and char [] can be used as char *. 

yes.

> A fixed string in Ada (to me) is like declaring a char [], you must
> specify a size at compile time.

Yes.

> An unbounded_string in Ada is like char *, it can take on a
> different size when it appears on the LHS of an assignment operator.

No. The best analogy to char * is Ada.Strings.Unbounded.String_Access;
a pointer to an allocated string.

C does _not_ have a true unbounded string type, that can automatically
change size; you have to free and reallocate.

C++ provides a String class that behaves much like Ada's
Unbounded_String. 

> The catch is that unbounded_string can not be used in context of
> string. 

That's what To_String is for. You should not worry about whether that
is "efficient". When you have finished you application, if it is too
slow, you can measure it's speed, find the bottlenecks, and fix them.
I'd be very surprised if To_String is a bottleneck.

> This posses some design inconveniences and requires converting back
> and forth from string to unbounded_string multiple times.

That does sound like a problem. Perhaps you could give more details,
and we could provide better advice.

You could also measure the speed of the conversions now, to convince
yourself that it is (or is not) a problem.

> I defined a string pointer type so that I could dynamically create
> strings that are the fixed string type but I find that 'that' only
> defers the need to convert from fixed string to unbounded_string to
> different points in the design or that the conversion is not
> eliminated. 

There are many ways to avoid the need for unbounded strings,
typicallly using a local declare block. However, there are also times
when you need them, typically when storing strings in records.

How would you solve the problem in C? If you are happy with that
solution, do exactly the same thing in Ada, with the mapping char[] =>
String, char * => String_Access, malloc => new, free =>
Unchecked_Conversion.

> I am now thinking that for my company we could develop a "library"
> that has a "universal" string type. If we don't base it on the
> defined string in package standard and can use streams to read from
> files then we can define our own string type. I think...

What features would this "universal" string type have that either
String or Unbounded_String does not have?

> I'm not real sure whether to extend on the functionality of
> ada.text_io 

What is missing from Ada.Text_IO?

> or to create new functionality from the stream package. Any
> recommendations? Has anyone done something like this?

Many people have complained about Ada strings. They do take getting
used to, especially if you are coming from a C (rather than C++)
background. But no one has proposed a better solution (to my
knowledge). Hmm, Matthew Heaney's Charles library has a new String
type, but I haven't looked at it to see why.

-- 
-- Stephe

Re: conversion

[Robert I. Eachus]

Andrew wrote:
> I am experimenting with Ada as the primary language in our process.  It
> seems that the use of String and Unbounded_String require converting
 > from one to the other in order to read a line from a file and then
 > trim it or slice it or tokenize it.  For now, regardless of the
 > performance of these conversions it is rather inconvenient  to design
> for a language that does not have a "universal" string type.
> 
> For instance:  a variable of type char * can be used as char * or as
 > char [] and char [] can be used as char *.  A fixed string in Ada (to me)
 > is like declaring a char [], you must specify a size at compile time.  An
 > unbounded_string in Ada is like char *, it can take on a different size
 > when it appears on the LHS of an assignment operator.  The catch is that
 > unbounded_string can not be used in context of string.  This posses some
> design inconveniences and requires converting back and forth from string to
> unbounded_string multiple times.
> 
> I defined a string pointer type so that I could dynamically create strings
> that are the fixed string type but I find that 'that' only defers the need
 > to convert from fixed string to unbounded_string to different points 
in the
 > design or that the conversion is not eliminated. I am now thinking 
that for
 > my company we could develop a "library" that has a "universal" string 
type.
 > If we don't base it on the defined string in package standard and can use
> streams to read from files then we can define our own string type.  I
> think...
> 
> I'm not real sure whether to extend on the functionality of ada.text_io or
> to create new  functionality from the stream package.  Any recommendations?
 > Has anyone done something like this?
> 
> Andrew

Hmmm.  Where to begin.  You are thinking in C about Ada concepts.  That 
is confusing you because the Ada mappings are different.  In Ada, the 
TYPE String is unconstrained.  Objects must be constrained, so if you 
need to put a String somewhere, you have to provide a constraint, 
explicitly or implicitly.  If you do:

Foo: String := Bar;

The object Foo is constrained to the length of the String returned by 
the call to Bar (if Bar is a function), or to have the same length as 
Bar, if Bar is an object.

In C, you can have objects of type char [], but you can't have values of 
char [].  So parameters of char [] are implicitly converted to char *. 
In Ada, you almost never need an access to String type.  You can create 
one, or use the one defined in Ada.Strings.Unbounded, but it just 
muddies up the waters.

So what is Ada.Strings.Unbounded.Unbounded_String?  Conceptually all you 
need to know is that it is a (constrained) container type, so you can 
have objects of type Ada.Strings.Unbounded_String.  Putting strings into 
a container should be less expensive than malloc and free in C.  (Or I 
guess free and malloc in this case.)  Using the String VALUE that is in 
an Unbounded_String container is no harder than using any other value.

So in Ada, 99% of the time when you need to use a (lower case) string 
type, you use String, and done.  If for some reason you need a string 
object that can vary within bounds (like PL/I char * varying) or a 
string object whose bounds can vary radically, you create an instance of 
Ada.Strings.Bounded_String, or use Ada.Strings.Unbounded_String.

Ada.Strings.Unbounded_String has no counterpart that I am aware of 
outside garbage collected languages.  It does automatic string 
allocation and storage management at a very low cost.

Re: conversion

[Bill Findlay]

On 27/6/03 13:37, in article uznk3u258.fsf@nasa.gov, "Stephen Leake"
<Stephe.Leake@nasa.gov> wrote:

> "Andrew" <andrew@carroll-tech.net> writes:
>> A fixed string in Ada (to me) is like declaring a char [], you must
>> specify a size at compile time.
> 
> Yes.

Actually, no.
The size of a fixed string is determined when its declaration is elaborated.

You specify the index subtype bounds (and hence the size) at run time.
The bound values need not be known at compile time, although they may be.

I'm not being pedantic, this is a surprise to many C* programmers.

In the case of a local string variable, it may take a different size each
time its scope is entered, e.g.:

 function f (n : positive) return String is
    s : String(1..n) := (others => ' ');
 begin
    if n > 1 then return s & f(n-1); end if;
    return s;
 end f;

This returns a blank string of length n(n+1)/2.
-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Re: conversion

[Matthew Heaney]

"Andrew" <andrew@carroll-tech.net> wrote in message news:<mailman.18.1056709818.8204.comp.lang.ada@ada.eu.org>...
> 
> I'm not real sure whether to extend on the functionality of ada.text_io or
> to create new
> functionality from the stream package.  Any recommendations?  Has anyone
> done
> something like this?

GNAT has added a child package to Text_IO to add support for reading
into an unbounded_string directly.

It has also added a child packet to Ada.Strings.Unbounded, to return a
pointer to the underlying string.  This will make conversions from
unbounded_string to string more efficient.

The Charles library also has a string container package, that provides
a similar function to return a pointer to the underlying string.  It
would be simple enough (and also more efficient) to add a child
package (did I do it already?) to read into an unbounded string
container type directly.

http://home.earthlink.net/~matthewjheaney/charles/

I'll have a new release of the charles library probably later today
(Fri, 27 June 2003).  If there's something you need right away maybe I
can fold it into today's release.

Realize that you have a similar issue in C++, because you have both
type char* and class std::string.  The std::string class has a member
function c_str() that allocs a const char* array containing the
current value of the string.

Re: conversion

[Georg Bauhaus]

Bill Findlay <yaldnifw@blueyonder.co.uk> wrote:
:> "Andrew" <andrew@carroll-tech.net> writes:
: 
: function f (n : positive) return String is
:    s : String(1..n) := (others => ' ');
: begin
:    if n > 1 then return s & f(n-1); end if;
:    return s;
: end f;
: 
: This returns a blank string of length n(n+1)/2.

You can combine this with Get_Line and then Find_Token.


Georg

Re: conversion

[Georg Bauhaus]

Andrew <andrew@carroll-tech.net> wrote:
: For instance:  a variable of type char * can be used as char * or as char []
: and char []
: can be used as char *.

As an aside, Ada's strings might turn out to be helpful in situations
like

  char s[SZ];
  // ...
  char* t = (char*)malloc(100);
  // ...
  strncpy(s, t, SZ);

for a few reasons.


georg

Re: conversion

[Alexander Kopilovitch]

>The catch is that unbounded_string can not be used in context of string.
>This posses some design inconveniences and requires converting back and forth
>from string to unbounded_string multiple times.

Exactly. This is very inconvenient (perhaps, most inconvenient) feature of
Ada language.

Certainly, a chorus tells you that Ada is not C, but what about Pascal, which
has much more resemblance with Ada? Pascal isn't C, it does not rely heavily
upon pointers, but at the same time it has quite good and usable strings.

The chorus also tells you that in Ada you should not need those conversion
too often. Well, they are honest enough, they simply do not use Ada for
a job and in an environment where you must mix varying strings and constant
strings here and there, and at the same time you can't afford several weeks
for design for every change in specifications.

Ada simply understimates need of strings in non-numerical world (almost like
Fortran IV, that is, before Fortran 77). I'm sure that Ada people would cry
very loudly if there were similar situation with Integer type: imagine that
there is unconstrained (for value, not for storage size) type Integer, which
objects must be constrained (by value). Then, there are types Bounded_Integer
and Unbounded_Integer. Unbounded_Integer is good for general use, except that
you always have to write explicit conversion when you assign a literal (say,
1 or 0) to an object of Unbounded_Integer type (currently Ada Integer is like
a Pascal string in this respect).



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: conversion

[Stephen Leake]

"Andrew" <andrew@carroll-tech.net> writes:

> Ok, so I found the ada.strings.unbounded package spec and body and
> took a look at the definition and implementation of unbounded
> string. Finally I found them!

ok.

> <snip>

> So...The conversion from Unbounded_String to String is pretty easy.
> Return the pointer de-reference. 

Yes.

> From String to Unbounded_String is the expensive one. In general it
> is: allocate memory copy values from old to new return the new.

Yes.

> So, using unbounded and calling to_string is relatively fast. Good,
> I'm satisfied with that part. 

Ok.

> I think it would be easy enough to create a slice and trim method
> that returned an unbounded_string so that I would not have to use
> the expensive string to unbounded_string conversion and that nagging
> inconvenience would be pacified.

What is your application? There are many other ways to represent
pieces of strings. For example, you can store a string and a bunch of
indexes into the string.

> It wasn't hard at all to write a program that uses to_string and
> to_unbounded_string. It works. 

Good.

> It's just that I didn't realize in design that I would need so many
> conversions and I wasn't fluent enough with all the "utility"
> methods like slice, trim, head, etcetera to really specify at design
> time whether I needed String or Unbounded_String. Once
> implementation time came up I almost immediately had to go back to
> design because I was introducing so much code for the conversions. 

Yes, this is often the case when learning new utilities. My rule is
that the design isn't right until you've redone it three times.

> I thought "there has to be a better way".

You'll get there :).

> Something else I really like about Ada is separate compilation. I
> can separate subprocedures into other files with the "is separate"
> and Separate(<name>) feature. That one thing would make code SO much
> more manageable. I could spread that thing out and assign tasks by
> function if needed. Then, just compile!

Better to use child packages. "is separate" is really an Ada 83
feature; child packages in Ada 95 is a better way to structure things.
Sometimes "is separate" is a good way to go, but rarely.

> I also was trying to get gnatmem to run but it fails.

Give an example of the code and error message; maybe I can help.

> Has anyone used the Ada Core Technologies compiler? 

Yes.

> How does it compare to the public GNAT that I'm using; comes with
> FreeBSD Unix.

Hmm, this is confused. GNAT _is_ the Ada Core Technologies (ACT)
compiler. ACT is constantly developing the compiler; when they get a
reasonably stable new version, they release it to their supported
customers. After the supported customers have time to find some more
bugs, they release it to the public. 

Then there is the version of GNAT bundled with the GCC release. ACT
calls that 5.01w; gcc calls it 3.1. It is _not_ as well tested as the
public ACT release.

So as a supported customer, I'm using GNAT 3.16a. The one that comes
with FreeBSD Unix may be 3.15p, or 3.1. Yes, it is confusing. But they
are all versions of the same compiler.

-- 
-- Stephe

Re: conversion

[Preben Randhol]

Alexander Kopilovitch wrote:
> Certainly, a chorus tells you that Ada is not C, but what about Pascal, which
> has much more resemblance with Ada? Pascal isn't C, it does not rely heavily
> upon pointers, but at the same time it has quite good and usable strings.

Oh I remembered when we had to use Pascal in some introductory
programming course at the university that there was several machines
crashing due to that the students didn't get the pointers correctly.

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

conversion

[Andrew]

Ok, so I found the ada.strings.unbounded package spec and body and took a
look
at the definition and implementation of unbounded string.  Finally I found
them!

Unbounded_string is basically an object that contains a reference to a
string.
It would be something like:

typdef struct unbounded_string{
    char* reference;
}

with methods to manipulate the structure.  My example may not be
syntactically correct
but I think I convey the basic idea.  String is an array, Unbounded_String
is an
"object" that contains a reference to an array.

So...The conversion from Unbounded_String to String is pretty easy.  Return
the
pointer de-reference.  From String to Unbounded_String is the expensive one.
In
general it is:
allocate memory
copy values from old to new
return the new.

So, using unbounded and calling to_string is relatively fast.  Good, I'm
satisfied with
that part.  I think it would be easy enough to create a slice and trim
method that
returned an unbounded_string so that I would not have to use the expensive
string to
unbounded_string conversion and that nagging inconvenience would be
pacified.

Dmitry mentioned that get_line reads in to a string buffer.  Then after the
line
was read another string could be made because the last parameter is the
length of
what was read.  Your absolutely right!  I knew that and looked right over
it.

It wasn't hard at all to write a program that uses to_string and
to_unbounded_string.
It works.  It's just that I didn't realize in design that I would need so
many conversions
and I wasn't fluent enough with all the "utility" methods like slice, trim,
head, etcetera
to really specify at design time whether I needed String or
Unbounded_String.  Once
implementation time came up I almost immediately had to go back to design
because
I was introducing so much code for the conversions.  I thought "there has to
be a better
way".

Something else I really like about Ada is separate compilation.  I can
separate subprocedures
into other files with the "is separate" and Separate(<name>) feature.  That
one thing would
make code SO much more manageable.  I could spread that thing out and assign
tasks by
function if needed.  Then, just compile!

I also was trying to get gnatmem to run but it fails.

Has anyone used the Ada Core Technologies compiler?  How does it compare to
the public
GNAT that I'm using; comes with FreeBSD Unix.

Thanks for the help!

Andrew

Re: conversion

[tmoran]

>Hmmm.  Where to begin.  You are thinking in C about Ada concepts.  That
>is confusing you because the Ada mappings are different.  In Ada, the
  As a general rule, if something seems inordinately hard to do in Ada,
you are probably not using Ada appropriately.  In the case of strings,
declaring dynamically sized strings, passing strings as dynamically sized
parameters, using concatenation, and, especially, using slices will handle
a great many string processing tasks.  eg,

  procedure Process_Line(Line : in String) is
  -- From "Fred Smith #12345; John Jones, Albert"
  -- make 2 calls on Process_First_Name
  --   Process_Full_Name("Smith, Fred");
  --   Process_Full_Name("Jones, John");
    First, Last : Natural;
  begin
    First := Line'first;
    loop
      Ada.Strings.Fixed.Find_Token
           (Source=>Line(First .. Line'last),
            Set   =>Ada.Strings.Maps.Constants.Letter_Set,
            Test  =>Ada.Strings.Inside,
            First =>First,
            Last  =>Last);
      exit when Last = 0;
      declare
        use Ada.Strings;
        use Ada.Strings.Maps.Constants;
        First_Name : String renames Line(First .. Last);
      begin
        Fixed.Find_Token(Line(Last+1 .. Line'last), Letter_Set, Inside,
                         First, Last);
        exit when Last = 0;
        Process_Full_Name(Line(First .. Last) & ", " & First_Name);
      end;
      First := Last+1;
    end loop;
  end Process_Line;
  ...
  Line : String(1 .. 80);
  Last : Natural;
  ...
  Ada.Text_IO.Get_Line(Input, Line, Last);
  Process_Line(Line(Line'first .. Last));

Re: conversion

[Alexander Kopilovitch]

Preben Randhol wrote:

> > Certainly, a chorus tells you that Ada is not C, but what about Pascal, which
> > has much more resemblance with Ada? Pascal isn't C, it does not rely heavily
> > upon pointers, but at the same time it has quite good and usable strings.
>
>Oh I remembered when we had to use Pascal in some introductory
>programming course at the university that there was several machines
>crashing due to that the students didn't get the pointers correctly.

Is it all you remember about Pascal? If so that, perhaps, you should not be
much surprised when other people associate Ada with Ariane 5 crash only.

Anyway, why you switched to the Pascal pointers from the theme of strings?
Pascal is not C, and Pascal strings aren't naturally associated with pointers.

Finally, as you mention those dangerous pointers in Pascal, let me quote
the "Programming in Ada 95" by John Barnes (2nd edition, 1998), Chapter 10,
Access Types, p.171 :

"Playing with pointers is like playing with fire. Fire is perhaps the most
important tool known to man. Carefully used, fire brings enormous benefits,
but when fire gets out of control, disaster strikes. Pointers have similar
characteristics but are well tamed in the form of access types in Ada."



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: conversion

[Robert I. Eachus]

Alexander Kopilovitch wrote:

> The chorus also tells you that in Ada you should not need those conversion
> too often. Well, they are honest enough, they simply do not use Ada for
> a job and in an environment where you must mix varying strings and constant
> strings here and there, and at the same time you can't afford several weeks
> for design for every change in specifications.
> 
> Ada simply understimates need of strings in non-numerical world (almost like
> Fortran IV, that is, before Fortran 77). I'm sure that Ada people would cry
> very loudly if there were similar situation with Integer type: imagine that
> there is unconstrained (for value, not for storage size) type Integer, which
> objects must be constrained (by value). Then, there are types Bounded_Integer
> and Unbounded_Integer. Unbounded_Integer is good for general use, except that
> you always have to write explicit conversion when you assign a literal (say,
> 1 or 0) to an object of Unbounded_Integer type (currently Ada Integer is like
> a Pascal string in this respect).

This is silly.  The situation in Ada is exactly the same with integer 
and string types.  Objects must be constrained, values need not be.  If 
I write: X: Integer; ... X := X + 1; ... the result may not fit in an 
Integer and I'll get Constraint_Error.  But the Constraint_Error occurs 
because of this value/object dichotomy, just as if I had tried to assign 
an 81 character string to an 80 character buffer.  The 
Ada.Strings.Bounded and Ada.Strings.Unbounded packages provide a way to 
create objects that have only a maximum or no minimum and no maximum 
length respectively.  The equivalent for integer types is a bignum 
package, which supports any size integer value without Constraint_Error.

Now compile and run this code:

with Ada.Text_IO; use Ada.Text_IO;
procedure NumEx is
   X: Integer := 2**65 / 3**38 + 3;
begin
   Put_Line("The value of X is" & Integer'Image(X));
end NumEx;

If it doesn't compile without error and print:

The value of X is 30

Send a bug report to the compiler vendor.  What happened there? If you 
don't see why there would be a problem in most languages, go back and 
look more carefully.  I'll wait.

I suspect that 2**65 is out of range for any predefined integer type for 
your compiler.  (If it isn't, make up your own example.)  This behaviour 
is required by RM 8.6(29) which states a preference for operations for 
root integer and root real.  These rules require every Ada compiler to 
implement a bignum package and a rational arithmetic package and use 
them at compile time in some cases.

If you are a language lawyer, you should know how to "take advantage" of 
these special rules to do (numerical) things in Ada.  Of course, if you 
need unbounded rational arithmetic objects not values, the best way is 
to snarf the rational arithmetic package from the compiler.  It isn't as 
easy to use as using Integer--for exactly the same reasons that using 
Unbounded_String is not quite as easy as using String. Of course, as I 
showed above, you can use these exended arithmetic features of Ada very 
easily and not really know that you are doing it.

To sum up, everything you can do with char[] and char* in C can be done 
in Ada with String.

There are things you can do with String in Ada that are not possible in 
C. (Of course, in the sense that both languages are Turing complete, 
that isn't true, but you get my meaning.)

There are things you can do in PL/I with char * varying, that you can do 
in Ada with Ada.Strings.Bounded.

There are things that you can do in C++ with the class str that you can 
do in Ada with Ada.Strings.Unbounded.

If you are bugged by writing To_String, and To_Unbounded_String, go 
ahead and create your own functions.  THERE IS A BIG CATCH HERE.  But 
let me show you what I mean.

First, look at all the functions that are available in 
Ada.Strings.Unbounded.  There is a lot of unexpected wealth there.  For 
example:

with Ada.Strings.Unbounded; use Ada.Strings.Unbounded;
with Ada.Text_IO; use Ada.Text_IO;
procedure Fun is
   U1: Unbounded_String := 3 * 'A';
   U2: Unbounded_String := 2 * "can";
   S1: String := " dance";
   function "&"(L: String; R: Unbounded_String) return String is
   begin return L & To_String(R); end "&";
begin
   Put_Line(" U1 is " & U1);
   Put_Line(" U2 is " & U2);
   Put_Line(" U2 & S1 is " & U2 & S1);
end Fun;

So what is the catch?  Notice that I only created one new "&" operation, 
if I had added:

   function "&"(L: Unbounded_String; R: String) return String is
   begin return To_String(L) & R; end "&";

as well, then the program wouldn't have compiled.  I could use a 
qualified expression inside the third Put_Line to determine which "&" 
functions got called, but best is not to have too may operators floating 
around.  Adding one or two can really help clean up your code, adding 
too many leads to madness.  Personally I think that the functions that 
return String are more useful, so I could have avoided a use clause for 
Ada.Strings.Unbounded  But in this example I wanted to show the 
multiplier notation as well.

Re: conversion

[Jeffrey Carter]

Andrew wrote:
> Ok, so I found the ada.strings.unbounded package spec and body and took a
> look
> at the definition and implementation of unbounded string.  Finally I found
> them!
> 
> Unbounded_string is basically an object that contains a reference to a
> string.

What you are discussing is one specific compiler's implementation of 
Ada.Strings.Unbounded.Unbounded_String. Other compilers may use other 
implementations. This may seem unlikely, but some compilers might treat 
objects of this type as a special case in order to speed up the memory 
management required for them.

Ada has so many ways to use type String that there are few cases when a 
variable-length string type is really needed. Many cases where other 
languages need a variable string can be handled very easily by Ada's 
type String, and many uses of Unbounded_String in Ada are more examples 
of laziness or unfamiliarity with Ada's capabilities than of a real need 
for a variable string.

This is similar to the case of pointers. Access types are needed much 
more rarely in Ada than in many other languages, especially C. People 
who are using a lot of access types, objects, and values in Ada are 
probably using the language ineffectively, frequently because that's the 
way they're used to doing things in other languages.

-- 
Jeff Carter
"I'm a lumberjack and I'm OK."
Monty Python's Flying Circus

conversion

[Andrew]

The more I think about the string/unbounded_string inconvenience the
more I think about polymorphism.  Polymorphism helps readability in
some situations.  In the case of the 'utilities' functions I think
polymorphism
would provide a great service.

The "flavor" that char* and char[] as parameters in functions is that they
seem interchangeable.  I can pass a char* into a function declared to use
char[], and vice-versa.  It's not that way in Ada, most likely for a real
good
reason, but it would sure be nice if there were a way to make it seem that
easy in Ada.

Enter polymorphism.

If overloaded slice inside Unbounded package to return an unbounded_string
an unbounded_string would still need to be created.  I don't think there is
any
way around that part but having the overloaded slice function would bring a
type transparent feeling to using the slice function and many others as
well.
Polymorphism in this case would help.  One way to achieve polymorphism is to
overload the 'utility' functions.

That explains why I had the feeling of extending the functionality of the
Unbounded
package.  It doesn't seem complete.

-- In regard to separate compilation
>Better to use child packages. "is separate" is really an Ada 83
>feature; child packages in Ada 95 is a better way to structure things.
>Sometimes "is separate" is a good way to go, but rarely.
Is the "is separate" feature going away?

-- In regard to gnatmem
gnatmem says it will start a program and you can provide the
command line arguments to it.
"gnatmem <program> <arg1> <arg2>..."

So, I have a program fashionably called testprog that takes two
command line arguments; a path and a filename.  So I try to run
gnatmem (after compiling with debug flag) like:

"gnatmem testprog . testdata.txt"

Gnatmem then says that the program ended unexpectedly.  I can
run "testprog . testdata.txt" from the command line and it works
fine.

-- In regard to GNAT
>Hmm, this is confused. GNAT _is_ the Ada Core Technologies (ACT)
>compiler.
Ok, how about the IDE portion?

Thanks for the help all!

Andrew

Re: conversion

[Preben Randhol]

Alexander Kopilovitch wrote:
> Preben Randhol wrote:
> 
>> > Certainly, a chorus tells you that Ada is not C, but what about
>> > Pascal, which has much more resemblance with Ada? Pascal isn't C,
>> > it does not rely heavily upon pointers, but at the same time it has
>> > quite good and usable strings.
>>
>>Oh I remembered when we had to use Pascal in some introductory
>>programming course at the university that there was several machines
>>crashing due to that the students didn't get the pointers correctly.
> 
> Is it all you remember about Pascal? If so that, perhaps, you should
> not be much surprised when other people associate Ada with Ariane 5
> crash only.

I also remember problematic syntax where you should not put ";" in some
cases. This most students got wrong. Anyway it has been 10 years since I
look at Pascal, but I think I should be able to read it.

> Anyway, why you switched to the Pascal pointers from the theme of
> strings?  Pascal is not C, and Pascal strings aren't naturally
> associated with pointers.

No, I was commenting on what was written (se above) about pointer. I
didn't say Pascal didn't have good strings as I don't remember how they
worked now. Must look it up.

> Finally, as you mention those dangerous pointers in Pascal, let me
> quote the "Programming in Ada 95" by John Barnes (2nd edition, 1998),
> Chapter 10, Access Types, p.171 :
> 
> "Playing with pointers is like playing with fire. Fire is perhaps the
> most important tool known to man. Carefully used, fire brings enormous
> benefits, but when fire gets out of control, disaster strikes.
> Pointers have similar characteristics but are well tamed in the form
> of access types in Ada."

Yes? Not sure I see your point with this quote though.

Preben
-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: conversion

[Preben Randhol]

Andrew wrote:

> seem interchangeable.  I can pass a char* into a function declared to
> use char[], and vice-versa.  It's not that way in Ada, most likely for
> a real good reason, but it would sure be nice if there were a way to
> make it seem that easy in Ada.

Ada doesn't to implicit conversion which is a *very* good thing.

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

conversion

[Andrew]

Just out of curiosity; what would be wrong with moving string into it's own
package?

Andrew

Re: conversion

[David C. Hoos, Sr.]

----- Original Message ----- 
From: "Andrew" <andrew@carroll-tech.net>
To: <comp.lang.ada@ada.eu.org>
Sent: June 29, 2003 4:41 AM
Subject: conversion


> Just out of curiosity; what would be wrong with moving string into it's own
> package?

Lack of backward compatibility.

> 
> Andrew
> 
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 
> 

Re: conversion

[Dmitry A. Kazakov]

On Fri, 27 Jun 2003 22:13:54 GMT, "Robert I. Eachus"
<rieachus@attbi.com> wrote:

>Alexander Kopilovitch wrote:
>
>> The chorus also tells you that in Ada you should not need those conversion
>> too often. Well, they are honest enough, they simply do not use Ada for
>> a job and in an environment where you must mix varying strings and constant
>> strings here and there, and at the same time you can't afford several weeks
>> for design for every change in specifications.
>> 
>> Ada simply understimates need of strings in non-numerical world (almost like
>> Fortran IV, that is, before Fortran 77). I'm sure that Ada people would cry
>> very loudly if there were similar situation with Integer type: imagine that
>> there is unconstrained (for value, not for storage size) type Integer, which
>> objects must be constrained (by value). Then, there are types Bounded_Integer
>> and Unbounded_Integer. Unbounded_Integer is good for general use, except that
>> you always have to write explicit conversion when you assign a literal (say,
>> 1 or 0) to an object of Unbounded_Integer type (currently Ada Integer is like
>> a Pascal string in this respect).
>
>This is silly.  The situation in Ada is exactly the same with integer 
>and string types. 

If you mean that unversal integer is something like String, then you
are probably right. But the difference is that we cannot declare
objects of universal integer. On contrary, for strings we can, but
surprisingly that type is called "Unbounded_String" and even more
surprising is that it is unrelated to String.

It is clear (isn't it) that all different string types have same
semantics and differ only in how they implement that semantics. So
they should be related. That length of a String value cannot be
changed is just a value constraint which by no means changes string
semantics.

So instead of looking for explanations which I doubt would convince
anybody, one could simply admit that, yes, String and Unbounded_String
should be better siblings, but to do it consistently would require too
many changes Ada's ADT model.

For example, what would happen if

   type Name is new Unbounded_String;

Should it produce a new String type? Surely. How should it be named?
Who knows.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: conversion

[Stephen Leake]

"Andrew" <andrew@carroll-tech.net> writes:

> The more I think about the string/unbounded_string inconvenience the
> more I think about polymorphism.  Polymorphism helps readability in
> some situations.  In the case of the 'utilities' functions I think
> polymorphism
> would provide a great service.

It would help tremendously in this discussion if you would post some
actual examples. Simply stating what C does is not helpful; we need to
hear what you think Ada does (so we can point out what you may be
missing), and why it isn't good enough (so we can help you see why it
is :).


> <snip> 
> That explains why I had the feeling of extending the functionality of the
> Unbounded
> package.  It doesn't seem complete.

Please be specific. What features/functionality is it missing?

> -- In regard to separate compilation
> >Better to use child packages. "is separate" is really an Ada 83
> >feature; child packages in Ada 95 is a better way to structure things.
> >Sometimes "is separate" is a good way to go, but rarely.
> Is the "is separate" feature going away?

No.

> -- In regard to gnatmem gnatmem says it will start a program and you
> can provide the command line arguments to it. "gnatmem <program>
> <arg1> <arg2>..."
> 
> So, I have a program fashionably called testprog that takes two
> command line arguments; a path and a filename.  So I try to run
> gnatmem (after compiling with debug flag) like:
> 
> "gnatmem testprog . testdata.txt"

You'll have to post the source for testprog to get help on this one.

> -- In regard to GNAT
> >Hmm, this is confused. GNAT _is_ the Ada Core Technologies (ACT)
> >compiler.
> Ok, how about the IDE portion?

In addition to the compiler, ACT also produces two IDE's; GLIDE and
GPS. GLIDE is a minor enhancement and packaging of Gnu Emacs, and is a
very good IDE; I use Gnu Emacs (but not the GLIDE packaging) for all
work, mainly because I can customize it to do _exactly_ what I want it
to do, partly because it is available on _every_ operating system I
care about (Windows, Linux, Lynx, Solaris, etc.).

GPS is a new IDE (there is not yet a public release). It uses the Gtk
GUI library, and is therefore portable across MS Windows and X-Windows
(but not Lynx, yet). It is not as powerful as Gnu Emacs, and has
limited user customizations. It is definitely a work in progress; the
goal is to compete with MS Visual Studio etc.

GPS will be eaiser to learn than GLIDE for people who are used to
IDE's such as MS Visual Studio or Borland; GLIDE will be easier to
learn for people who are familiar with any flavor of Emacs. 

There is also a small IDE called AdaGide; it is intended for student
use, and has very limited functionality. It is not produced by ACT,
but by a group at the Air Force Academy (I believe).

-- 
-- Stephe

Re: conversion

[Robert I. Eachus]

Dmitry A. Kazakov wrote:

> If you mean that unversal integer is something like String, then you
> are probably right. But the difference is that we cannot declare
> objects of universal integer. On contrary, for strings we can, but
> surprisingly that type is called "Unbounded_String" and even more
> surprising is that it is unrelated to String.

No! No! No!  You are very confused.  First of all, what do you think the 
type of Foo is in:

   Foo: constant := 123456789012;

(Actually in Ada 95 it is _root_integer_ while the literal 123456789012 
is of type _universal_integer_, but that is a detail. (_root_integer_ 
includes all other integer types, including _universal_integer_.)

The Integer type that corresponds most closely to String, is Integer, 
and they are both declared in Standard.

> It is clear (isn't it) that all different string types have same
> semantics and differ only in how they implement that semantics. So
> they should be related.

Yes, so the three different implementations are all clustered under 
Ada.Strings: Ada.Strings.Fixed, Ada.Strings.Bounded, and 
Ada.Strings.Unbounded.

 >                             That length of a String value cannot be
 > changed is just a value constraint which by no means changes string
 > semantics.

No. String values are never constrained, String objects are always 
constrained, often by their initial values.  If I have a function that 
may return a different length string every time it is called, and that 
length is unpredictable in advance?  That is not a problem, it is a 
common idiom:

     while not Done loop
       declare
         Buffer: String := Get_Line;
       begin
         -- process Buffer...
       end;
     end loop;

There is no static/dynamic dichotomy here, nor is there a 
bounded/unbounded distinction, or even constrained/unconstrained. 
Buffer is always constrained to be the same length as the String 
returned by the most recent call to Get_Line.  (Unfortunately that 
function is not Ada.Text_IO.Get_Line, but I hope we will fix that next 
time around.)

> So instead of looking for explanations which I doubt would convince
> anybody, one could simply admit that, yes, String and Unbounded_String
> should be better siblings, but to do it consistently would require too
> many changes Ada's ADT model.

Ada.Strings.Fixed, Ada.Strings.Bounded, and Ada.Strings.Unbounded are 
the siblings.  It may bother you that Ada.Strings.Fixed reuses String, 
and Ada.Strings.Bounded is a generic package you have to instantiate, 
but those are not the issues you are describing here.

> For example, what would happen if
> 
>    type Name is new Unbounded_String;
> 
> Should it produce a new String type? Surely. How should it be named?
> Who knows.

It would be named Name, unless I am missing something, just as:

type New_String is new String;

Creates a new string type named New_String.  Or if you prefer:

type New_String is array(Positive range <>) of Character;
pragma Pack(String);

Do that in Ada and you will find that you get a type with literals like 
"foo"...  String is not a priviledged type in Ada.  You can even create 
a new character type--Character is similarly not special.  For example 
you could create a Cyrillic character type which used ISO 8859/5 
Latin/Cyrillic with the upper and lower pages reversed.  Or whatever.  A 
character type is an enumeration type with character literals.  A string 
type is any array of any character type.
-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: conversion

[Dave Thompson]

On Fri, 27 Jun 2003 15:26:36 +0100, Bill Findlay
<yaldnifw@blueyonder.co.uk> wrote:

> On 27/6/03 13:37, in article uznk3u258.fsf@nasa.gov, "Stephen Leake"
> <Stephe.Leake@nasa.gov> wrote:
> 
> > "Andrew" <andrew@carroll-tech.net> writes:
> >> A fixed string in Ada (to me) is like declaring a char [], you must
> >> specify a size at compile time.
> > 

I would say C char[] is kind of in-between Ada (fixed) String 
and Bounded_String.  Yes the space allocated is fixed, 
at compile time or at best at "elaboration" time (below),
but a string value within it is by convention null-terminated 
and (thus) variable up to the allocated size minus one.

> > Yes.
> 
> Actually, no.
> The size of a fixed string is determined when its declaration is elaborated.
> 
> You specify the index subtype bounds (and hence the size) at run time.
> The bound values need not be known at compile time, although they may be.
> 
C99 does allow array size of locals to be determined at runtime; 
they are called Variable Length Arrays.
You cannot choose lowerbound, as you cannot for any 
array in C, although for strings that is rarely a big issue.
You still aren't guaranteed, and rarely if ever get, 
bounds checking, or even stack overflow checking.
And C99 isn't widely implemented yet, although this 
particular feature is already available in gcc and has 
been for some years as an extension.

It's not clear if this will be picked up by C++, especially since 
as noted elsethread they already have std::string.

> I'm not being pedantic, this is a surprise to many C* programmers.
> 
> In the case of a local string variable, it may take a different size each
> time its scope is entered, e.g.:
> 
>  function f (n : positive) return String is
>     s : String(1..n) := (others => ' ');
>  begin
>     if n > 1 then return s & f(n-1); end if;
>     return s;
>  end f;
> 
> This returns a blank string of length n(n+1)/2.

But in C you (still) can't return, or assign or pass as (value) 
argument, _any_ array, string or otherwise; trying to do so 
at most sets a pointer; and returning a pointer to local space, 
which becomes invalid on the return, is a dangerous error -- 
which some C compilers will even diagnose!

- David.Thompson1 at worldnet.att.net

Re: conversion

[Janeit]

I like to use the package Ustrings. Mirrored on my site and taken from the
cgi binding I find it very useful.

location: http://www.noam.nl/download/ada95/ustrings.adb
             http://www.noam.nl/download/ada95/ustrings.ads


"Andrew" <andrew@carroll-tech.net> schreef in bericht
news:mailman.0.1056888878.2855.comp.lang.ada@ada.eu.org...
> Just out of curiosity; what would be wrong with moving string into it's
own
> package?
>
> Andrew
>

Re: conversion

[Alexander Kopilovitch]

Robert I. Eachus wrote:

>... The situation in Ada is exactly the same with integer 
>and string types.

But the situation in applications is not the same.

>... The Ada.Strings.Bounded and Ada.Strings.Unbounded packages provide a way to 
>create objects that have only a maximum or no minimum and no maximum 
>length respectively.  The equivalent for integer types is a bignum 
>package, which supports any size integer value without Constraint_Error.

So, Unbounded_String corresponds to bignum. Good, I may even like this
analogy. But imagine that Ada language once becomes somehow more popular
(well, not so popular as Visual Basic or even C++ -:) . How many programmers
will need bignum package? Very tiny fraction (and I think that even now the
same is true). But most of programmers that use (even moderately) widespread
language will need Unbounded_String.

The varying strings of unspecified maximum size are common for many applications
outside of current, quite restricted Ada world. And arrays of such strings
are no less common. And I'm sure that at least initialization with literals
must be provided directly, without any explicit conversions.

I can imagine that most often there are ways (of which I'm not aware)
to avoid heavy use of Unbounded_Strings. If this is true then I wish this ways
be explained -- for programmer, not for language lawyer - in some book
(or at least in comprehensive article) dedicated to this issue.

Dmitry A. Kazakov wrote:

>So instead of looking for explanations which I doubt would convince
>anybody, one could simply admit that, yes, String and Unbounded_String
>should be better siblings, but to do it consistently would require too
>many changes Ada's ADT model.

I tried (about year ago, I think) to propose (in Ada-Comment) a construct
for this purpose:

  type Y is private envelope of X;

which should lead to

  type Unbounded_String is private envelope of String;

This my proposition did not sink in silence, I was faced with a list of
remarks and questions... I tried to respond for them, but failed miserably,
due to lack of language lawyer skills and experience.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: conversion

[Georg Bauhaus]

Alexander Kopilovitch <aek@vib.usr.pu.ru> wrote:
: The varying strings of unspecified maximum size are common for many applications
: outside of current, quite restricted Ada world. And arrays of such strings
: are no less common.

Care to list some examples?

Re: conversion

[Alexander Kopilovitch]

Georg Bauhaus wrote:

> > The varying strings of unspecified maximum size are common for many applications
> > outside of current, quite restricted Ada world. And arrays of such strings
> > are no less common.
>
>Care to list some examples?

  /* C/C++ example */

  char *Titles[] = {
                    "Quizionary",
                    "Nose To Nose",
                    "Myself",
                    "General Dissent",
                    "Veteran's Opinion",
                    "Corporate Science Weekly",
                    "Truth, Wealth, Health",
                    "Bribery Times"
                   };


  { Object Pascal example }
                                                
  const
        Dishes : array [1..4] of String = (
                                           'black pudding',
                                           'crab soup',
                                           'steak & kidney pie',
                                           'lemon tart'
                                          );
                                                




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: conversion

[Robert I. Eachus]

Alexander Kopilovitch wrote:

>   /* C/C++ example */
> 
>   char *Titles[] = {
>                     "Quizionary",
>                     "Nose To Nose",
>                     "Myself",
>                     "General Dissent",
>                     "Veteran's Opinion",
>                     "Corporate Science Weekly",
>                     "Truth, Wealth, Health",
>                     "Bribery Times"
>                    };
> 
> 
>   { Object Pascal example }
>                                                 
>   const
>         Dishes : array [1..4] of String = (
>                                            'black pudding',
>                                            'crab soup',
>                                            'steak & kidney pie',
>                                            'lemon tart'
>                                           );

Two examples.  One without any Ada support packages, and one that uses
Ada.Strings.Bounded.  Personally I think that during standarization, to 
much was added in, and as a result, Ada.Strings.Bounded is harder to use 
than it should be.  But of course, you can roll your own, the way you 
had to in Ada 83.

But notice two major differences between the Ada way, and the C and 
Pascal way.  The Ada solutions are built around standard Ada features, 
not special case features, and the Ada solution allows for non-constant 
arrays, in fact the individual elements can change in length. (Yes, I 
know that in the C++ case you can assign other pointers, but the 
original values can't be modified as such.)

procedure Varying is -- an example of how to create ragged arrays in Ada.

   subtype Lim_Int is Integer range 0..30;
   type Inner(L: Lim_Int := 0) is record S: String(1..L); end record;
   type Wrapper is record I: Inner; end record;
   type Ragged_Array is array (Integer range <>) of Wrapper;

   function "+" (S: in String) return Wrapper is
   begin return (I =>(S'Length, S)); end "+";

   function "+" (W: in Wrapper) return String is
   begin return W.I.S; end "+";

   Dishes: Ragged_Array := (+"black pudding",
                            +"crab soup",
                            +"steak & kidney pie",
                            +"lemon tart");

   Titles: Ragged_Array := (+"Quizionary",
                            +"Nose To Nose",
                            +"Myself",
                            +"General Dissent",
                            +"Veteran's Opinion",
                            +"Corporate Science Weekly",
                            +"Truth, Wealth, Health",
                            +"Bribery Times");

begin null; end Varying;

with Ada.Strings.Bounded;
procedure Varying2 is -- an example of how to use Ada.Strings.Bounded.

   package Bounded_Str is new
              Ada.Strings.Bounded.Generic_Bounded_Length(30);

   subtype Bounded_String is Bounded_Str.Bounded_String;

   function "+" (S: in String) return Bounded_String
   is begin return
        Bounded_Str.To_Bounded_String(S, Ada.Strings.Error);
   end "+";

   function "+" (B: in Bounded_String) return String renames
        Bounded_Str.To_String;

   type Ragged_Array is array (Integer range <>) of Bounded_String;

   Dishes: Ragged_Array := (+"black pudding",
                            +"crab soup",
                            +"steak & kidney pie",
                            +"lemon tart");

   Titles: Ragged_Array := (+"Quizionary",
                            +"Nose To Nose",
                            +"Myself",
                            +"General Dissent",
                            +"Veteran's Opinion",
                            +"Corporate Science Weekly",
                            +"Truth, Wealth, Health",
                            +"Bribery Times");

begin null; end Varying2;

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: conversion

[Jeffrey Carter]

Robert I. Eachus wrote:
> 
>   Dishes: Ragged_Array := (+"black pudding",
>                            +"crab soup",
>                            +"steak & kidney pie",
>                            +"lemon tart");

I think we should allow the unary function "\" for this kind of thing, 
so we can drive C people crazy by writing

Dishes : Ragged_Array := (\"black pudding",
                           \"crab soup",
                           \"steak & kidney pie",
                           \"lemon tart");

-- 
Jeff Carter
"This trial is a travesty. It's a travesty of a mockery of a
sham of a mockery of a travesty of two mockeries of a sham. ...
Do you realize there's not a single homosexual on that jury?"
Bananas

Re: conversion

[Chad R. Meiners]

"Jeffrey Carter" <spam@spam.com> wrote in message
news:3F07B075.8020807@spam.com...
> I think we should allow the unary function "\" for this kind of thing,
> so we can drive C people crazy by writing

Nice, but what we really need is the new unary "" function for this kind of
thing ;-)  You would just have to be careful where you make it visible ;-)

Re: conversion

[Georg Bauhaus]

Alexander Kopilovitch <aek@vib.usr.pu.ru> wrote:
: Georg Bauhaus wrote:
: 
:> > The varying strings of unspecified maximum size are common for many applications
:> > outside of current, quite restricted Ada world. And arrays of such strings
:> > are no less common.
:>
:>Care to list some examples?
: 
:  /* C/C++ example */
: 
:  char *Titles[] = {
:                    "Quizionary",
:                    "Nose To Nose",
:                    "Myself",
:                    "General Dissent",
:                    "Veteran's Opinion",
:                    "Corporate Science Weekly",
:                    "Truth, Wealth, Health",
:                    "Bribery Times"
:                   };

If you need to have syntactic sugar, you can have

   Titles: constant array(1..8) of String_Access :=
     (-"Quizionary",
      -"Nose To Nose",
      -"Myself",
      -"General Dissent",
      -"Veteran's Opinion",
      -"Corporate Science Weekly",
      -"Truth, Wealth, Health",
      -"Bribery Times");

where
   function "-"(s: String) return String_Access;

I am always trying something like the following. The string literals end
up as literals in the assembly listing, so there does not seem to
be allocation at run time, despite new:

procedure str is

   type String_Access is access constant String;

   Titles: constant array(1..8) of String_Access :=
     (new String'("Quizionary"),
      new String'("Nose To Nose"),
      new String'("Myself"),
      new String'("General Dissent"),
      new String'("Veteran's Opinion"),
      new String'("Corporate Science Weekly"),
      new String'("Truth, Wealth, Health"),
      new String'("Bribery Times"));

begin
   null;
end str;

But, as a sidenote, I alway try to avoid string literals in source
code. They make the text fixed, a typo requires recompilation,
language translation requires that programmers be involved, because
the translators do not know how to recompile the program to include
the latest translations, etc. If that seems too much, there could be
an enumeration of the 8 strings above, such that, for every natural
language (or other variation in the string values), you could have

    array(Languages, Kinds_of_Titles) of String_Access := ...;

in some library package.

What is more, the varying size you have mentioned is known at
compile time in your example. But for sure string literals are not
the usual input to a string processing program?

-- Georg

Re: conversion

[Alexander Kopilovitch]

Robert I. Eachus wrote:

>But notice two major differences between the Ada way, and the C and 
>Pascal way.  The Ada solutions are built around standard Ada features, 
>not special case features,

I do not see major difference between C and Ada general approaches to
strings (Pascal is another matter). In both C and Ada strings are no more
than regular arrays of characters - in core language, and all support for
them is in standard library only.
  The particular difference between C and Ada regarding literals in a
string array initializer is then simply a consequence of C's array/pointer
kinship.

>procedure Varying is -- an example of how to create ragged arrays in Ada.
>
>   subtype Lim_Int is Integer range 0..30;
>   type Inner(L: Lim_Int := 0) is record S: String(1..L); end record;
>   type Wrapper is record I: Inner; end record;
>   type Ragged_Array is array (Integer range <>) of Wrapper;
>
>   function "+" (S: in String) return Wrapper is
>   begin return (I =>(S'Length, S)); end "+";
>
>   function "+" (W: in Wrapper) return String is
>   begin return W.I.S; end "+";

Just interesting detail: you use the same name "+" for both conversions.
(I do not argue against that, I simply found that somehow symptomatic.)

>   Dishes: Ragged_Array := (+"black pudding",
>                            +"crab soup",
>                            +"steak & kidney pie",
>                            +"lemon tart");
>
>   Titles: Ragged_Array := (+"Quizionary",
>                            +"Nose To Nose",
>                            +"Myself",
>                            +"General Dissent",
>                            +"Veteran's Opinion",
>                            +"Corporate Science Weekly",
>                            +"Truth, Wealth, Health",
>                            +"Bribery Times");
>
>begin null; end Varying;

As you may expect, I'm not satisfied with two things here:

1) Lim_Int - why 30, why not 123 ? Why should I always bother myself with
justification of this value, and then, at the end, sooner or later, invite
something like Ariane 5 effect (hopefully, in much lesser scale -;) ?

2) "+" at the beginning of each string literal. It reads as "Warning! This
programming language does not pay particular attention to strings, you will
be often obliged to do manually some common things with the strings".

First point is certainly minor, because I can use Unbounded_String here.
But the second point is quite significant. Just compare the situation with
richness of representations for literals for numeric types in Ada.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: conversion

[Stephen Leake]

> Alexander Kopilovitch <aek@vib.usr.pu.ru> wrote:
> : Georg Bauhaus wrote:
> : 
> :> > The varying strings of unspecified maximum size are common for
> :> > many applications outside of current, quite restricted Ada
> :> > world. And arrays of such strings are no less common.
> :>
> :>Care to list some examples?
> : 
> :  /* C/C++ example */
> : 
> :  char *Titles[] = {
> :                    "Quizionary",
> :                    "Nose To Nose",
> :                    "Myself",
> :                    "General Dissent",
> :                    "Veteran's Opinion",
> :                    "Corporate Science Weekly",
> :                    "Truth, Wealth, Health",
> :                    "Bribery Times"
> :                   };

These are _not_ "varying strings of unspecified length"!

These are all _constant_ strings, whose length is determined from the
initializer. The compiler should put them in the "constant" section,
so you can't even treat them as ordinary C null-terminated variable
strings; you can't write to them!
-- 
-- Stephe

Re: conversion

[Alexander Kopilovitch]

Stephen Leake wrote:

>> :> > The varying strings of unspecified maximum size are common for
>> :> > many applications outside of current, quite restricted Ada
>> :> > world. And arrays of such strings are no less common.
>> :>
>> :>Care to list some examples?
>> : 
>> :  /* C/C++ example */
>> : 
>> :  char *Titles[] = {
>> :                    "Quizionary",
>> :                    "Nose To Nose",
>> :                    "Myself",
>> :                    "General Dissent",
>> :                    "Veteran's Opinion",
>> :                    "Corporate Science Weekly",
>> :                    "Truth, Wealth, Health",
>> :                    "Bribery Times"
>> :                   };
>
>These are _not_ "varying strings of unspecified length"!
>
>These are all _constant_ strings, whose length is determined from the
>initializer. The compiler should put them in the "constant" section,
>so you can't even treat them as ordinary C null-terminated variable
>strings; you can't write to them!

"varying" always is relative to some account of time, right? Well, I meant
more "lifetime" than "run-time" of a program. 



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: conversion

[Dmitry A. Kazakov]

On Thu, 03 Jul 2003 07:03:43 GMT, "Robert I. Eachus"
<rieachus@attbi.com> wrote:

>Dmitry A. Kazakov wrote:
>
>> If you mean that unversal integer is something like String, then you
>> are probably right. But the difference is that we cannot declare
>> objects of universal integer. On contrary, for strings we can, but
>> surprisingly that type is called "Unbounded_String" and even more
>> surprising is that it is unrelated to String.
>
>No! No! No!  You are very confused.  First of all, what do you think the 
>type of Foo is in:
>
>   Foo: constant := 123456789012;
>
>(Actually in Ada 95 it is _root_integer_ while the literal 123456789012 
>is of type _universal_integer_, but that is a detail. (_root_integer_ 
>includes all other integer types, including _universal_integer_.)

This is what I meant. You can consider string literals as being of
some unversal string type. Then you can have some parent string type
for all string types. Call it root string if you want. The hierarchy
might look like:

root string
   universal string = Unbounded_String
      String
      Bounded_String
      user-defined strings with literals
   user-defined strings with no literals

>The Integer type that corresponds most closely to String, is Integer, 
>and they are both declared in Standard.

It does not. Because Integer is constrained.

>> It is clear (isn't it) that all different string types have same
>> semantics and differ only in how they implement that semantics. So
>> they should be related.
>
>Yes, so the three different implementations are all clustered under 
>Ada.Strings: Ada.Strings.Fixed, Ada.Strings.Bounded, and 
>Ada.Strings.Unbounded.

This does not help. Types have to be related, order of packages is
rather a cosmetic thing.

> >                             That length of a String value cannot be
> > changed is just a value constraint which by no means changes string
> > semantics.
>
>No. String values are never constrained, String objects are always 
>constrained, often by their initial values.  If I have a function that 
>may return a different length string every time it is called, and that 
>length is unpredictable in advance?  That is not a problem, it is a 
>common idiom:
>
>     while not Done loop
>       declare
>         Buffer: String := Get_Line;
>       begin
>         -- process Buffer...
>       end;
>     end loop;

You missed the point. String as a concept has a semantics which allows
*any* values. That String as a type implementing  the concept has
values constrained in some special way, does not change that
semantics.

>There is no static/dynamic dichotomy here, nor is there a 
>bounded/unbounded distinction, or even constrained/unconstrained. 
>Buffer is always constrained to be the same length as the String 
>returned by the most recent call to Get_Line.  (Unfortunately that 
>function is not Ada.Text_IO.Get_Line, but I hope we will fix that next 
>time around.)

Yes.

>> So instead of looking for explanations which I doubt would convince
>> anybody, one could simply admit that, yes, String and Unbounded_String
>> should be better siblings, but to do it consistently would require too
>> many changes Ada's ADT model.
>
>Ada.Strings.Fixed, Ada.Strings.Bounded, and Ada.Strings.Unbounded are 
>the siblings.
>It may bother you that Ada.Strings.Fixed reuses String, 
>and Ada.Strings.Bounded is a generic package you have to instantiate, 
>but those are not the issues you are describing here.
>
>> For example, what would happen if
>> 
>>    type Name is new Unbounded_String;
>> 
>> Should it produce a new String type? Surely. How should it be named?
>> Who knows.
>
>It would be named Name, unless I am missing something, just as:
>
>type New_String is new String;
>
>Creates a new string type named New_String.  Or if you prefer:
>
>type New_String is array(Positive range <>) of Character;
>pragma Pack(String);
>
>Do that in Ada and you will find that you get a type with literals like 
>"foo"...  String is not a priviledged type in Ada.  You can even create 
>a new character type--Character is similarly not special.  For example 
>you could create a Cyrillic character type which used ISO 8859/5 
>Latin/Cyrillic with the upper and lower pages reversed.  Or whatever.  A 
>character type is an enumeration type with character literals.  A string 
>type is any array of any character type.

The problem is. Should String and Unbounded_String be siblings
(descendants of same base), or better, as many would rightfully
expect, String be *both* a subtype and a supertype of
Unbounded_String, then we will have a lot of problems to solve.
Because ADT in Ada is presently unable to deal with that.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: conversion

[Robert I. Eachus]

Dmitry A. Kazakov wrote:

> This is what I meant. You can consider string literals as being of
> some unversal string type. Then you can have some parent string type
> for all string types. Call it root string if you want. The hierarchy
> might look like...

This is where your confusion starts.  String is the root type for all 
strings of Latin1 characters.  If you want a universal type what it 
needs to cover are things like Wide_String, Wide_Wide_String, and any 
user defined string types with either a different set of characters, or 
different index types.  Strings in Ada are much richer than your 
imagination realizes:

type Color is (Red, Orange, Yellow, Green, Blue, Violet);

type Digit is ('0','1','2','3','4','5','6','7','8','9');

type Digit_String is array (Color range <>) of Digit; -- new string type

Foo: Digit_String := "12345";

>>The Integer type that corresponds most closely to String, is Integer, 
>>and they are both declared in Standard.

> It does not. Because Integer is constrained.

And String is constrained in exactly the same way.  Most Ada 
implementations now have Integer'Last = 2**32-1, which not 
coincidentally is the maximum number of Characters in a String.

> You missed the point. String as a concept has a semantics which allows
> *any* values. That String as a type implementing  the concept has
> values constrained in some special way, does not change that
> semantics.

Hoo boy, you still are wearing blinders.  In concept a string could be 
any ordered set of say Japanese Kanji, or if you prefer, and the 
Japanese do, a mixture of Katakana, Hirigana, and Kanji.  In Ada this 
does't fit in a String, but Japanese is a subset of Wide_Character. And 
  so Wide_String is fine for Japanese. On the other hand, Wide_Character 
cannot represent all of the Chinese characters, there are already 
several additional planes of additional Chinese characters defined in 
ISO 10646.  In Ada the corresponding string type, if supported, would be 
Wide_Wide_Character.

> The problem is. Should String and Unbounded_String be siblings
> (descendants of same base), or better, as many would rightfully
> expect, String be *both* a subtype and a supertype of
> Unbounded_String, then we will have a lot of problems to solve.
> Because ADT in Ada is presently unable to deal with that.

But Unbounded_String is really a (very useful) container type for 
Standard.String, no more, no less.  I can easily imagine--because I have 
had to do it in Ada 83 which was not as friendly in this area--writing a 
package which had to display messages in Latin (English), Cyrillic, and 
Arabic.  Three separate (7-bit) character sets, and the corresponding 
string types.  If I were to rewrite that code in Ada 95, I would 
probably use the corresponding ISO 8859 8-bit character sets.  But I 
would need an instance of Ada.Strings.Bounded_String for each.  (Well 
actually only the Latin1 version could be an instance of 
Ada.Strings.Bounded_String, but that is a detail.)

Why am I spending so much time on this?  Simple.  A lot of effort over 
the years has gone into the support for additional character sets (and 
string types) in Ada.  The most recent discussion was whether or not to 
"officially" change the default character set to one of the new 8859 
variants with the Euro symbol.  (Verdict, no.)  People who look at Ada 
through a mono-linguistic filter tend to miss this.  But what really 
suprises me is the fact that many people whose first language is not 
English still tend to think of Ada as having an English bias. 
(Technically, Ada does have a slight Western European bias, but very 
slight, see 3.5.2.(4). And as I indicated above Ada does not define the 
Wide_Wide_Character type needed for full Chinese language support.)

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: conversion

[Dmitry A. Kazakov]

On Wed, 09 Jul 2003 17:04:53 GMT, "Robert I. Eachus"
<rieachus@attbi.com> wrote:

>Dmitry A. Kazakov wrote:
>
>> This is what I meant. You can consider string literals as being of
>> some unversal string type. Then you can have some parent string type
>> for all string types. Call it root string if you want. The hierarchy
>> might look like...
>
>This is where your confusion starts.  String is the root type for all 
>strings of Latin1 characters.  If you want a universal type what it 
>needs to cover are things like Wide_String, Wide_Wide_String, and any 
>user defined string types with either a different set of characters, or 
>different index types.  Strings in Ada are much richer than your 
>imagination realizes:

Your example proves exactly the opposite. How to get an
Unbounded_String of Colors?

>type Color is (Red, Orange, Yellow, Green, Blue, Violet);
>
>type Digit is ('0','1','2','3','4','5','6','7','8','9');
>
>type Digit_String is array (Color range <>) of Digit; -- new string type
>
>Foo: Digit_String := "12345";

Yes, and why is this? Because Ada 83 did it (arrays) in a right,
though a very limited way. On the contrary, Ada 95 failed to extend
ADT in a reasonable way. So we have got a private Unbounded_String
falling out of the concept.

>>>The Integer type that corresponds most closely to String, is Integer, 
>>>and they are both declared in Standard.
>
>> It does not. Because Integer is constrained.
>
>And String is constrained in exactly the same way.  Most Ada 
>implementations now have Integer'Last = 2**32-1, which not 
>coincidentally is the maximum number of Characters in a String.

Compare:

   X : Integer := 5;
   Y : String  := "12345";
begin
   X := 7;
   Y := "1234567";

A decalration of a string variable, in effect, also declares an
anonymous constrained subtype which makes the last assignment illegal.
It is not so for integer types.

>> You missed the point. String as a concept has a semantics which allows
>> *any* values. That String as a type implementing  the concept has
>> values constrained in some special way, does not change that
>> semantics.
>
>Hoo boy, you still are wearing blinders.  In concept a string could be 
>any ordered set of say Japanese Kanji, or if you prefer, and the 
>Japanese do, a mixture of Katakana, Hirigana, and Kanji.

Absolutely!

>In Ada this 
>does't fit in a String, but Japanese is a subset of Wide_Character. And 
>  so Wide_String is fine for Japanese. On the other hand, Wide_Character 
>cannot represent all of the Chinese characters, there are already 
>several additional planes of additional Chinese characters defined in 
>ISO 10646.  In Ada the corresponding string type, if supported, would be 
>Wide_Wide_Character.

It is not a problem if you have a full blown ADT. If we could say that
one array is a subtype of another, then all problems would disappear.
The type of elements will become a representation issue. So even
Wide_Wide_Very_Wide_Unbounded_Remote_Oracle_String could be yet made a
sub- and supertype of String, i.e. substitutable. 

>> The problem is. Should String and Unbounded_String be siblings
>> (descendants of same base), or better, as many would rightfully
>> expect, String be *both* a subtype and a supertype of
>> Unbounded_String, then we will have a lot of problems to solve.
>> Because ADT in Ada is presently unable to deal with that.
>
>But Unbounded_String is really a (very useful) container type for 
>Standard.String, no more, no less.

Yes, it does not solve the problem, so people are unhappy with it.
What I am trying to say is that to get it right would require too many
changes in Ada, which was impossible then and, I am afraid, is still
impossible now.

>I can easily imagine--because I have 
>had to do it in Ada 83 which was not as friendly in this area--writing a 
>package which had to display messages in Latin (English), Cyrillic, and 
>Arabic.  Three separate (7-bit) character sets, and the corresponding 
>string types.  If I were to rewrite that code in Ada 95, I would 
>probably use the corresponding ISO 8859 8-bit character sets.  But I 
>would need an instance of Ada.Strings.Bounded_String for each.  (Well 
>actually only the Latin1 version could be an instance of 
>Ada.Strings.Bounded_String, but that is a detail.)
>
>Why am I spending so much time on this?  Simple.  A lot of effort over 
>the years has gone into the support for additional character sets (and 
>string types) in Ada.  The most recent discussion was whether or not to 
>"officially" change the default character set to one of the new 8859 
>variants with the Euro symbol.  (Verdict, no.)  People who look at Ada 
>through a mono-linguistic filter tend to miss this.  But what really 
>suprises me is the fact that many people whose first language is not 
>English still tend to think of Ada as having an English bias.

(:-)) I would recommend you to take a look at Russian edition of
revised report on ALGOL 68, with Cyrillic identifiers and keywords.
Even a native Russian is unable to understand such a garbage.

>(Technically, Ada does have a slight Western European bias, but very 
>slight, see 3.5.2.(4). And as I indicated above Ada does not define the 
>Wide_Wide_Character type needed for full Chinese language support.)

And it also should not. ADT can deal with all that on the basis of
user-defined types. You cannot support all possible languages. It is
utopic. Alone Russian has dozens of different code tables. Germans are
going to eliminate their beta (�). Would change the language standard
each time some of 200 crazy governments over the world modify an
alphabet?

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: conversion

[Alexander Kopilovitch]

Dmitry A. Kazakov wrote:

>(:-)) I would recommend you to take a look at Russian edition of
>revised report on ALGOL 68, with Cyrillic identifiers and keywords.
>Even a native Russian is unable to understand such a garbage.

Oh, yes. Those "Russian keywords" were great -;) . If I remember right, "file"
became "fund" (that is, if we translate that Russian keyword for "file" into
English we'll get "fund" or "foundation"). But generally (not for Algol 68
only, but everywhere) it always was the common way to understand "russified"
programming term: just guess how it was called in English.

>... Alone Russian has dozens of different code tables.

You exaggregate, I think - I believe that there are no more than 8-10 Cyrillic
code tables in current use -;) . There is surely no more than 4 Cyrillic code
tables for PC (including Windows, DOS, OS/2, Linux and various flavours of Unix),
other non-Russian computers (except IBM mainframes) add none. (Don't forget
that most of hardware/software "legacy" in Russia was completely and irreversibly
disappeared over past 15 years.)



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia