Boost logo

Boost Users :

From: John Maddock (john_at_[hidden])
Date: 2007-02-20 05:51:38


Peter Poulsen wrote:
> I know this sounds insane, but our developers are very happy with
> boost (who can blame them :-)), and want to have boost available on
> our embedded systems. We only have 64 mb of flash memory available
> for the entire system (OS, hardware monitoring and applications) and
> I simply cannot get boost down to a reasonable size. Am I trying to
> do an impossible task, or can somebody give me some good advice on
> how to build boost so it has a more reasonable size?
>
> Of course what should be done is removing some of the features, and I
> can probably negotiate with developers about what features we can
> provide and which have to go. Which one should I try to get rid of
> first?

At the risk of stating the obvious :-)

There are two main things to bare in mind:

1) Many libraries are header only, and you only pay for what you use. It's
unlikely for example that you could implement the equivalent of shared_ptr
with less runtime cost that the existing implementation, so you may as well
just go with it. And metaprogramming libraries obviously have no runtime
cost at all :-)

2) If you link to libraries that have separate source, then linking to the
static versions of the libraries will likely save you a lot of disk space:
for example using regex statically linked requires about a 50K overhead for
minimal usage, where as the shared library is rather larger than that (if
you need hints for pruning it down further still, give me a shout).

So basically, get your developers to think about what they're doing before
they start coding and you should be OK :-)

There's one other thing to bare in mind: given a choice between using a
general purpose component like spirit or regex, and a custom parser, a
custom parser is likely to win in terms of both size and speed, but on the
other hand will slow down your development. If you separate these
components from the rest of your app, you can always protype with a general
purpose Boost-component, and then replace later if the need arises. No
doubt similar compromises can be made with other Boost components
(serialisation, program options etc).

HTH,

John


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net