We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi,
I'm writing a C++ program that will run on an STM3210E-EVAL board and I'm having some problems using STL vectors. I'm wondering what I'm doing wrong. (Or if STL vectors are even supported.)
Here's a snippet:
#include <vector> . . . void func() { std::vector<int> temp; temp.push_back(5); }
When I try to run the debugger on my target, I end up somewhere in assembly land and never reach the beginning of my main() function. (I am not familiar with assembly so, I'm not quite sure where I am or how I got there.)
When I run in simulator mode, everything works fine. (I end up at the beginning of my main() function like I expect.)
It appears that whenever I make any command that increases the size of my vector, I get the same result. If I never insert into my vector or resize it, then the debugger brings me to the beginning of main(), like I'd expect.
The last time I saw something like this was when my heap was 0 and I tried newing something on the heap. If anyone has any ideas, I'd be grateful.
I'm required to write my program in C++ and though I'm not required to use vectors, I really would like to. (I also have a few ideas of how to implement it differently if it turns out that vectors don't work.)
Thanks,
Did you check your RAM/ROM address ranges (in the "Target" tab)?
A C++ compiler has a naming rule for all external symbols that has a lot of extra bells and whistles. The aim is to get type-safe linking, i.e. if one module think a function takes a double as parameter, and another module think it takes an integer, then the two modules will generate two different function names. When linking, the actual function will have the true name based on what parameters and parameter types and return values the function really takes.
C does not have such augmentated (mangled) names. So if you include a C header file in a C++ program, all linking will fail. Your program may ask for a $abs$_3v1v4z function, while your C runtime library main contain a _abs function.
Encapsulating all C declarations in extern "C" (for the runtime library, this is normally already done inside the files, but many tool vendors don't take their time to do it for all of their own files) makes sure that the compiler will not mangle the external names of the symbols.
In some situations, the compiler may also change calling convention (how parameters and return values are passed and what registers that gets destroyed) depending on if the reference is to a C symbol or a C++ symbol.
You normally do not get a runtime error from one too much or one too little extern "C" in your code. The extern "C" part is to get a correct linking step - with mismatch your program will (almost always) not link. It is possible to get into troubles if the runtime library has two functions with the same name - one name-mangled and one using standard C naming convention. The intention would then be that a correct C++ program should pick up the mangled C++ version, while a C program should pick up the un-mangled C version. But having extern "C" in one C++ module and not in another can result in both copies of the function being included with strange results.
In your case, you have a problem with a C++ data type - so there should not be any corresponding C code that may link in by mistake unless you have manually added a vector library written in C.
That is why I initially asked the OP if he sees a linker warning. Can such a blunt mistake go unnoticed...?
IROM1 Start is 0x8000000, Size 0x80000 IRAM1 Start is 0x20000000, Size 0xC000
It looks reasonable to me...
Using STL will bring in a lot of extra code. C++ can give a smaller program growth when you add one more feature to an existing program. But it tends to produce very large "hello world" applications compared to C programs. And huge "hello world" applications compared to assembler applications.
It does not sound good that your program does not include your main().
Oh, main() is still there. It just decided to remove some other portions of my code... (Not sure which parts though...)
Using STL will bring in a lot of extra code.
I absolutely agree. I've got space for the time being. Hopefully, the reusability of the code is worth the code bloat.
http://www.keil.com/support/man/docs/armlib/armlib_cihdfbhe.htm
Are you doing something I/O related in your startup file?
Anybody - is it "normal" for IO functions to be invoked upon initialization of the C runtime library used by the RealView compiler? If not, what on earth is happening here?!