Re: Flexible Strings (was Equality operator...)

Re: Flexible Strings (was Equality operator...)

[Matthew Heaney]

In article <9704301422.AA07755@most>, "W. Wesley Groleau (Wes)"
<wwgrol@PSESERV3.FW.HAC.COM> wrote:

>I never had a problem implementing an Ada-83 equivalent of bounded strings
>so that no heap was required.  Did it pretty much as Matt Heaney suggested,
>after reviewing a couple of "free" dynamic_strings packages and finding
>that nearly every operation leaked heap.

Many people don't realize that Ada was more or less designed to that you
don't have to use heap.

The problem with Ada 83 is that when you do need it, memory leaks are bound
to happen, because clients often forget to clean up the data structure. 
Thankfully, this has been corrected in Ada 95.

And just to remind everyone, an access type (or even an array type) is a
low-level primitive.  Clients of a (high-level) abstraction shouldn't have
to manipulate access objects directly - use access types to implement an
(unbounded) abstraction.  Pointers are strictly an implementation feature
of the language, for use by the programmer to craft higher-level
abstractions.

>The one thing I really missed, however, is still not available in Ada 95:
>assigning string literals to these things.  I think that using unary "+"
>is a C-like solution (i.e., sacrificing "intuitive" readability to save
>keystrokes).  Defining a function that looked like a type conversion was
>better for the READER, but since you can't use the actual type name,
>it posed a memory inconvenience on the writer.

I often think that automatic type conversions such as are available in C++
would be useful.  You're right, it seems that

declare
   S : String_Buffer := "initial value of S";
begin
...

would be OK.  But I don't know.  Norm Cohen had a post once about how
difficult it is to reason about the correctness of software where automatic
conversions were taking place.  The bad thing is that what is happening at
run-time isn't obvious from reading the code, because conversion routines
are being invoked automatically.

Not being able to understand what's happening at run-time by reading the
static source text is what originally prompted Dijkstra to admonish against
the use of the goto.  It seems that Microsoft's Hungarian notation is a
desperate attempt to maintain intellectual control of when automatic
conversions are happening in C.

Where do you draw the line about syntactic difficultness vs semantic
correctness:

Automatic_Conversion:
declare
   SA : constant String_Buffer_Array := ("I'd", "gladly", "lose", "me",
"to", "find", "you");
begin

Explicit_Conversion:
declare
   SA : constant String_Buffer_Array :=  (
      To_String_Buffer ("I'd"), 
      To_String_Buffer ("gladly"), 
      To_String_Buffer ("lose"),
      To_String_Buffer ("me"),
      To_String_Buffer ("to"),
      To_String_Buffer ("find"),
      To_String_Buffer ("you"));
begin

A_Happy_Medium:
declare
   SA : constant String_Buffer_Array := (+"I'd", +"gladly", +"lose", +"me",
+"to", +"find", +"you")
begin

Yes, explicit conversion makes it obvious that conversion is happening, but
you tend to lost the forest through the trees with the middle approach
above.

I got the "+" idea from Barnes' book.  Don't think of it as a hack; think
of it as what it is: the identity operator.  It's a happy medium between
the 2 extremes.

There's probably a comprimise in there somewhere.  Everyone is still
realing from the heights of automatic conversions in Algol 68 - that vastly
complicated the language - and Ada 83's staticness was an (over)reaction to
that.  Things have been loosened up a bit in Ada 95, but there's probably
room for more loosening.  But how far do you go with syntactic ease before
you comprimise semantic characteristics?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Flexible Strings (was Equality operator...)

[W. Wesley Groleau (Wes)]

I never had a problem implementing an Ada-83 equivalent of bounded strings
so that no heap was required.  Did it pretty much as Matt Heaney suggested,
after reviewing a couple of "free" dynamic_strings packages and finding
that nearly every operation leaked heap.

The one thing I really missed, however, is still not available in Ada 95:
assigning string literals to these things.  I think that using unary "+"
is a C-like solution (i.e., sacrificing "intuitive" readability to save
keystrokes).  Defining a function that looked like a type conversion was
better for the READER, but since you can't use the actual type name,
it posed a memory inconvenience on the writer.

---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Hughes Defense Communications (MS 10-41)                 Home: 219-471-7206
Fort Wayne,  IN   46808                  (Unix): wwgrol@pseserv3.fw.hac.com
--
SPAM should be sent to   I.want.one@mailbombs.for.idiots.org
If you want to be prosecuted under 27 USC 227, go ahead and send it here.
---------------------------------------------------------------------------

Re: Flexible Strings (was Equality operator...)

[Robert Dewar]

Wes said

<<The problem with Ada 83 is that when you do need it, memory leaks are bound
to happen, because clients often forget to clean up the data structure.
Thankfully, this has been corrected in Ada 95.
>>

That's a ferocious and incorrect over-generalization. Of course it is 
possible to use the heap in Ada 83 programs without having memory leaks.
In fact I would guess that the majority of all Ada programs ever written
are in this category.

Yes, you can program memory leaks in Ada 83 if you are sloppy.

No, Ada 95 does not magically prevent this, although the use of
finalization can help, if used carefully -- if used carelessly
it can make things worse, by obscuring where the leaks are taking
place.

Re: Flexible Strings (was Equality operator...)

[W. Wesley Groleau (Wes)]

(Also posted to comp.lang.ada)

:> >I never had a problem implementing an Ada-83 equivalent of bounded strings
:> >so that no heap was required.  Did it pretty much as Matt Heaney suggested,
:> >after reviewing a couple of "free" dynamic_strings packages and finding
:> >that nearly every operation leaked heap.
:>
:> The problem with Ada 83 is that when you do need it, memory leaks are bound
:> to happen, because clients often forget to clean up the data structure.

The problem with the packages I was offered was that the clients COULDN'T
clean up the heap.  These guys had every string on the heap, and if a client
wanted to say A := A & B the result was a new allocation overwriting the
previous pointer in A.

:> I got the "+" idea from Barnes' book.  Don't think of it as a hack; think
:> of it as what it is: the identity operator.  It's a happy medium between
:> the 2 extremes.

I agree with you that automatic conversion is generally harmful.  And that
too much explicit conversion is information hiding of the wrong sort, i.e.,
hiding the abstraction in implementation clutter.  The thing with "+" is
more an issue of retraining one's instincts--after more than 35 years, it's
hard not to think of it as something associated with quantities.  But then,
the strangeness of it is a point in its favor because it catches the
attention.  If it were routine, being only a single character, it could
easily be overlooked.

---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Hughes Defense Communications (MS 10-41)                 Home: 219-471-7206
Fort Wayne,  IN   46808                  (Unix): wwgrol@pseserv3.fw.hac.com
--
SPAM should be sent to   I.want.one@mailbombs.for.idiots.org
If you want to be prosecuted under 27 USC 227, go ahead and send it here.
---------------------------------------------------------------------------

Re: Flexible Strings (was Equality operator...)

[Kevin Cline]

mheaney@ni.net (Matthew Heaney) wrote:

>In article <9704301422.AA07755@most>, "W. Wesley Groleau (Wes)"
><wwgrol@PSESERV3.FW.HAC.COM> wrote:
>
>>I never had a problem implementing an Ada-83 equivalent of bounded strings
>>so that no heap was required.  Did it pretty much as Matt Heaney suggested,
>>after reviewing a couple of "free" dynamic_strings packages and finding
>>that nearly every operation leaked heap.
>
>Many people don't realize that Ada was more or less designed to that you
>don't have to use heap.

Heap usage is required for programs which solve problems whose size
is unknown and run on machines with unknown memory resources.
Embedded applications don't have these requirements, so dynamic allocation
wasn't interesting to the Ada '83 design team.

>
>The problem with Ada 83 is that when you do need it, memory leaks are bound
>to happen, because clients often forget to clean up the data structure. 
>Thankfully, this has been corrected in Ada 95.

Too late, too late...


>Explicit_Conversion:
>declare
>   SA : constant String_Buffer_Array :=  (
>      To_String_Buffer ("I'd"), 
>      To_String_Buffer ("gladly"), 
>      To_String_Buffer ("lose"),
>      To_String_Buffer ("me"),
>      To_String_Buffer ("to"),
>      To_String_Buffer ("find"),
>      To_String_Buffer ("you"));

This is about the point where C++ programmers turn away laughing.

Re: Flexible Strings (was Equality operator...)

[Robert Dewar]

Wes said

<<I agree with you that automatic conversion is generally harmful.  And that
too much explicit conversion is information hiding of the wrong sort, i.e.,
hiding the abstraction in implementation clutter.  The thing with "+" is
more an issue of retraining one's instincts--after more than 35 years, it's
hard not to think of it as something associated with quantities.  But then,
the strangeness of it is a point in its favor because it catches the
attention.  If it were routine, being only a single character, it could
easily be overlooked.>>

Jean Ichbiah argued strongly during the Ada 95 design for introducing one
additional unary operator that would have no predefined meaning, to be used
for these kind of conversion operations.

I supported that, and suggested the possibility of using the international
currency conversion symbol for this purpose (it is sometimes called pillow).

However, we seemed to be alone, and others did not like the idea, so
must not be a good idea after all :-)

Re: Flexible Strings (was Equality operator...)

[Robert Dewar]

Kevin Cline said

<<Heap usage is required for programs which solve problems whose size
is unknown and run on machines with unknown memory resources.
Embedded applications don't have these requirements, so dynamic allocation
wasn't interesting to the Ada '83 design team.>>

This is nonsense and in no way reflects reality. Of course the Ada 83
design team recognized the importance of dynamic allocation. This is why
Ada 83 has a full facility for this capability, comparable to that provided
in many other languages (such as C, PL/1, Pascal).

Ada 83 did NOT require garbage collection, but the design went out of its
way to accomodate garbage collection (in strong contrast to the design of
C for example). In fact the designers (and Fisher in particular in his
role as DoD mentor of this project) were hopeful that technology would
be developed to allow the effective use of garbage collection even in
real time programs. 

Ada 83 also did not provide user defined finalization. I really can't 
recall that ever being discussed as a possibility -- perhaps the concept
was not even sufficiently familiar in the late 70's when Ada was designed.

But to say that dynamic allocatoin wasn't interesting to the design team
is just plain wrong. 

Re: Flexible Strings (was Equality operator...)

[Jon S Anthony]

In article <3F2AA8DEC61418AE.502E81A8ECA1C4E7.3A25DE2FB38755A4@library-proxy.airnews.net> clines@delete_this.airmail.net (Kevin Cline) writes:

> Heap usage is required for programs which solve problems whose size
> is unknown and run on machines with unknown memory resources.
> Embedded applications don't have these requirements, so dynamic allocation
> wasn't interesting to the Ada '83 design team.

This is where I start laughing.  Any reason why you think stating this
sort of laughable, completely unsupported and in direct conflict with
the facts opinion is of any use whatsoever?


> >Explicit_Conversion:
> >declare
> >   SA : constant String_Buffer_Array :=  (
> >      To_String_Buffer ("I'd"), 
> >      To_String_Buffer ("gladly"), 
> >      To_String_Buffer ("lose"),
> >      To_String_Buffer ("me"),
> >      To_String_Buffer ("to"),
> >      To_String_Buffer ("find"),
> >      To_String_Buffer ("you"));
> 
> This is about the point where C++ programmers turn away laughing.

As they go back to trying to get their templates to work - or just try
to figure out what they were even trying to say with them...

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Flexible Strings (was Equality operator...)

[Kevin Cline]

dewar@merv.cs.nyu.edu (Robert Dewar) wrote:


>But to say that dynamic allocatoin wasn't interesting to the design team
>is just plain wrong. 

Evidently it wasn't important enough for the standard to mandate any useful
semantics for unchecked_deallocation.

Re: Flexible Strings (was Equality operator...)

[Robert Dewar]

Kevin Cline said

<<Evidently it wasn't important enough for the standard to mandate any useful
semantics for unchecked_deallocation.>>

That shows a misunderstanding of language semantics. There is no easy way
to formalize what it means to free storage that would encompass all possible
dynamic allocation techiques, including effects of fragmentation etc.

For example, if we try to define that certain classes of programs should
run for ever without getting storage error, then it is still a semantically
valid implementation to just use up virtual memory for ever (if necessary
asking for new tapes to be loaded to store the old junk).

So no language standard can meaninfuly specify formal semantiocs for
what deallocation might mean, beyond specifying that reference to freed
storage is in an appropriate sense incorrect.

So Ada is no different from C or Pascal or any other lanuage here. I suspect
that Kevin is not the kind of person who spends his time studying formal
standards, but if you want to follow this up, for example go look at the
definition of Dispose in the ANSI Pascal standard.

What does the Ada standard say about Unchecked_Deallocation:

    9  Free(X), when X is not equal to null first performs finalization,
       as described in 7.6.  It then deallocates the storage occupied by
       the object designated by X. If the storage pool is a user-defined


Nice, but of course deallocate is not really formally defined, then we have
the implementation advice:

17   For a standard storage pool, Free should actually reclaim the storage.

again "actually reclaim" is not formally defined.

BUT, does this matter in practice? Of course not, all Ada compilers always
have followed this advice for the standard storage pool, and it would be
surprising if it were otherwise. This is exactly the same situation as
observing that all C compilers actualy free storage when free is used.

Is it possible to make a formally conforming implementation in which
unchecked deallocation is useless. Most certainly. It is also possible
to make a formally conforming impl,ementation in which all integr
additions take one hour to complete. Bothy implementations are formally
correct according to the standard, both are totally useless!

Re: Flexible Strings (was Equality operator...)

[Kaz Kylheku]

In article <dewar.862755569@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>So no language standard can meaninfuly specify formal semantiocs for
>what deallocation might mean, beyond specifying that reference to freed
>storage is in an appropriate sense incorrect.
>
>So Ada is no different from C or Pascal or any other lanuage here. I suspect
>that Kevin is not the kind of person who spends his time studying formal
>standards, but if you want to follow this up, for example go look at the
>definition of Dispose in the ANSI Pascal standard.

Actually Ada must be different here. If were were discussing C, we wouldn't
need to generate a week long thread regarding what malloc() and free() are, and
how to use them.

>What does the Ada standard say about Unchecked_Deallocation:
>
>    9  Free(X), when X is not equal to null first performs finalization,
>       as described in 7.6.  It then deallocates the storage occupied by
>       the object designated by X. If the storage pool is a user-defined
>
>
>Nice, but of course deallocate is not really formally defined, then we have
>the implementation advice:
>
>17   For a standard storage pool, Free should actually reclaim the storage.
>
>again "actually reclaim" is not formally defined.
>
>BUT, does this matter in practice? Of course not, all Ada compilers always
>have followed this advice for the standard storage pool, and it would be
>surprising if it were otherwise. This is exactly the same situation as
>observing that all C compilers actualy free storage when free is used.

But the C standard firmly says that ``The free function causes the space
pointed to by ptr to be deallocated, that is, made available for further
allocation'' (ISO 9899:1990 7.10.3.2 The free function). This pretty much
constitutes a requirement that the C implementation actually deallocate
when free is called, which carries more weight than a mere observation
about what all existing implementations do.

Re: Flexible Strings (was Equality operator...)

[Robert A Duff]

In article <53F35740C6EF076C.14BEEF8227919F71.39E2B6FED1F30314@library-proxy.airnews.net>,
Kevin Cline <clines@delete_this.airmail.net> wrote:
>I was a member of ANSI X3H3 (PHIGS) for two years.  I read the Ada'83 standard
>cover to cover.  I've read most of the C++ DWP.  Perhaps there is not a lot of
>difference in theory between Ada and C storage management, but there is a huge
>practical difference.  In C or C++, the application programmer can take
>complete control of the allocation process in a couple of ways.  In C++, new
>and delete can be redefined globally or on a class-by-class basis.
>Additionally, the compiler vendor's implementation of malloc and free can be 
>replaced with one more carefully tuned to the particular application.
>Although not mandated by the standard, almost all C compilers do link malloc
>and free from their run-time library, and replacement implementations can be
>linked instead.  Few Ada compilation systems are so open.

What you say may be true of Ada 83, but Ada 95 allows user-defined
storage pools.  You can use whatever allocation strategy you like.  This
is a required feature of all Ada compilers.  It much more flexible than
globally replacing malloc, because you get control on a per-access-type
basis.

- Bob

Re: Flexible Strings (was Equality operator...)

[Jon S Anthony]

In article <mheaney-ya023680000705970214190001@news.ni.net> mheaney@ni.net (Matthew Heaney) writes:

> I'm confused.  Isn't that what storage pools are for in Ada 95?  I can

Yes.

> create a pool so that new and Unchecked_Deallocation call routines I
> define, on a type-by-type basis.  What's the difference?

The Ada route affords you rather more control over the implementation
and use of the pool and the "access types" assigned to it.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Flexible Strings (was Equality operator...)

[Jon S Anthony]

In article <53F35740C6EF076C.14BEEF8227919F71.39E2B6FED1F30314@library-proxy.airnews.net> clines@delete_this.airmail.net (Kevin Cline) writes:

> I was a member of ANSI X3H3 (PHIGS) for two years.  I read the
> Ada'83 standard cover to cover.

No longer relevant.


> I've read most of the C++ DWP.  Perhaps there is not a lot of
> difference in theory between Ada and C storage management, but there
> is a huge practical difference.

OK, let's hear it.


> In C or C++, the application programmer can take complete control of
> the allocation process in a couple of ways.  In C++, new and delete
> can be redefined globally or on a class-by-class basis.

That's what Ada provides with storage pools.  In fact, it is rather
tighter as you can control the usage of the "pointer types" much more.


> Additionally, the compiler vendor's implementation of malloc and
> free can be replaced with one more carefully tuned to the particular
> application.

First this is (as you point out, but apparently promptly forget) and
implementation issue and not a language issue.  Second, this has been
done in several Ada implementations.  So, you still haven't given an
example.


> Although not mandated by the standard, almost all C compilers do

So, again irrelevant.


> link malloc and free from their run-time library, and replacement
> implementations can be linked instead.  Few Ada compilation systems
> are so open.

There is no reason whatsoever to keep you from doing this as long as
you know what the link names for the alloc/dealloc for the standard
pool are.  Typically this will in fact be good ol' malloc/free.  So,
just replace them.  If not, get the names and replace them.

/Jon



-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Flexible Strings (was Equality operator...)

[Robert Dewar]

<<But the C standard firmly says that ``The free function causes the space
pointed to by ptr to be deallocated, that is, made available for further
allocation'' (ISO 9899:1990 7.10.3.2 The free function). This pretty much
constitutes a requirement that the C implementation actually deallocate
when free is called, which carries more weight than a mere observation
about what all existing implementations do.>>


That's a misconception. The above statement is one of intent, but it
has no semantic force, because it would be impossible to specify the
conditions under which storage could be reused. For example if the
total heap size is 2N words, and we allocate two blocks of N and then
free them, then can we allocate a single 2N word block -- the C
standard is silent on this, and indeed has to be.

So the above paragraph is not "firmly" saying anything. An implementation
that ignores free is formally conformant. It would take the attitude that
the storage is indeed made available for further allocation, but
unfortunately none of your subsequent requests were able to be filled
using this storage.

Of course a C compiler that abused this too much would be useless and no one
would use it, just as an Ada compiler that ignored unchecked deallocation
would also be useless. Note that the Ada RM does indeed say:

17   For a standard storage pool, Free should actually reclaim the storage.

which has just as much force from a formal point of view as the statementin the C standard. In the Ada RM it is Implementation Advice, which is much more
honest. In the C standard it is also implementation advice, but it is less
obvious that this is the case, as we seel from Kaz's post.

It is a very common misconception for those without experience in what
semantic definition is about, and what as-if semantics are about, to want
to put statements like this into a language definition, but it is misleading
and confusing. However, there is usually enough vocal support for such
semantic nonsense that it creeps in from time to time in any language
standard (the Ada RM is not without its examples of this kind of thing!)

Actually I think the Implementation Advice sections in the RM are very
helpful, because, since they are non-normative, you can use rather informal
("you know what I mean") kind of language, and say things that you could
not say at all in normative text.

Re: Flexible Strings (was Equality operator...)

[Robert Dewar]

Kevin Cline said

<<I was a member of ANSI X3H3 (PHIGS) for two years.  I read the Ada'83 standard
cover to cover.  I've read most of the C++ DWP.  Perhaps there is not a lot of
difference in theory between Ada and C storage management, but there is a huge
practical difference.  In C or C++, the application programmer can take
complete control of the allocation process in a couple of ways.  In C++, new
and delete can be redefined globally or on a class-by-class basis.
Additionally, the compiler vendor's implementation of malloc and free can be
replaced with one more carefully tuned to the particular application.
Although not mandated by the standard, almost all C compilers do link malloc
and free from their run-time library, and replacement implementations can be
linked instead.  Few Ada compilation systems are so open.>>


Apparently you have not kept up with the times, you are comparing an
obsolete version of Ada to C++, which is rather inappropriate, considering
that Ada 95 is standardized several years before C++!

So I suggest you bring yourself up to date before making statements about
what "few Ada compilation systems" may or may not provide. Our convention
in this newsgroup is that Ada undecorated means the current version of
Ada, i.e. Ada 95 (note that the Ada 95 standard is now over two years
old, there are over 50 validated compilers, and Ada 95 is available on
virtually every common architecture, so we are not talking science fiction
here).

One of the important features in Ada 95 is the storage pool mechanism,
which provides considerably more flexibility than the corresponding
C++ mechanisms. All versions of GNAT, and most if not all, other
Ada 95 technologies fully support this storage pool feature.

Re: Flexible Strings (was Equality operator...)

[Robert Dewar]

<<But the C standard firmly says that ``The free function causes the space
pointed to by ptr to be deallocated, that is, made available for further
allocation'' (ISO 9899:1990 7.10.3.2 The free function). This pretty much
constitutes a requirement that the C implementation actually deallocate
when free is called, which carries more weight than a mere observation
about what all existing implementations do.>>

Let me give a possible implementation of the C standard. Suppose we are
on a machine with huge address space, and lots of virtual memory. We
assume for example a 256-bit virtual address space.

Now our C implementation works this way, malloc always returns the
next sequentially available location. Free works by simply removing
the relevant pages from the page table.

This is a perfectly defensible and usable implementation of C. Would
it violate the standard? Of course not!

Re: Flexible Strings (was Equality operator...)

[Robert Dewar]

Bob said

<<Of course, I admit that the C standard is easier to understand on this
particular point, if you're just a programmer trying to write programs,
and not a language lawyer.  The Ada standard goes out of its way to
raise questions of this nature, unfortunately.  Nonetheless, I claim
that the requirements of C and Ada are identical with respect to whether
free/Unch_Dealloc must/should reclaim storage.  They're just written in
a different style.>>

Well you are the author, so if you say the C standard is easier to understand
on this point, I suppose that must have some force. But let me quote again
the words you wrote here in the Ada standard:

17   For a standard storage pool, Free should actually reclaim the storage.

That sure seems like an easy-to-understand unambiguous statement of intent
to me, I don't see it any harder to understand than the referenced statement
from the C standard.

Re: Flexible Strings (was Equality operator...)

[Robert A Duff]

In article <5kocg6$hln@bcrkh13.bnr.ca>,
Kaz Kylheku <kaz@vision.crest.nt.com> wrote:
>But the C standard firmly says that ``The free function causes the space
>pointed to by ptr to be deallocated, that is, made available for further
>allocation'' (ISO 9899:1990 7.10.3.2 The free function). This pretty much
>constitutes a requirement that the C implementation actually deallocate
>when free is called, which carries more weight than a mere observation
>about what all existing implementations do.

It *sounds* firm, but it isn't really saying anything precise.  For
example, it doesn't address the issue of fragmentation.  If I deallocate
1000 objects of size 100 bytes each, does that mean I can now allocate a
single 100,000-byte object in that space?  After all, it says that
storage is "available for allocation".  Do you interpret this
requirement to require compaction of storage?  Sure sounds like it, but
that surely wasn't the intent.

Can you write a test program that detects the difference between a C
implementation that obeys the above "requirement", and one that doesn't?
If not, then it should be viewed merely as Implementation Advice, from a
formal point of view.

Of course, I admit that the C standard is easier to understand on this
particular point, if you're just a programmer trying to write programs,
and not a language lawyer.  The Ada standard goes out of its way to
raise questions of this nature, unfortunately.  Nonetheless, I claim
that the requirements of C and Ada are identical with respect to whether
free/Unch_Dealloc must/should reclaim storage.  They're just written in
a different style.

- Bob

Re: Flexible Strings (was Equality operator...)

[Kevin Cline]

In article <dewar.862755569@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>So no language standard can meaninfuly specify formal semantiocs for
>what deallocation might mean, beyond specifying that reference to freed
>storage is in an appropriate sense incorrect.
>
>So Ada is no different from C or Pascal or any other lanuage here. I suspect
>that Kevin is not the kind of person who spends his time studying formal
>standards, but if you want to follow this up, for example go look at the
>definition of Dispose in the ANSI Pascal standard.

I was a member of ANSI X3H3 (PHIGS) for two years.  I read the Ada'83 standard
cover to cover.  I've read most of the C++ DWP.  Perhaps there is not a lot of
difference in theory between Ada and C storage management, but there is a huge
practical difference.  In C or C++, the application programmer can take
complete control of the allocation process in a couple of ways.  In C++, new
and delete can be redefined globally or on a class-by-class basis.
Additionally, the compiler vendor's implementation of malloc and free can be 
replaced with one more carefully tuned to the particular application.
Although not mandated by the standard, almost all C compilers do link malloc
and free from their run-time library, and replacement implementations can be
linked instead.  Few Ada compilation systems are so open.

Re: Flexible Strings (was Equality operator...)

[Matthew Heaney]

In article
<53F35740C6EF076C.14BEEF8227919F71.39E2B6FED1F30314@library-proxy.airnews.ne
t>, clines@delete_this.airmail.net (Kevin Cline) wrote:

>Perhaps there is not a lot of
>difference in theory between Ada and C storage management, but there is a huge
>practical difference.  In C or C++, the application programmer can take
>complete control of the allocation process in a couple of ways.  In C++, new
>and delete can be redefined globally or on a class-by-class basis.
>Additionally, the compiler vendor's implementation of malloc and free can be 
>replaced with one more carefully tuned to the particular application.
>Although not mandated by the standard, almost all C compilers do link malloc
>and free from their run-time library, and replacement implementations can be
>linked instead.  Few Ada compilation systems are so open.

I'm confused.  Isn't that what storage pools are for in Ada 95?  I can
create a pool so that new and Unchecked_Deallocation call routines I
define, on a type-by-type basis.  What's the difference?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Flexible Strings (was Equality operator...)

[Robert I. Eachus]

In article <E9sAq2.HE8@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

  > Of course, I admit that the C standard is easier to understand on this
  > particular point, if you're just a programmer trying to write programs,
  > and not a language lawyer.  The Ada standard goes out of its way to
  > raise questions of this nature, unfortunately.  Nonetheless, I claim
  > that the requirements of C and Ada are identical with respect to whether
  > free/Unch_Dealloc must/should reclaim storage.  They're just written in
  > a different style.

   The three reasons that the Ada standard doesn't always require
deallocation to do anything are finalization, storage pools, and
tasking.  It is easy to say, that Ada should require that storage is
always freed, but if you free a running task, or an object whose
finialization never completes, or an object in a storage pool with a
user supplied Deallocate procedure, the standard can't require
immediate deallocation.

   In all other cases, as I read 13.11.2(10) the wording is pretty
similar to the C standard.  And of course the three exceptions above
are not that likely to disturb anyone in real programs.  (Unless the
actual behavior of the Deallocate or Finalize routine involved is due
to a bug, not design.)


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Flexible Strings (was Equality operator...)

[Erik Magnuson]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> BUT, does this matter in practice? Of course not, all Ada compilers always
> have followed this advice for the standard storage pool, and it would be
> surprising if it were otherwise. This is exactly the same situation as
> observing that all C compilers actualy free storage when free is used.
> 
> Is it possible to make a formally conforming implementation in which
> unchecked deallocation is useless. Most certainly. It is also possible
> to make a formally conforming impl,ementation in which all integr
> additions take one hour to complete. Bothy implementations are formally
> correct according to the standard, both are totally useless!

Robert, your claim is a little broad here. I have used 2 different Ada 83
compilers runtimes for embedded targets that did NOT implement any storage
reclamation for Unchecked_Conversion, i.e., UC simply set the pointer to
null. (One of these was the small runtime from a company you used to work
with!) Now, both of these compilers also had versions that supported
reclaiming storage. But for small, embedded systems, it is often nice to
have a simple "new" that you can use at startup without including any
overhead for UC. If you believe that these compilers were useless, you had
better not fly on any modern commercial airliner.

-- 
Erik

Re: Flexible Strings (was Equality operator...)

[Robert Dewar]

John Volan said

<<Erik Magnuson wrote:

> Robert, your claim is a little broad here. I have used 2 different Ada 83
> compilers runtimes for embedded targets that did NOT implement any storage
> reclamation for Unchecked_Conversion, i.e., UC simply set the pointer to>>

(UC => UD as per later clarification)


For an Ada 83 compiler with a narrow intended target of use (embedded
targets), this may not be a bad choice. Many coding standards for high
reliability code allow dynamic allocation, but do NOT allow dynamic
freeing (the former is safe and easy to analyse, the latter potentially
dangerous and very hard to analyze).

So, I can certainly see that this choice might make sense for such a
compiler. I was really thinking in terms of general purpose Ada 83
compilers when I made the statement.

But in any case, the storage pools of Ada 95 give a much greater level
of control. For examle, in the embedded case, you could use the storage
pools to

a) completely forbid deallocatoin
b) ignore deallocation
c) implement an alloc/free that had bounded time behavior

etc.

Re: Flexible Strings (was Equality operator...)

[Robert Dewar]

Erik said

<<Robert, your claim is a little broad here. I have used 2 different Ada 83
compilers runtimes for embedded targets that did NOT implement any storage
reclamation for Unchecked_Conversion, i.e., UC simply set the pointer to
null. (One of these was the small runtime from a company you used to work
with!) Now, both of these compilers also had versions that supported
reclaiming storage. But for small, embedded systems, it is often nice to
have a simple "new" that you can use at startup without including any
overhead for UC. If you believe that these compilers were useless, you had
better not fly on any modern commercial airliner.>>

(finally I see your original post, rather than a quote of a piece of it)

It is DEFINITIELY appropriate for an Ada 83 compiler to offer a choice
of storage allocators in this manner. Actually it is interesting to note
that from what you say, they DID provide unchecked deallocation that worked
via an option.

In fact I can imagine an Ada 83 compiler for an embedded system which
simply completely ignored UC under all circumstances, and as you rightly
point out, this is often an appropriate choice for small embedded
systems. Actually what you really want in this case is not a UC that
does nothing at runtime, you want to declare access types for which UD
(oops UC => UD throughout, I'm copying your mistake :-) is simply not
permitted, period.

Note that in Ada 95, providing you are using a compiler, such as GNAT, that
fully supports annex H, then you have *exactly* what you need via

   pragma Restrictions (No_Unchecked_Deallocation);

this will cause a program to be illegal if it attempts to instantiate
Unchecked_Deallocation -- just what you want for your small embedded system
example.

Re: Flexible Strings (was Equality operator...)

[Matthew Heaney]

In article <dewar.863277551@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:


>But in any case, the storage pools of Ada 95 give a much greater level
>of control. For examle, in the embedded case, you could use the storage
>pools to
>
>a) completely forbid deallocatoin
>b) ignore deallocation
>c) implement an alloc/free that had bounded time behavior

a) By forbid do you mean detect (and therefore prevent) deallocation at
compile time?

Can you explain these with examples?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Flexible Strings (was Equality operator...)

[Matthew Heaney]

In article <dewar.863287346@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:


>Note that in Ada 95, providing you are using a compiler, such as GNAT, that
>fully supports annex H, then you have *exactly* what you need via
>
>   pragma Restrictions (No_Unchecked_Deallocation);
>
>this will cause a program to be illegal if it attempts to instantiate
>Unchecked_Deallocation -- just what you want for your small embedded system
>example.

Is this restriction global, or can you forbid deallocation on a per access
type basis?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Flexible Strings (was Equality operator...)

[John G. Volan]

Erik Magnuson wrote:

> Robert, your claim is a little broad here. I have used 2 different Ada 83
> compilers runtimes for embedded targets that did NOT implement any storage
> reclamation for Unchecked_Conversion, i.e., UC simply set the pointer to
                  ^^^^^^^^^^^^^^^^^^^^        ^^
                  Unchecked_Deallocation      UD

Well, we knew what you meant to say.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Flexible Strings (was Equality operator...)

[Robert Dewar]

Matthew asks

<<>a) completely forbid deallocatoin
>b) ignore deallocation
>c) implement an alloc/free that had bounded time behavior

a) By forbid do you mean detect (and therefore prevent) deallocation at
compile time?

Can you explain these with examples?>>


a) body = "raise Program_Error"
b) body = "null"
c) body = "complicated allocatoin algorithm left as reader excercise :-)

By forbid I mean raise Program_Error, if you want to prevent dealloation
at compile time, you use pragma Restrictions (it's all in the RM!)

Re: Flexible Strings (was Equality operator...)

[Erik Magnuson]

"John G. Volan" <johnvolan@sprintmail.com> writes:

> Erik Magnuson wrote:
> > reclamation for Unchecked_Conversion, i.e., UC simply set the pointer to
>                   ^^^^^^^^^^^^^^^^^^^^        ^^
>                   Unchecked_Deallocation      UD
> 
> Well, we knew what you meant to say.

Thanks. Somehow the threads on "no code for Unchecked_Conversion" and this
one collided in my local namespace... (Would I have made the same mistake if
the routines were called Conversion_Unchecked and Deallocation_Unchecked ;-)

-- 
Erik