Re: [boost] [python] Tru64/CXX function template issues

From: David Abrahams (dave_at_[hidden])
Date: 2005-06-19 13:09:43

Markus Schöpflin <markus.schoepflin_at_[hidden]> writes:

> David Abrahams wrote:
>
>> "Ralf W. Grosse-Kunstleve" <rwgk_at_[hidden]> writes:
>
>>>>This is pretty bad because quite a few boost libraries depend on more than 
>>>>only the C names as specified in the standard. (thread and fs at least, 
>>>>IIRC, but I think there are more)
>>>
>>>In the hot days of Boost.Python development we were very careful to use only
>>>ANSI features. Anything else is non-portable and bound to break somewhere,
>>>sooner or later. I.e. I think the libraries that don't compile with -std
>>>strict_ansi should be fixed.
>> 
>> pthreads is an extension to what's required by ANSI.  I think that
>> might make Boost.Threads impossible.
>
> Well, every boost library that relies on more than ANSI would be 
> affected. That is at least filesystem, thread and test because each of 
> them needs some POSIX feature to work properly.
>
> And CXX is quite strict in strict ansi mode. Nothing is there besides 
> the things promised in the standard. For boost.test for example that 
> means, including <signal.h> doesn't give you sigaction, even not if the 
> POSIX feature macros say it's there.
>
> So I think as long as the bug in iotraits is not fixed, boost.python 
> will not work on this platform, at least not with the boost.build 
> toolset. :-(

Note:  when using Boost.Build you are supposed to #include one of its
headers first.  That means boost/python/detail/prefix.hpp gets
#included before anything else, which gives you an opportunity to
play all sorts of nasty tricks like

   #define ios_traits broken_ios_traits
   #include <iotraits>
   #undef ios_traits

   struct ios_traits  // the working version
   {

   }

to work around brokenness.

HTH,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com