Booch: iterator invalidation

Booch: iterator invalidation

[Victor Porton]

What are conditions when Booch iterators are invalidated?
It is missing in the documentation.

It also would be great to have the debug version of Booch, checking
validity of iterators and raising an exception. With GNAT it can be
done as in C by #ifdef/#endif preprocessor directives (assigning a
long (may be 64, 128, or 256 bytes) counter incrementing on each
invalidation to each container and analogous counters to iterators
and comparing these counters).

Re: Booch: iterator invalidation

[Jeffrey Creem]

"Victor Porton" <porton@ex-code.com> wrote in message
news:3dcbb4e4$0$299$bed64819@news.gradwell.net...
> What are conditions when Booch iterators are invalidated?
> It is missing in the documentation.
>
> It also would be great to have the debug version of Booch, checking
> validity of iterators and raising an exception. With GNAT it can be
> done as in C by #ifdef/#endif preprocessor directives (assigning a

Usually no need to resort to #ifdef preprocessor stuff.. Just make a generic
formal
that says error checking enabled. Generic actual parameter is a
constant/static then any decent compiler will optimize out any of the actual
checks in the object code and you get the same effect as the #ifdefs without
the lack of portability.

Re: Booch: iterator invalidation

[Randy Brukardt]

Jeffrey Creem wrote in message ...
>Usually no need to resort to #ifdef preprocessor stuff.. Just make a
generic formal
>that says error checking enabled. Generic actual parameter is a
>constant/static then any decent compiler will optimize out any of the
actual
>checks in the object code and you get the same effect as the #ifdefs
without
>the lack of portability.


That won't work for a compiler which does generic sharing of
implementations. In that case, the code would remain all of the time.
(This is true of Janus/Ada and the ICC compiler.)

But why make it a parameter? Just make in a constant in the body of the
source code, and change it as needed.

              Randy.

Re: Booch: iterator invalidation

[Victor Porton]

In article <iYOy9.16284$Dc4.56479@rwcrnsc51.ops.asp.att.net>,
	"Jeffrey Creem" <jeff@thecreems.com> writes:
> "Victor Porton" <porton@ex-code.com> wrote in message
> news:3dcbb4e4$0$299$bed64819@news.gradwell.net...
>> What are conditions when Booch iterators are invalidated?
>> It is missing in the documentation.
>>
> Usually no need to resort to #ifdef preprocessor stuff.. Just make a generic
> formal
> that says error checking enabled. Generic actual parameter is a
> constant/static then any decent compiler will optimize out any of the actual
> checks in the object code and you get the same effect as the #ifdefs without
> the lack of portability.

I suggested #ifdef because as I remeber I've readied somewhere that
modern Ada compilers use code sharing for generics, not repeated
compilation like C++.

What about GNAT in particular?

Re: Booch: iterator invalidation

[Simon Wright]

porton@ex-code.com (Victor Porton) writes:

> What are conditions when Booch iterators are invalidated?
> It is missing in the documentation.

Point taken.

> It also would be great to have the debug version of Booch, checking
> validity of iterators and raising an exception. With GNAT it can be
> done as in C by #ifdef/#endif preprocessor directives (assigning a
> long (may be 64, 128, or 256 bytes) counter incrementing on each
> invalidation to each container and analogous counters to iterators
> and comparing these counters).

I am not going to include GNAT-specific stuff in the BCs if I can help
it (and if there are any such I will do my best to remove them, just
let me know!).

Re: Booch: iterator invalidation

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

> > It also would be great to have the debug version of Booch, checking
> > validity of iterators and raising an exception. With GNAT it can be
> > done as in C by #ifdef/#endif preprocessor directives (assigning a
> > long (may be 64, 128, or 256 bytes) counter incrementing on each
> > invalidation to each container and analogous counters to iterators
> > and comparing these counters).
> 
> I am not going to include GNAT-specific stuff in the BCs if I can help
> it (and if there are any such I will do my best to remove them, just
> let me know!).

I believe "pragma Assert" is supported by all major Ada compilers at
this time; that could be used to give a good "debug version".

-- 
-- Stephe

Re: Booch: iterator invalidation

[Robert A Duff]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:

> I believe "pragma Assert" is supported by all major Ada compilers at
> this time; that could be used to give a good "debug version".

There is also an AI on this, not yet approved, I think.
AI-286.

- Bob

Re: Booch: iterator invalidation

[Simon Wright]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:

> I believe "pragma Assert" is supported by all major Ada compilers at
> this time; that could be used to give a good "debug version".

At one time the BCs did use the pragma, but it wasn't available on all
compilers (and one had an incompatible form, so you couldn't compile
if you'd used the GNAT form).

Re: Booch: iterator invalidation

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

> Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:
> 
> > I believe "pragma Assert" is supported by all major Ada compilers at
> > this time; that could be used to give a good "debug version".
> 
> At one time the BCs did use the pragma, but it wasn't available on all
> compilers (and one had an incompatible form, so you couldn't compile
> if you'd used the GNAT form).

Bummer. Let's hope that makes it into the language soon.

-- 
-- Stephe

Re: Booch: iterator invalidation

[Victor Porton]

In article <u65v268c4.fsf@gsfc.nasa.gov>,
	Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:
> Simon Wright <simon@pushface.org> writes:
> 
>> > It also would be great to have the debug version of Booch, checking
>> > validity of iterators and raising an exception. With GNAT it can be
>> > done as in C by #ifdef/#endif preprocessor directives (assigning a
>> > long (may be 64, 128, or 256 bytes) counter incrementing on each
>> > invalidation to each container and analogous counters to iterators
>> > and comparing these counters).
>> 
> I believe "pragma Assert" is supported by all major Ada compilers at
> this time; that could be used to give a good "debug version".

I'm not about asserting but about records which have or don't have
a component dependingly on whether it is the debuging version. Can
variant records be used for this without lost of space efficiency?

type T_Internal(Debug: Boolean) is
  record
    -- ...
    case Debug is
      when True =>
        -- ... additional debugging stuff
      when others =>
        null;
    end case;
  end record;

type T is T_Internal(Use_Debug); -- Use_Debug is a Boolean _constant_

Will this not bring "additional debugging stuff" in the release
version (when Use_Debug=False)?

Re: Booch: iterator invalidation

[Stephen Leake]

porton@ex-code.com (Victor Porton) writes:

> I'm not about asserting but about records which have or don't have
> a component dependingly on whether it is the debuging version. 

Hmm. I've never done that for testing. Can you give a real example?
What sort of "additional information" would you add?

I've used "debug storage pools" that report statistics on
allocations/deallocations. I guess that is a form of what you are
talking about here.

Part of the point of "debug stuff" is that it ideally should have
_zero_ impact on the "real code". "pragma Assert" comes very close to
that; the optimizer may do things differently when it is turned on,
but nothing else changes.

> Can variant records be used for this without lost of space
> efficiency?
>
> type T_Internal(Debug: Boolean) is
>   record
>     -- ...
>     case Debug is
>       when True =>
>         -- ... additional debugging stuff
>       when others =>
>         null;
>     end case;
>   end record;
> 
> type T is T_Internal(Use_Debug); -- Use_Debug is a Boolean _constant_
> 
> Will this not bring "additional debugging stuff" in the release
> version (when Use_Debug=False)?

Now everything that uses T_Internal has to specify a Debug
discriminant. To intrusive for my taste.

-- 
-- Stephe

Re: Booch: iterator invalidation

[Victor Porton]

In article <uptta4kgc.fsf@gsfc.nasa.gov>,
	Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:
> porton@ex-code.com (Victor Porton) writes:
> 
>> I'm not about asserting but about records which have or don't have
>> a component dependingly on whether it is the debuging version. 
> 
> Hmm. I've never done that for testing. Can you give a real example?
> What sort of "additional information" would you add?
> 
> I've used "debug storage pools" that report statistics on
> allocations/deallocations. I guess that is a form of what you are
> talking about here.

Yes, it is of such kind. Also it may be e.g. back references from
a container to iterators for checking validity etc.

>> Can variant records be used for this without lost of space
>> efficiency?
>>
>> type T_Internal(Debug: Boolean) is
>>   record
>>     -- ...
>>     case Debug is
>>       when True =>
>>         -- ... additional debugging stuff
>>       when others =>
>>         null;
>>     end case;
>>   end record;
>> 
>> type T is T_Internal(Use_Debug); -- Use_Debug is a Boolean _constant_
>> 
>> Will this not bring "additional debugging stuff" in the release
>> version (when Use_Debug=False)?
> 
> Now everything that uses T_Internal has to specify a Debug
> discriminant. To intrusive for my taste.

It is meant for user code to use _only_ T, not T_Internal.
(In OO style T_Internal should be in private section.)

All compiler implementors should consider this to ensure that
they have zero space-efficiency.

Re: Booch: iterator invalidation

[Stephen Leake]

porton@ex-code.com (Victor Porton) writes:

> In article <uptta4kgc.fsf@gsfc.nasa.gov>,
> 	Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:
> > I've used "debug storage pools" that report statistics on
> > allocations/deallocations. I guess that is a form of what you are
> > talking about here.
> 
> Yes, it is of such kind. 

Ok. In that particular case, the "real code" was not affected. Well, I
had to add a generic parameter for the storage pool, but I convinced
myself that was a "good thing" anyway :).

> Also it may be e.g. back references from a container to iterators
> for checking validity etc.

Ah. That makes sense. I wonder if you can do that via a storage pool?
I guess there would have to be one pool per container, rather than per
container type.

> >> type T is T_Internal(Use_Debug); -- Use_Debug is a Boolean _constant_
> >> 
> >> Will this not bring "additional debugging stuff" in the release
> >> version (when Use_Debug=False)?
> > 
> > Now everything that uses T_Internal has to specify a Debug
> > discriminant. To intrusive for my taste.
> 
> It is meant for user code to use _only_ T, not T_Internal.
> (In OO style T_Internal should be in private section.)

Ok, that makes it better. But you'll need a wrapper around T_Internal
to enforce that. I would still try to use gnatprep or some similar
tool, so the "real code" does not have this "debug only" overhead.
 
> All compiler implementors should consider this to ensure that
> they have zero space-efficiency.

I'm not clear what you mean here. I suppose if the compiler could
prove that _every_ instance of T_Internal had the same value for
Use_Debug, it could optimize stuff. But that seems like a lot of work.
Any time T_Internal is passed as a subprogram parameter, you'd either
have to inline the subprogram or do full data-flow analysis.

-- 
-- Stephe

Re: Booch: iterator invalidation

[Victor Porton]

In article <uel9p8qms.fsf@gsfc.nasa.gov>,
	Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:
> porton@ex-code.com (Victor Porton) writes:
> 
>> >> type T is T_Internal(Use_Debug); -- Use_Debug is a Boolean _constant_
>> >> 
>> >> Will this not bring "additional debugging stuff" in the release
>> >> version (when Use_Debug=False)?
>> > 
>> > Now everything that uses T_Internal has to specify a Debug
>> > discriminant. To intrusive for my taste.
>> 
>> It is meant for user code to use _only_ T, not T_Internal.
>> (In OO style T_Internal should be in private section.)
> 
>> All compiler implementors should consider this to ensure that
>> they have zero space-efficiency.
> 
> I'm not clear what you mean here. I suppose if the compiler could
> prove that _every_ instance of T_Internal had the same value for
> Use_Debug, it could optimize stuff. But that seems like a lot of work.
> Any time T_Internal is passed as a subprogram parameter, you'd either
> have to inline the subprogram or do full data-flow analysis.

I meant the case when _all_ except of debug (like Dump, Check, 
Throw_If_Invalid) rountines use only T, not T_Internal.