Re: memory management in Ada: tedious without GC?

[Brian Drummond <brian_drummond@btconnect.com>]

On Sun, 18 May 2008 09:06:55 +0100, Simon Wright
<simon.j.wright@mac.com> wrote:

>Brian Drummond <brian_drummond@btconnect.com> writes:
>
>> Which explained to me how changing from ptr to auto_ptr (presumably
>> to make code safer!) can introduce a spectacularly silly bug,
>> completely statically determinable, but which the compiler allows
>> just fine and lets the code die with a segfault.
>
>Is auto_ptr the one where assignment moves the content? "b = a;" means
>that a is now null and b references the previous content of a?
>
>If so, it seems to me that it's the concept that's spectacularly
>silly! (I considered introducing an auto pointer into the Booch
>Components, but then thought about using it .. I can see that there
>might be a use within a very narrow scope, but a standard ref-counted
>smart pointer works just as well. No doubt there is an appropriate
>usage idiom?)

That's the one. It's maybe not spectacularly silly; I can see how it
would help in other circumstances, but not here. 

Maciek is probably right that one or more of scoped_ptr, unique_ptr or
shared_ptr would be a better choice, but that is where I want to part
company with C++[+STL] - that looks like four new mechanisms to increase
complexity, without eliminating the basic problems of ptr.

I would prefer to catch problems at (or even before) the compiler,
rather than as here, let them manifest at runtime. So, having assigned
b=a, at the very least, any further references to 'a' in the same block
ought to be grounds for compilation failure. But apparently not, at
least in this compiler (gcc).

- Brian