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