Re: private types

Re: private types

[Stanley R. Allen]

The message content seems to be hidden from the user!

-- 
Stanley Allen
mailto:s_allen@hso.link.com



Binh Truong wrote:

Re: private types

[Thomas Hood]

Of course it is...  It's private

Thomas Hood
thood@ifn.com

"Stanley R. Allen" wrote:
> 
> The message content seems to be hidden from the user!
> 
> --
> Stanley Allen
> mailto:s_allen@hso.link.com
> 
> Binh Truong wrote:

private types

[ada_student]

Consider the following package declaration,

    package PrivateType is

        type MyInteger is private;

        procedure  Read(O : out myInteger);
        procedure Write(I : in MyInteger);

    private

        type MyInteger is range 1 .. 2**31 - 1;

    end;

    Why does Ada allow MyInteger to be made visible outside the
    scope of PrivateType ? Doesnt it make the code less secure(for
    example,consider an "uninitialized" object of type
    PrivateType.MyInteger).

Re: private types

[Mark Lorenzen]

ada_student@yahoo.com writes:

> Consider the following package declaration,
> 
>     package PrivateType is
> 
>         type MyInteger is private;
> 
>         procedure  Read(O : out myInteger);
>         procedure Write(I : in MyInteger);
> 
>     private
> 
>         type MyInteger is range 1 .. 2**31 - 1;
> 
>     end;
> 
>     Why does Ada allow MyInteger to be made visible outside the
>     scope of PrivateType ? Doesnt it make the code less secure(for
>     example,consider an "uninitialized" object of type
>     PrivateType.MyInteger).

First of all: If you want to learn about Ada, I can recommend the book
"Programming in Ada 95" by John Barnes.

I think that I understand what you are trying to do... You want to
prevent the user of your package from declaring uninitialised
variables of type PrivateType.MyInteger, right? In this case I would
declare the partial view of the type (the non-private part) to be
indefinite:

        type MyInteger (<>) is private;

And then declare a function to provide an initial value of that type:

        function Nil returns MyInteger;

The user of your package can then only declare a variable of type
PrivateType.MyInteger if she initialises it at the same time:

with PrivateType;

[...]

My_Var : PrivateType.MyInteger := PrivateType.Nil;

Again: A good textbook on the subject will give you a much better
understanding of the language than just trying to find Ada equivalents
of C++ intricacies.

- Mark

Re: private types

[Pascal Obry]

Mark Lorenzen a �crit :

> I think that I understand what you are trying to do... You want to
> prevent the user of your package from declaring uninitialised
> variables of type PrivateType.MyInteger, right? In this case I would
> declare the partial view of the type (the non-private part) to be
> indefinite:
> 
>         type MyInteger (<>) is private;

Or:

private
   type T is range 1 .. 2**31 - 1;

   type MyInteger is record
      Value : T := 0;
   end record;

This depends on the "real" program. Hard to tell if this is not overkill
for the simple code snippet posted :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: private types

[ada_student]

>
>         type MyInteger (<>) is private;
>

Funny, how my copy of the AARM doesnt include this
construct in the grammar although ObjectAda points
to  LRM:3.3.1(5) which states (in my copy) -->

    "An object_declaration without the reserved word constant
    declares a variable object. If it has a subtype_indication or
    an array_type_definition that defines an indefinite subtype,
    then there shall be an initialization expression. An
    initialization expression shall not be given if the object is
    of a limited type."

Re: private types

[Simon Wright]

ada_student@yahoo.com writes:

>>
>>         type MyInteger (<>) is private;
>>

unknown_discriminant_part .. 3.7(3).

This use is 7.3(11).

Re: private types

[Jeffrey R. Carter]

ada_student@yahoo.com wrote:

> Consider the following package declaration,
> 
>     package PrivateType is
> 
>         type MyInteger is private;
> 
>         procedure  Read(O : out myInteger);
>         procedure Write(I : in MyInteger);
> 
>     private
> 
>         type MyInteger is range 1 .. 2**31 - 1;
> 
>     end;
> 
>     Why does Ada allow MyInteger to be made visible outside the
>     scope of PrivateType ? Doesnt it make the code less secure(for
>     example,consider an "uninitialized" object of type
>     PrivateType.MyInteger).

Because that's what private means in Ada.

I suggest you spend some time with an Ada text or tutorial. It appears that 
you're guessing at Ada based on experience with another language.

On-line texts and tutorials are available at adapower.com and adaworld.com. If 
you're fairly experienced in another language, you might want to look at "Ada 
Distilled". It's fairly concise while still providing a good introduction to Ada 
concepts.

-- 
Jeff Carter
"You've got the brain of a four-year-old boy,
and I bet he was glad to get rid of it."
Horse Feathers
47

Re: private types

[Brian May]

>>>>> "Jeffrey" == Jeffrey R Carter <spam.not.jrcarter@acm.not.spam.org> writes:
    >> MyInteger to be made visible outside the scope of PrivateType ?
    >> Doesnt it make the code less secure(for example,consider an
    >> "uninitialized" object of type PrivateType.MyInteger).

    Jeffrey> Because that's what private means in Ada.

He does have a point though - some languages will initialise all
variables to dummy values - this means you can get predictable results
in code that (wrongly) uses them before setting them to a value.

In this case it is possible to force initialisation (at least outside
the package), as per another poster's suggestion, because it is a
private type. Alternatively it is possible to turn it into a record
type and provide a default value for the component, as per another
post.

In other cases it isn't so easy, e.g. any non-private non-record type.

In fact, by default (at least last time I checked), gcc (or was that
gnat) doesn't check the validity of parameters to functions if the
type matches, even though the type hasn't been initialised and may
just happen to contain an illegal value.

I seem to recall Ada will initialise access types to null, and record
components (if defaults given), but nothing else.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: private types

[Ludovic Brenta]

Brian May a écrit :
> In fact, by default (at least last time I checked), gcc (or was that
> gnat) doesn't check the validity of parameters to functions if the
> type matches, even though the type hasn't been initialised and may
> just happen to contain an illegal value.

That is true, you need to pass -gnatVi -gnatVm to enable these checks.

-- 
Ludovic Brenta.

Re: private types

[Alex R. Mosteo]

Brian May wrote:
>>>>>>"Jeffrey" == Jeffrey R Carter <spam.not.jrcarter@acm.not.spam.org> writes:
> 
>     >> MyInteger to be made visible outside the scope of PrivateType ?
>     >> Doesnt it make the code less secure(for example,consider an
>     >> "uninitialized" object of type PrivateType.MyInteger).
> 
>     Jeffrey> Because that's what private means in Ada.
> 
> He does have a point though - some languages will initialise all
> variables to dummy values - this means you can get predictable results
> in code that (wrongly) uses them before setting them to a value.
> 
> In this case it is possible to force initialisation (at least outside
> the package), as per another poster's suggestion, because it is a
> private type. Alternatively it is possible to turn it into a record
> type and provide a default value for the component, as per another
> post.
> 
> In other cases it isn't so easy, e.g. any non-private non-record type.
> 
> In fact, by default (at least last time I checked), gcc (or was that
> gnat) doesn't check the validity of parameters to functions if the
> type matches, even though the type hasn't been initialised and may
> just happen to contain an illegal value.
> 
> I seem to recall Ada will initialise access types to null, and record
> components (if defaults given), but nothing else.

Access variables are initialized to null by language definition. 
Normalize_Scalars pragma exists also, and Gnat has Initialize_Scalars I 
think. These can give more control, but IMHO that's an after-the-bug 
resort.

Re: private types

[Justin Gombos]

On 2006-03-14, Brian May <bam@snoopy.apana.org.au> wrote:
>
> He does have a point though - some languages will initialise all
> variables to dummy values - this means you can get predictable
> results in code that (wrongly) uses them before setting them to a
> value.

Beyond access types, I would not consider that feature you're
describing helpful.  In fact, it's more of a disservice.  

The first problem: initializing to zero, or some other "dummy" value
of the compilers choice is likely to result in a valid value
(sometimes), which only serves to /hide/ bugs in the cases where the
object is used prior to a meaningful assignment.

Then problem with user forced initialization (which is what the OP is
after): it could mask the cases where reassignment is inevitable.
IOW, suppose you have subprograms like this:

  function exists return boolean is

    --Later assignment to found_it is evitable
    --
    found_it : boolean := false;

  begin

    if some_precondition then

      found_it := some_other_condition;

    end if;

    return found_it;

  end exists;

In the above case, an initial value may persist if some path is not
executed.  The maintainer can immediately expect this to be the case
upon seeing the initialization (assuming the author was competent).
In other cases, an initial value may get overwritten no matter what.
In these cases it makes more sense not to initialize, because it
clarifies to the maintainer what kind of logic to expect before even
looking at the body of code.

It's always irritating to be reading someone elses code, and find that
they've blanket initialized objects needlessly.  It hides bugs, and
also obscures the logic from the maintainer.

We don't know enough about the OPs case to know whether forced
initialization is wise, but he should be cautioned not to take this
approach arbitrarily, or on a regular basis.  It really depends on the
situation.

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: private types

[Brian May]

I am not sure how this:

  function exists return boolean is

    --Later assignment to found_it is evitable
    --
    found_it : boolean := false;

  begin

    if some_precondition then

      found_it := some_other_condition;

    end if;

    return found_it;

  end exists;

Is any better/worse then this:

  function exists return boolean is

    --Later assignment to found_it is evitable
    --
    found_it : boolean;

  begin

    if some_precondition then

      found_it := some_other_condition;

    end if;

    return found_it;

  end exists;

It is possible a smart compiler might trigger a warning in the second
case - but this depends on you noticing the warning and investigating
it. There are cases when the compiler might get confused and produce
false positives or false negatives.

Otherwise, the above problem is a problem that can only be found
either by careful inspection of the code or by proper testing.

For testing the code, as found_it is undefined in the second test, it
is possible it might just fluke the tests you give it and pass
everyone.

The first code is predictable though, and as long as you give it the
same inputs, it will always produce the same outputs, making it easier
(IMHO) to test.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: private types

[Justin Gombos]

On 2006-03-17, Brian May <bam@snoopy.apana.org.au> wrote:
> I am not sure how this:
>
>   function exists return boolean is
>
>     --Later assignment to found_it is evitable
>     --
>     found_it : boolean := false; 
> 
>   begin
>
>     if some_precondition then
>
>       found_it := some_other_condition;
>
>     end if;
>
>     return found_it;
>
>   end exists;
>
> Is any better/worse then this:
>
>   function exists return boolean is
>
>     --Later assignment to found_it is evitable
>     --
>     found_it : boolean;
>
>   begin
>
>     if some_precondition then
>
>       found_it := some_other_condition;
>
>     end if;
>
>     return found_it;
>
>   end exists;

The second case is obviously careless, and as you say, unpredictible.
The first case is a good approach, as is this alternative:

  function exists return boolean is

    --Later assignment to found_it is inevitable
    --
    found_it : boolean;

  begin

    if some_precondition then

      found_it := some_other_condition;
  
    else

      found_it := a_different_condition;

    end if;

    return found_it;

  end exists;
 
My main purpose was to put the spotlight on this foolish practice:

  function exists return boolean is

    --Later assignment to found_it is inevitable
    --
    found_it : boolean := false; --needless and misleading initialization

  begin

    if some_precondition then

      found_it := some_other_condition;
  
    else

      found_it := a_different_condition;

    end if;

    return found_it;

  end exists;

Users of the OPs API might be forced into this scenario if the API is
constructed to force explicit initialization on instantiation.

> It is possible a smart compiler might trigger a warning in the
> second case - but this depends on you noticing the warning and
> investigating it. There are cases when the compiler might get
> confused and produce false positives or false negatives.
>
> Otherwise, the above problem is a problem that can only be found
> either by careful inspection of the code or by proper testing.

Sure there are multiple opportunities to find flaws; but the idea is
to not depend on them more than we have to.

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: private types

[Randy Brukardt]

"Brian May" <bam@snoopy.apana.org.au> wrote in message
news:sa4hd5x1wgd.fsf@snoopy.microcomaustralia.com.au...
...
> For testing the code, as found_it is undefined in the second test, it
> is possible it might just fluke the tests you give it and pass
> everyone.
>
> The first code is predictable though, and as long as you give it the
> same inputs, it will always produce the same outputs, making it easier
> (IMHO) to test.

It's not just testing. Ada 95 is very clear that an Ada compiler cannot
assume an object is in range unless it can prove it is initialized. Explicit
initialization makes this proof trivial (and leaving it out may make it
impossible to prove.) Thus, given
    A : Positive := 10;
    B : Positive;
the compiler can assume that A is in range, potentially being able to
eliminate checks and speeding up the code. But it cannot assume that B is in
range (unless it can prove that it is initialized further on).

So I recommend initalizing everything (or assigning it immediately after the
begin) that could be significant to performance.

                                     Randy.

Re: private types

[Justin Gombos]

On 2006-03-18, Randy Brukardt <randy@rrsoftware.com> wrote:
>
> Thus, given
>     A : Positive := 10;
>     B : Positive;
> the compiler can assume that A is in range, potentially being able
> to eliminate checks and speeding up the code. But it cannot assume
> that B is in range (unless it can prove that it is initialized
> further on).
>
> So I recommend initalizing everything (or assigning it immediately
> after the begin) that could be significant to performance.

As a rule, I try to put readability ahead of optimizations.  But if I
did want to write optimum code, I'm not seeing your point here.  

The runtime checks that might be placed on B need not affect code not
handling B.  Assuming an extreme case, suppose B is not assigned until
100 lines later (ie not immediately following the begin).  There
should be no runtime checks in those 100 lines between the 'begin' and
the first assignment to B if B is not referenced (and if B is
referenced prior to assignment, that's a problem that outweighs
excessive checks anyway).  The first occurrance of B is going to be an
assignment to B, and it must have the same checks that A would have if
A were being reassigned at this point.  So I'm not seeing why more
runtime checks would occur in the case of B.

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: private types

[Randy Brukardt]

"Justin Gombos" <rpbkbq.xax.gld@uluv.kbq> wrote in message
news:I4KSf.552$bu.180@trnddc04...
> On 2006-03-18, Randy Brukardt <randy@rrsoftware.com> wrote:
> >
> > Thus, given
> >     A : Positive := 10;
> >     B : Positive;
> > the compiler can assume that A is in range, potentially being able
> > to eliminate checks and speeding up the code. But it cannot assume
> > that B is in range (unless it can prove that it is initialized
> > further on).
> >
> > So I recommend initalizing everything (or assigning it immediately
> > after the begin) that could be significant to performance.
>
> As a rule, I try to put readability ahead of optimizations.  But if I
> did want to write optimum code, I'm not seeing your point here.

You're right about premature optimizations, of course.

> The runtime checks that might be placed on B need not affect code not
> handling B.  Assuming an extreme case, suppose B is not assigned until
> 100 lines later (ie not immediately following the begin).  There
> should be no runtime checks in those 100 lines between the 'begin' and
> the first assignment to B if B is not referenced (and if B is
> referenced prior to assignment, that's a problem that outweighs
> excessive checks anyway).  The first occurrance of B is going to be an
> assignment to B, and it must have the same checks that A would have if
> A were being reassigned at this point.  So I'm not seeing why more
> runtime checks would occur in the case of B.

Because, in general, you don't know whether B is initialized. And Ada 95
requires that invalid values be detected before they cause any damage (with
some unfortunate exceptions). If B is used to index an array, for instance,
it must be checked unless the compiler can prove that it is valid. But that
is very hard in general, because of path issues:

    B : Positive;
 begin
   if Bafflegab (10) then
        B := 10;
   end if;
   ... Str (B) ... -- Must check for invalid values here.
 end;

There is no way that the compiler can tell if B has been initialized or not.
And Ada 95 does not allow *assuming* that it is initialized (which is
essentially what your argument boils down to) -- the compiler must presume
the program is incorrect for this purpose unless it can prove that it is
not.

But note Bob Duff's point that there are other ways to arrange code
generators that might have different effects on checking. That's true in
general, but in this case in particular, the compiler cannot remove the
check for Str (B) no matter what the code generation scheme. If B had been
initialized, it would have been able to in most schemes.

In any case, in most real code, it's hard to prove something is initialized
unless it is done right at the top. Moreover, compilers vary in the amount
of flow analysis that they do. So preinitializtion is the way to go for
maximum portability. (But I suggest this when you're going to initialize the
value anyway, as opposed to initializing it just for this purpose.)

                              Randy.

Re: private types

[Martin Dowie]

Randy Brukardt wrote:
> It's not just testing. Ada 95 is very clear that an Ada compiler cannot
> assume an object is in range unless it can prove it is initialized. Explicit
> initialization makes this proof trivial (and leaving it out may make it
> impossible to prove.) Thus, given
>     A : Positive := 10;
>     B : Positive;
> the compiler can assume that A is in range, potentially being able to
> eliminate checks and speeding up the code. But it cannot assume that B is in
> range (unless it can prove that it is initialized further on).
> 
> So I recommend initalizing everything (or assigning it immediately after the
> begin) that could be significant to performance.


Or use a tool like PolySpace, which is very good at spotting this sort 
of thing. (www.polyspace.com).

Cheers

-- Martin

Re: private types

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> It's not just testing. Ada 95 is very clear that an Ada compiler cannot
> assume an object is in range unless it can prove it is initialized.

This is not quite true.  What the compiler can prove depends on the
compiler's code generation strategy.  Example:

    type Index is range 1..10;
    type A is array(Index) of Character;

    X: Index; -- not initialized here

    procedure P(Y: Index) is
    begin
        ...
    end P;

    ... -- (*) might initialize X here

    P(X);

Suppose the compiler cannot prove that the code marked "-- (*)"
will initialize X.  The compiler has a choice:  It can do
a range check at the call to P, and then assume inside the body
of P that Y is in range (even though the value _might_ have
come from an uninitialized variable).  Or, the compiler can
avoid the range check on the call to P, in which case it cannot
assume that Y is in range.

> So I recommend initalizing everything (or assigning it immediately after the
> begin) that could be significant to performance.

That also depends on the compiler.  Many compilers can prove that a
variable is initialized here:

    begin
        if ... then
            A := 3;
        else
            A := 4;
        end if;
        ... -- Here, we can presume A is in range.

Adding "A := 0;" between "begin" and "if" would be overkill
for such compilers.

- Bob

Re: private types

[Maciej Sobczak]

Justin Gombos wrote:

>>He does have a point though - some languages will initialise all
>>variables to dummy values - this means you can get predictable
>>results in code that (wrongly) uses them before setting them to a
>>value.
> 
> Beyond access types, I would not consider that feature you're
> describing helpful.  In fact, it's more of a disservice.  

So you have the whole pragma as such "disservice":

http://www.adaic.org/standards/95aarm/html/AA-H-1.html


> The first problem: initializing to zero, or some other "dummy" value
> of the compilers choice is likely to result in a valid value
> (sometimes), which only serves to /hide/ bugs in the cases where the
> object is used prior to a meaningful assignment.

Right. Then, why not minimize the scope of the object to the extent when 
it's never even visible before being initialized with the value that is 
meaningful in the given context? It's not always possible, of course, 
but in many (most?) cases programmers tend to put all variables at the 
beginning of some rather coarse-grained scope (for example, beginning of 
the procedure or function), and later wonder what is the "right" initial 
value for them. It's the misplacement of declaration that is a primary 
source of problems and this is what should be actually addressed.

> Then problem with user forced initialization (which is what the OP is
> after): it could mask the cases where reassignment is inevitable.
> IOW, suppose you have subprograms like this:
> 
>   function exists return boolean is
> 
>     --Later assignment to found_it is evitable
>     --
>     found_it : boolean := false;
> 
>   begin
> 
>     if some_precondition then
> 
>       found_it := some_other_condition;
> 
>     end if;
> 
>     return found_it;
> 
>   end exists;

Single entry - single exit syndrome? :)


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: private types

[Frank J. Lhota]

Maciej Sobczak wrote:
> Justin Gombos wrote:
> 
>> ....
>>
>> Beyond access types, I would not consider that feature you're
>> describing helpful.  In fact, it's more of a disservice.  
> 
> So you have the whole pragma as such "disservice":
> 
> http://www.adaic.org/standards/95aarm/html/AA-H-1.html

Actually, the purpose of the Normalize_Scalars pragma is to eliminate 
any dependency on default initializations. The idea is to fill those 
scalars that are not initialized by the user with some extreme value, 
preferably out of range, so that any use of an uninitialized value can 
be readily detected.

The Normalize_Scalars pragma is the high level version of the "DEAD 
BEEF" option provided by many Unix C compilers / linkers. As you may 
recall, the C standard specifies that any static data not initialized by 
the user is implicitly initialized to 0. With the "DEAD BEEF" option, 
the static data not initialized in the code is filled with the hex bytes 
0xDEADBEEF, which results in outrageous integer / floating point / 
string values. Again, the point of this option is to eliminate 
dependence on implicit initialization.

>> The first problem: initializing to zero, or some other "dummy" value
>> of the compilers choice is likely to result in a valid value
>> (sometimes), which only serves to /hide/ bugs in the cases where the
>> object is used prior to a meaningful assignment.
> 
> Right. Then, why not minimize the scope of the object to the extent when 
> it's never even visible before being initialized with the value that is 
> meaningful in the given context? It's not always possible, of course, 
> but in many (most?) cases programmers tend to put all variables at the 
> beginning of some rather coarse-grained scope (for example, beginning of 
> the procedure or function), and later wonder what is the "right" initial 
> value for them. It's the misplacement of declaration that is a primary 
> source of problems and this is what should be actually addressed.
> 
>> Then problem with user forced initialization (which is what the OP is
>> after): it could mask the cases where reassignment is inevitable.
>> IOW, suppose you have subprograms like this:
>>
>>   function exists return boolean is
>>
>>     --Later assignment to found_it is evitable
>>     --
>>     found_it : boolean := false;
>>
>>   begin
>>
>>     if some_precondition then
>>
>>       found_it := some_other_condition;
>>
>>     end if;
>>
>>     return found_it;
>>
>>   end exists;
> 
> Single entry - single exit syndrome? :)
> 
> 


-- 
"All things extant in this world,
Gods of Heaven, gods of Earth,
Let everything be as it should be;
Thus shall it be!"
- Magical chant from "Magical Shopping Arcade Abenobashi"

"Drizzle, Drazzle, Drozzle, Drome,
Time for the this one to come home!"
- Mr. Lizard from "Tootor Turtle"

Re: private types

[Justin Gombos]

On 2006-03-17, Maciej Sobczak <no.spam@no.spam.com> wrote:
>
> So you have the whole pragma as such "disservice":
>
> http://www.adaic.org/standards/95aarm/html/AA-H-1.html

I don't have a problem with implicit initializations when the compiler
can ensure a bad value (or "abnormal object", to use the language of
the ARM).  I was responding to Brian May's comment about compilers
implicitly assigning "dummy values", which did not sound to me like
values that are intelligently selected to be invalid for the type.
I've heard of compilers implicitly initializing to zero, and figured
that was what he might be advocating.

BTW- I sometimes have a use for creating an abnormal object, and find
     Ada lacking in not providing such a mechanism.  I'm sometimes
     forced to either include abnormal values in the set of values
     declared for a type, or to have a seperate flag.  Both of these
     are messy.  Why not have a 'invalid function added to Ada to
     enable simple and explicit initialization of abnormal objects?

> Right. Then, why not minimize the scope of the object to the extent
> when it's never even visible before being initialized with the value
> that is meaningful in the given context? It's not always possible,
> of course, but in many (most?) cases programmers tend to put all
> variables at the beginning of some rather coarse-grained scope (for
> example, beginning of the procedure or function), and later wonder
> what is the "right" initial value for them. It's the misplacement of
> declaration that is a primary source of problems and this is what
> should be actually addressed.

I agree.  Declare blocks can eliminate some of these issues.  I like
the fact that declare blocks enable me to declare more constants than
variables.  But it's not a full solution.  The opposite extreme of
this would be to introduce a declare block at every introduction of a
new object, which can obviously become detrimental to readability.
It's a trade off that requires judgement - judgement that is unequal
among adaists.

> Single entry - single exit syndrome? :)

Yes, I have that syndrome.  I think I acquired it from the Ada Quality
and Style Guide or a coding standard that I followed at one point.

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: private types

[Randy Brukardt]

"Justin Gombos" <rpbkbq.xax.gld@uluv.kbq> wrote in message
news:FJHSf.1898$TK2.497@trnddc07...
...
> BTW- I sometimes have a use for creating an abnormal object, and find
>      Ada lacking in not providing such a mechanism.  I'm sometimes
>      forced to either include abnormal values in the set of values
>      declared for a type, or to have a seperate flag.  Both of these
>      are messy.  Why not have a 'invalid function added to Ada to
>      enable simple and explicit initialization of abnormal objects?

You're confusing an "invalid" object with an "abnormal" object. Accessing an
abnormal one is erroneous; surely you don't want to intentionally put that
into your programs. (Remember, "erroneous" is Ada-speak for "anything at all
can happen".)

The reason there is no way to construct invalid values is simple: there is
no requirement that an implementation provide any such values. Some types
(like Integer) don't have any invalid values; what would 'Invalid return for
them. (This is the reason that Normalize_Scalars doesn't require
initialization to invalid values.) Moreover, "invalid" only applies to
scalar objects; there is no similar concept for composite types. In any
case, this is a very complex area, and I don't think anyone wants to tread
here.

I'm dubious about your problem anyway; the values you are talking about are
clearly part of the value set of a type. Claiming that they are not and
trying to avoid including them is just confusing. "Null", for instance, is
just another normal value (there are no valid or invalid values for access
types, as they are not scalar) for an access type. Sure, it means "no
object", and that's a bit unusual, but it's clearly an expected value.

                                     Randy.

Re: private types

[Dmitry A. Kazakov]

On Fri, 17 Mar 2006 23:36:05 GMT, Justin Gombos wrote:

> BTW- I sometimes have a use for creating an abnormal object, and find
>      Ada lacking in not providing such a mechanism.  I'm sometimes
>      forced to either include abnormal values in the set of values
>      declared for a type, or to have a seperate flag.  Both of these
>      are messy.  Why not have a 'invalid function added to Ada to
>      enable simple and explicit initialization of abnormal objects?

As Randy have pointed out, there is a great difference between faults and
bugs. If we stay in the realm of correct programs, then the mechanism you
are asking for is subtyping. One can exclude some values by putting a
subtype constraint on the base type.

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

Re: private types

[Robert A Duff]

Justin Gombos <rpbkbq.xax.gld@uluv.kbq> writes:

> On 2006-03-14, Brian May <bam@snoopy.apana.org.au> wrote:
> >
> > He does have a point though - some languages will initialise all
> > variables to dummy values - this means you can get predictable
> > results in code that (wrongly) uses them before setting them to a
> > value.
> 
> Beyond access types, I would not consider that feature you're
> describing helpful.

I'm not sure what the right answer is, but surely all the arguments for
and against dummy values apply equally to access types.

- Bob

Re: private types

[Justin Gombos]

On 2006-03-17, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
> Justin Gombos <rpbkbq.xax.gld@uluv.kbq> writes:
>
> I'm not sure what the right answer is, but surely all the arguments
> for and against dummy values apply equally to access types.

I don't agree with that.  Null is a standard abnormal object for
access types in all languages, and can never be taken for something
valid.  Null pointers are quickly detected, and easily understood.

But with any other type, null (zero) is most likely a valid value.
This is probably why the ARM states:

      The implicit initial value for an access subtype is the null
      value of the access type.

But makes no such rule for other types.

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: private types

[Dmitry A. Kazakov]

On Fri, 17 Mar 2006 23:44:08 GMT, Justin Gombos wrote:

> On 2006-03-17, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
>> Justin Gombos <rpbkbq.xax.gld@uluv.kbq> writes:
>>
>> I'm not sure what the right answer is, but surely all the arguments
>> for and against dummy values apply equally to access types.
> 
> I don't agree with that.  Null is a standard abnormal object for
> access types in all languages, and can never be taken for something
> valid.

No. Null is a legal access value. You can compare, copy, assign null
pointers. You *can* dereference them! It is just so, that the effect of
this operation would be Constraint_Error.

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

Re: private types

[Robert A Duff]

Justin Gombos <rpbkbq.xax.gld@uluv.kbq> writes:

> On 2006-03-17, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
> > Justin Gombos <rpbkbq.xax.gld@uluv.kbq> writes:
> >
> > I'm not sure what the right answer is, but surely all the arguments
> > for and against dummy values apply equally to access types.
> 
> I don't agree with that.  Null is a standard abnormal object for
> access types in all languages, and can never be taken for something
> valid.

Null is neither "abnormal" nor "invalid" in Ada.  As for "all
languages", some have a concept of "null" or "nil" or whatever that is
the same in this regard.  Some languages have no such concept.

In Ada, if an object of an access type has no explicit initial value,
you can't easily tell whether that means "null is a meaningful value for
this variable, and that's the default I want" versus "this variable will
be initialized to a meaningful (non-null) value later".

This is exactly analogous to the case with integers -- if they were
default-initialized to zero, you can't easily tell whether zero is
intended as a meaningful initial value, versus later initialization to a
meaningful value.

- Bob

Re: private types

[Justin Gombos]

On 2006-03-18, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
>
> In Ada, if an object of an access type has no explicit initial
> value, you can't easily tell whether that means "null is a
> meaningful value for this variable, and that's the default I want"
> versus "this variable will be initialized to a meaningful (non-null)
> value later".

If you want to distinguish between the two possiblities, you could
explicitly initialize your pointers to null in the first case, and not
in the second.  I rarely use access types, and I probably wouldn't do
that myself simply because I find the distinction unimportant for
access types.  Regardless, I'm not going to give up the benefit of
having this distinction on non-access scalars simply because my access
type declarations don't have it.

> This is exactly analogous to the case with integers -- if they were
> default-initialized to zero, you can't easily tell whether zero is
> intended as a meaningful initial value, versus later initialization
> to a meaningful value.

Integers, and other non-access scalars are different in this case
because you cannot expect zero to have the same meaning.  Zero has a
universal meaning with access types, but it could be in range or out
of range for any other type.  The ARM selects access types
specifically to get a default initialization of zero for this reason.

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: private types

[Martin Krischik]

Justin Gombos wrote:

> Zero has a
> universal meaning with access types, but it could be in range or out
> of range for any other type. ï¿œThe ARM selects access types
> specifically to get a default initialization of zero for this reason.

Who says that Null := 16#0#? I could image a Hardware/CPU/OS where it would
be better to define Null := 16#FFFF_FFFF_FFFF_FFFF#.

For example an OS who's Virtual Memory Management System assign address
16#0# to be a valid address and to hold some important process data to
which the process needs access.

Of course programming C or C++ on such an OS could be quite challenging
(Write to (void*)0 and you mess up your Proccess Information Descriptor).

Martin 
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: private types

[Peter C. Chapin]

Martin Krischik <krischik@users.sourceforge.net> wrote in
news:1259548.CMTukHGvVZ@linux1.krischik.com: 

> Of course programming C or C++ on such an OS could be quite
> challenging (Write to (void*)0 and you mess up your Proccess
> Information Descriptor). 

The C/C++ standard does not require NULL pointers to be represented by all 
zero bits either. The null pointer constant, (void*)0, might be translated 
into 0xFFFFFFFF or some other value.

Peter

Re: private types

[Björn Persson]

Peter C. Chapin wrote:
> Martin Krischik <krischik@users.sourceforge.net> wrote in
> news:1259548.CMTukHGvVZ@linux1.krischik.com: 
>>Of course programming C or C++ on such an OS could be quite
>>challenging (Write to (void*)0 and you mess up your Proccess
>>Information Descriptor). 
> 
> The C/C++ standard does not require NULL pointers to be represented by all 
> zero bits either. The null pointer constant, (void*)0, might be translated 
> into 0xFFFFFFFF or some other value.

Well, does the standard require that (void*)0 == NULL? What if I wanted 
a pointer to address zero on this hypothetical OS? How would I get that 
if (void*)0 gets transformed to a non-zero NULL?

-- 
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: private types

[Martin Krischik]

Bjï¿œrn Persson wrote:

> Peter C. Chapin wrote:
>> Martin Krischik <krischik@users.sourceforge.net> wrote in
>> news:1259548.CMTukHGvVZ@linux1.krischik.com:
>>>Of course programming C or C++ on such an OS could be quite
>>>challenging (Write to (void*)0 and you mess up your Proccess
>>>Information Descriptor).
>> 
>> The C/C++ standard does not require NULL pointers to be represented by
>> all zero bits either. The null pointer constant, (void*)0, might be
>> translated into 0xFFFFFFFF or some other value.
> 
> Well, does the standard require that (void*)0 == NULL?

Before I learned C++ in deeps I thought the same. But then I read that the
use of #define NULL is depreciated C++ and that one should use a simple 0
instead.

> What if I wanted 
> a pointer to address zero on this hypothetical OS?

That too is an interesting point. Actually dereference to (char*)0 is not
forbidden - you will get the content of memory element 0x0. And when I did
C work on systems without an MMU and the memory protection this was a
serious problem. (char*)NULL would return data.

Modern OS don't map the first memory page to the process so access will
result in an error. But they only do that to ease up C/C++ development.
There is no other reason.

> How would I get that 
> if (void*)0 gets transformed to a non-zero NULL?

Interesting question.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: private types

[Maciej Sobczak]

Martin Krischik wrote:

>>Well, does the standard require that (void*)0 == NULL?
> 
> Before I learned C++ in deeps I thought the same. But then I read that the
> use of #define NULL is depreciated C++ and that one should use a simple 0
> instead.

Where did you read this?
NULL is not depreciated. It's defined in the <cstddef> header to be a 
null-pointer constant, which is any integral const expression that 
evaluates to 0. Possible definition is:

#define NULL 0

Note: the following is explicitly prohibited:

#define NULL (void*)0

but still, (void*)0 == NULL will always evaluate to true, even if the 
internal representation of the null pointer is not zero.


>>What if I wanted 
>>a pointer to address zero on this hypothetical OS?
> 
> That too is an interesting point. Actually dereference to (char*)0 is not
> forbidden - you will get the content of memory element 0x0.

Not necessarily. It depends on what is the internal representation of 
the null pointer.


One of the possible ways to *really* get at address 0x0 is to do 
reinterpret_cast or use a union with the same effect. Usual cast 
notation as the one above will not do.

>>How would I get that 
>>if (void*)0 gets transformed to a non-zero NULL?
> 
> Interesting question.

The interesting question is why it might make any difference to you?
The only thing that really matters is that the null pointer is distinct 
from any other valid pointer, in which case it's equivalent to Ada's 
null. If you need more knowledge than this, then either you are doing 
something wrong, or you work in the application domain where you really 
need an intimate knowledge of all the parts of the underlying platform - 
including your compiler - in which case your above worries are gone anyway.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: private types

[Peter C. Chapin]

Maciej Sobczak <no.spam@no.spam.com> wrote in
news:dvlu9d$mg6$1@sunnews.cern.ch: 

> Where did you read this?
> NULL is not depreciated. It's defined in the <cstddef> header to be a 
> null-pointer constant, which is any integral const expression that 
> evaluates to 0. Possible definition is:
> 
> #define NULL 0
> 
> Note: the following is explicitly prohibited:
> 
> #define NULL (void*)0

This defintion of NULL is not workable in C++. This is because C++ does 
not allow pointers to void to be put into other pointer types without a 
cast. If the above definition was used the following would be an error:

int *p = NULL;

Thus in C++, NULL must be defined as the literal "0". Note that this 
issue does not come up in C because C's type system is more permissive. 
Thus the (void*)0 is often used in C.

Because "NULL" just expands to "0" in C++, code using NULL can at times 
be misleading. For example consider

void f(int);
void f(char *);

f(NULL);  // Ambiguous, could call either f(int) or f(char *).

This is a surprising error. Other surprises come up when passing NULL to 
functions taking a variable number of arguments. Type checking is 
essentially turned off for the variable arguments and thus if integers 
and pointers have different representations or if the NULL pointer must 
be handled in a special way (not all bits zero), errors can occur

printf("The address is: %p\n", NULL);

In C++ this passes the integer zero to printf, not a pointer. The 
compiler can't understand that "0" is a null pointer constant in this 
context because it doesn't know what type the second argument to printf 
is supposed to be.

For these reasons many C++ experts recommend using "0" explicitly to 
represent NULL pointers and not the symbol NULL. This makes the problems 
above more apparent in the source and thus more likely that the 
programmer will notice them.

Peter

Re: private types

[Peter C. Chapin]

"Peter C. Chapin" <pchapin@sover.net> wrote in 
news:Xns978C3CC16F9D7pchapinsovernet@198.186.192.137:

> Maciej Sobczak <no.spam@no.spam.com> wrote in
> news:dvlu9d$mg6$1@sunnews.cern.ch: 
> 
>> Note: the following is explicitly prohibited:

Let me apologize for my last posting... I had read the above as "the 
following is explicitly *permitted*". I need to read a little more 
carefully in the future!

Peter

Re: private types

[Maciej Sobczak]

Peter C. Chapin wrote:

>>Note: the following is explicitly prohibited:
>>
>>#define NULL (void*)0
> 
> This defintion of NULL is not workable in C++.

Which we've already cleared. :)


> Thus in C++, NULL must be defined as the literal "0".

Not exactly. It can be anything that is an integral constant expression 
evalutating to zero. Thus, "0" is one obvious choice, but not any better 
than, say, "0L", "'\0'" or even "(125 - 5 * 5 * 5)".


> Because "NULL" just expands to "0" in C++, code using NULL can at times 
> be misleading. For example consider
> 
> void f(int);
> void f(char *);
> 
> f(NULL);  // Ambiguous, could call either f(int) or f(char *).
> 
> This is a surprising error.

That's why one of the sweeties in the upcoming C++ standard is a new 
keyword nullptr, which will be useable only in those contexts where a 
pointer type is expected, so that:

f(nullptr);

will always choose the second overload from the above.

> Other surprises come up when passing NULL to 
> functions taking a variable number of arguments.

Such functions are FUBARed anyway. :)

> For these reasons many C++ experts recommend using "0" explicitly to 
> represent NULL pointers and not the symbol NULL. This makes the problems 
> above more apparent in the source and thus more likely that the 
> programmer will notice them.

On the other hand, for the human reader "NULL" is immediately associated 
with some special pointer value, not with not-at-all-special integer, so 
that the following:

if (item != NULL) ...

is also immediately recognized as a test against *existence* of some 
item (which also implies that item is a pointer), not as a test against 
item's integer value. In such contexts I use NULL.

As you see, this subject has many faces.
I invite you to comp.lang.c++.moderated to discuss them in more depth.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: private types

[Robert A Duff]

Maciej Sobczak <no.spam@no.spam.com> writes:

> but still, (void*)0 == NULL will always evaluate to true, even if the
> internal representation of the null pointer is not zero.

Are you sure?  Are you talking about C or C++ or both?

Does (void*)x always return NULL if x is an appropriate-sized integer
whose value is zero?  That would require run-time overhead if
NULL is not represented as all-zero-bits.

On the other hand, it's pretty confusing if casting zero to (void*)
is sometimes guaranteed to return NULL, and sometimes not, depending
on whether the zero value is known at compile time.

- Bob

Re: private types

[James Dennett]

Robert A Duff wrote:
> Maciej Sobczak <no.spam@no.spam.com> writes:
> 
>> but still, (void*)0 == NULL will always evaluate to true, even if the
>> internal representation of the null pointer is not zero.
> 
> Are you sure?  Are you talking about C or C++ or both?

It's true for both, given the right interpretation of
(void*)0.

> Does (void*)x always return NULL if x is an appropriate-sized integer
> whose value is zero? 

Not necessarily.  But if x is a null pointer constant,
which to C++ means an integral constant expression with
value zero, then it will.  (C also allows an ICE of zero
cast to void*, so you have a NPC already.)

> That would require run-time overhead if
> NULL is not represented as all-zero-bits.

Yes, but that's not required.  You can get different
behaviour from

int i(0);
void *p((void*)i);

than from

int const i(0);
void *p((void*)i);

because for C++ the latter i is a valid integral constant
expression, while the former is not.

> On the other hand, it's pretty confusing if casting zero to (void*)
> is sometimes guaranteed to return NULL, and sometimes not, depending
> on whether the zero value is known at compile time.

Afraid so; generally C++ is arranged so that removing const,
where legal, should not change the meaning of code -- but
this is an exception, in theory at least.

-- James

Re: private types

[Martin Krischik]

Maciej Sobczak wrote:

> Where did you read this?
> NULL is not depreciated. It's defined in the <cstddef> header to be a
> null-pointer constant, which is any integral const expression that
> evaluates to 0. Possible definition is:

But that is only a C compatibility header, only there to provide
compatibility C and one should avoid using them in pure C++?

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: private types

[Maciej Sobczak]

Martin Krischik wrote:

>>NULL is not depreciated. It's defined in the <cstddef> header to be a
>>null-pointer constant, which is any integral const expression that
>>evaluates to 0. Possible definition is:
> 
> But that is only a C compatibility header

No, there is nothing like this in C++. The C library is part of C++ by 
explicit inclusion, not by compatibility.
Consider, for example, general purpose functions, like rand() (this one 
declared in <cstdlib>). It does not make any sense to say that such 
functions are C-compatibility stuff only, because that would imply that 
it's not possible to do even such basic things in "pure" C++.

C++ *contains* the C library. It uses different header names (for 
example, cstdlib instead of stdlib.h) and namespace std (so that you 
have std::rand, std::printf, etc.), but everything is there and 
everything is part of C++. Including NULL.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: private types

[Martin Krischik]

Maciej Sobczak wrote:

> The interesting question is why it might make any difference to you?
> The only thing that really matters is that the null pointer is distinct
> from any other valid pointer, in which case it's equivalent to Ada's
> null.

For C++ I can - barely - see that but C is supposed to system programming
language suitable for kernel and/or embedded progamming. Taking that into
account: How actually are the languages implementers to implement 
"distinct from any other valid pointer". If you are implementing a Ring 0
device driver on x86 all pointers are valid and on PC architecture there is
memory at (void*0) which one might want to access.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: private types

[Maciej Sobczak]

Martin Krischik wrote:

>>The interesting question is why it might make any difference to you?
>>The only thing that really matters is that the null pointer is distinct
>>from any other valid pointer, in which case it's equivalent to Ada's
>>null.
> 
> For C++ I can - barely - see that but C is supposed to system programming
> language suitable for kernel and/or embedded progamming. Taking that into
> account: How actually are the languages implementers to implement 
> "distinct from any other valid pointer".

Any way they want.

> If you are implementing a Ring 0
> device driver on x86 all pointers are valid and on PC architecture there is
> memory at (void*0) which one might want to access.

The point is that if you are writing software for some specific piece of 
hardware, then handling of NULL is the least of your problems. You need 
extensive knowledge and guarantees, considering, among others, stuff 
like word sizes, alignment, byte ordering, representation and existence 
of trap values, etc. In other words, you don't just pick any compiler at 
random, but rather you use the one which gives you the set of required 
guarantees. And among those guarantees there will be something about the 
NULL pointer.
Most likely you will just know that the NULL pointer has representation 
of all bits zero.

Note also that in so called reality compilers that do not implement NULL 
as zero just do not sell very well. This is because many C programmers 
are used to do this:

struct S
{
     int x;
     char *p;
     /* ... */
};

struct S s;
memset(&s, 0, sizeof(S));  /* <- here */

and later expect that s.p == NULL;

The "idiom" of memsetting structures is so deeply rooted in the C 
community that you can find it in almost every C program and most C 
books. It's clear that the "idiom" bypasses the typesafety of fields by 
just plowing over their underlying representation, and this can work 
only with those compilers that do not exercise the full freedom that the 
standard gives them.

So - no worry. It just works. :)


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: private types

[Simon Wright]

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

> Before I learned C++ in deeps I thought the same. But then I read
> that the use of #define NULL is depreciated C++ and that one should
> use a simple 0 instead.

deprecated (depreciation is what happens to a currency during inflation)

Re: private types

[Larry Kilgallen]

In article <1172812.9zPbPKbdVq@linux1.krischik.com>, Martin Krischik <krischik@users.sourceforge.net> writes:

> Modern OS don't map the first memory page to the process so access will
> result in an error. But they only do that to ease up C/C++ development.
> There is no other reason.

Some operating systems map the first memory page to the process to aid
LISP development.  Pity the person whose program uses both languages.

Re: private types

[Peter C. Chapin]

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

Bj�rn Persson <spam-away@nowhere.nil> wrote in
news:SteTf.48935$d5.205176@newsb.telia.net: 

> Well, does the standard require that (void*)0 == NULL? What if I
> wanted a pointer to address zero on this hypothetical OS? How would I
> get that if (void*)0 gets transformed to a non-zero NULL?

I'd have to review the precise definition of the null pointer constant. 
Anything other than that is treated in the "usual" way. So for example, 
this might work

const int p = 0;

...  (void*)p ...

Or maybe you need to take the 'const' off the declaration of p.

Peter

Re: private types

[Robert A Duff]

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

> Justin Gombos wrote:
> 
> > Zero has a
> > universal meaning with access types, but it could be in range or out
> > of range for any other type. ï¿œThe ARM selects access types
> > specifically to get a default initialization of zero for this reason.
> 
> Who says that Null := 16#0#? I could image a Hardware/CPU/OS where it would
> be better to define Null := 16#FFFF_FFFF_FFFF_FFFF#.

The convention on TOPS-20 for null (in all the various languages that
have it) is to use some address other than zero.  I don't remember
which address.  The OS protects that page so it traps
(just as most modern operating systems do for page zero).

There was even an Ada compiler for TOPS-20, and of course it obeyed that
convention.

Using all-zero-bits for null has some minor efficiency advantages.

> For example an OS who's Virtual Memory Management System assign address
> 16#0# to be a valid address and to hold some important process data to
> which the process needs access.
> 
> Of course programming C or C++ on such an OS could be quite challenging
> (Write to (void*)0 and you mess up your Proccess Information Descriptor).

I believe the C++ rule is that 0 (written in your program) is the same
thing as NULL -- but it need not be represented internally by
all-zero-bits.  Casting the integer zero to a pointer, however,
does not necessarily result in NULL.  That's sort of confusing,
but if you understand the rules, the "quite challenging" comment
above does not hold.

- Bob

Re: private types

[Martin Krischik]

Robert A Duff wrote:

> I believe the C++ rule is that 0 (written in your program) is the same
> thing as NULL -- but it need not be represented internally by
> all-zero-bits. ï¿œCasting the integer zero to a pointer, however, 
> does not necessarily result in NULL. ï¿œThat's sort of confusing,
> but if you understand the rules, the "quite challenging" comment
> above does not hold.

Super! And how many (in %) of C++ programmer actually know that. By guess is
0.1%. And indeed I is the main problem: Only a very few C/C++ programmers
actually master the language. 

Martin 
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: private types

[Dr. Adrian Wrigley]

On Sun, 19 Mar 2006 20:20:52 +0100, Martin Krischik wrote:

> Robert A Duff wrote:
> 
>> I believe the C++ rule is that 0 (written in your program) is the same
>> thing as NULL -- but it need not be represented internally by
>> all-zero-bits. �Casting the integer zero to a pointer, however, 
>> does not necessarily result in NULL. �That's sort of confusing,
>> but if you understand the rules, the "quite challenging" comment
>> above does not hold.
> 
> Super! And how many (in %) of C++ programmer actually know that. By guess is
> 0.1%. And indeed I is the main problem: Only a very few C/C++ programmers
> actually master the language. 

It is (or was) quite a common interview question, to see if
C (and C++) programmers know their subject properly.  As you
say, Robert, most don't.

A related topic is the issue of pointer representation, which
(IIRC) says that pointers to char (any kind) and void have to be
the same.  Pointers to functions have to be the same.  But all
other pointers can have their own representation.  All pointers
can be converted to and from pointers to void, without loss.  And
pointers can have different sizes and different patterns for the
null pointer.  I suspect a lot of code would fail if compilers
wanted to exercise their full freedoms!
--
Adrian

Re: private types

[Robert A Duff]

"Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> writes:

> On Sun, 19 Mar 2006 20:20:52 +0100, Martin Krischik wrote:
> 
> > Robert A Duff wrote:
> > 
> >> I believe the C++ rule is that 0 (written in your program) is the same
> >> thing as NULL -- but it need not be represented internally by
> >> all-zero-bits. �Casting the integer zero to a pointer, however, 
> >> does not necessarily result in NULL. �That's sort of confusing,
> >> but if you understand the rules, the "quite challenging" comment
> >> above does not hold.
> > 
> > Super! And how many (in %) of C++ programmer actually know that. By guess is
> > 0.1%. And indeed I is the main problem: Only a very few C/C++ programmers
> > actually master the language. 
> 
> It is (or was) quite a common interview question, to see if
> C (and C++) programmers know their subject properly.  As you
> say, Robert, most don't.

Martin said that.  I have no idea how close his .1% estimate is
to the truth.  It's certainly true that many programmers learn
their programming languages by experiment -- what works is
all-too-often assumed to be what the language is.

- Bob

Re: private types

[Dave Thompson]

--
On Sun, 19 Mar 2006 20:43:42 GMT, "Dr. Adrian Wrigley"
<amtw@linuxchip.demon.co.uk.uk.uk> wrote:

> On Sun, 19 Mar 2006 20:20:52 +0100, Martin Krischik wrote:
(C++ null pointers not all-bits-zero, also true of C)
> > Super! And how many (in %) of C++ programmer actually know that. By guess is
> > 0.1%. And indeed I is the main problem: Only a very few C/C++ programmers
> > actually master the language. 
> 
Languages, or either language. C++ is not C much as Ada is not Pascal.

> It is (or was) quite a common interview question, to see if
> C (and C++) programmers know their subject properly.  As you
> say, Robert, most don't.
> 
I don't know how common it is on interviews, having neither attended
nor given any for quite some time. It is several FAQs on comp.lang.c.

> A related topic is the issue of pointer representation, which
> (IIRC) says that pointers to char (any kind) and void have to be
> the same.  Pointers to functions have to be the same.  But all

Pointers to char and void the same, yes. Separately pointers to all
structs, and to all unions; this allows using them for 'incomplete'
types, almost (not fully) like Ada private.

Pointers to functions, not completely. Pointers to differently
prototyped functions are different types, and calling a function
through a wrong-type pointer is Undefined Behavior (= erroneous = not
required to be caught/diagnosed or to do anything even remotely
reasonable). However, any function that is or could have been defined
in nonprototype aka K&R1 aka oldstyle form must be callable using a
(K&R1-style) 'pointer to function of unspecified arguments'. In
practice this means that most systems use a compatible calling
sequence for at least all nonvarargs functions, so pointers to any of
them actually work interchangeably. I have seen platforms, but only a
handful, where varargs are different, and mixing pointers to them (or
misdeclaring) does cause (serious) problems.

> other pointers can have their own representation.  All pointers
> can be converted to and from pointers to void, without loss.  And

All _data_ pointers can be converted to and from void* without loss.
All function pointers can  be converted to other function pointers
without loss; at least formally you must convert back before using.

> pointers can have different sizes and different patterns for the
> null pointer.  I suspect a lot of code would fail if compilers
> wanted to exercise their full freedoms!

Agree with both of those.

- David.Thompson1 at worldnet.att.net

Re: private types

[Maciej Sobczak]

Martin Krischik wrote:

> Only a very few C/C++ programmers
> actually master the language. 

As is true for any language that is at least moderately useful.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: private types

[Robert A Duff]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Martin Krischik wrote:
> 
> > Only a very few C/C++ programmers
> > actually master the language.
> 
> As is true for any language that is at least moderately useful.

True.  Language designers ought to take that into account -- whenever
possible, try to design features subtle misunderstandings are unlikely
to cause bugs.

Suppose an Ada programmer and a C++ programmer both think that null/NULL
must be represented as all-zero-bits.  Both programmers are confused.
But which programmer is more likely to write code that won't work
on a machine where the assumption turns out to be false?

- Bob

Re: private types

[Maciej Sobczak]

Robert A Duff wrote:

>>>Only a very few C/C++ programmers
>>>actually master the language.
>>
>>As is true for any language that is at least moderately useful.
> 
> True.  Language designers ought to take that into account -- whenever
> possible, try to design features subtle misunderstandings are unlikely
> to cause bugs.

True, I don't have any doubts about it.

> Suppose an Ada programmer and a C++ programmer both think that null/NULL
> must be represented as all-zero-bits.  Both programmers are confused.

Both programmers take assumptions which are equally wrong.

> But which programmer is more likely to write code that won't work
> on a machine where the assumption turns out to be false?

Naither of those programmer should have any problems with their 
programs, because pointers are, well, pointers, not integers. Neither of 
them should have any temptation to interpret pointers as numbers, so 
that the actual "value" of the pointer never really matters. Even the 
question "is the NULL pointer zero?" makes no sense in this light, 
unless you target specific piece of silicon (see my replies to Martin 
Krischik).

In practice, in the world of pointers it's not the NULL pointer 
representation which is causing problems, but rather unconstrained 
pointer arithmetics.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: private types

[Robert A Duff]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Robert A Duff wrote:
> 
> >>>Only a very few C/C++ programmers
> >>>actually master the language.
> >>
> >>As is true for any language that is at least moderately useful.
> > True.  Language designers ought to take that into account -- whenever
> > possible, try to design features subtle misunderstandings are unlikely
> > to cause bugs.
> 
> True, I don't have any doubts about it.
> 
> > Suppose an Ada programmer and a C++ programmer both think that null/NULL
> > must be represented as all-zero-bits.  Both programmers are confused.
> 
> Both programmers take assumptions which are equally wrong.

Right.

> > But which programmer is more likely to write code that won't work
> > on a machine where the assumption turns out to be false?
> 
> Naither of those programmer should have any problems with their
> programs, because pointers are, well, pointers, not integers. Neither of
> them should have any temptation to interpret pointers as numbers, so
> that the actual "value" of the pointer never really matters.

You say "should".  But we're talking about confused/wrong programmers.

But the C++ programmer has been taught to use "0" as a value of type
char* (which pointer value, of course, is not necessarily represented as
all-zero-bits).  See other posts in this thread, which recommend that
style.  It's not far from there, to (wrongly) believing that casting an
integer zero to pointer will result in null.

>... Even the
> question "is the NULL pointer zero?" makes no sense in this light,
> unless you target specific piece of silicon (see my replies to Martin
> Krischik).

I agree that the question "is the NULL pointer zero?" makes no sense,
but the question "is the NULL pointer represented as zero (in some or
all implementations of a certain language)?" makes sense.

It's not usually a hardware ("silicon") issue, though.
Ada compilers choose to represent null as zero because compilers
for other languages do that, and because operating systems arrange
for page zero to trap.  Also, I think there are some minor efficiency
advantages.

> In practice, in the world of pointers it's not the NULL pointer
> representation which is causing problems, but rather unconstrained
> pointer arithmetics.

Certainly pointer arithmetic adds extra trouble.  But even without that,
dereferencing of null pointers is a plentiful source of bugs.

- Bob

Re: private types

[Jeffrey R. Carter]

Martin Krischik wrote:
> 
> Of course programming C or C++ on such an OS could be quite challenging
> (Write to (void*)0 and you mess up your Proccess Information Descriptor).

Programming C/++ on all OSes is quite challenging, by definition.

-- 
Jeff Carter
"What I wouldn't give for a large sock with horse manure in it."
Annie Hall
42

Re: private types

[Robert A Duff]

Justin Gombos <rpbkbq.xax.gld@uluv.kbq> writes:

> On 2006-03-18, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
> >
> > In Ada, if an object of an access type has no explicit initial
> > value, you can't easily tell whether that means "null is a
> > meaningful value for this variable, and that's the default I want"
> > versus "this variable will be initialized to a meaningful (non-null)
> > value later".
> 
> If you want to distinguish between the two possiblities, you could
> explicitly initialize your pointers to null in the first case, and not
> in the second.

Yes, that's a reasonable style, and I use it myself.
But there's no compiler support for that style.
As far as the language and compiler are concerned,
"X: T" and "X: T := null" mean EXACTLY the same thing.
It's hard to tell whether the programmer means the same thing
in these cases.

>...  I rarely use access types,

So you rarely create trees, linked list, etc?

>... and I probably wouldn't do
> that myself simply because I find the distinction unimportant for
> access types.  Regardless, I'm not going to give up the benefit of
> having this distinction on non-access scalars simply because my access
> type declarations don't have it.
> 
> > This is exactly analogous to the case with integers -- if they were
> > default-initialized to zero, you can't easily tell whether zero is
> > intended as a meaningful initial value, versus later initialization
> > to a meaningful value.
> 
> Integers, and other non-access scalars are different in this case
> because you cannot expect zero to have the same meaning.  Zero has a
> universal meaning with access types,

No, zero has no meaning with access types!

>... but it could be in range or out
> of range for any other type.  The ARM selects access types
> specifically to get a default initialization of zero for this reason.

There is no "default initialization of zero".  There is a default-init
to null, which has nothing to do with zero (according to the Ada
standard).

- Bob

Re: private types

[Justin Gombos]

On 2006-03-25, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
> Justin Gombos <rpbkbq.xax.gld@uluv.kbq> writes:
>
> So you rarely create trees, linked list, etc?

That's right.  In fact, a few months ago was the first time I
implemented a dynamic container in Ada since I studied it in school.
I haven't had a need for them in any of the avionics systems that I've
worked.

>> Integers, and other non-access scalars are different in this case
>> because you cannot expect zero to have the same meaning.  Zero has
>> a universal meaning with access types,
>
> No, zero has no meaning with access types!
>
>>... but it could be in range or out of range for any other type.
>>The ARM selects access types specifically to get a default
>>initialization of zero for this reason.
>
> There is no "default initialization of zero".  There is a
> default-init to null, which has nothing to do with zero (according
> to the Ada standard).

You're forgetting why we got side tracked on this discussion.  Your
comment was:

  I'm not sure what the right answer is, but surely all the arguments
  for and against dummy values apply equally to access types.

Access types are special, and get different treatment than other
scalars because they include in their set a representation for a null
value.  Integers do not; so the same arguements for implicit
initialization of access values do not necessarily apply.  

Whether null values are actually represented as zeros is irrelevant to
this matter.  Even if null values are nonzero, integers still do not
have a null object.

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: private types

[Robert A Duff]

Justin Gombos <rpbkbq.xax.gld@uluv.kbq> writes:

> On 2006-03-25, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
> > Justin Gombos <rpbkbq.xax.gld@uluv.kbq> writes:
> >
> > So you rarely create trees, linked list, etc?
> 
> That's right.  In fact, a few months ago was the first time I
> implemented a dynamic container in Ada since I studied it in school.
> I haven't had a need for them in any of the avionics systems that I've
> worked.

OK.  I'm a compiler writer, so I use pointers (access types or whatever)
quite a lot.

> >> Integers, and other non-access scalars are different in this case
> >> because you cannot expect zero to have the same meaning.  Zero has
> >> a universal meaning with access types,
> >
> > No, zero has no meaning with access types!
> >
> >>... but it could be in range or out of range for any other type.
> >>The ARM selects access types specifically to get a default
> >>initialization of zero for this reason.
> >
> > There is no "default initialization of zero".  There is a
> > default-init to null, which has nothing to do with zero (according
> > to the Ada standard).
> 
> You're forgetting why we got side tracked on this discussion.

Sorry.  These discussions tend to ramble a bit.  ;-)

>...Your
> comment was:
> 
>   I'm not sure what the right answer is, but surely all the arguments
>   for and against dummy values apply equally to access types.

And I stand by that comment.

> Access types are special, and get different treatment than other
> scalars because they include in their set a representation for a null
> value.

Yes, access types in Ada are special, because they have a special null
value.  C and Pascal and so forth are similar.  But it doesn't HAVE to
be that way.  Some languages (SML comes to mind) do not have a special
null value provided for free -- if you want one, you declare one.
(Or, if you want two, you declare two!)

>...Integers do not; so the same arguements for implicit
> initialization of access values do not necessarily apply.

Again, it doesn't have to be that way.  The language designer could
provide a special value for integers, too.

Most of the time, I do not want a special null value (neither for access
types nor for integers).  I would prefer a language that did not give me
special null values for free -- they're just a tripping hazard, except
when I want them.

The Ada 2005 "not null" thing is somewhat helpful, in this regard.

> Whether null values are actually represented as zeros is irrelevant to
> this matter.

Quite true.  Sorry -- I was confused by your referring to zero as a null
access value.

- Bob

Re: private types

[Jeffrey R. Carter]

Robert A Duff wrote:
> Justin Gombos <rpbkbq.xax.gld@uluv.kbq> writes:
>> Access types are special, and get different treatment than other
>> scalars because they include in their set a representation for a null
>> value.
> 
> Yes, access types in Ada are special, because they have a special null
> value.  C and Pascal and so forth are similar.  But it doesn't HAVE to
> be that way.  Some languages (SML comes to mind) do not have a special
> null value provided for free -- if you want one, you declare one.
> (Or, if you want two, you declare two!)

I think we're missing the point. Access types are NOT scalar types in Ada. C 
pointers may be, since you can treat them pretty much like integers. The ARM TOC has

3.5 Scalar Types
3.5.1 Enumeration Types
3.5.2 Character Types
3.5.3 Boolean Types
3.5.4 Integer Types
3.5.5 Operations of Discrete Types
3.5.6 Real Types
3.5.7 Floating Point Types
3.5.8 Operations of Floating Point Types
3.5.9 Fixed Point Types
3.5.10 Operations of Fixed Point Types

and

3.10 Access Types
3.10.1 Incomplete Type Declarations
3.10.2 Operations of Access Types

Access types are NOT in the section for scalar types (3.5); they are in their 
own, separate section (3.10). Once you accept that access types are not scalar 
types, arguing about the meaning of null changes. Access types are an 
abstraction, and the concept of null is part of that abstraction. In the 
abstraction, an access value either designates an object or it doesn't; = null 
means the former and /= null, the latter. How that is represented is an 
implementation detail hidden from the user. You could have something sort of 
equivalent to

    type Access_Type is private;

    null : constant Access_Type;
private
    type Access_Type (Designates_Something : Boolean := False) is record
       case Designates_Something is
       when False =>
          null;
       when True =>
          Data : System.Address;
          -- other fields as needed
       end case;
    end record;

    null : constant Access_Value := (Designates_Something => False);

(though I doubt any compiler actually does). Access types aren't special 
compared to scalar types because they're not scalar types; they're not even 
conceptually similar.

-- 
Jeff Carter
"I spun around, and there I was, face to face with a
six-year-old kid. Well, I just threw my guns down and
walked away. Little bastard shot me in the ass."
Blazing Saddles
40

Re: private types

[Justin Gombos]

On 2006-03-26, Jeffrey R. Carter <spam.not.jrcarter@acm.not.spam.org> wrote:
>
> I think we're missing the point. Access types are NOT scalar types
> in Ada. C pointers may be, since you can treat them pretty much like
> integers. 

I believe you're right.  I had the idea that access types are scalars
from page 18 of Michael Feldman's book "Software Construction and Data
Structures with Ada 95," but apparently he's wrong about that.

> Access types aren't special compared to scalar types because they're
> not scalar types; they're not even conceptually similar.

Exactly, so it's reasonable to treat access types differently when it
comes to default initialization, despite Robert Duffs comment that the
arguments for/against apply to both kinds of types.  After reading
Duff's last post, I can see that he was talking outside of the
language, so that's where the misunderstanding was.  My position had a
premise that we're dealing with Ada integers as they are (that is,
non-abstract, and without a null value).

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: private types

[Robert A Duff]

Justin Gombos <rpbkbq.xax.gld@uluv.kbq> writes:

>...After reading
> Duff's last post, I can see that he was talking outside of the
> language, ...

Yes, of course!  We were talking about how Ada _ought_ to deal with
uninitialized variables.  Therefore, we must be talking about
hypothetical languages that are different from Ada.

>...so that's where the misunderstanding was.  My position had a
> premise that we're dealing with Ada integers as they are (that is,
> non-abstract, and without a null value).

Yes, access types have null, and integers do not (in Ada).
But that's not a good argument that access types _should_
have null, or that integers should _not_ have null.
"It's best if Ada does X, because Ada does X" -- that's
circular reasoning.  ;-)

- Bob

Re: private types

[Robert A Duff]

"Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> writes:

> Access types are NOT in the section for scalar types (3.5); they are in
> their own, separate section (3.10). Once you accept that access types
> are not scalar types,...

Sorry, but I don't "get" this argument.

I accept that access types are not scalar types.  Both are "elementary"
types, however.  I don't see any fundamental difference between access
and scalar that would imply that uninit vars should be treated
differently for the two.

Of course, there are many fundamental differences, which imply a
different set of operations (can't do arithmetic on access values,
can't do 'Access and get an integer, etc).  But there are also
many things in commmon between scalar and access: both can be passed
as parameters, both can be stored as record components, both are by-copy
types.

An uninit var should be considered a bug, whether it's access or
integer.  I see no fundamental difference, here.  Defaulting to null
hides this bug.

>... arguing about the meaning of null changes. Access
> types are an abstraction, and the concept of null is part of that
> abstraction. In the abstraction, an access value either designates an
> object or it doesn't; = null means the former and /= null, the
> latter.

Yes, but my claim is that that's a poorly designed abstraction.
In most cases, null is just a tripping hazard.
The programmer should have the choice -- access type without
any special value, access type with a special value that doesn't
designate anything, access type with _two_ special values, ...

Ada 2005 comes closer, by having "not null" -- but the default is
backwards (for obvious compatibility reasons).

Note that when I declare a private type, I choose whether it should have
"special" values, and what they mean.  And I choose whether a special
value is used as a default.  I can choose to raise an exception if
clients look at an uninit var.  I can choose to prevent uninit
vars statically, using (<>) discriminants.

- Bob

Re: private types

[Jeffrey R. Carter]

Robert A Duff wrote:
> 
> An uninit var should be considered a bug, whether it's access or
> integer.  I see no fundamental difference, here.  Defaulting to null
> hides this bug.

This only holds true for types that don't have meaningful default initial 
values. I've written lots of types for which an uninitialized variable of the 
type is perfectly reasonable, and even the expected behavior. Usually they're 
defined as "[limited] private". I don't expect users of a data structure to have 
to make a special initialization call to be able to use the structure.

Whether the default initial value for access types is a good choice is not 
something I'm debating. I'm simply saying that default initial values are not a 
bad thing for ADTs, an access type is closer to an ADT than to a scalar type, 
and using the same criteria for both doesn't compute.

> Yes, but my claim is that that's a poorly designed abstraction.
> In most cases, null is just a tripping hazard.
> The programmer should have the choice -- access type without
> any special value, access type with a special value that doesn't
> designate anything, access type with _two_ special values, ...

That may be, but because it's an abstraction, it's not similar to scalar types, 
and so arguments that apply to scalar types don't necessarily apply.

> Note that when I declare a private type, I choose whether it should have
> "special" values, and what they mean.  And I choose whether a special
> value is used as a default.  I can choose to raise an exception if
> clients look at an uninit var.  I can choose to prevent uninit
> vars statically, using (<>) discriminants.

Access types are like a private type. The only difference is that access types 
are part of the core language, and don't carry all the extra syntax that 
defining them as an explicit private type would add. Ichbiah and company chose 
that the abstraction called access types should have a "special" value, and what 
it means. They chose that a special value is used as a default. They chose to 
raise an exception if clients apply certain operations to an uninitialized 
variable. They may not be the choices you would make for this abstraction, but 
your choices may not be what others would choose, also.

-- 
Jeff Carter
"My name is Jim, but most people call me ... Jim."
Blazing Saddles
39

Re: private types

[Frank J. Lhota]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccr74q19up.fsf@shell01.TheWorld.com...
>>...  I rarely use access types,
>
> So you rarely create trees, linked list, etc?

Not necessarily; One could create these entities using a container library 
such as the Booch components or the 2005 Ada Containers. Of course, such 
libraries will use acess types in their implementation, but the end user 
does not have to handle access values directly.

-- 
"All things extant in this world,
Gods of Heaven, gods of Earth,
Let everything be as it should be;
Thus shall it be!"
- Magical chant from "Magical Shopping Arcade Abenobashi"

"Drizzle, Drazzle, Drozzle, Drome,
Time for this one to come home!"
- Mr. Lizard from "Tooter Turtle"

Re: private types

[Robert A Duff]

"Frank J. Lhota" <NOSPAM.FrankLho@rcn.com> writes:

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
> news:wccr74q19up.fsf@shell01.TheWorld.com...
> >>...  I rarely use access types,
> >
> > So you rarely create trees, linked list, etc?
> 
> Not necessarily; One could create these entities using a container library 
> such as the Booch components or the 2005 Ada Containers. Of course, such 
> libraries will use acess types in their implementation, but the end user 
> does not have to handle access values directly.

Good point.  At least for the "linked lists, etc" part.

But for trees and symbol tables and the like, as in a compiler,
those container libraries are no help.

- Bob

Re: private types

[Jeffrey R. Carter]

Robert A Duff wrote:
> 
> But for trees and symbol tables and the like, as in a compiler,
> those container libraries are no help.

I would think by now you would have created domain-specific packages to 
encapsulate these concepts for your language-processing tool development work, 
and still not have to deal directly with the access types.

-- 
Jeff Carter
"My name is Jim, but most people call me ... Jim."
Blazing Saddles
39

Re: private types

[Simon Wright]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> But for trees and symbol tables and the like, as in a compiler,
> those container libraries are no help.

What is so special about trees and symbol tables? (I can see that
application-specific optimisation might be a problem).