Re: Booch: iterator invalidation

[Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>]

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