Re: How (or Where?) to get started on Ada? (Properly)

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 4 Sep 2013 09:05:19 -0700 (PDT), e.s.harney@gmail.com wrote:

>> Extensive should mean coverage tests, I suppose. Not the number of times
>> the same function with same parameters was called and nobody noticed it
>> crashed? 
> 
> Perhaps my choice of words wasn't ideal.. What I really meant was not
> really tested in the context of unit tests, but something that is widely
> used or at least part of a widely used library (and thus checked/analyzed
> for conformance/compatibility/vulnerabilities, as well as optimized). 

Some Ada libraries are more popular some are less. I don't think that
popularity is much relevant. More important is whether the library is
maintained and, no less important, whether the maintainers bother keeping
it backward compatible. Most, if not all, Ada libraries are extremely
stable.

You may expect 20+ years old Ada code compiled with no or marginal changes,
and working.

> Back then though, I thought of this as more of a hack, since I was
> creating lots of small functions that essentially just worked around the
> fact of not having a heap. Is this accepted practice when working with
> Ada?

Yes, it is usually safer and more efficient than using unbounded strings
(which internally are allocated on the heap). For most applications a
string either comes from outside or is constant or has well defined limit
on its length (e.g. some buffer).

Dynamically allocated strings are overused and misused.

> How does Ada do these stack-allocations of variable size? Is there any
> performance downside to it? (e.g. by having to relocate things on the
> stack, or stacks getting huge?)

When you return a string from a function, it is not the function which
tells where the result is allocated:

   function Foo return String is
   begin
       return "foo";
   end Foo;

can be used as:

   X : String := Foo; -- This is on the stack

or

   type String_Ptr is access String;

   Y : String_Ptr := new String'(Foo); -- This is in the heap
 
or

   type Custom_Storage_Pool_Pointer is access String;
   for Custom_Storage_Pool_Pointer'Storage_Pool use My_Pool;

   Z : Custom_Storage_Pool_Pointer := new String'(Foo); -- Somewhere else

>> This is an orthogonal issue. A string is an array of code points. As such
> it cannot be UTF-8 or not. 
> 
> "Idealized" Spec and "conventions" (libraries/APIs) sort of drift apart
> here in most languages in my experience, which is why I haven't really
> perceived this as an orthogonal issue so far. (Things like the length
> function counting non-bmp "code points" differently depending on how the
> run time is compiled in python or counting always only the size in bytes
> in Go, or having no surrogate-aware substring functionality in Java, etc.)

In Ada there is S'Length which is the length of the array (and string) =
how many characters it has. There also is X'Size which tells how many bits
are needed to store X in memory. Size /= Length obviously.

If you bring encoding into it, then depending on which memory unit is used
by the encoding, you have encoding length in these units. E.g. UTF-8 uses
octets, UTF-16 uses words, ASCII uses chunks of 7-bits, RADIX-50 uses 5 1/3
bits ad so on.

Yes, libraries impose certain encoding, e.g. Windows A-calls use ASCII,
W-calls use UTF-16. That does not influence Ada program. If you look at Ada
interfaces to such libraries (which are called "bindings"), the design is
that you pass an Ada string to the procedure or get it from a function, and
it is the binding's business to convert it as appropriate. Ada is a
strongly typed language. You cannot do anything wrong. If the bindings is
thin, it rather deploys a string type native to the library. E.g. thin
bindings to C libraries are using char_array or chars_ptr . You cannot pass
String where char_array is expected. You must convert it using the function
To_C, which adds NUL etc. If you don't try to fool Ada compiler (in order
to getting performance boost, in 99.9% cases illusory), you are quite safe.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de