bus error, resize vector

[imutate]

I get a bus (or is it buss) error when I resize a vector

typedef std::vector<dou bledblvec;
n = 127;
dblvec rv;
rv.resize(n); // error happens here

Any clues ? I can post more info if required ?

[Daniel T.]

im*****@hotmail .co.uk wrote:

Daniel T. wrote:

>In the line before that, put:

assert( i < myVec.size() );

Do that everywhere you are using "at()".

When the code breaks, it will tell you what file and line number in
that file the problem is located at.

That won't do it, I already output at every place I write to these
vectors and there is no indication that I am assigning
3276..whatever (actually 2^31 - 1 or such like). Something else is
corrupting this vector.

The only way the vector can be corrupted is if you are dereferencing an
invalid pointer somewhere, or if you are going outside the bounds of
some other vector or array. The problem probably has nothing to do with
that particular vector at all. The problem is most assuredly not in the
vector code itself.

--
There are two things that simply cannot be doubted, logic and perception.
Doubt those, and you no longer*have anyone to discuss your doubts with,
nor any ability to discuss them.

[imutate]

The only way the vector can be corrupted is if you are dereferencing an

invalid pointer somewhere, or if you are going outside the bounds of
some other vector or array. The problem probably has nothing to do with
that particular vector at all. The problem is most assuredly not in the
vector code itself.

I ran on a different machine and I get a different number assigned, it
looks more like a long int than the 32767 number I got in Linux. I
asserted the range and there is no problem until the error. I've only
got no other arrays (or vectors) and one pointer and it is a function
pointer, can I assert (or templatise) this too ?

It is along the lines of
typedef double fn(const double &x);
typedef fn *fnptr;

[Daniel T.]

im*****@hotmail .co.uk wrote:

>The only way the vector can be corrupted is if you are
dereferencin g an invalid pointer somewhere, or if you are going
outside the bounds of some other vector or array. The problem
probably has nothing to do with that particular vector at all. The
problem is most assuredly not in the vector code itself.

I ran on a different machine and I get a different number assigned,
it looks more like a long int than the 32767 number I got in Linux.
I asserted the range and there is no problem until the error.

Then you are somehow putting that value into the vector, probably by
pushing an uninitialized variable into the vector.

I've only got no other arrays (or vectors) and one pointer and it is
a function pointer, can I assert (or templatise) this too ?

It is along the lines of
typedef double fn(const double &x);
typedef fn *fnptr;

Sure. Assign it the value "0" when you create the function pointer, then
assert( myFnptr != 0 ) before you use it.

--
There are two things that simply cannot be doubted, logic and perception.
Doubt those, and you no longer*have anyone to discuss your doubts with,
nor any ability to discuss them.

[Greg]

Daniel T. wrote:

im*****@hotmail .co.uk wrote:

The only way the vector can be corrupted is if you are
dereferencing an invalid pointer somewhere, or if you are going
outside the bounds of some other vector or array. The problem
probably has nothing to do with that particular vector at all. The
problem is most assuredly not in the vector code itself.

I ran on a different machine and I get a different number assigned,
it looks more like a long int than the 32767 number I got in Linux.
I asserted the range and there is no problem until the error.

Then you are somehow putting that value into the vector, probably by
pushing an uninitialized variable into the vector.

I've only got no other arrays (or vectors) and one pointer and it is
a function pointer, can I assert (or templatise) this too ?

It is along the lines of
typedef double fn(const double &x);
typedef fn *fnptr;

Sure. Assign it the value "0" when you create the function pointer, then
assert( myFnptr != 0 ) before you use it.

--
There are two things that simply cannot be doubted, logic and perception.
Doubt those, and you no longer have anyone to discuss your doubts with,
nor any ability to discuss them.

I found my mistake, it was a vector index problem, yes, indexing past
the end. I made a change and did not reflect the change across my app.
Better object design next time.

[Greg]

The STL vector does not throw any error if you index past the end, at
least not if you have reserved the space.

x.reserve(10);
x.push_back(wha tever);
...x[0] // OK
...x[1] // Also "OK", no error.

[red floyd]

Greg wrote:

The STL vector does not throw any error if you index past the end, at
least not if you have reserved the space.

x.reserve(10);
x.push_back(wha tever);
..x[0] // OK
..x[1] // Also "OK", no error.

True, but x[1] is UB. x.at(1) will throw.