Boost logo

Boost :

From: Ed Brey (brey_at_[hidden])
Date: 2001-03-02 17:22:10


From: "Trevor Perrin" <tperrin_at_[hidden]>
> A couple questions about the workaround:
>
> - what does "deletion with std::nothrow" mean?

A case like "new (std::nothrow) int", where the expression evaluates to 0
instead of throwing if there is an error allocating the memory.

> - also, if I add only the non-array delete:
>
> inline void operator delete(const void* p) throw() {operator
> delete(const_cast<void*>(p));}
>
> but then do:
>
> const int* y = new int[10];
> delete[] y;
>
> the non-array version above still gets called (if I add the array
version
> as well then it gets called appropriately); I believe it's okay to delete
> arrays with the non-array version in VC (so the above I think works), but
it
> still seems incorrect function resolution.

I've verified by stepping through the code that the array and non-array
versions of operator delete end up calling the same code, so it happens to
work. Relying on this fact isn't a problem, since the buggy compiler puts
you into compiler-specific hack-land in the first place. Compiler
work-arounds are allowed to take advantage of non-portable implementation
details (of course, avoiding them if fine too, if possible). As I recall,
there is't a non-const operator delete[] to call, so when I implemented the
workaround for myself I had to rely on the detail that VC6 happens to
implement scalar and array delete the same.

> Anyways, if there's a procedure for submitting bugs/workarounds please
> point me at it (you mentioned a VC Known Bug page, which I'd be very
> interested in seeing!); thanks.

http://www.boost.org/more/microsoft_vcpp.html

Note that at this time, this page doesn't cover the problems and workarounds
regarding new and delete expressions/operators. (Also note that there are a
couple other new/delete expression related VC6 bugs that I skipped
mentioning, since they are more obscure and tend not to be triggered in
conjunction with boost libraries.)


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk