Re: Constraint error?

["Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>]

I almost always find it easier to immediately jump to Ada.Strings.Unbounded
because to used fixed strings, you just end up duplicating in some manner
the things you get automagically in Unbounded. The only problem is that in
Standard Issue Ada, you still need to know about fixed strings when first
learning the language because they are the basis for string literals &
Text_IO. You can shield the beginner from the Text_IO part with a
non-standard skin* over it. However, to use string literals, you've got to
still understand the fixed array of characters aspect of it. The same
applies to the attributes that have something to do with strings ('Image and
'Value come to mind.)

I think it would be useful for beginning users of Ada to be shown everything
in the context of Unbounded strings for their simplicity and ease of use.
I'm just not sure it is possible to totally avoid talking about standard
strings and Ada.Strings.Fixed. Is it better for the beginner to be forced to
learn about fixed strings and after all the pain be shown how to use
.Bounded and .Unbounded? Or should an approach be found to talk about
everything from the perspective of Unbounded & then ease the newbie into the
more difficult aspects later? And of course, as you observe, everything you
learn about fixed strings applies to any array one might use, so maybe its
best to get it over with up front. It certainly isn't any worse than
teaching about strings in C - but that isn't saying much. One would like to
claim that Ada is easier than C - which it is - but WRT strings, there is
just a lot to know and a paradigm shift to go through before the "easier"
part shows up.


*Maybe "skin" is the word to distinguish between a thin binding, a thick
binding and a subsystem? You have a "binding" a "skin" and a "subsystem"
wherein a "skin" shields you from uncomfortable parameters, but doesn't add
any significant functionality? But this is another debate...

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:60OS6.3835$v4.183613@www.newsranger.com...
> In article <fIzS6.25747$DG1.4262027@news1.rdc1.mi.home.com>, McDoobie
says...
> >I'm really starting to like Ada, but compared to using C it still feels
like
> >I'm wrestling a gorilla. I'll get it yet.
>
> What mostly seems to be tripping you up here is string handling. You
shouldn't
> feel bad about that, because that's the thing that frustrates most
beginners.
> Ada's string handling is actually much *more* powerful and convienent than
C's
> in most cases, but you have to go about things quite differently.
>
> The main thing to realize is that an Ada string is *not* just an array of
> characters; its also a range within that array (a starting and ending
index). If
> you don't specify that range explicitly, then most routines assume its the
first
> character of the array to the last. The character ASCII.NUL has *no*
special
> significance in Ada.
>
> Now this philosophy forces 3 main methods for dealing with strings on you.
The
> first is that you declare your string arrays large enough to hold whatever
you
> might ever want to put in them, and keep track of the valid characters in
> separate variables. Usually the start of the string can be assumed to be
at the
> first character ('first), so you only really have to keep track of the
logical
> end. This is the method that has to be used with the Text_IO.Get_*
routines, as
> they use this technique for their interface. Likewise, if you write your
own
> procedures that use a string as an "out" or "in out" parameter, you will
also
> need to pass out a "length" parameter.
>
> The second way to deal with strings is to delay their declaration until
you can
> assign the value directly into them. That way you can leave the bounds off
of
> the declaration and let it size itself perfectly to the contents. This is
the
> easiest method to deal with, if you can use it. Most of the attributes
> ('whatever) that deal with strings can be used with this method. If you
want to
> use this method in your own subprograms, you should endevor to always
return
> strings as function return values. Of course this method only works if you
don't
> plan on changing the contents. For example (my apologies if my newsreader
hoses
> the formatting):
>
> declare
> Width_Answer : constant String := Answer (1..Answer_Length);
> begin
> -- work with Width_Answer in here.
> ..
> end;
>
> Now if you *do* need to change the string's contents, or have to declare
it
> before you can assign into it, then you can use the third way: the
> Ada.Strings.Unbounded (or Ada.Strings.Bounded) package. Few predefined Ada
> routines use these packages, but you may have a good use for them in your
own
> code.
>
> Make sure you are acquainted with all the language defined attributes that
deal
> with strings and arrays. They are central to how you do strings in Ada.
>
> As a final point, remember that strings are really just arrays, so the
first two
> techniques work just as well for arrays as they do for strings. :-)
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com