Re: A simple ADA puzzle (I haven't the answer)

Re: A simple ADA puzzle (I haven't the answer)

[Christoph Karl Walter Grein]

From: "Dmitry A.Kazakov" <mailbox@dmitry-kazakov.de>
> As for Ada strings, there are only two problems related:
> 
> 1. The default values for discriminants shall not have any implicit
> effects on the memory allocation policy. That was a mistake of Ada 83.

This syntax was defined exactly for this purpose. So it's _not_ a mistake. You may argue whether that was a clever choice. But there is no other use for the default discriminant than allowing discriminant changes.
An alternative would have been to use a special reserved word. They tried to minimize the number of reserved words and used solutions with special syntax wherever possible.

There are other syntax elements that are not very intuitive either:

   Type_Name'Identifier vs. Type_Name'(Identifier) vs. Type_Name(Identifier)

> 2. Unbounded_String and Bounded_String are nasty patches, which should
> be replaced when Ada will finally have a common supertype for all
> types strings.

This will never by I guess.
____________________________________________________
Aufnehmen, abschicken, nah sein - So einfach ist 
WEB.DE Video-Mail: http://freemail.web.de/?mc=021200

Re: A simple ADA puzzle (I haven't the answer)

[Randy Brukardt]

"Christoph Karl Walter Grein" <AdaMagica@web.de> wrote in message
news:mailman.119.1087461544.391.comp.lang.ada@ada-france.org...
> From: "Dmitry A.Kazakov" <mailbox@dmitry-kazakov.de>
> > As for Ada strings, there are only two problems related:
> >
> > 1. The default values for discriminants shall not have any implicit
> > effects on the memory allocation policy. That was a mistake of Ada 83.
>
> This syntax was defined exactly for this purpose. So it's _not_ a mistake.
You may argue whether
> that was a clever choice. But there is no other use for the default
discriminant than allowing
> discriminant changes. An alternative would have been to use a special
reserved word. They tried
> to minimize the number of reserved words and used solutions with special
syntax wherever possible.

I have to agree with Dmitry. Tying "defaulted discriminants" to "mutable
objects" was an awful mistake in Ada 83. It caused Tucker Taft and the rest
of the Ada 95 design team no end of trouble, and it has continued to cause
the ARG trouble. They're separate concepts, and they should have been
handled separately. I think most of the ARG would agree with this opinion (I
*know* Tucker would).

                    Randy.

A simple ADA puzzle (I haven't the answer)

[Abby]

Hi! I have this code:

  type LEN_TYPE is array (INTEGER range <>)
    of CHARACTER;

  type STRING_TYPE (LEN : INTEGER := 0) is
    record
      STRING : LEN_TYPE (1 .. LEN);
    end record;

  type UNC2_ARRAY_TYPE is array (INTEGER range <>)
    of STRING_TYPE;

  type RET2_TYPE (INIT : INTEGER := 0) is
    record
      IFOS : UNC2_ARRAY_TYPE (1 .. INIT);
    end record;

  type RET_TYPE
       ( DEF : INTEGER := 0 )
  is
    record
      ID  : INTEGER;
      IFO : RET2_TYPE (INIT => DEF);
    end record;

  type UNC_ARRAY_TYPE is
    array (INTEGER range <>) of
      RET_TYPE;

and i'd like to initialize and use a variable of type UNC_ARRAY_TYPE (for
the unconstraint array and records choose any value you want, al least 1
:) ). I can say that simply write  VAR : UNC_ARRAY_TYPE (1..3);  gives some
warning but compiles, but gives also a beautiful constraint_error when you
use it, obviously. Any ideas? Thanx for your time!

Re: A simple ADA puzzle (I haven't the answer)

[Frank J. Lhota]

The problem with your definition of String_Type is that an unconstrained
object of this type would require an outrageous amount of memory. Assume
that we declare:

    My_Name : STRING_TYPE;

Since My_Name is unconstrained, we can assign any STRING_TYPE value to
My_Name, including

    My_Name := STRING_TYPE'( Len => Integer'Last, String => ( others => '
' ) );

So even though My_Name.Len is initially 0, My_Name must be allocated enough
space to contain the largest object of STRING_TYPE. Frankly, I'd be
surprised if there was space for one such object. There is nothing
surprising about getting some sort of error when declaring an array of 3
unconstrained objects of type STRING_TYPE, although Storage_Error should
have been raised instead of Constraint_Error.

The right way to fix this depends on one question: is there a reasonable
upper bound to the length of the Len discriminant?

----------------------------------------

If  there is a reasonable upper limit on the LEN discriminant, say 100, we
can constrain the LEN component as follows:

  type LEN_TYPE is array (INTEGER range <>)
    of CHARACTER;


  subtype STRING_LEN is INTEGER range 0 .. 100;

  type STRING_TYPE (LEN : STRING_LEN := 0) is
    record
      STRING : LEN_TYPE (1 .. LEN);
    end record;

With these declararations, LEN is constrained to be no larger than 100. You
can now declare an unconstrained object of type STRING_TYPE without
requiring ridiculous amounts of space.

----------------------------------------

If  there is no reasonable upper limit on the LEN discriminant, if say LEN
can vary from 1 to hundreds of thousands, then the best solution would be to
use an array of pointers. This would be the only reasonable way to create an
array of objects of widely varying sizes. For example:

  type LEN_TYPE is array (INTEGER range <>)
    of CHARACTER;

  type STRING_TYPE (LEN : INTEGER := 0) is
    record
      STRING : LEN_TYPE (1 .. LEN);
    end record;

  type STRING_ACC is access all STRING_TYPE;
  procedure Deallocate is
     new Ada.Unchecked_Deallocation( STRING_TYPE, STRING_ACC );

  type UNC2_ARRAY_TYPE is array (INTEGER range <>)
    of STRING_ACC;

This solution does require that the array component values be allocated (and
deallocated once you are finished with them), but it does allow you to make
a table of STRING_TYPE values that take on the full range of LEN
discriminants.

Re: A simple ADA puzzle (I haven't the answer)

[Abby]

Thanx for your answer. Sorry if I don't show you well what my problem is, I
try again ;) : I have the structure as in my first post and I can't change
it, I mean, "someone" wrote that type and I must use it so i need to declare
a variable of that "monstrous" type and I can't change that type in anyway.
DO you know some way to declare and use it without any constraint error?
Thanx again!

Re: A simple ADA puzzle (I haven't the answer)

[Frank J. Lhota]

"Abby" <none@no.one.it> wrote in message
news:4x_zc.40702$G%.32360@tornado.fastwebnet.it...
>
> Thanx for your answer. Sorry if I don't show you well what my problem is,
I
> try again ;) : I have the structure as in my first post and I can't change
> it, I mean, "someone" wrote that type and I must use it so i need to
declare
> a variable of that "monstrous" type and I can't change that type in
anyway.
> DO you know some way to declare and use it without any constraint error?
> Thanx again!

Which types can't you change? Just STRING_TYPE? If so, you can go with my
second solution.

If no changes can be made in any of the declarations through UNC_ARRAY_TYPE,
then you have an impossible task. These declarations are very badly written,
and I find it quite implausable that they were ever used in any real,
working application. Any object of type UNC2_ARRAY_TYPE with more than a few
components would use up all available memory. For this reason, it is hard to
believe that an object of type RET2_TYPE with a Init more than 3 was ever
created, so an unconstrained object of this type is completely out of the
question. But wait! It gets worse: an unconstrained object of type RET_TYPE
must have enough space for INTEGER'LAST unconstrained objects of type
RET2_TYPE. Finally, we need 3 of these RET_TYPE objects! No wonder
Constraint_Error was raised; the run time generated an arithmetic overflow
when computing the amount of space required.

My guess is that these declarations were written by someone who performed no
other check on the code other than whether it compiles. These declarations
are unusable, and that is reason enough to refuse to use them.

If you provide more details about what this code is supposed to do, I could
advise you as to how these type declarations should be written.

Re: A simple ADA puzzle (I haven't the answer)

[Martin Krischik]

Frank J. Lhota wrote:

> "Abby" <none@no.one.it> wrote in message
> news:4x_zc.40702$G%.32360@tornado.fastwebnet.it...
> is completely out of the question. But wait! It gets worse: an
> unconstrained object of type RET_TYPE must have enough space for
> INTEGER'LAST unconstrained objects of type RET2_TYPE. 

Even more worse: He used Integer not Natural or Positive. The array can go
from Integer'First .. Integer'Last. On a 32 bit system -2147483647 ..
2147483648.

Who needs a String that size?

With Regards

MArtin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: A simple ADA puzzle (I haven't the answer)

[Brian May]

>>>>> "Martin" == Martin Krischik <krischik@users.sourceforge.net> writes:

    Martin> Even more worse: He used Integer not Natural or
    Martin> Positive. The array can go from Integer'First
    Martin> .. Integer'Last. On a 32 bit system -2147483647 ..
    Martin> 2147483648.

type STRING_TYPE (LEN : INTEGER := 0) is
    record
      STRING : LEN_TYPE (1 .. LEN);
    end record;

Wouldn't that always start at 1? Unlike LEN, I thought 1 was constant.
Or did I miss something here?
-- 
Brian May <bam@snoopy.apana.org.au>

Re: A simple ADA puzzle (I haven't the answer)

[Frank J. Lhota]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:14128336.jbdz6aYDds@linux1.krischik.com...
> Frank J. Lhota wrote:
>
> > "Abby" <none@no.one.it> wrote in message
> > news:4x_zc.40702$G%.32360@tornado.fastwebnet.it...
> > is completely out of the question. But wait! It gets worse: an
> > unconstrained object of type RET_TYPE must have enough space for
> > INTEGER'LAST unconstrained objects of type RET2_TYPE.
>
> Even more worse: He used Integer not Natural or Positive. The array can go
> from Integer'First .. Integer'Last. On a 32 bit system -2147483647 ..
> 2147483648.

No, it isn't quite that bad. The STRING component of STRING_TYPE has a lower
bound fixed at 1, so the longest STRING could be is 2147483647 characters,
which is bad enough.

> Who needs a String that size?

Exactly! Actually, I bet the arrays in RET2_TYPE and RET_TYPE will always be
reasonably short (say 40 components), making these declarations terribly
wasteful.


> With Regards
>
> MArtin
> -- 
> mailto://krischik@users.sourceforge.net
> http://www.ada.krischik.com
>

Re: A simple ADA puzzle (I haven't the answer)

[Jeffrey Carter]

Abby wrote:

> Thanx for your answer. Sorry if I don't show you well what my problem
> is, I try again ;) : I have the structure as in my first post and I
> can't change it, I mean, "someone" wrote that type and I must use it
> so i need to declare a variable of that "monstrous" type and I can't
> change that type in anyway. DO you know some way to declare and use
> it without any constraint error?

If you can't change any of the declarations, then you're stuck. There is 
no way to declare an object of Unc_Array_Type on most systems. These 
type declarations are garbage.

By the way, the name is "Ada", named after a woman.

-- 
Jeff Carter
"Go and boil your bottoms."
Monty Python & the Holy Grail
01

Re: A simple ADA puzzle (I haven't the answer)

[Randy Brukardt]

"Jeffrey Carter" <spam@spam.com> wrote in message
news:vT%zc.7119$Wr.262@newsread1.news.pas.earthlink.net...
> Abby wrote:
>
> > Thanx for your answer. Sorry if I don't show you well what my problem
> > is, I try again ;) : I have the structure as in my first post and I
> > can't change it, I mean, "someone" wrote that type and I must use it
> > so i need to declare a variable of that "monstrous" type and I can't
> > change that type in anyway. DO you know some way to declare and use
> > it without any constraint error?
>
> If you can't change any of the declarations, then you're stuck. There is
> no way to declare an object of Unc_Array_Type on most systems. These
> type declarations are garbage.

My opinion is that a compiler that can't handle these declarations is
garbage, not the declarations. (Janus/Ada *never* allocates anything to
maximum size). But I realize this is a minority opinion - most Ada compilers
can't handle these.

OTOH, if you don't want automatic dynamic memory allocation, then these
sorts of declarations should be avoided.

                   Randy.

Re: A simple ADA puzzle (I haven't the answer)

[Simon Wright]

"Abby" <none@no.one.it> writes:

> Thanx for your answer. Sorry if I don't show you well what my
> problem is, I try again ;) : I have the structure as in my first
> post and I can't change it, I mean, "someone" wrote that type and I
> must use it so i need to declare a variable of that "monstrous" type
> and I can't change that type in anyway.  DO you know some way to
> declare and use it without any constraint error?  Thanx again!

I wrote this little subset:
------------------------------------------------------------------------
procedure Huge is

   type Len_Type is array (Integer range <>) of Character;
   type String_Type (Len : Integer := 0) is record
      String : Len_Type (1 .. Len);
   end record;

   X : String_Type (Len => 24);
   Y : String_Type;

begin
   null;
end Huge;
------------------------------------------------------------------------

and GNAT says:

gcc -c -I/home/simon/tmp/ -g -gnatqQafoy -gnatwaL -O2 -I- /home/simon/tmp/huge.adb
huge.adb:4:09: warning: creation of "String_Type" object may raise Storage_Error
huge.adb:8:04: warning: "X" is never assigned a value
huge.adb:9:04: warning: "Y" is never assigned a value
huge.adb:9:04: warning: Storage_Error will be raised at run-time
gnatbind -aO./ -E -I- -x huge.ali
gnatlink huge.ali -o /home/simon/tmp/huge -g

So there is no problem with my declaration of X, because I've
constrained the object X.

The warning at line 4 says that there may be a problem ..

and sure enough the second warning at line 9 shows it's happened. I
don't know if it's clear from what the other people have been saying,
but the difficulty is that Y can change size at run time: so there has
to be enough space reserved for it to expand into.


All the above is fine at one level of record composition. I think the
full set you supplied are past praying for ..

-- 
Simon Wright                               100% Ada, no bugs.

Re: A simple ADA puzzle (I haven't the answer)

[Jeffrey Carter]

Frank J. Lhota wrote:
> 
> If  there is no reasonable upper limit on the LEN discriminant, if
> say LEN can vary from 1 to hundreds of thousands, then the best
> solution would be to use an array of pointers. This would be the only
> reasonable way to create an array of objects of widely varying sizes.
> For example:

No, the best solution is to use Ada.Strings.Unbounded.Unbounded_String.

-- 
Jeff Carter
"Go and boil your bottoms."
Monty Python & the Holy Grail
01

Re: A simple ADA puzzle (I haven't the answer)

[Martin Dowie]

"Jeffrey Carter" <spam@spam.com> wrote in message
news:_Q%zc.7117$Wr.4869@newsread1.news.pas.earthlink.net...
> Frank J. Lhota wrote:
> >
> > If  there is no reasonable upper limit on the LEN discriminant, if
> > say LEN can vary from 1 to hundreds of thousands, then the best
> > solution would be to use an array of pointers. This would be the only
> > reasonable way to create an array of objects of widely varying sizes.
> > For example:
>
> No, the best solution is to use Ada.Strings.Unbounded.Unbounded_String.

I'm not sure this is going to help - the style this is written in is Ada83
and
I've seen exactly this problem in '83 code written at a sister site within
the
company I work for (don't worry Simon, it wasn't yours! ;-)

Not being allowed to change things at all is a common fixation when
porting an existing Ada83 application - nonsensical, but common.

Cheers

-- Martin

Re: A simple ADA puzzle (I haven't the answer)

[Jeffrey Carter]

Martin Dowie wrote:

> "Jeffrey Carter" <spam@spam.com> wrote in message
>> 
>> No, the best solution is to use
>> Ada.Strings.Unbounded.Unbounded_String.
> 
> I'm not sure this is going to help - the style this is written in is
> Ada83 and I've seen exactly this problem in '83 code written at a
> sister site within the company I work for (don't worry Simon, it
> wasn't yours! ;-)

Even if this is Ada 83 (the OP simply said "ADA", but the code is legal 
and useless Ada 83 as well as Ada), pointers are not the best solution, 
assuming the declarations can be changed.

-- 
Jeff Carter
"Go and boil your bottoms."
Monty Python & the Holy Grail
01

Re: A simple ADA puzzle (I haven't the answer)

[Martin Dowie]

"Jeffrey Carter" <spam@spam.com> wrote in message news:XM5Ac.3542> >> No,
the best solution is to use
> >> Ada.Strings.Unbounded.Unbounded_String.
> >
> > I'm not sure this is going to help - the style this is written in is
> > Ada83 and I've seen exactly this problem in '83 code written at a
> > sister site within the company I work for (don't worry Simon, it
> > wasn't yours! ;-)
>
> Even if this is Ada 83 (the OP simply said "ADA", but the code is legal
> and useless Ada 83 as well as Ada), pointers are not the best solution,
> assuming the declarations can be changed.

Pointers? Not me!

My pointer (which having read my reply) that I failed to make is that
if he is maintaining Ada83 code, he doesn't have package
Ada.Strings.Unbounded to use.

If however he is /porting/ to Ada95 then that's a different story and
yes of course he should use Ada.Strings.Unbounded.

Cheers

-- Martin

Re: A simple ADA puzzle (I haven't the answer)

[Frank J. Lhota]

"Jeffrey Carter" <spam@spam.com> wrote in message
news:_Q%zc.7117$Wr.4869@newsread1.news.pas.earthlink.net...
> Frank J. Lhota wrote:
> >
> > If  there is no reasonable upper limit on the LEN discriminant, if
> > say LEN can vary from 1 to hundreds of thousands, then the best
> > solution would be to use an array of pointers. This would be the only
> > reasonable way to create an array of objects of widely varying sizes.
> > For example:
>
> No, the best solution is to use Ada.Strings.Unbounded.Unbounded_String.

Well, that depends. Determinig the best solution requires a lot of details
not given in this thread. For example, is Abby required to use Ada 83? Is
there a requirement to use STRING_TYPE? If the answer is "Yes" to either of
these questions, then Unbounded_String is not a viable solution.

Even if Abby is working in Ada 95 and is able to replace STRING_TYPE with
something from the predefined library, it is not entirely clear that
Unbounded_String is the best solution. If there is a reasonable upper bound
on the length of the strings (say 60 characters), then Bounded_String would
be be a faster solution.

As always, all of this depends on one question: what is this software
supposed to do?

Re: A simple ADA puzzle (I haven't the answer)

[Wojtek Narczynski]

Jeffrey Carter <spam@spam.com> wrote in message news:<_Q%zc.7117$Wr.4869@newsread1.news.pas.earthlink.net>...
> Frank J. Lhota wrote:
> > 
> > If  there is no reasonable upper limit on the LEN discriminant, if
> > say LEN can vary from 1 to hundreds of thousands, then the best
> > solution would be to use an array of pointers. This would be the only
> > reasonable way to create an array of objects of widely varying sizes.
> > For example:
> 
> No, the best solution is to use Ada.Strings.Unbounded.Unbounded_String.

Please allow a small quiz: how much memory does an Unbounded_String
instance take, for a string "a" (of lenght 1 char)?

Regards,
Wojtek

Re: A simple ADA puzzle (I haven't the answer)

[Frank J. Lhota]

"Wojtek Narczynski" <wojtek@power.com.pl> wrote in message
news:5ad0dd8a.0406181007.775eae12@posting.google.com...
> Jeffrey Carter <spam@spam.com> wrote in message
news:<_Q%zc.7117$Wr.4869@newsread1.news.pas.earthlink.net>...
> Please allow a small quiz: how much memory does an Unbounded_String
> instance take, for a string "a" (of lenght 1 char)?

The answer depends heavily on how Unbounded_String is implemented, and that
will vary from compiler to compiler. However, I think I know what point
you're getting at: the Unbounded_String solution has its own storage
overhead, and that if the strings involved are all short enough, the
Unbounded_String approach may actually use more memory.

For similar reasons, there are times where C++ should not use std::string to
represent character strings (as useful as std::string is).

That is why we need more information about the problem domain before we can
determine the best solution to Abby's problem.

Re: A simple ADA puzzle (I haven't the answer)

[Brian May]

>>>>> "Frank" == Frank J Lhota <NOSPAM.lhota.adarose@verizon.net> writes:

    Frank> The answer depends heavily on how Unbounded_String is
    Frank> implemented, and that will vary from compiler to
    Frank> compiler. However, I think I know what point you're getting
    Frank> at: the Unbounded_String solution has its own storage
    Frank> overhead, and that if the strings involved are all short
    Frank> enough, the Unbounded_String approach may actually use more
    Frank> memory.

This is an issue where there is a tradeoff between efficiency of the
program and how general it can be.

(note: when I say "you" read as "the programmer or the
interpreter/compiler").

If you want fixed length strings, then you are stuck with a fixed
length, but you get maximum use of memory, and minimal overheads.

If you want variable length strings, but have a maximum length, you
can allocate up to this maximum length, but you need to keep track of
the actual length used somehow, eg. by counting bytes or adding a null
terminator at the end of the string. Also if you accidently exceed
this length, you will get undesired results (unless you are using Ada
and can somehow gracefully deal with the exception).

If you want variable length strings, with no maximum limit, then you
need to allocate/free memory dynamically at run time and keep track of
the length allocated.

Some languages may try to hide these issues (to various degrees) from
the programmers, but they still remain issues which may be important
with some applications (eg. time critical applications).

At least Ada not only allows you to choose which one you want (like C
or C++), but it will also enforce your choice to, so you can't exceed
the maximum length for instance and allow corrupting surrounding data.

Similar issues also arise with arrays.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: A simple ADA puzzle (I haven't the answer)

[Wojtek Narczynski]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> wrote in message news:<lDGAc.1313$U.812@nwrdny02.gnilink.net>...
> "Wojtek Narczynski" <wojtek@power.com.pl> wrote in message
> news:5ad0dd8a.0406181007.775eae12@posting.google.com...
> > Jeffrey Carter <spam@spam.com> wrote in message
>  news:<_Q%zc.7117$Wr.4869@newsread1.news.pas.earthlink.net>...
> > Please allow a small quiz: how much memory does an Unbounded_String
> > instance take, for a string "a" (of lenght 1 char)?
> 
> The answer depends heavily on how Unbounded_String is implemented, and that
> will vary from compiler to compiler.

Please feel free to qualify your answer with a compiler name and
hardware platform.

> However, I think I know what point you're getting at: the Unbounded_String
> solution has its own storage overhead, and that if the strings involved are
> all short enough, the Unbounded_String approach may actually use more memory.

Actually I am one step further in my wickedness. I am aking for a
quantitative answer to the overhead question.

Regards,
Wojtek

Re: A simple ADA puzzle (I haven't the answer)

[Jeffrey Carter]

Wojtek Narczynski wrote:

> Please allow a small quiz: how much memory does an Unbounded_String
> instance take, for a string "a" (of lenght 1 char)?

There are many responses to this. One is: it depends on the compiler. No 
implementation is specified for Unbounded_String.

Another is: Why do you care? If you have strict memory limitations, you 
should probably not be using a general-purpose component anyway. If you 
don't, then it's very unlikely to make a difference, so you shouldn't 
worry about it unless it actually proves to be a problem.

A 3rd is: Not withstanding #1, an obvious implementation is a controlled 
type containing a String_Access. The language requires such an 
implementation to occupy space for one access value, and whatever space 
is required by the string it designates. This is exactly the same amount 
of space as using explicit access values, without the possibilities for 
errors they introduce. (While a controlled type is a tagged type, there 
is no requirement that tags actually be stored, and in the case of 
Unbounded_String, there is no need to store the tag.)

-- 
Jeff Carter
"When danger reared its ugly head, he bravely
turned his tail and fled."
Monty Python and the Holy Grail
60

Re: A simple ADA puzzle (I haven't the answer)

[Wojtek Narczynski]

Jeffrey Carter <spam@spam.com> wrote in message news:<8EMAc.5698$w07.1296@newsread2.news.pas.earthlink.net>...
> Wojtek Narczynski wrote:
> 
> > Please allow a small quiz: how much memory does an Unbounded_String
> > instance take, for a string "a" (of lenght 1 char)?
> 
> There are many responses to this. One is: it depends on the compiler. No 
> implementation is specified for Unbounded_String.
> 
> (...)
>

Under the only compiler I can check - GNAT, 32 bit machine: 60 bytes,
measured empirically.

Maybe life is more comfortable without knowing certain facts, but I
happened to already know this, and I can't help it by now.


Regards,
Wojtek

Re: A simple ADA puzzle (I haven't the answer)

[Hyman Rosen]

Frank J. Lhota wrote:
> The problem with your definition of String_Type

I don't know if you've been following the Improving Ada's
Image thread, but this is a perfect illustration of what I
said there - trying to handle strings in Ada is a nightmare
if you don't understand a lot about arrays and types and
constraints. New Ada users, especially those coming from C
or Java, are going to be utterly confused.

Just the fact that
   type LEN_TYPE is array (INTEGER range <>) of CHARACTER;
   type STRING_TYPE (LEN : INTEGER := 0) is
     record STRING : LEN_TYPE (1 .. LEN); end record;
   X : STRING_TYPE;
can result in the allocation of all of memory is completely
counterintuitive.

Re: A simple ADA puzzle (I haven't the answer)

[Frank J. Lhota]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1087410710.477506@master.nyc.kbcfp.com...
> I don't know if you've been following the Improving Ada's
> Image thread, but this is a perfect illustration of what I
> said there - trying to handle strings in Ada is a nightmare
> if you don't understand a lot about arrays and types and
> constraints. New Ada users, especially those coming from C
> or Java, are going to be utterly confused.
>
> Just the fact that
>    type LEN_TYPE is array (INTEGER range <>) of CHARACTER;
>    type STRING_TYPE (LEN : INTEGER := 0) is
>      record STRING : LEN_TYPE (1 .. LEN); end record;
>    X : STRING_TYPE;
> can result in the allocation of all of memory is completely
> counterintuitive.

I don't know if you noticed, but this code never uses that standard Ada
String type! If the author was more familiar with the predefined Ada
libraries, s/he might have used Bounded_String or Unbounded_String and
avoided some of these problems.

The part that I find completely counterintuitive is how anyone can expect to
write a simple record type that, without any additional memory allocation,
could hold arbitrarily large arrays and still remain within reasonable
memory constraints. Most likely, a C programmer would come up with a
solution using pointers. Java, by its very nature, would require a pointer
based solution, since all Java classes and arrays are handled via pointers.

Re: A simple ADA puzzle (I haven't the answer)

[Hyman Rosen]

Frank J. Lhota wrote:
> The part that I find completely counterintuitive is how anyone can expect to
> write a simple record type that, without any additional memory allocation,
> could hold arbitrarily large arrays and still remain within reasonable
> memory constraints.

Because when you write

     type STRING_TYPE (LEN : INTEGER := 0) is
       record STRING : LEN_TYPE (1 .. LEN); end record;

it's perfectly reasonable to expect that the array is
allocated just enough room to hold whatever LEN is
specified. After all, you can do something that looks
superficially very similar (or at least I think so; I
don't know Ada):

     procedure foo(LEN : INTEGER) is
       type LEN_TYPE is array (INTEGER range <>) of CHARACTER;
       type STRING_TYPE is
         record STRING : LEN_TYPE (1 .. LEN); end record;
       X : STRING_TYPE;
     begin end foo;

and this is perfectly fine, and will only allocate LEN
elements. Now, all the experts here certainly understand the
difference, and even I do, but what is a newcomer to Ada to
make of this?

Re: A simple ADA puzzle (I haven't the answer)

[Frank J. Lhota]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1087419927.480130@master.nyc.kbcfp.com...
> Frank J. Lhota wrote:
> > The part that I find completely counterintuitive is how anyone can
expect to
> > write a simple record type that, without any additional memory
allocation,
> > could hold arbitrarily large arrays and still remain within reasonable
> > memory constraints.
>
> Because when you write
>
>      type STRING_TYPE (LEN : INTEGER := 0) is
>        record STRING : LEN_TYPE (1 .. LEN); end record;
>
> it's perfectly reasonable to expect that the array is
> allocated just enough room to hold whatever LEN is
> specified. After all, you can do something that looks
> superficially very similar (or at least I think so; I
> don't know Ada):
>
>      procedure foo(LEN : INTEGER) is
>        type LEN_TYPE is array (INTEGER range <>) of CHARACTER;
>        type STRING_TYPE is
>          record STRING : LEN_TYPE (1 .. LEN); end record;
>        X : STRING_TYPE;
>      begin end foo;
>
> and this is perfectly fine, and will only allocate LEN
> elements. Now, all the experts here certainly understand the
> difference, and even I do, but what is a newcomer to Ada to
> make of this?

ARM 3.7.1 defines very precisely how this works. When you get past the
language legalese, it is very simple. In an object declaration, if the type
name is immediately followed by values for the type discriminants, then the
discriminants are constrained to those values. For example, if I declare

    My_Name : STRING_TYPE ( LEN => 80 );

The My_Name.LEN is constrained to 80, and My_Name needs only 80 characters
of space for the STRING component of My_Name. If the type definition does
not provide defaults for the type discriminants, then all object
declarations for this type must constrain the type discriminants.

If we declare variable object with no constraint on its discriminants, then
its discriminants will have the default values, but the variable should be
able to be assigned any value of that type. That is why the original poster
was running  into trouble.

We do not have a description of the original problem, but from the looks of
it, the intention was that these discriminants were meant to be modifiable.
The programmer who wrote these declarations was being terribly naive. The C
equivalent of these declarations would have used

    char STRING[ 0x7FFFFFFF ];

with the assumption that somehow, the system would only allocate storage for
the part of STRING actually used!

Re: A simple ADA puzzle (I haven't the answer)

[Hyman Rosen]

Frank J. Lhota wrote:
> ARM 3.7.1 defines very precisely how this works.
 > When you get past the language legalese, it is very simple.
> The programmer who wrote these declarations was being terribly naive.

Sigh.

Re: A simple ADA puzzle (I haven't the answer)

[Frank J. Lhota]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1087481981.332197@master.nyc.kbcfp.com...
> Frank J. Lhota wrote:
> > The programmer who wrote these declarations was being terribly naive.
>
> Sigh.

I stand by my contempt for the author of the type definitions that were
foisted on Abbey. If this programmer had done ANY testing of this code, even
just a small stand-along program, the error would show up immediately. Now
it is up to Abbey to clean up the mess, and to do so with the misguided
recommendation to use these declarations unchanged. Abbey has my sympathy.

Re: A simple ADA puzzle (I haven't the answer)

[Randy Brukardt]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> wrote in message
news:pIiAc.34538$mz.30946@nwrdny02.gnilink.net...
...
> I stand by my contempt for the author of the type definitions that were
> foisted on Abbey. If this programmer had done ANY testing of this code,
even
> just a small stand-along program, the error would show up immediately. Now
> it is up to Abbey to clean up the mess, and to do so with the misguided
> recommendation to use these declarations unchanged. Abbey has my sympathy.

Why? They work perfectly well on Janus/Ada to this day. Such objects are
allocated to their actual size, as the declarations clearly imply was
intended. I believe that there were other Ada 83 compilers on which these
worked as well. The problem is clearly with allowing Ada compilers to not
implement the clear intent of the declarations!

                             Randy.

Re: A simple ADA puzzle (I haven't the answer)

[Georg Bauhaus]

Frank J. Lhota <NOSPAM.lhota.adarose@verizon.net> wrote:
: "Hyman Rosen" <hyrosen@mail.com> wrote in message
:>
:> Because when you write
:>
:>      type STRING_TYPE (LEN : INTEGER := 0) is
:>        record STRING : LEN_TYPE (1 .. LEN); end record;
:>
:> it's perfectly reasonable to expect that the array is
:> allocated just enough room to hold whatever LEN is
:> specified.

I guess this is true all the more there is a default
value for the discriminant. How is one to know that
a default value for a length does not actually
extend to the type's size? 

with Ada.Text_IO;

procedure str is

   type T(size: Natural := 0) is record
      comp: String(1.. size);
   end record;

   package TIO renames Ada.Text_IO;

begin
   TIO.put_line("type's size is" & Natural'base'image(T'size));
end str;

There is not even an explicit declaration of a T object
anywhere in the program, yet it fails miserably. The
compiler warns, but nevertheless it doesn't explain
why (a) object of this type may raise Storage_Error,
and (b), more subtly I guess, the following:

 12.    TIO.put_line("type's size is" & Natural'base'image(T'size));
                                                            |
     >>> warning: Constraint_Error will be raised at run-time

(Seen in the light of a Natural size constraint intended
for the type.)

: The C equivalent of these declarations would have used
: 
:    char STRING[ 0x7FFFFFFF ];

I don't think so, the literal in the Ada code is no greater
than 0, and who knows, maybe people are lead to believe that
a default value of 0 (not?) used for the last index of a string
will give them a rather short string.

Re: A simple ADA puzzle (I haven't the answer)

[Alexander E. Kopilovich]

Hyman Rosen wrote:

> trying to handle strings in Ada is a nightmare

This is true, and I tried to convey this truth here in comp.lang.ada from time
to time in past years, but without any visible success.

> if you don't understand a lot about arrays and types and
> constraints.

Yes, this is required, but still not enough - you should also agree with that
you'll be constantly reminded by the language that strings are arrays and
therefore you generally can't deal with them as with scalars (you can do that
in Pascal, and you often can mimic that in C - using pointers).

The problem is that Ada designers did not recognize in proper time that
strings aren't exactly arrays, and that in growing number of applications
thinking of strings as of arrays is no more natural than thinking of numbers
as of arrays of bits.

A workaround is to use Unbounded_Strings only, but then you'll have a trouble
every time when fixed-length string is expected; and you'll be oblidged to
submit a petition every time when you need to initialize that string with a
literal.

> New Ada users, especially those coming from C
> or Java, are going to be utterly confused.

As well as those coming from Pascal/Delphi.

But there is an environment, in which handling of strings is even more (at
least no less) gorgeous/complicated than in Ada - it is Symbian OS (I mean
C++ SDKs for Symbian), which is used in majority of high-end smartphones
today (Nokia, SonyEricsson, etc.) .
 



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

Re: A simple ADA puzzle (I haven't the answer)

[Björn Persson]

Alexander E. Kopilovich wrote:

> Hyman Rosen wrote:
> 
>>New Ada users, especially those coming from C
>>or Java, are going to be utterly confused.
> 
> As well as those coming from Pascal/Delphi.

I came from Turbo Pascal. I still find it annoying to have to write 
"To_String" and "To_Unbounded_String" everywhere, but I can't remember 
being particularly confused. But then again, I came to Pascal from Basic 
and I had seen Scheme, C and other languages as well as fixed-length 
strings in standard Pascal, null-terminated strings in Turbo Pascal and 
Turbo Pascal's special length-in-byte-0 strings. So I already knew that 
there are many ways to handle strings.

-- 
Björn Persson

jor ers @sv ge.
b n_p son eri nu

Re: A simple ADA puzzle (I haven't the answer)

[Frank J. Lhota]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

"Bj�rn Persson" <spam-away@nowhere.nil> wrote in message
news:BkeAc.96157$dP1.313881@newsc.telia.net...
Alexander E. Kopilovich wrote:
> I came from Turbo Pascal. I still find it annoying to have to write
> "To_String" and "To_Unbounded_String" everywhere, but I can't remember
>being particularly confused.

What I generally do is rename these functions to the unary "+" operator. By
doing this, I still have an indication that the conversion operation takes
place, but it does not take up a lot of room.

Re: A simple ADA puzzle (I haven't the answer)

[Alexander E. Kopilovich]

Frank J. Lhota wrote:

> > I came from Turbo Pascal. I still find it annoying to have to write
> > "To_String" and "To_Unbounded_String" everywhere, but I can't remember
> >being particularly confused.
>
> What I generally do is rename these functions to the unary "+" operator.

Certainly so (or use V() and S()), but it is still annoying.

> By
> doing this, I still have an indication that the conversion operation takes
> place,

But I don't want that indication, particularly because actually there is no
conversion of data at all (neither in my mind nor in the computer). There may
be check for a constraint (if unbounded string is assigned to fixed or bounded
string), but that situation is just similar to integer subtypes, and there are
no indication for conversion (which is certainly right, as there is no conversion).

> but it does not take up a lot of room.

The problem is not about the room, but about the annoying irregularity and
a portion of distraction.




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

Re: A simple ADA puzzle (I haven't the answer)

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> wrote in message
news:WYhAc.34333$mz.18815@nwrdny02.gnilink.net...
> "Bj�rn Persson" <spam-away@nowhere.nil> wrote in message
> news:BkeAc.96157$dP1.313881@newsc.telia.net...
> Alexander E. Kopilovich wrote:
> > I came from Turbo Pascal. I still find it annoying to have to write
> > "To_String" and "To_Unbounded_String" everywhere, but I can't remember
> >being particularly confused.
>
> What I generally do is rename these functions to the unary "+" operator.
By
> doing this, I still have an indication that the conversion operation takes
> place, but it does not take up a lot of room.

I'm still annoyed that we couldn't get that done as part of
Ada.Strings.Unbounded. It was proposed, but enough people thought it was
ugly that it wasn't included. Why anyone would think that writing:

         Ada.Strings.Unbounded.To_Unbounded_String ("abc");

is preferable to

        +"abc"

I don't know. (Our style guide only allows "use type", so the above is
precisely what I'd write in the two cases.)

                          Randy.

Re: A simple ADA puzzle (I haven't the answer)

[Dmitry A. Kazakov]

On Wed, 16 Jun 2004 14:31:50 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

>Frank J. Lhota wrote:
>> The problem with your definition of String_Type
>
>I don't know if you've been following the Improving Ada's
>Image thread, but this is a perfect illustration of what I
>said there - trying to handle strings in Ada is a nightmare
>if you don't understand a lot about arrays and types and
>constraints.

If a programmer does not understand what are arrays, types and
constraints, then probably he/she should look for other job, probably
as a dish-washer?

As for Ada strings, there are only two problems related:

1. The default values for discriminants shall not have any implicit
effects on the memory allocation policy. That was a mistake of Ada 83.

2. Unbounded_String and Bounded_String are nasty patches, which should
be replaced when Ada will finally have a common supertype for all
types strings.

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

Re: A simple ADA puzzle (I haven't the answer)

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> If a programmer does not understand what are arrays, types and
> constraints, then probably he/she should look for other job, probably
> as a dish-washer?

But this programmer does understand what arrays and types are,
just not how they manifest in Ada. And constrained types are
unique to Ada, or at least they are not present in the popular
languages of the day. Knowing what an array is has nothing to
do with knowing that in Ada they can be passed by value, or that
you can declare an array object which gets its bounds from an
initializer. Knowing what a type is does not tell you that in
Ada a polymorphic type can't be declared in the same places that
other types can. And that bit of code with constraints that eats
all of memory looks completely innocent. How is an Ada newcomer
to know that the default discriminant doesn't apply when an object
of that type is created?

Since most programmers do not know Ada, if they are to be taught
the language then these places where Ada is extremely different
from the languages they do know must be carefully described, and
done so in terms of the concepts they already know.

Acting condescendingly towards people who are not learned in the
nuances of what is at best a niche language is not going to win
any converts.

Re: A simple ADA puzzle (I haven't the answer)

[Dmitry A. Kazakov]

On Thu, 17 Jun 2004 08:19:21 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> If a programmer does not understand what are arrays, types and
>> constraints, then probably he/she should look for other job, probably
>> as a dish-washer?
>
>But this programmer does understand what arrays and types are,
>just not how they manifest in Ada. And constrained types are
>unique to Ada, or at least they are not present in the popular
>languages of the day.

But constraining is so general concept that requires no explanations,
IMO.

Then I would argue that the following in C++ is an example of
contraining:

class Base
{
public :
   Base (int Constrain) { ... }
};

class Constrained
{
public :
   Constrained () : A (25) { ... }
};

>Knowing what an array is has nothing to
>do with knowing that in Ada they can be passed by value,

Again, passing by value vs. by reference is a general concept. It is
not clear why somebody should think of array as of something being
passed in some definite way. Why should he/she care of parameter
passing? Knuth's saying about evils of premature optimization should
be carved in everybody's mind.

>or that
>you can declare an array object which gets its bounds from an
>initializer.

What about C++ which has contructors with parameters? I would rather
expect people perplexed by Ada's lack of true constructors with
parameters. But that is another story.

>Knowing what a type is does not tell you that in
>Ada a polymorphic type can't be declared in the same places that
>other types can.

Not worse than in C++, where you cannot:

void foo ()
{
   class Local {...};
   Local Thing;

   ...
};

Everybody agree that silly limitations are annoying, even if they have
more or less firm rationale.

>And that bit of code with constraints that eats
>all of memory looks completely innocent.
>
>How is an Ada newcomer
>to know that the default discriminant doesn't apply when an object
>of that type is created?

Here I agree, I think that was a mistake to tie these things together.

>Since most programmers do not know Ada, if they are to be taught
>the language then these places where Ada is extremely different
>from the languages they do know must be carefully described, and
>done so in terms of the concepts they already know.

First the difference is not that big. Second they should think in
terms of more generic concepts, which all programming languages share.
If somebody thinks of integers as being 16-bits long because his first
C compiler was for PDP-11, then dirty dishes are waiting for him.

>Acting condescendingly towards people who are not learned in the
>nuances of what is at best a niche language is not going to win
>any converts.

I do not think that Ada is so far away from other languages. I wished
it were true, but it isn't.

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

Re: A simple ADA puzzle (I haven't the answer)

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> But constraining is so general concept
 > that requires no explanations

Since confusion is evident, especially in the case
of default values that don't apply when people think
they do, you are self-evidently wrong when it comes
to how constraining is used in Ada.

Re: A simple ADA puzzle (I haven't the answer)

[Brian May]

>>>>> "Dmitry" == Dmitry A Kazakov <mailbox@dmitry-kazakov.de> writes:

    Dmitry> Not worse than in C++, where you cannot:

    Dmitry> void foo ()
    Dmitry> {
    Dmitry> class Local {...};
    Dmitry> Local Thing;

    Dmitry> ...
    Dmitry> };

Are you sure?

The following code compiles and runs fine for me under g++ 3.3.3, and
produces no warnings with -Wall:

--- cut ---
void foo ()
{
   class Local { public: void doit() { printf("Hello World\n"); } };
   Local Thing;
   Thing.doit();
};
--- cut ---
-- 
Brian May <bam@snoopy.apana.org.au>

Re: A simple ADA puzzle (I haven't the answer)

[Dmitry A. Kazakov]

On Fri, 18 Jun 2004 08:51:43 +1000, Brian May
<bam@snoopy.apana.org.au> wrote:

>>>>>> "Dmitry" == Dmitry A Kazakov <mailbox@dmitry-kazakov.de> writes:
>
>    Dmitry> Not worse than in C++, where you cannot:
>
>    Dmitry> void foo ()
>    Dmitry> {
>    Dmitry> class Local {...};
>    Dmitry> Local Thing;
>
>    Dmitry> ...
>    Dmitry> };
>
>Are you sure?
>
>The following code compiles and runs fine for me under g++ 3.3.3, and
>produces no warnings with -Wall:
>
>--- cut ---
>void foo ()
>{
>   class Local { public: void doit() { printf("Hello World\n"); } };
>   Local Thing;
>   Thing.doit();
>};
>--- cut ---

It is not what it appears to be. It is equivalent to

class Local { public: void doit() { printf("Hello World\n"); } };
void foo ()
{
   Local Thing;
   Thing.doit();
};

The following will not compile:

class Global
{
public :
   virtual void doit() = 0;
};

Global * foo ()
{
   char Text [] = { ... };
   class Local : public Global
   {
   public :
      void doit() { printf (Text); } // Error Text is unknown!
   };

   return new Local ();
};

Fortunately it will not, because, otherwise "foo ()->doit ()" will be
wonderfully surprising.

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

Re: A simple ADA puzzle (I haven't the answer)

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> It is not what it appears to be. It is equivalent to
> class Local { public: void doit() { printf("Hello World\n"); } };
> void foo ()
> {
>    Local Thing;
>    Thing.doit();
> };

No, that's not correct. Local classes really are local.
For example, I could declare two different Local classes
in two different functions, and they would not clash.

> The following will not compile:
> Global * foo ()
> {
>    char Text [] = { ... };
>    class Local : public Global {
>    public: void doit() { printf (Text); } // Error Text is unknown!
>    };

True, but that does not mean that Local isn't local,
it simply means that local classes cannot access the
automatic variables of their enclosing scopes, for
obvious reasons. On the other hand, your code would
compile if Text were
     static char Text[] = "...";

In other words, Loacal is local with respect to its static scope,
not its dynamic one, and things that depend on dynamic scope such
as parmeters and automatic variables are inaccesible to it.

Re: A simple ADA puzzle (I haven't the answer)

[Ole-Hjalmar Kristensen]

What do you mean it does not work in C++? It works just fine,
and you may even do:

class Base{...};

Base* foo ()
{
   class Local : public Base {...};
   return new Local();
};

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:

<snip>

> >Knowing what a type is does not tell you that in
> >Ada a polymorphic type can't be declared in the same places that
> >other types can.
> 
> Not worse than in C++, where you cannot:
> 
> void foo ()
> {
>    class Local {...};
>    Local Thing;
> 
>    ...
> };
> 

<snip>

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: A simple ADA puzzle (I haven't the answer)

[Hyman Rosen]

Ole-Hjalmar Kristensen wrote:
> What do you mean it does not work in C++? It works just fine,
> and you may even do:
> class Base{...};
> Base* foo ()
> {
>    class Local : public Base {...};
>    return new Local();
> };

But you can't use local classes as template parameters.
To follow up on your example, if you tried to declare a
vector<Local> inside foo, you would get a compile error.
It's rather annoying, actually.

Re: A simple ADA puzzle (I haven't the answer)

[Dmitry A. Kazakov]

On 18 Jun 2004 11:14:44 +0200, Ole-Hjalmar Kristensen
<ole-hjalmar.kristensen@substitute_employer_here.com> wrote:

>What do you mean it does not work in C++? It works just fine,
>and you may even do:
>
>class Base{...};
>
>Base* foo ()
>{
>   class Local : public Base {...};
>   return new Local();
>};

Which proves that Local is defined on the library level, same as in
Ada. The only difference is that C++ fakes you out, while Ada tells
the sad truth.

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

Re: A simple ADA puzzle (I haven't the answer)

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Which proves that Local is defined on the library level, same as in
> Ada. The only difference is that C++ fakes you out, while Ada tells
> the sad truth.

It is not "defined on thelibrary level", whatever that might
mean in C++. It does not have external linkage (so it cannot
be used as a template parameter) and it may access anything
from its scope other than automatic variables and parameters.

In C++ all types are static entities. They never depend on
automatic variables or runtime properties, and so there is
never a problem with objects of those types persisting after
the scope in which those types are defined is exited.

Re: A simple ADA puzzle (I haven't the answer)

[Dmitry A. Kazakov]

On Fri, 18 Jun 2004 09:16:16 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> Which proves that Local is defined on the library level, same as in
>> Ada. The only difference is that C++ fakes you out, while Ada tells
>> the sad truth.
>
>It is not "defined on thelibrary level", whatever that might
>mean in C++. It does not have external linkage (so it cannot
>be used as a template parameter) and it may access anything
>from its scope other than automatic variables and parameters.
>
>In C++ all types are static entities. They never depend on
>automatic variables or runtime properties, and so there is
>never a problem with objects of those types persisting after
>the scope in which those types are defined is exited.

So no matter how we call it, the situation does not much differ from
what we have in Ada. You cannot access local scope from that type.
Neither in C++ nor in Ada.

BTW, I by no means advocate Ada. I think that it might be very useful
to lift that limitation. But that is not very easy to do consistently
and efficient.

Nevertheless, Ada is at least honest about this matter with the
programmer.

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

Re: A simple ADA puzzle (I haven't the answer)

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Nevertheless, Ada is at least honest about this matter with the
> programmer.

Limiting the scope of something can be useful of itself;
there is nothing dishonest about allowing this, even if
access to automatics is not permitted.

Re: A simple ADA puzzle (I haven't the answer)

[Dmitry A. Kazakov]

On Fri, 18 Jun 2004 12:14:22 -0400, Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> Nevertheless, Ada is at least honest about this matter with the
>> programmer.
> 
> Limiting the scope of something can be useful of itself;

What's the gain of limiting scope here? A relief for lazy
programmers, who do not want to create extra *.h files?

> there is nothing dishonest about allowing this, even if
> access to automatics is not permitted.

Limiting scope is useful, but it should be made consistently. Clearly a
nested thing should see everything from its scope.

Talking about uneducated programmers how would you explain one of them
what and when will be visible? Ada's choice was to give a clear,
though unpleasant answer, rather than vague "yes, but".

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

Re: A simple ADA puzzle (I haven't the answer)

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> What's the gain of limiting scope here? A relief for lazy
> programmers, who do not want to create extra *.h files?

The same gain as any limitation of scope - localizing things
to the narrowest region where they are needed. It is no less
sensible than Ada's declare statement. I often write tiny
classes whose job is nothing more than invoking a cleanup
function on an object in its destructor. I put them right next
to the object they will be handling.

> Limiting scope is useful, but it should be made consistently.
 > Clearly a nested thing should see everything from its scope.

C and C++ do not choose to allow closures because of difficulties
with function pointers that result. So it is clear that access to
local variables will never be permitted. The question is then
whether to also forbid a useful thing because of misguided efforts
to impose a useless philosophy. Fortunately the answer was "no".

> Talking about uneducated programmers how would you explain one of them
> what and when will be visible? Ada's choice was to give a clear,
> though unpleasant answer, rather than vague "yes, but".

As I have said, it's extremely simple. Automatic variables are invisible.

Re: A simple ADA puzzle (I haven't the answer)

[Dmitry A. Kazakov]

On Mon, 21 Jun 2004 03:30:32 GMT, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> What's the gain of limiting scope here? A relief for lazy
>> programmers, who do not want to create extra *.h files?
>
>The same gain as any limitation of scope - localizing things
>to the narrowest region where they are needed. It is no less
>sensible than Ada's declare statement. I often write tiny
>classes whose job is nothing more than invoking a cleanup
>function on an object in its destructor. I put them right next
>to the object they will be handling.

I usually put helper classes in the class of the object, but it is a
matter of taste.

>> Limiting scope is useful, but it should be made consistently.
>> Clearly a nested thing should see everything from its scope.
>
>C and C++ do not choose to allow closures because of difficulties
>with function pointers that result.

Same fault as in Ada. There should be routine types, which in most
cases would eliminate any need in pointers.

>So it is clear that access to
>local variables will never be permitted.

So it is inconsistent.

>The question is then
>whether to also forbid a useful thing because of misguided efforts
>to impose a useless philosophy.

That's another philosophy, the C++'s one: quick and dirty, or rather
"let's first make it dirty, maybe it happens to be quick".

>Fortunately the answer was "no".

One cannot correct one error by making another.

>> Talking about uneducated programmers how would you explain one of them
>> what and when will be visible? Ada's choice was to give a clear,
>> though unpleasant answer, rather than vague "yes, but".
>
>As I have said, it's extremely simple. Automatic variables are invisible.

Huh, how is it better than Ada's limitation on tagged types?

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

Re: A simple ADA puzzle (I haven't the answer)

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> So it is inconsistent.

"A foolish consistency is the hobgoblin of small minds."

> That's another philosophy, the C++'s one: quick and dirty, or rather
> "let's first make it dirty, maybe it happens to be quick".

As opposed to Ada's "if we don't have it you don't need it",
like leaving procedure pointers out of Ada 83.

> Huh, how is it better than Ada's limitation on tagged types?

Access to automatic variables from local classes is not provided
because it causes implemenation difficulties which would spread
throught many aspects of the language. Ada's limitation on tagged
types has no such technical basis; it is there because someone
could accidentally use the construct incorrectly.

Re: A simple ADA puzzle (I haven't the answer)

[David Starner]

On Mon, 21 Jun 2004 12:32:54 -0400, Hyman Rosen wrote:

>> That's another philosophy, the C++'s one: quick and dirty, or rather
>> "let's first make it dirty, maybe it happens to be quick".
> 
> As opposed to Ada's "if we don't have it you don't need it",
> like leaving procedure pointers out of Ada 83.

"There are times when Wirth believes in small solutions for big problems.
I don't believe in that sort of miracle. Big problems need big solutions."
- Jean Ichbiah

For a language that got pounded for having too many features and being too
complex, I think it a little specious to complain that they ignored the
need for features. A decision was made, right or wrong, just like many
decisions were made in C++ to add or not add features.

Re: A simple ADA puzzle (I haven't the answer)

[Frank J. Lhota]

I have to agree with Hyman on the issue of pointers to subprograms. It was a
bad mistake to leave them out of Ada 83. I recall having to use generics in
instances where it would have been preferable to pass a pointer to a
procedure / function instead. Of course, now that we have Ada 95, that is
all water under the bridge.

Re: A simple ADA puzzle (I haven't the answer)

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:2i5dd0lu0i3a8bokfh7916r4j67g42ri4o@4ax.com...
...
> >As I have said, it's extremely simple. Automatic variables are invisible.
>
> Huh, how is it better than Ada's limitation on tagged types?

The only limitation on tagged types in Ada 2005 is that you can't extend a
formal type in a generic body. See AI-344, approved in Palma de Mallorca.
(There are accessibility checks if you try pass an object of a nested type
outwards.)

So what are you talking about??

             Randy Brukardt
             ARG Editor

Re: A simple ADA puzzle (I haven't the answer)

[Dmitry A. Kazakov]

On Wed, 23 Jun 2004 16:37:01 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:2i5dd0lu0i3a8bokfh7916r4j67g42ri4o@4ax.com...
> ...
>>>As I have said, it's extremely simple. Automatic variables are invisible.
>>
>> Huh, how is it better than Ada's limitation on tagged types?
> 
> The only limitation on tagged types in Ada 2005 is that you can't extend a
> formal type in a generic body. See AI-344, approved in Palma de Mallorca.
> (There are accessibility checks if you try pass an object of a nested type
> outwards.)

But I will be still able to allocate it, return a class-wide pointer and
then to dispatch to an out-of-scope subroutine. It seems that some
additional overhead will be needed to catch that.

BTW, there could be alternatives to accessibility checks, when overhead is
accepted. For example, one could forcibly upcast objects if their type goes
out of scope.

> So what are you talking about??

(:-))

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

Re: A simple ADA puzzle (I haven't the answer)

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:pltjvkdjp69c.11hhxh2y8idq9.dlg@40tude.net...
> On Wed, 23 Jun 2004 16:37:01 -0500, Randy Brukardt wrote:
>
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> > news:2i5dd0lu0i3a8bokfh7916r4j67g42ri4o@4ax.com...
> > ...
> >>>As I have said, it's extremely simple. Automatic variables are
invisible.
> >>
> >> Huh, how is it better than Ada's limitation on tagged types?
> >
> > The only limitation on tagged types in Ada 2005 is that you can't extend
a
> > formal type in a generic body. See AI-344, approved in Palma de
Mallorca.
> > (There are accessibility checks if you try pass an object of a nested
type
> > outwards.)
>
> But I will be still able to allocate it, return a class-wide pointer and
> then to dispatch to an out-of-scope subroutine. It seems that some
> additional overhead will be needed to catch that.

No. The conversion to the class-wide pointer (presumably global) would fail
its accessibility check. So the program would be illegal. No overhead
needed.

Tucker's idea was simply to move the accessibility checks from the
declaration of the type (the Ada 95 rule) to the uses of the objects (which
turn out to be only a handful of places).

It is true that dispatching to an overridden routine for a type in a nested
scope will be more expensive (there will be a wrapper to set the static link
or display properly). But that's a small price to pay for something that you
can't do at all now. (And it won't make any existing code slower,
obviously.)

> BTW, there could be alternatives to accessibility checks, when overhead is
> accepted. For example, one could forcibly upcast objects if their type
goes
> out of scope.

Silent truncation (upcasting) of a type was considered a very bad thing
during the design of Ada 95. Anything that would require that (such has
having both statically and dynamically tagged operands in a single call -
see 3.9.2(8)) is illegal.

You could argue whether that is a good idea or not, but I don't think that
we're going to change that part of the philosophy.

                          Randy.

Re: A simple ADA puzzle (I haven't the answer)

[Dmitry A. Kazakov]

On Thu, 24 Jun 2004 15:53:33 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:pltjvkdjp69c.11hhxh2y8idq9.dlg@40tude.net...
>> On Wed, 23 Jun 2004 16:37:01 -0500, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:2i5dd0lu0i3a8bokfh7916r4j67g42ri4o@4ax.com...
>>> ...
>>>>>As I have said, it's extremely simple. Automatic variables are
> invisible.
>>>>
>>>> Huh, how is it better than Ada's limitation on tagged types?
>>>
>>> The only limitation on tagged types in Ada 2005 is that you can't extend
> a
>>> formal type in a generic body. See AI-344, approved in Palma de
> Mallorca.
>>> (There are accessibility checks if you try pass an object of a nested
> type
>>> outwards.)
>>
>> But I will be still able to allocate it, return a class-wide pointer and
>> then to dispatch to an out-of-scope subroutine. It seems that some
>> additional overhead will be needed to catch that.
> 
> No. The conversion to the class-wide pointer (presumably global) would fail
> its accessibility check. So the program would be illegal. No overhead
> needed.

I see.

I hope that Unchecked_Conversion on such pointers and all sorts of games
with 'Unchecked_Access on views will be also illegal.

> Tucker's idea was simply to move the accessibility checks from the
> declaration of the type (the Ada 95 rule) to the uses of the objects (which
> turn out to be only a handful of places).
> 
> It is true that dispatching to an overridden routine for a type in a nested
> scope will be more expensive (there will be a wrapper to set the static link
> or display properly). But that's a small price to pay for something that you
> can't do at all now. (And it won't make any existing code slower,
> obviously.)
> 
>> BTW, there could be alternatives to accessibility checks, when overhead is
>> accepted. For example, one could forcibly upcast objects if their type
> goes
>> out of scope.
> 
> Silent truncation (upcasting) of a type was considered a very bad thing
> during the design of Ada 95. Anything that would require that (such has
> having both statically and dynamically tagged operands in a single call -
> see 3.9.2(8)) is illegal.
> 
> You could argue whether that is a good idea

I would not. Tags should be constant that is almost sacral to me. (:-)) But
only if objects are by-reference, which is the case anyway. But if some day
Ada will allow by-value tagged objects, then ...

> or not, but I don't think that
> we're going to change that part of the philosophy.

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

Re: A simple ADA puzzle (I haven't the answer)

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:gai7jyv9d81z.8udv40m7s363.dlg@40tude.net...
> On Thu, 24 Jun 2004 15:53:33 -0500, Randy Brukardt wrote:
> >> But I will be still able to allocate it, return a class-wide pointer
and
> >> then to dispatch to an out-of-scope subroutine. It seems that some
> >> additional overhead will be needed to catch that.
> >
> > No. The conversion to the class-wide pointer (presumably global) would
fail
> > its accessibility check. So the program would be illegal. No overhead
> > needed.
>
> I see.
>
> I hope that Unchecked_Conversion on such pointers and all sorts of games
> with 'Unchecked_Access on views will be also illegal.

If you creating dangling pointers with Unchecked_Conversion or with
'Unchecked_Access, and the dangling pointer is dereferenced, your program is
erroneous. Nothing new there. There is no way to check these, of course,
because the entire point is to eliminate checking in the cases where the
programmer is going to guarentee the lack of a problem. OTOH, if the pointer
isn't dangling (the object, and thus the type still exist), it should work
properly. That's why wrappers are used in the implementation model, not
something special happening on calls.

                         Randy.

Re: A simple ADA puzzle (I haven't the answer)

[Dmitry A. Kazakov]

On Fri, 25 Jun 2004 12:37:20 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:gai7jyv9d81z.8udv40m7s363.dlg@40tude.net...

>> I hope that Unchecked_Conversion on such pointers and all sorts of games
>> with 'Unchecked_Access on views will be also illegal.
> 
> If you creating dangling pointers with Unchecked_Conversion or with
> 'Unchecked_Access, and the dangling pointer is dereferenced, your program is
> erroneous. Nothing new there.

Well, there are shades of being erroneous. Probably, because accessibility
checks were undiscriminating, 'Unchecked_Access managed to become almost a
decent citizen. It seems that now 'Unchecked_Access will be less
necessary, but more dangerous. Bad news for those lazy, who accustomed to
type it automatically instead of 'Access.

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

Re: A simple ADA puzzle (I haven't the answer)

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:pan.2004.06.26.07.41.42.776463@dmitry-kazakov.de...
> On Fri, 25 Jun 2004 12:37:20 -0500, Randy Brukardt wrote:
> > If you creating dangling pointers with Unchecked_Conversion or with
> > 'Unchecked_Access, and the dangling pointer is dereferenced, your
program is
> > erroneous. Nothing new there.
>
> Well, there are shades of being erroneous. Probably, because accessibility
> checks were undiscriminating, 'Unchecked_Access managed to become almost a
> decent citizen. It seems that now 'Unchecked_Access will be less
> necessary, but more dangerous. Bad news for those lazy, who accustomed to
> type it automatically instead of 'Access.

I don't follow. It's going to be just as necessary, because the usual use is
to use it inside of a subprogram to put an object on a global chain. Even if
the object is known to be global, or finalization cleans up properly (as in
Claw), it still fails the accessibility check.

Similarly, the creation of dangling pointers isn't new. And it could hardly
get more dangerous than dereferencing a dangling pointer and writing over
someone else's memory - which can happen with any dangling pointer.
Dispatching (which only involves reading) is the least of the problems --
and typically it would trap even before getting anywhere (because the tag
has been overwritten) -- much less bad than the typical write through a
dangling pointer.

                      Randy.

Re: A simple ADA puzzle (I haven't the answer)

[Dmitry A. Kazakov]

On Mon, 28 Jun 2004 19:08:04 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:pan.2004.06.26.07.41.42.776463@dmitry-kazakov.de...
>> On Fri, 25 Jun 2004 12:37:20 -0500, Randy Brukardt wrote:
>>> If you creating dangling pointers with Unchecked_Conversion or with
>>> 'Unchecked_Access, and the dangling pointer is dereferenced, your
> program is
>>> erroneous. Nothing new there.
>>
>> Well, there are shades of being erroneous. Probably, because accessibility
>> checks were undiscriminating, 'Unchecked_Access managed to become almost a
>> decent citizen. It seems that now 'Unchecked_Access will be less
>> necessary, but more dangerous. Bad news for those lazy, who accustomed to
>> type it automatically instead of 'Access.
> 
> I don't follow. It's going to be just as necessary, because the usual use is
> to use it inside of a subprogram to put an object on a global chain. Even if
> the object is known to be global, or finalization cleans up properly (as in
> Claw), it still fails the accessibility check.
> 
> Similarly, the creation of dangling pointers isn't new. And it could hardly
> get more dangerous than dereferencing a dangling pointer and writing over
> someone else's memory - which can happen with any dangling pointer.

New is creation of dangling pointers in/to a dispatching table. Provided
that no tag checks are made.

Alternatively to tag checks one could patch the dispatching table by
throwing out all overridings happened in the scope. However then, one will
be able to dispatch to an abstract subprogram, much like in C++. Also this
would lead to memory leaks, if out-of-use dispatching tables are not
removed. Seems like no runner.

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

Re: A simple ADA puzzle (I haven't the answer)

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:lmxpjfq0f1wq$.58zpkhc78ocd.dlg@40tude.net...
> On Mon, 28 Jun 2004 19:08:04 -0500, Randy Brukardt wrote:

..
> > I don't follow. It's going to be just as necessary, because the usual
use is
> > to use it inside of a subprogram to put an object on a global chain.
Even if
> > the object is known to be global, or finalization cleans up properly (as
in
> > Claw), it still fails the accessibility check.
> >
> > Similarly, the creation of dangling pointers isn't new. And it could
hardly
> > get more dangerous than dereferencing a dangling pointer and writing
over
> > someone else's memory - which can happen with any dangling pointer.
>
> New is creation of dangling pointers in/to a dispatching table. Provided
> that no tag checks are made.

So what? That's no worse than anything else that can happen for a dangling
pointer. Besides, such dispatch tables can only exist in objects which
themselves are out of scope and have been finalized. (The objects always go
away before the type. That's why you're not allowed to allocate such a
nested type for a outer access type. Neither 'Unchecked_Access nor
Unchecked_Conversion can change the owner of an object.) So the dangling
pointer is the one at the object; the dispatch table is just another part of
the invalid contents.

Thus, there is no reason to treat these specially; nothing worse can happen
than can happen with any other dangling pointer. *Any* dangling pointer can
access or overwrite memory that it doesn't own. And code never disappears,
so there is no problem actually making a call.

I've had to debug programs that dispatched thru dangling pointers in Ada 95,
and it isn't pretty (usually, you end up jumping to some random location,
often several times before trapping). A dangling dispatch table would be a
lot easier to deal with, because it would actually be executing code (as
opposed to random junk).

                           Randy.

Re: A simple ADA puzzle (I haven't the answer)

[Randy Brukardt]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1087410710.477506@master.nyc.kbcfp.com...
> Frank J. Lhota wrote:
> > The problem with your definition of String_Type
>
> I don't know if you've been following the Improving Ada's
> Image thread, but this is a perfect illustration of what I
> said there - trying to handle strings in Ada is a nightmare
> if you don't understand a lot about arrays and types and
> constraints. New Ada users, especially those coming from C
> or Java, are going to be utterly confused.
>
> Just the fact that
>    type LEN_TYPE is array (INTEGER range <>) of CHARACTER;
>    type STRING_TYPE (LEN : INTEGER := 0) is
>      record STRING : LEN_TYPE (1 .. LEN); end record;
>    X : STRING_TYPE;
> can result in the allocation of all of memory is completely
> counterintuitive.

And just plain wrong, IMHO. The decision to allow Ada 83 compilers to
emasculate this critically useful feature was one of the worst made. (If
that decision had not been made, we wouldn't really need
Ada.Strings.Unbounded, among other things.) The original ACVC tests required
this to work, and people put pressure on the AVO to get them removed.

But, it's too late to reverse this decision (changing this has far reaching
consequences in compilers, and that makes the cost too high to contemplate).
Sigh.

                     Randy.

Re: A simple ADA puzzle (I haven't the answer)

[Jeffrey Carter]

Randy Brukardt wrote:

> And just plain wrong, IMHO. The decision to allow Ada 83 compilers to
>  emasculate this critically useful feature was one of the worst made.
> (If that decision had not been made, we wouldn't really need 
> Ada.Strings.Unbounded, among other things.) The original ACVC tests
> required this to work, and people put pressure on the AVO to get them
> removed.

It looks as if Randy is back from Europe (7 posts on this thread alone 
today).

While I agree with the concept, responses to the OP must deal with the 
language as it is and be portable across compilers.

-- 
Jeff Carter
"You empty-headed animal-food-trough wiper."
Monty Python & the Holy Grail
04

Re: A simple ADA puzzle (I haven't the answer)

[Frank J. Lhota]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:fd2dndsj1oy3aUTdRVn-vA@megapath.net...
> "Hyman Rosen" <hyrosen@mail.com> wrote in message
> news:1087410710.477506@master.nyc.kbcfp.com...
> > Just the fact that
> >    type LEN_TYPE is array (INTEGER range <>) of CHARACTER;
> >    type STRING_TYPE (LEN : INTEGER := 0) is
> >      record STRING : LEN_TYPE (1 .. LEN); end record;
> >    X : STRING_TYPE;
> > can result in the allocation of all of memory is completely
> > counterintuitive.
>
> And just plain wrong, IMHO. The decision to allow Ada 83 compilers to
> emasculate this critically useful feature was one of the worst made. (If
> that decision had not been made, we wouldn't really need
> Ada.Strings.Unbounded, among other things.) The original ACVC tests
required
> this to work, and people put pressure on the AVO to get them removed.
>
> But, it's too late to reverse this decision (changing this has far
reaching
> consequences in compilers, and that makes the cost too high to
contemplate).
> Sigh.

So if I understand the concept correctly, the way a compiler could handle
this type declaration would be to always allocate objects of this type off
of a heap, so that sizes could be adjusted as needed. In othr words, when
you declare

    My_String : STRING_TYPE;

then My_String could actually hold a pointer to an object on the heap, with
the current LEN discriminant. If My_String were assigned a value with a
different value of LEN, the pointer in My_String would be changed if
necessary to point to a heap object of the appropriate size. Is this the
Janus Ada approach?

AFAICT this approach would not conflict with any part of the language
standard, and would be a better approach to programming applications like
this. The only drawback is that this implicitly introduces the overhead of
heap manipulation, but it seems that this is hard to avoid in this problem
domain. So after giving the matter some thought, I agree with your (and I
believe Hyman's) POV on this matter: these declarations should be allowed
and implemented via the heap. Ada 95 compilers, by their very nature, have a
lot of the infrastructure needed to implement this approach, so this might
be a worthwhile addition to Ada 1x.

Re: A simple ADA puzzle (I haven't the answer)

[Ed Falis]

On Thu, 24 Jun 2004 15:19:51 GMT, Frank J. Lhota  
<NOSPAM.lhota.adarose@verizon.net> wrote:

> then My_String could actually hold a pointer to an object on the heap,  
> with
> the current LEN discriminant. If My_String were assigned a value with a
> different value of LEN, the pointer in My_String would be changed if
> necessary to point to a heap object of the appropriate size. Is this the
> Janus Ada approach?

This is the same approach the Alsys compilers used, Frank.  Except that  
the object could be allocated on stack as well on 68K targets (if memory  
serves).  The downside is all the potential allocation, deallocation and  
copying should the discriminant change.

- Ed

Re: A simple ADA puzzle (I haven't the answer)

[Randy Brukardt]

"Ed Falis" <falis@verizon.net> wrote in message
news:opr93v80kw5afhvo@localhost...
> On Thu, 24 Jun 2004 15:19:51 GMT, Frank J. Lhota
> <NOSPAM.lhota.adarose@verizon.net> wrote:
>
> > then My_String could actually hold a pointer to an object on the heap,
> > with
> > the current LEN discriminant. If My_String were assigned a value with a
> > different value of LEN, the pointer in My_String would be changed if
> > necessary to point to a heap object of the appropriate size. Is this the
> > Janus Ada approach?
>
> This is the same approach the Alsys compilers used, Frank.  Except that
> the object could be allocated on stack as well on 68K targets (if memory
> serves).  The downside is all the potential allocation, deallocation and
> copying should the discriminant change.

I thought I remembered that at least one other Ada 83 compiler did this.
Since we used the Alsys compiler as our model when in doubt, it's not
surprising that we decided to support that as well.

I understand that there is a lot of overhead when the size changes in this
approach. But there is nothing preventing implementors from using the
Max_Size approach when the Max_Size is reasonably small. That would leave
the costs only to objects for which there is little choice.

I really see no downside to requiring this support - customers want it and
try to use it all the time; it wouldn't have a performance impact on types
that already work; and the restriction No_Implicit_Heap_Allocation would be
used if you really had to avoid the overhead. But I'm in the minority on
this one.

                     Randy.

Re: A simple ADA puzzle (I haven't the answer)

[Frank J. Lhota]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:KZedneo665VD3EbdRVn-uA@megapath.net...
> I really see no downside to requiring this support - customers want it and
> try to use it all the time; it wouldn't have a performance impact on types
> that already work; and the restriction No_Implicit_Heap_Allocation would
be
> used if you really had to avoid the overhead. But I'm in the minority on
> this one.

As a recent convert, I can tell you how I became convinced of this point of
view. When it comes to implementing variant records, there are two ends of a
spectrum where the correct course of action is easily determined:

1) If the size of the record does not vary much, e.g. if the type
discriminants allow the length of a character array to vary from 1 to 20
characters, then you might as well eschew the overhead of heap allocation
and simply create the object "in place".

2) If the size of the record varies widely depending on the discriminants,
so that a variable of this type can store values that vary from 10 bytes to
10,000,000 bytes in length, then either the programmer or the compiler
should implement these objects using the heap. We can complain about the
overhead, but there is no other way.

But what about the cases between these two extremes? Assume that we are
writing code that is to be ported to multiple platforms. Assume further that
the variations in size of an object of our record type are large enough so
that on platforms with tight memory constraints (say embedded DOS) would
require heap allocation, but small enough that static allocation is an
option on other platforms. How do we write something that works and is
optimal for all platforms? Ideally, shouldn't the programmer write what is
desired, and let the compiler decide the most appropriate way to implement
it for the given platform?

When this argument occurred to me, it was one of those "Eureka!" moments.
Although it is too late to get this into Ada 0x, perhaps we can get this
changed for Ada 1x.

Re: A simple ADA puzzle (I haven't the answer)

[Bob Spooner]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> wrote in message
news:8yXCc.548$Av3.500@nwrdny01.gnilink.net...
> As a recent convert, ...
>
> But what about the cases between these two extremes? Assume that we are
> writing code that is to be ported to multiple platforms. Assume further
that
> the variations in size of an object of our record type are large enough so
> that on platforms with tight memory constraints (say embedded DOS) would
> require heap allocation, but small enough that static allocation is an
> option on other platforms. How do we write something that works and is
> optimal for all platforms? Ideally, shouldn't the programmer write what is
> desired, and let the compiler decide the most appropriate way to implement
> it for the given platform?
>

There is another case that isn't being considered here. When doing real-time
programming, I consider implicit use of the heap a _bad thing_ because the
amout of time it takes to do the allocation is not deterministic. If I want
something to be allocated on the heap, I will say so explicitly. I do not
want a compiler that silently does something I didn't ask for.

Bob

                            Robert L. Spooner
                     Registered Professional Engineer
                       Associate Research Engineer
                  Intelligent Control Systems Department

         Applied Research Laboratory        Phone: (814) 863-4120
         The Pennsylvania State University  FAX:   (814) 863-7841
         P. O. Box 30
         State College, PA 16804-0030       rls19@psu.edu

Re: A simple ADA puzzle (I haven't the answer)

[Frank J. Lhota]

"Bob Spooner" <rls19@psu.edu> wrote in message
news:cbhq5o$bne$1@f04n12.cac.psu.edu...
> There is another case that isn't being considered here. When doing
real-time
> programming, I consider implicit use of the heap a _bad thing_ because the
> amout of time it takes to do the allocation is not deterministic.

Would you consider it acceptable if implicit allocation could be controlled
by a pragma and / or compiler option? A compiler with such a pragma / option
would give us the best of both worlds, allowing the programmer to either
allow the compiler to choose the best option or to make that choice
herself/himself.

> If I want
> something to be allocated on the heap, I will say so explicitly. I do not
> want a compiler that silently does something I didn't ask for.

I am quite sympathetic to that point of view. The problem, as indicated in
my previous post, is that for some types, the choice of whether one wants to
use the stack for these object is platform-specific. How does one code such
types in a  portable way without allowing the compiler to choose the memory
allocation strategy? As noted before, pragmas and / or compiler options
could be used to override the compiler's default choice. Is there a downside
to this scheme? Is there an alternative scheme that would provide us with as
much portability?

Re: A simple ADA puzzle (I haven't the answer)

[Robert I. Eachus]

Frank J. Lhota wrote:

> I am quite sympathetic to that point of view. The problem, as indicated in
> my previous post, is that for some types, the choice of whether one wants to
> use the stack for these object is platform-specific. How does one code such
> types in a  portable way without allowing the compiler to choose the memory
> allocation strategy? As noted before, pragmas and / or compiler options
> could be used to override the compiler's default choice. Is there a downside
> to this scheme? Is there an alternative scheme that would provide us with as
> much portability?

Yes, and that is what has been chosen for Ada 0Y.  The container library 
will/should be the normal way of creating these unbounded objects in Ada 
0Y, and different implementations of the container library should give 
Frank what he wants.  Of course, if you want no implicit heap 
allocation, and types with potentially huge sizes, there will still be 
no workable solution on some systems.  But in that case, it is the 
nature of the problem.

Incidently, now that AMD is selling lots of AMD64 chips, and Intel will 
soon be shipping Pentium 4s with their version of the same ISA, 
allocating the max for a string with a 32-bit Integer index will not 
necessarily raise Storage_Error.  (You can do this on other 
architectures such as UltraSPARC and PowerPC as well.)  In fact, you 
should be able to allocate thousands of such objects, and let the 
virtual memory system deal with extending any particular string.

So even today, the code the OP was working with may allocate the max and 
still work on some architectures. ;-)


-- 

                                           Robert I. Eachus

"Reason and experience both forbid us to expect that national morality 
can prevail in exclusion of religious principles." -- George Washington

Re: A simple ADA puzzle (I haven't the answer)

[Steve]

The last I heard was Intel was only planning on including the 64 bit ISA on
their XEON processors.
Have you heard differently?

Steve
(The Duck)

"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:V8adnRwSBJZfCEDdRVn-uA@comcast.com...
[snip]
>
> Incidently, now that AMD is selling lots of AMD64 chips, and Intel will
> soon be shipping Pentium 4s with their version of the same ISA,
[snip]
>
>                                            Robert I. Eachus
>
> "Reason and experience both forbid us to expect that national morality
> can prevail in exclusion of religious principles." -- George Washington
>

Re: A simple ADA puzzle (I haven't the answer)

[Robert I. Eachus]

Steve wrote:

> The last I heard was Intel was only planning on including the 64 bit ISA on
> their XEON processors.
> Have you heard differently?

Yes, AFIAK right now, 64-bit Prescotts are scheduled for August.  We can 
argue whether or not they will be useful 64-bit chips due to the lack of 
an IOMMU.  But they will support the same ISA, and long-mode processes 
will be allowed to have terabytes of virtual memory.  (Just as long as 
it isn't all materialized, or you have plenty of disk space. ;-)

-- 

                                           Robert I. Eachus

"The flames kindled on the Fourth of July, 1776, have spread over too 
much of the globe to be extinguished by the feeble engines of despotism; 
on the contrary, they will consume these engines and all who work them." 
-- Thomas Jefferson, 1821

Re: A simple ADA puzzle (I haven't the answer)

[Randy Brukardt]

"Bob Spooner" <rls19@psu.edu> wrote in message
news:cbhq5o$bne$1@f04n12.cac.psu.edu...
> There is another case that isn't being considered here. When doing
real-time
> programming, I consider implicit use of the heap a _bad thing_ because the
> amout of time it takes to do the allocation is not deterministic. If I
want
> something to be allocated on the heap, I will say so explicitly. I do not
> want a compiler that silently does something I didn't ask for.

But you did ask for it -- you declared a variable-sized type. If you don't
want variable-sized types, then don't declare them.

In any case, Ada provides pragma Restrictions (No_Implicit_Heap_Allocations)
for this case. To say that a compiler should never implicitly use the heap
just because there are a few users that can't allow it is silly (especially
since a restriction is defined for these users). Most (regular) applications
use the heap plenty in their code, and additional use will not cause any
performance problems. Avoid heap use simply because it might cause a problem
is simply premature optimization for most applications.

So, no I have absolutely *no* sympathy for this position (in terms of the
language requirements, not of course in terms of application requirements).

                               Randy.

Re: A simple ADA puzzle (I haven't the answer)

[Randy Brukardt]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> wrote in message
news:riCCc.2700$A9.1045@nwrdny01.gnilink.net...
...
> So if I understand the concept correctly, the way a compiler could handle
> this type declaration would be to always allocate objects of this type off
> of a heap, so that sizes could be adjusted as needed. In othr words, when
> you declare
>
>     My_String : STRING_TYPE;
>
> then My_String could actually hold a pointer to an object on the heap,
with
> the current LEN discriminant. If My_String were assigned a value with a
> different value of LEN, the pointer in My_String would be changed if
> necessary to point to a heap object of the appropriate size. Is this the
> Janus Ada approach?

Essentially, although the allocation only done for components that depend on
discriminants and can change size (that is, arrays). Records are always
allocated fixed size (only the array components can change size, and they're
allocated separately). That works better when you have multiple array
components.

                       Randy.

Re: A simple ADA puzzle (I haven't the answer)

[Martin Krischik]

Abby wrote:

> Hi! I have this code:
> 
>   type LEN_TYPE is array (INTEGER range <>)
>     of CHARACTER;
> 
>   type STRING_TYPE (LEN : INTEGER := 0) is
>     record
>       STRING : LEN_TYPE (1 .. LEN);
>     end record;

STRING_TYPE'Size = (2**32 * 8 + 32);

>   type UNC2_ARRAY_TYPE is array (INTEGER range <>)
>     of STRING_TYPE;
> 
>   type RET2_TYPE (INIT : INTEGER := 0) is
>     record
>       IFOS : UNC2_ARRAY_TYPE (1 .. INIT);
>     end record;

RET2_TYPE'Size = ((2**32 * 8 +32) * (2**32 * 8)) +32;

 
>   type RET_TYPE
>        ( DEF : INTEGER := 0 )
>   is
>     record
>       ID  : INTEGER;
>       IFO : RET2_TYPE (INIT => DEF);
>     end record;

RET_TYPE'Size =  ((2**32 * 8 +32) * (2**32 * 8)) +32 + 2 * 32

>   type UNC_ARRAY_TYPE is
>     array (INTEGER range <>) of
>       RET_TYPE;
> 
> and i'd like to initialize and use a variable of type UNC_ARRAY_TYPE (for
> the unconstraint array and records choose any value you want, al least 1
> :) ). I can say that simply write  VAR : UNC_ARRAY_TYPE (1..3);  gives
> :some
> warning but compiles, but gives also a beautiful constraint_error when you
> use it, obviously. Any ideas? Thanx for your time!

Normalise to byte:

RET_TYPE'Storage_Elements =  ((2**32 +4 ) * (2**32)) +4 + 2 *4
RET_TYPE'Storage_Elements =  ((2**32 +4 ) * (2**32)) +12
RET_TYPE'Storage_Elements = 18.446.744.090.889.420.812

So unless you have 17.179.869.200 GB to spare the program is going to fail.

Try something like:

type Max_Len is range 0 .. 255;

type LEN_TYPE is array (Max_Len range <>)

But this will still be a static solution which will wast lots of memory

Maybe using Ada.Unbounded_Strings it the better option. And some component
library with some form of dynamic Array. There are lots of the around.


With Regards

Martin

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: A simple ADA puzzle (I haven't the answer)

[Björn Persson]

Martin Krischik wrote:

> So unless you have 17.179.869.200 GB to spare the program is going to fail.

Could it be that the code works on some compilers that use hidden 
pointers to dynamically allocated memory instead of allocating the 
maximum size (at least as long as no one calls RET_TYPE'Size)? If they 
have changed compilers at Abby's project, this could explain some things.

-- 
Björn Persson

jor ers @sv ge.
b n_p son eri nu

Re: A simple ADA puzzle (I haven't the answer)

[Steve]

I think the trick to the answer is that you must provide an initializer for
your structure that gives specific values to each of the discriminants.  The
use of default discriminants in the type definition is misleading... it will
not work.

Try something along the lines of
  VAR : UNC_ARRAY_TYPE := ( 1 => ... )

Sorry I don't have time to work out a full example right now.

Steve
(The Duck)


"Abby" <none@no.one.it> wrote in message
news:dRZzc.40593$G%.26441@tornado.fastwebnet.it...
> Hi! I have this code:
>
>   type LEN_TYPE is array (INTEGER range <>)
>     of CHARACTER;
>
>   type STRING_TYPE (LEN : INTEGER := 0) is
>     record
>       STRING : LEN_TYPE (1 .. LEN);
>     end record;
>
>   type UNC2_ARRAY_TYPE is array (INTEGER range <>)
>     of STRING_TYPE;
>
>   type RET2_TYPE (INIT : INTEGER := 0) is
>     record
>       IFOS : UNC2_ARRAY_TYPE (1 .. INIT);
>     end record;
>
>   type RET_TYPE
>        ( DEF : INTEGER := 0 )
>   is
>     record
>       ID  : INTEGER;
>       IFO : RET2_TYPE (INIT => DEF);
>     end record;
>
>   type UNC_ARRAY_TYPE is
>     array (INTEGER range <>) of
>       RET_TYPE;
>
> and i'd like to initialize and use a variable of type UNC_ARRAY_TYPE (for
> the unconstraint array and records choose any value you want, al least 1
> :) ). I can say that simply write  VAR : UNC_ARRAY_TYPE (1..3);  gives
some
> warning but compiles, but gives also a beautiful constraint_error when you
> use it, obviously. Any ideas? Thanx for your time!
>
>

Re: A simple ADA puzzle (I haven't the answer)

[Björn Persson]

Steve wrote:

> Try something along the lines of
>   VAR : UNC_ARRAY_TYPE := ( 1 => ... )

That doesn't help. The compiler will still try to make room for bigger 
values that may be assigned later. What you're trying to do can only be 
done with discriminants inside the type declarations, like this:

   type UNC2_ARRAY_TYPE is array (INTEGER range <>)
     of STRING_TYPE(50);

-- 
Björn Persson

jor ers @sv ge.
b n_p son eri nu