Re: delete

From: Jerry Coffin (jcoffin_at_taeus.us)
Date: 06/02/04


Date: Tue, 1 Jun 2004 20:18:52 -0600

In article <49bpb017ab7tqer3461r0je2a4sr5inp7f@4ax.com>, dsh@mvps.org
says...

[ ... ]

> Even VC6 (circa 1998) rejects that approach. In addition, you clipped the
> part where I went on to explain that even if you used an old compiler that
> allowed the overloading of operator delete on void*&, you'd still run into
> ambiguities when you tried to use it:

That's because it's irrelevant -- do you honestly think that a
compiler so defective as to allow it in the first place is likely to
enforce the other rules perfectly?

[ ... ]
 
> So there are multiple reasons why it doesn't work, and even if it did work
> under some ancient compiler, imagine the effects of moving to a newer one.
> Not only is your code immediately broken, you labored all that time with the
> wrong understanding of the delete operator, or at best, you came to rely on
> a crutch, which in the world of VC++, hasn't had a leg to stand on in at
> least six years. Earlier, you did characterize it as a "poor idea", and I
> elaborated on why it's an exceedingly poor idea, but in your reply, you seem
> to have backed away from that.

Please be so kind as to point out where I've said anything to the
effect that this is a good idea, or anything like it.

The fact is, I haven't backed away from anything! I said it was a
bad idea, and I've said _nothing_ to contradict that at all. I don't
see any particular requirement to re-state what I thought I'd already
made obvious, but apparently your memory is as bad as your logic, so
I'll reiterate.

The standard doesn't allow this. Chances are that your compiler
won't allow it either. If your compiler is so defective that it does
allow it, you should definitely get a better compiler immediately.
If you do insist on continuing to use such a piece of garbage, making
use of this particular defect is a bad idea anyway.

If you think that's too weakly stated, tough.

-- 
    Later,
    Jerry.
The universe is a figment of its own imagination.


Relevant Pages

  • Re: delete
    ... >compiler so defective as to allow it in the first place is likely to ... that would enable your admitted "poor idea". ... You know, some things are better left unsaid, such as this idea to overload ... >use of this particular defect is a bad idea anyway. ...
    (microsoft.public.vc.language)
  • Re: Does This Leak Memory?
    ... > I call the routine like so: ... > He claims that the two temporaries in the first case may leak memory. ... That would depend on the compiler. ... other C++ compilers with such a defect. ...
    (microsoft.public.vc.atl)
  • Re: Does This Leak Memory?
    ... > I call the routine like so: ... > He claims that the two temporaries in the first case may leak memory. ... That would depend on the compiler. ... other C++ compilers with such a defect. ...
    (microsoft.public.vc.language)
  • Re: mutually referential (Pg 140 K&R2)
    ... >>I ran the following test program through my C compiler to see if it ... >>struct t ... If we add #include the code is perfectly valid. ... defect in the area under discussion. ...
    (comp.lang.c)
  • Re: Strange behaviour of printf. See the code below and please tell why it behaves in this way.
    ... >>> A question was asked on an observed behaviour, ... > the argument passing is not even left up the compiler: ... Imagine tracking down the ... bug, ...
    (comp.lang.c)