Michael Marcin wrote:
John Torjo wrote:
Eames, Andrew wrote:
Hi,
I apologize if this is a FAQ - I couldn't find much on other compilers
I am interested in using boost with a compiler for a DSP - The compiler is somewhat archaic - I'm not using RTTI or exceptions (the compiler supports them but it is currently broken) - the STL has old iostreams and no doubt I will find some other musty corners. I don't have any illusions about getting the whole of boost to compile but I'm sure there are some large pieces that will work OK. I have no problem doing the port myself.
RTTI is pretty useful, and I think quite a few libraries rely on dynamic_cast at least once.
For instance Boost Logging Lib ( http://torjo.com/log2/ ) relies on it once - I guess you could get 'round it.
I guess the 1M$ question is : why do you need that specific compiler?
I'm in a similar situation where I have to use a specific compiler because it's the only compiler supported by the closed SDK for the platform we're developing for.
Right now I, unfortunately, can only use the Torjo logging library for a windows port of the application because the target platform doesn't support RTTI (exceptions are fine). This is annoying because the debuggers for these embedded devices are sometimes flaky and logging on device is sometimes the only way to fix bugs. So we have to have another simple homegrown logging library for on device logging.
There are many other Boost libraries that we can't use, at least out of the box, because they use RTTI in one or two places where they probably don't have to. For instance lexical_cast uses it to provide extra information to the bad_lexical_cast exception but functions just fine without it. I didn't dig enough into the implementation but it looks like Boost.Function and Boost.Variant may be in a similar boat.
I think shared_ptr used to have this issue but got changed after 1.34. I wish more libraries would follow its lead if possible.
You can raise the viability of the issue by submitting patches. Where RTTI is useful, but not essential, I'd personally rather not remove it entirely. Instead, the code could respond to a macro (BOOST_NO_RTTI perhaps) and avoid usage when present. But the default would be to user RTTI on the theory it is usually available. --Beman