(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?
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.
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@johnmaddock.co.uk> 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
Your workaround 1 is exactly what I was looking for. Thanks a lot! Workaround 2 doesn't help here --- it has already been used in Boost::TR1, but as I mentioned in my original email, Sun CC avoids reload the standard header <memory> (which is replaced by Boost::TR1's own memory.SUNWCCh), the TR1 extension can't be found in the sun-test.cpp. On Thu, Nov 13, 2008 at 6:16 AM, Simon Atanasyan <atanasyan@gmail.com>wrote:
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.
Simon Atanasyan wrote:
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.
Simon, Boost already has the *.SUNWCCh files which just forward to the real headers. However, as reported it appears that CC doesn't even open these if it's seen them already :-( John.
I agree with you that there isn't an (easy) way to fix it as long as Sun CC refuses to reload its SUNWCCh headers. I like Simon's workaround 1 to turn off Sun's special treatment on standard headers. That way we don't even need the boost/tr1/tr1/sun folder. Maybe we can put that in the document of Boost::TR1, as an alternative? On Thu, Nov 13, 2008 at 5:48 AM, John Maddock <john@johnmaddock.co.uk>wrote:
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.
Ling Li wrote:
I agree with you that there isn't an (easy) way to fix it as long as Sun CC refuses to reload its SUNWCCh headers. I like Simon's workaround 1 to turn off Sun's special treatment on standard headers. That way we don't even need the boost/tr1/tr1/sun folder. Maybe we can put that in the document of Boost::TR1, as an alternative?
Will do, John.
participants (3)
-
John Maddock -
Ling Li -
Simon Atanasyan