Thread: bad_alloc

Thanks laserlight,


My question is answered.

Originally Posted by laserlight

Yes, that's the one, thus it was caught in the catch (int) exception handler.

regards,
George

Originally Posted by CornedBee

Zero is a valid input to the allocator function.

are you sure? I know in C that malloc(0) is implementation defined. Compilers are allowed to return NULL or a value not equalling NULL that can not be dereferenced.

Is this different with C++'s new?

Originally Posted by George2

Hi cpjust,

Is nothrow new supported in Visual Studio 2008?

I haven't tried 2008, I'm still using 2005, but it's been in the C++ standard for a long time.

yes, it could already be used in MSVC6, although new would always return NULL in that version. They do it correct nowadays including nothrow

Just to avoid starting a new thread on a related subject, I was wondering whether

Code:

std::vector<T> v;
T *p = &v[0];

triggers undefined behavior even if p is not dereferenced. I'm guessing that the allocation of the underlying array is done in a similar manner to new[] and that the answer is no, but want to be sure. (This isn't exactly what my code does, but it may use the expression &v[0] even when v has size 0, though it never dereferences anything it's not supposed to.)

Originally Posted by robatino

Just to avoid starting a new thread on a related subject, I was wondering whether

Code:

std::vector<T> v;
T *p = &v[0];

triggers undefined behavior even if p is not dereferenced.

That's undefined behavior even in straight C. Highly unlikely to cause a crash but still undefined.

Originally Posted by brewbuck

That's undefined behavior even in straight C. Highly unlikely to cause a crash but still undefined.

If v was a dynamic array (in C or C++), I would have just used "v" instead of "&v[0]" to sidestep the problem. I wanted to avoid dynamic arrays, but my program needs a huge number of small arrays, all of the same length (length 1 would be common), and the container overhead of a vector for each one is unnecessary, so I allocate a single huge vector and pass out pieces of the underlying array instead. So memory management can still be done vector-style but the container overhead amortizes to almost zero.

Hi robatino,


What do you mean "container overhead amortizes" and why it is zero?

Originally Posted by robatino

If v was a dynamic array (in C or C++), I would have just used "v" instead of "&v[0]" to sidestep the problem. I wanted to avoid dynamic arrays, but my program needs a huge number of small arrays, all of the same length (length 1 would be common), and the container overhead of a vector for each one is unnecessary, so I allocate a single huge vector and pass out pieces of the underlying array instead. So memory management can still be done vector-style but the container overhead amortizes to almost zero.

regards,
George

Hi robatino,


I still do not know why "triggers undefined behavior even if p is not dereferenced" after reading the discussion from you guys. Why it is undefined? Could you help to provide more description please?

Originally Posted by robatino

Oops, I should have realized that. Thanks.

Edit: I've seen other code that does this:

Code:

T *p = v.empty()? 0 : &v[0];

Now I know why.

regards,
George

Thank you. I should also have mentioned that even if I allocated lots of little dynamic arrays, instead of vectors, there would still be per-object overhead, not to mention possible memory fragmentation. So it makes sense to allocate a single large container either way - and since the extra overhead of a huge vector vs. a huge dynamic array is negligible, it may as well be a vector.