STL containers and managing memory allocation in embedded systems

[Alex Vinokur]

The memory allocation issue in embedded systems is usually critical..

How can one manage that?

1. Via 'new'
char* p = new (nothrow) char [SOME_SIZE];
if (p == 0)
{
// He we know that it is impossible to allocate the requested memory
// We can do something relevant.
}


2. But how to manage memory allocation in containers for embedded
systems?

For instance,
vector<Foo> v;
Foo f;
v.push_back(f);

push_back() returns no values.

So, how can we know (except try-catch) that it is impossible to
allocate the requested memory in push_back()?

 

[flagos]

Alex:

When you say 'vector<Foo> v;' actually you are saying:
vector<Foo,allocator<Foo> > v;
because of the default second parameter of the vector template
definition:

template <class T, class Allocator = allocator<T> >
class vector.....

And the member allocate() of allocator "...Throws the exception
bad_alloc if the storage is unavailable. This function uses operator
new(size_t)..."

Hope this help.

 

[Hans-Bernhard Broeker]

The memory allocation issue in embedded systems is usually critical..

It's usually beyond critical --- it's inacceptable, period. An
embedded system has nobody to complain to if an operation as strictly
internal as a memory allocation fails. So it had better not go there
at all.

If you can't afford to allow exception handling, you generally can't
allow C++ style dynamic memory handling. It's as easy as that.

How can one manage that?

Primarily by not doing it.

2. But how to manage memory allocation in containers for embedded
systems?

Primarily by not using them.

 

[Alex Vinokur]

2. But how to manage memory allocation in containers for embedded
systems?

For instance,
vector<Foo> v;
Foo f;
v.push_back(f);

push_back() returns no values.

So, how can we know (except try-catch) that it is impossible to
allocate the requested memory in push_back()?

[snip]

By the way, is this check correct?


vector<Foo> v;
// Stuff

size_t the_size = v.size();
Foo f;
v.push_back (f);

if (v.size() != (the_size + 1))
{
cerr << "Unable to allocate memory via push_back()" << endl;
}

 

[Gavin Deane]

By the way, is this check correct?


vector<Foo> v;
// Stuff

size_t the_size = v.size();
Foo f;
v.push_back (f);

The standard behaviour when any memory allocation fails is to throw a
std::bad_alloc exception, so if push_back needs to allocate but is
unable, you don't get to the code below at all.

if (v.size() != (the_size + 1))
{
cerr << "Unable to allocate memory via push_back()" << endl;
}

Gavin Deane

 

[Acer]

The standard behaviour when any memory allocation fails is to throw a
std::bad_alloc exception, so if push_back needs to allocate but is
unable, you don't get to the code below at all.


Gavin Deane

if I would like to restrict size of some objs (ex. vector<string>)
what can I do?
rewrite the allocator? is there any shortcut?

 

[Alex Vinokur]

The standard behaviour when any memory allocation fails is to throw a
std::bad_alloc exception, so if push_back needs to allocate but is
unable, you don't get to the code below at all.

Green Hills' Extended Embedded C++ compiler enables the user to cancel
exception handling. In this case, can the code below work? Does anybody
have such experience?

[snip]

Alex Vinokur
email: alex DOT vinokur AT gmail DOT com
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn

 

[Maxim Yegorushkin]

Green Hills' Extended Embedded C++ compiler enables the user to cancel
exception handling. In this case, can the code below work? Does anybody
have such experience?

The standard containers do not provide any guarantees for your case.
Create and use your own containers that do.

 

[CBFalconer]

2. But how to manage memory allocation in containers for embedded
systems?

For instance,
vector<Foo> v;
Foo f;
v.push_back(f);

push_back() returns no values.

So, how can we know (except try-catch) that it is impossible to
allocate the requested memory in push_back()?

[snip]

By the way, is this check correct?

vector<Foo> v;
// Stuff

.... snip ...

If you are worried about memory and bloat, why are you using C++ in
the first place?
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Ian Collins]

The memory allocation issue in embedded systems is usually critical..

How can one manage that?

1. Via 'new'
char* p = new (nothrow) char [SOME_SIZE];
if (p == 0)
{
// He we know that it is impossible to allocate the requested memory
// We can do something relevant.
}


2. But how to manage memory allocation in containers for embedded
systems?

For instance,
vector<Foo> v;
Foo f;
v.push_back(f);

push_back() returns no values.

So, how can we know (except try-catch) that it is impossible to
allocate the requested memory in push_back()?

The only save way if you disable exceptions is to provide your own
allocator and assert.

 

[Alex Vinokur]

The standard containers do not provide any guarantees for your case.
Create and use your own containers that do.

Or own allocators for STL containers?

Alex Vinokur
email: alex DOT vinokur AT gmail DOT com
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn