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

Subject: Re: [boost] [TR1] Sun problems (again)
From: Simon Atanasyan (atanasyan_at_[hidden])
Date: 2008-11-13 06:16:48

There are two workarounds. Both of them are quite ugly but it's better
than nothing:

1. You can use undocumented command line option '-Qoption ccfe -nosunwcch'.
2. You can create symlink <inc_name>.SUNWCCh points to <inc_name>. By
default Sun C++ replace #include <memory> by #include <memory.SUNWCCh>
and lookup memory.SUNWCCh using regular include file lookup rules.

On Thu, Nov 13, 2008 at 1:48 PM, John Maddock <john_at_[hidden]> wrote:
> 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.
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

-- 
Simon Atanasyan