Re: [boost] [TR1] Sun problems (again)

Subject: Re: [boost] [TR1] Sun problems (again)
From: John Maddock (john_at_[hidden])
Date: 2008-11-13 05:48:48

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.