[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c++

STL vector resize on MSVC broken?

Drawknob

12/15/2008 8:07:00 PM

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?
7 Answers

Victor Bazarov

12/15/2008 9:19:00 PM

0

Drawknob wrote:
> 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?

You post more of your code, that what. How do you really expect us to
give you any recommendation if we can't see any declarations/definitions
of your objects, nor what's coming before them, or after them... It
sounds like memory corruption, but there is no way to tell for sure.
It's very likely the problem is not due to a "broken vector resize" in
MSVC (after all the library has been around for more than a decade now
and from the millions of programmers using it every day somebody would
have stumbled upon this already), but due to some bad memory management
on your part. Try narrowing your problem down by removing (one by one)
parts that you don't think related to your problem. Perhaps during that
removal you will find which part, when removed, makes the error go away.
Then examine that part closely.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Daniel T.

12/16/2008 1:12:00 AM

0

Drawknob <Drawknob@gmail.com> wrote:

> 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?

Quit blaming the library and start looking at your code. Somewhere you
have an un-initialized value (probably a pointer,) or you are writing
outside the bounds of an array or vector, or you have improperly written
a copy constructor or assignment operator. Note: these are not exclusive
ors, you might have done several of them.

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, and check
every class that has a destructor and make sure the copy c_tor and op=
are defined properly. In doing all that, you will likely find your
problem.

James Kanze

12/16/2008 11:18:00 AM

0

On Dec 16, 2:11 am, "Daniel T." <danie...@earthlink.net> wrote:
> Drawknob <Drawk...@gmail.com> wrote:
> > 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.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Daniel T.

12/16/2008 11:45:00 AM

0

James Kanze <james.kanze@gmail.com> wrote:
> On Dec 16, 2:11 am, "Daniel T." <danie...@earthlink.net> wrote:
> > Drawknob <Drawk...@gmail.com> wrote:

> > > 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.)

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

Rolf Magnus

12/16/2008 12:46:00 PM

0

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

12/17/2008 4:03:00 AM

0

James Kanze wrote:
> On Dec 16, 2:11 am, "Daniel T." <danie...@earthlink.net> wrote:
>> Drawknob <Drawk...@gmail.com> wrote:
>>> 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

12/17/2008 9:03:00 AM

0

On Dec 17, 5:03 am, red floyd <no.spam.h...@example.com> wrote:
> James Kanze wrote:
> > On Dec 16, 2:11 am, "Daniel T." <danie...@earthlink.net> wrote:
> >> Drawknob <Drawk...@gmail.com> wrote:
> >>> 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).

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34