🚀 go-pugleaf

In article 6FA@netcom.com, sjc@netcom.com (Steven Correll) writes:

>What must a conforming compiler do when confronted with this?
> 
>        struct x;
>        struct y;
> 
>        void
>        p(x *arg0, y *arg1)
>          {
>          delete [] arg0;
>          delete arg1;
>          }

>Section 5.3.5 of my 5/95 copy of the draft standard says "If the object
>being deleted has incomplete class type at the point of deletion and the
>class has a non-trivial destructor...the behavior is undefined." Is this
>still true?

Yes.

>I don't see how a compiler could avoid noticing that it hasn't a clue what
>destructor to invoke at compilation time. Is there a reason (aside from
>encouraging people to migrate to Java) not to require the compiler to
>diagnose this as an error, instead of allowing it to fault at execution
>time?

If x and y have trivial destructors, the code is well-formed. It would
be possible to make the code unconditionally ill-formed, meaning that
you could not delete an object unless its type is complete. I don't have
a good answer for why this is not the case. (I only see two feasible
definitions: status quo, or the code is always ill-formed.)

I would expect a compiler to warn about deleting incomplete types.
The current Sun C++ does, for example.

I don't understand the reference to Java. In Java, all objects of class
type are on the heap and are garbage-collected. This has the obvious
advantage of eliminating memory-management errors. On the other hand,
you cannot predict when (or whether, under current Java versions) an
object will ever be destroyed, so doing anything important in a
"destructor" (finalize) seems ill-advised. In effect, it seems to me
that "destructors" in Java should always be trivial, and if cleanup
actions are needed, they should usually be put in a method you call
explicitly at the appropriate time.  Hmmm -- seems isomorphic to the
C++ memory-management problem, except for having somewhat limited bad
consequences. 

(OK, the comparison might not be completely fair. Typically, a C++
destructor is needed to free allocated memory, and Java never needs a
destructor for that purpose. But if the destructor is needed to free
some other resource -- close a file, release a lock -- you are back
to the "when does it happen" problem. Future versions of Java are
supposed to guarantee that the "finalize" method of every object is
eventually run, but you cannot predict or control the order in which
they are run.)

---
Steve Clamage, stephen.clamage@eng.sun.com




[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]