"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ae9l0o$2lur$1@digitaldaemon.com...
>
> I'd want the compiler to do data flow analysis and
> explicitly clean up objects it can prove are no longer referenced when a
> block exits.  Those kinds of objects can be allocated on the stack too to
> avoid malloc overhead.

This is actually quite a good idea. The trouble with it is it will depend on the quality of the data flow analysis, which is implementation dependent. For example, the normal thing to do with an object is call a method on it - the 'this' pointer may get copied and squirreled away somewhere by the method.

"Walter" <walter@digitalmars.com> wrote in message news:aedvpb$120n$1@digitaldaemon.com...
>
> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ae9l0o$2lur$1@digitaldaemon.com...
> >
> > I'd want the compiler to do data flow analysis
>
> This is actually quite a good idea. The trouble with it is it will depend
on
> the quality of the data flow analysis, which is implementation dependent. For example, the normal thing to do with an object is call a method on
it -
> the 'this' pointer may get copied and squirreled away somewhere by the method.

   The obvious solution might be adding semantic markers to the language,
not unlike "const" and "volatile" in C++.

   For example, markers for pure functions (in the pure functional sense)
and for unaliased parameters could help the compiler do the right thing
better.

   Note that those markers would have to become part of the interface of the
method. Like "const" and "volatile", and unlike function exception
specifications in C++ or contracts in D. This would increase the burden on
the programmer that uses them, and in the compiler, but it would increase
the ability for the programmer to express known intent.

Salutaciones,
                         JCAB

"Pavel Minayev" <evilone@omen.ru> wrote in message news:ae8far$1bj9$1@digitaldaemon.com...
> "Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:ae7i8l$8cd$1@digitaldaemon.com...
>
> > Please, please no Undefined Behaviour in language specs.
> > If you delete an object all references to it should magically became
null.
> > Or invalid. Or get a GPF, or ... format the hard disk in a documented manner.
>
> Now, how would it be implemented in a more or less effective way (other than holding a list of pointers for each object)?
>
Well, you only use explicit delete in special cases. IMHO, it doesn't need
to be fast.
It could traverse the reference tree in much the same way as GC do, and
check for references.
Then it could find all other references, and do something EXPLICITELY
SPECIFIED with them.
At least in the debug build.

Sandor