Ling Li wrote:
(The related thread is http://lists.boost.org/Archives/boost/2006/08/109450.php)
Sun CC seems to have #include guards automatically for standard headers like <memory>. This somehow causes problems to Boost::TR1. Here is a simple example (call it sun-test.cpp) that doesn't compile with Sun's compiler:
#include <string> #include <memory>
void f() { std::tr1::shared_ptr<int> p(new int()); }
The command line is: CC -c -library=stlport4 -I<BOOST_TOP>/boost/tr1/tr1/sun -I<BOOST_TOP>/boost/tr1/tr1 -I<BOOST_TOP> sun-test.cpp
And the error msgs: "sun-test.cpp", line 5: Error: tr1 is not a member of std. "sun-test.cpp", line 5: Error: shared_ptr is not defined. "sun-test.cpp", line 5: Error: Badly formed expression.
The reason is that the 2nd include, "#include <memory>," is not honored since Sun's <string> (included from Boost::TR1's string) somehow loads <memory> inside it. Although the <memory> header it loads is the Boost::TR1 version, Boost is smart enough not to include the TR1 extension part. That is actually the correct thing to do, and other compilers (VS and GCC) will get the TR1 extension via the 2nd include. But for Sun's CC, since the 2nd include is not honored, std::tr1 is missing.
Sun CC doesn't do that auto #include guards for user headers.
I am wondering if there is a way to turn off that auto guards for Sun CC (I haven't found a way yet). Or is there some way to change Boost::TR1 to accommodate this special behavior?
Oh heck, I'll think about this, but I can't see a way to fix it at present. The one thing we definitely can't do is allow recursive includes (so that vendor <string> includes Boost <memory>), because that leads to some awful and intractable cyclic dependencies. You could include <boost/tr1/memory.hpp> instead of <memory>, but that's not a good solution either :-( John.