Using boost in embedded system with memory limitation

Question

We are using c++ to develop an application that runs in Windows CE 4 on an embedded system.

One of our constraint is that all the memory used by the application shall be allocated during startup only. We wrote a lot of containers and algorithms that are using only preallocated memory instead of allocating new one.

Do you think it is possible for us to use the boost libraries instead of our own containers in these conditions?

Any comments and/or advice are welcomed!

Thanks a lot,

Nic

Answer 1

You could write your own allocator for the container, which allocates from a fixed size static buffer. Depending on the usage patterns of the container the allocator could be as simple as incrementing a pointer (e.g. when you only insert stuff into the container once at app startup, and don't continuously add/remove elements.)

Answer 2

We use boost for embedded systems. With boost you can pick and choose what you use. We use smart_ptr and boost::bind in all of our projects. We write software for cheap cell phones. And if Windows CE can run on your hardware I would expect that parts of boost would be applicable. There are parts of boost that have no allocation and you might find them useful.

I would pick and choose based on your requirements.

Like anything that you use, you need to know the costs.

Answer 3

Replacing your containers with Boost containers is NOT a good idea. The work to make appropriate custom allocators wouldn't be that bad, but you'd be violating the spirit of your 'allocate at startup' rule. The idea behind this rule (in my experience) is generally to make sure that you don't have to deal with out of memory type situations at run-time. The idea is to make sure that you have all the memory you could possibly need RIGHT AT THE START, so that there's no possibility of any part of the system coming up short of memory later on.

If you used the Boost containers with a custom allocator, you'd suddenly have to deal with the possibility that the pool the container is allocating from could go empty, thus eliminating the purpose of the 'allocate at startup' rule.

In the situation of a limited memory device, I would avoid any kind of container more complex than a statically allocated array.

Answer 4

Boost is a set of libraries. Some of them are focussed on template metaprogramming. Those don't even use any memory at runtime. But your question seems to be about replacing your containers. I'd doubt that is possible except using custom allocators. But even then, it's most likely you would be using plain STL containers and not boost. Boost only provides the TR1 containers, for those compilers that do not yet include TR1.

Answer 5

Do not use Boost.

It is a big library and your basic memory allocation requirements are very different from those of the libraries designers.

Even if you can get a current version of Boost to work according to your requirements with custom allocators it may break with a new version of Boost.

Feel free to look at the Boost source code though for some useful ideas but use your own implementation for what you need.

Answer 6

I'm looking into this right now — I would like to use circular buffers, lock-free containers, and asynchronous I/O, and instead of allocating dynamic memory, I'd prefer to use memory pools.

The biggest problem I've seen so far is that shared_ptr is used in a lot of places, with no easy way to replace it with intrusive_ptr. Since shared_ptr allocates dynamic memory to keep track of the reference count, I can't use it in an embedded system.

Fixing this looks doable, but a lot of work — I have to expand the template specification of any class that contains a shared_ptr so that the specific type of shared-pointer can be changed to intrusive_ptr if desired. So now I have to consider how much work that'll be, versus how much work it'll be to write my own version of the Boost features I need. Not a pleasant place to be.

I hope someone points out why I'm wrong about this.