PDA

View Full Version : Can I Using STL in BREW env like this?


yangcy
08-28-2003, 08:58 PM
We¡¯re going to re-use some original source code(cpp code, which uses SGI STL vector,pair,map,set,list, queue etc) in our new Brew Applet. And we know that in brew applet , we should use MALLOC, FREE, MEMCPY, MEMMOVE etc which defined in AEEStdlib.h instead of malloc, free, memcpy, memmove etc in ANSI C memory.h or something like this. After my firest failed attampt to just do some simple replace work in stl_alloc.h and others[1] , we tried like this (details below) , but we¡¯re not sure if it will work properly. so any suggestion about it from you are thankful and surely will benefit us a lot.

1) I write an customed Allocator myAlloc according to Nicolai M. Josuttis¡¯s << The C++ Standard Library >>description in chapter 15 Allocator. And in my customed allocator, I use MALLOC and FREE to allocate the memory
2) Replace memcpy with MEMCPY and so do the others for STL: stl_algobase.h, stl_uninitialized.h, and stl_alloc.h (of course, should have already included AEEStdlib.h)
3) replace codes like ¡°vector<POINT * > v¡± to ¡°vector<POINT * ,MyLib::MyAlloc<POINT *> > v¡± in our original source code
4) in OnAppfreeData or some other place to free applet object call ¡°v.~vector();¡± manually.

After doing so, while running the applet(dll) on BREW Emulator.it works properly.and while debugging it, I¡¯m sure that it acctually called myAlloc to alloc and de-alloc the memory,indeed.but I find a strange thing, ---if I don¡¯t do 4) above, BREW Emulator will complains ¡°can¡¯t free all the memory¡±. I think that under normal situation, 4) is not necessary and it will be done automatically

: ( so that¡¯s why I¡¯m here for your help, befor we begin to compile it to .mod and upload to handset. Thanks a lot.

The attachement is my test project

[1]after our doing so, the project can be compiled succussfully but will raise erro at STL¡¯s MEMMOVE statement : (

yangcy
08-29-2003, 01:54 AM
for upload file-size limits, the zip file only contains STL files which have been modified. You can get the full version from internet or mail to me(yangcy@neusoft.com).
thanks again...

aisaksen
08-29-2003, 02:15 PM
Your problem is that the STLTest object is never constructed/destructed using 'new'/'delete'. Instead, the memory is just MALLOCed and then casted to a STLTest. This is because the BREW runtime system doesn't know you are using C++; it thinks you are using C. The system doesn't automatically call the deconstructor for the std::vector because it doesn't know that it needs to destroy the STLTest and all its members.

Its safer to only have things that don't need to be constructed/deconstructed in your STLTest class. That means pointers and ints are ok, but objects are out. The easiest way to get around this is to have a STLTestObjects class which holds all your object and have a pointer to this wrapper class in STLTest. You need one more level of indirection in your code.

-Aaron

aisaksen
08-29-2003, 02:18 PM
One note of caution about using the STL in an embedded environment: it is not safe under low memory conditions when compiling with the ARM compiler. This is because ARM doesn't support exceptions and when the STL is compiled without exceptions it doesn't do a good job of catching out of memory conditions. Also, std::string requires static memory to deal with the empty string, so you'll have to rewrite that part of it.

Maybe you'll have better luck if you use the gcc compiler?

-Aaron

yangcy
09-04-2003, 01:44 AM
thanks a lot :)

j0rd
09-13-2003, 03:39 PM
more reading

http://www.developer.com/ws/brew/

some good articles related to CPP/STL/ARM compiler issues on the brew platform.