Re: Array new followed by non-array delete - request for experience
On Oct 2, 2:54 pm, int...@gmail.com wrote:
I would like to ask everyone who had previously had issues with non-
array operator delete used to delete the result of array new, i.e.:
char* p = new char[100];
...
delete p;
or
std::auto_ptr<char> p(new char[100]);
I know that it is undefined behavior according to the Standard. What I
would like to know, however, is how strict is this rule in practice.
Several widely used C++ implementations, in particular, do not seem to
have any troubles with the code above if the pointer is to a POD type
(in general, whenever destructors do not have to be called). However,
it seems likely that there do exist implementations where even for POD
types this will not work correctl. Therefore, I ask you to share your
experience on this subject: what code failed to work (if it is
sufficiently different from the pattern described above), whether the
type in question was a POD type or not, and what compiler and library
version were you using?
Instead of relying on implementation details of particular compilers,
it is easy to rewrite the statement so that the intent is unambiguous,
e.g.
typedef char T;
const std::size_t aligned_size(sizeof(T[100])/100);
std::auto_ptr<void> p(::operator new(100*aligned_size));//*
or
T* p=reinterpret_cast<T*>(::operator new(100*aligned_size));
::operator delete(p);
Now one can ask: for what kinds of T will this work for in my
application? For a POD, it works fine. So you could say that if
union {T x} _dummy;
compiles, the the above code has no worries.
Of course the syntax is a little more verbose, but you get much
clearer code, at least in intent. And you are not relying on
implementation defined behavior.
I cant recall any horror stories regaring asymmetric new[]/delete,
because the vast majority of people
1) use std::vector.
std::vector<T> p(100); //almost identical to new T[100]
(where the "almost" part refers to the extra size member inside
vector.)
2) wrap the C-style array in a struct
struct Twrap{
T buf[100];
T&operator[](unsigned idx){return buf[idx];}
operator T*(){return &buf[0];}
};
std::auto_ptr<Twrap> p(new Twrap); //does the right thing
3) use tr1::array
std::auto_ptr<tr1::array<T,100> > p(new tr1::array<T,100> );
//like std::vector without the extra size member
4) use use one of the boost "array deleters"
5) make their own "auto_array_ptr"
Who knows how all the different compilers (and options) react to
asymmetrical new[]/delete? As you can see, there are many ways to get
rid of the "undefined" and "implementation specific" behavior
cluttering your code.
Lance
*I got this to compile using gcc, but MSVC didnt like it
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]