TITLE: deleting and casting of an incomplete type

(Newsgroups: comp.std.c++)

CARDEN: jcarden@metronet.com (Jack Carden)

It seems if one provides a forward declaration for a class, one can then
invoke the delete operator on a pointer to an instance of that class
without regard to the definition of the class.

CLAMAGE: clamage@Eng.sun.com (Steve Clamage)

In particular, it would be reasonable for a compiler to warn about
deleting an object whose definition was not visible. Why isn't it always
an error? The point was discussed, and sentiment was on the side of
allowing the code because sometimes it is safe. If you took C code and
replaced malloc/free with new/delete, you would then not also have to
include struct definitions where they were not present before.

KARAS: Walter William Karas

This seems like a very slippery slope.  This decision seems to be
saying "since there is a good chance that the destructor is the
default destructor, assume it is".  This seems similar to the
pre-ANSI-C idea that "since there is a good chance that an undeclared
function is later declared with the formal parameter types the same as
the actual parameter types, assume that it is".  I'll never understand
why the C++ standard chose to break the trend in ANSI-C of tightening
the restrictions on use before declaration.  This seems to lead
inevitable to portability issues that are difficult to manage.


MYERS: Nathan Myers <ncm@cantrip.org>, 10 Jun 96

Karas is exactly right.  The reasoning (recounted accurately by Steve)
is obviously faulty.  But the ARM permitted such constructions, so
the question is whether we should reject old code containing them and 
say such code was broken; or "grandfather" it in, and then hope 
every compiler will issue warnings about it, and that users will heed
the warnings.

There's a similar problem with casts.  If you have an incomplete
pointer type, and you cast it to void*, then the offset (which would
have been subtracted if the definition were known) is not subtracted,
and your void* value is garbage.  This is necessary for C compatibility,
though it didn't have to be carried forward to static_cast<>.  Yet it 
was.  A good compiler will warn about static_cast applied to incomplete
pointer types, which is another good reason to use static_cast instead 
of the old-style syntax.