🚀 go-pugleaf

Steven Correll (sjc@netcom.com) wrote:
> 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?
>  
> 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

I think you have in fact answered your own question, nearly:

> time? (Given that x and y might be PODS, I doubt that it's possible to
> defer the solution to execution time, but if it is, then why not define
> the behavior and mandate that it be correct?)

I believe it is in fact that the objects might be PODS that makes this 
the only reasonable rule.  For a PODS, one assumes that there is no 
destructor, which is surely trivial, yes?  The problem whcih you go on to 
describe is simply what happens in the general case when a user-defined 
type is deleted without destruction: the destructor function isn't 
invoked, and so side effects don't happen as expected.

So why not make this sort of thing ill-formed?  Probably so that PODS can
continue to be used, as in legacy code that has been only partially ported
to C++.  (I'm thinking here of code that's been cleaned up to compile as
C++, and use some of the features such as new/delete, but that hasn't been
redesigned as OO.  Been there, done that, and it was quite worthwhile as
an intermediate step without which the code probaly would have had to
remain in Plain C until it was abandoned.) This accomodates the common C
use of an opaque data structure, which one might reasonably expect to find
used in the very C code that would be a leading candidate for such a move
to C++.  Or so it seems to me.  :-)

Now that you've pointed this out, I should have to agree that it would be 
very nice to see compilers diagnose this, but I wouldn't want them to 
reject such a program as ill-formed for reasons that must be obvious.  
Therefore it has to be a "quality of implementation" issue, or perhaps 
even a job for a lint++ tool, since in general one might have to examine 
files that are not normally, nor are intended to be, compiled together.



[ 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                             ]