In <4ov281$482@engnews1.Eng.Sun.COM> clamage@Eng.sun.com (Steve
Clamage) writes:
>
>In article av6@fohnix.metronet.com, 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.
>
..
>
>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.

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

(This is from comp.std.c++)

Jack Carden <jcarden@texas.bt.com> wrote:
>
> Our group has undergone a significant development effort and recently
> paused to examine lessons learned.  One of the points that came up regarding
> C++ was a group of bugs we identified relating to forward declarations and
> delete.
>
> 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.  See, for example, the
> following fragment:
>
> class X;
> void foo(X *x) { delete x; }
>
> Similar code to this compiles and links and executes without noticeable
> side effects in our system using both the Sun Solaris and Dec Alpha C++
> systems.
>
> It seems inconsistent to me that one could have defined a delete method
> and/or a destructor for class X which have now been totally bypassed.
>
> Is there some inherent reason why this choice is correct?  Is this area
> considered in the C++ standard?  We notice that new() is not supported for
> classes with a forward declaration.  We use forward declarations in order
> to simplify include file nesting.

This has been noted before, and has been discussed in committee.

The best explanation I have seen for keeping this behavior was that
it makes it easier for people to change all their calls to malloc and
free to new and delete expression when converting C code.  The claim
is that good compilers will issue a warning if you delete an incomplete
type. (Evidently your group did not use such a compiler.)

In my view, that's pretty thin reasoning -- not least because it encourages
people to say "delete p" when they really need to check whether "delete[] p"
is required, and a compiler can't detect that to warn about it.  I hope to
see this revisited at the next meeting.

To delete, deliberately, an object *p of incomplete type, I would expect to
be obliged to replace "free(p)" with "delete reinterpret_cast<void*>(p)",
which makes visible that something unsavory is going on.  Then "delete p"
could be diagnosed as the error it quite likely is.

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
]

Our group has undergone a significant development effort and recently
paused to examine lessons learned.  One of the points that came up regarding
C++ was a group of bugs we identified relating to forward declarations and
delete.

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.  See, for example, the
following fragment:

class X;

void foo(X *x)
{
 delete x;
}

Similar code to this compiles and links and executes without noticeable
side effects in our system using both the Sun Solaris and Dec Alpha C++
systems.

It seems inconsistent to me that one could have defined a delete method
and/or a destructor for class X which have now been totally bypassed.

Is there some inherent reason why this choice is correct?  Is this area
considered in the C++ standard?  We notice that new() is not supported for
classes with a forward declaration.  We use forward declarations in order
to simplify include file nesting.

TIA. Please send me an email copy of any follow-ups, if possible.

An outsider,

Jack Carden
BT North America
Richardson, Texas
email: jcarden@texas.bt.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                             ]

In article av6@fohnix.metronet.com, 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.

That issue is addressed in the draft standard in the section on "delete"
expressions. It says:

"If the object being deleted has incomplete class type at the point of
deletion and the class has a non   trivial destructor or an allocation
function or a deallocation function, the behavior is undefined."

New and delete in C++ are potentially dangerous, since all tradeoffs were
made in the direction of allowing efficient implementations. (But new and
delete are still less dangerous than malloc and free.)

On the plus side, many errors in memory management can be caught by the
compiler or runtime system. Since the behavior in the presence of errors
is formally undefined, it means that implementations are free to provide
all the checking that you might want. Indeed many implementations and
third-party tools provide extensive checking of memory management, trading
time and space for safety.

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.

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