STL vector resize on MSVC broken?

[Drawknob]

Changing the ordering of the resizes below gives me different results--
if it's this way it works, if I swap some lines, it results in
corrupted data.

All arrays start off at size 0 except tuftGuides, which has some data
and I expand it here. I read on the Web that resize() to larger size
adds elements while keeping the existing ones--but this is not
happening depending on how I order the below

The vectors hold either floats or structs of several floats, where the
structs have default and copy constructors and assignment operators
defined and working fine.

There's no issue in Debug build. I'm using Visual Studio 2008.
There's no exception thrown. A few of the vectors are class members,
and the other few are local to the function.

try
{
tuftGuides.resize(numTufts * LAYERS);
invTuftSz.resize(numTufts);
sineFactors.resize(numTufts);
hairSecs.resize(numHairs * LAYERS);
hairDia.resize(numHairs * LAYERS);
hairOffsets.resize(numHairs * LAYERS);
nears.resize(numHairs);
}
catch (...)
......

What do I do?

 

[James Kanze]

[...]

I suggest the first thing you do is make sure *every* variable
is initialized properly, replace every C array with a vector
and use the 'at()' member function instead of the op[]
member-function,

I agree with using vector, but why at()? In this case, the
immediate core dump you get with op[] would seem preferable. (I
know, the standard says it's undefined behavior, but any decent
implementation of std::vector will give you a core dump---the
ones with VC++ and g++ do, at any rate.)

 

[Rolf Magnus]

Daniel T. wrote:

I agree with using vector, but why at()? In this case, the
immediate core dump you get with op[] would seem preferable. (I
know, the standard says it's undefined behavior, but any decent
implementation of std::vector will give you a core dump---the
ones with VC++ and g++ do, at any rate.)

I didn't assume that the OP was working with a "decent implementation"
of the language, only a standard one.

No need to assume. The OP actually mentioned which one he was using.

 

[red floyd]

Changing the ordering of the resizes below gives me
different results-- if it's this way it works, if I swap
some lines, it results in corrupted data.

[...]
I suggest the first thing you do is make sure *every* variable
is initialized properly, replace every C array with a vector
and use the 'at()' member function instead of the op[]
member-function,

I agree with using vector, but why at()? In this case, the
immediate core dump you get with op[] would seem preferable. (I
know, the standard says it's undefined behavior, but any decent
implementation of std::vector will give you a core dump---the
ones with VC++ and g++ do, at any rate.)

You won't necessarily get an immediate core dump if the capacity is
larger than the size.

 

[James Kanze]

Changing the ordering of the resizes below gives me
different results-- if it's this way it works, if I swap
some lines, it results in corrupted data.

[...]

I suggest the first thing you do is make sure *every*
variable is initialized properly, replace every C array
with a vector and use the 'at()' member function instead of
the op[] member-function,

I agree with using vector, but why at()? In this case, the
immediate core dump you get with op[] would seem preferable.
(I know, the standard says it's undefined behavior, but any
decent implementation of std::vector will give you a core
dump---the ones with VC++ and g++ do, at any rate.)

You won't necessarily get an immediate core dump if the
capacity is larger than the size.

It's not guaranteed by the standard, ever. (It's undefined
behavior.) But you'll get the core dump immediately will with
any good implementation. You definitely do with g++ and VC++
(at least when you compile with the usual options---you can turn
it off with both).