jcarden@metronet.com (Jack Carden) writes:
> >>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@Eng.sun.com (Steve Clamage) writes:
> >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.

Walter William Karas wrote:
> 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.

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.

Nathan Myers
ncm@cantrip.org
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

> jcarden@metronet.com (Jack Carden) writes:
> > >>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@Eng.sun.com (Steve Clamage) writes:
> > >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.
>
> Walter William Karas wrote:
> > 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.
>
> Nathan Myers wrote:
> 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.

Forgive me if this has been covered, as I have just discovered this group
(and this thread), but doesn't deleting an object whose declaration is
incomplete allow for the possibility of protection violations? In other
words, if the declaration of the class makes operator delete or the
destructor private/protected, then the delete would have been allowed for
an object that should not be deleted.

Bob

Bob Hablutzel
Hablutzel Consulting
EMail: bobh@hablutzel.com
Phone: 603 431-5074
Fax:   603 431-0466
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]