Qnx632 and the std::vector, any problems?

I’m using QNX632 and have used std::vectors, only I’m getting runtime problems with my main app but not with my test aps, it’s weird and I’m not sure why.

e.g. pseudo-code…

std::vector<double> vec; vec.resize(4); vec.size() <- works ok, returns 4 vec.at(0) <- I get a sig 11? /(sigsegv/seg fault)

I’ve tried it by .resize…ing the vector and by push_back…ing to it, but the .at and [] both seg fault. When I switch to a static array it appears to be ok?
so… Qnx632 and the std::vector, any problems I don’t know about? could I have gotten some build option different for my main app which is set correctly in my test app? am I hearing hooves and thinking zebras here?

anytips for gdb’ing vectors?

cheers

Works fine for me.

Compiler is gcc 3.3.1.

My actual compile line was:

QCC -Wall -g -O -o test test.cpp -lm

The -lm wasn’t actually necessary, but I do it out of habit now because I’ve been burned so many times by forgetting it. The -O is optimize, although considering the bewildering number of options gcc has for optimizing it’s hard to know what that does. It worked without it as well, and without the -g for debug. -Wall is just about warnings, so really, the compile line only had to be:

QCC test.cpp

and then run a.out.

Let me stress that you absolutely MUST use QCC for this. (Well, you can pass something to qcc to make it do C++, but I never remember what it is so I just use the all caps version.) Trying to use gcc / g++ directly will NOT work.

You mentioned that this was working in test code but not in production code. Perhaps there is something in between your resize() (or push_back()) and your at() that is the problem? Another possibility is that somehow you’re calling your at() before the resize().

Good luck.

-James Ingraham
Sage Automation, Inc.

thanks for the reply… I’d placed my vector in shared memory and was accessing it from a different process, which apparently won’t work.
It looks like the size function returns a ‘wrong’ value without throwing anything but you can’t actually access whatever’s in there. The size being correct whilst debugging looks like a fluke as when I tried it again it was way off.

Most of the time the problem is always in what people forget to mention.

When you put something in a vector, the memory use to hold that data is put in the process memory ( a new() is performed) and not in sharedmemory. Hence when another process try to access the element in the vector, the pointers are invalid.

indeed, and when you find something it’s always in the last place you look ;)