Re: [boost] Re: stlport config patch and ???-stlport.jam tools

From: John Maddock (john_maddock_at_[hidden])
Date: 2002-07-21 06:01:38

> 3. Another topic related to stlport configuration. Following statement:
> #if !defined(_STLP_MEMBER_TEMPLATE_CLASSES)
> #  define BOOST_NO_STD_ALLOCATOR
> #endif
>
> does not seems to be true. At least for sunpro compiler: allocator_test
> seems to pass (it was not) if comment it out (see
> http://lists.boost.org/MailArchives/boost/msg32013.php)

Are you sure: STLport-4.5.3 has defines std::allocator with:

template <class _Tp>
class allocator {
public:

  typedef _Tp        value_type;
  typedef value_type *       pointer;
  typedef const _Tp* const_pointer;
  typedef _Tp&       reference;
  typedef const _Tp& const_reference;
  typedef size_t     size_type;
  typedef ptrdiff_t  difference_type;
# if defined (_STLP_MEMBER_TEMPLATE_CLASSES)
  template <class _Tp1> struct rebind {
    typedef allocator<_Tp1> other;
  };
# endif
// etc;

so there is no rebind member unless _STLP_MEMBER_TEMPLATE_CLASSES is
defined.  BTW I suspect that the test you are refering to does not rely on
this member - however other boost code (notably regex) does do so, as does
the config test for BOOST_NO_STD_ALLOCATOR.

> 4. I could not compile any_test with sunpro and stlport if  I define
> _STLP_NO_THREADS for <threading>single in toolset definition. After some
> investigation I found that the reason is that following two lines fails to
> compile:
> #include <cwchar>  // this guy came from STLPort headers
> #include <unistd.h> // this guy came from boost/config/posix_features.hpp
>
> This could be a STLPort (or SunPro bug), but here I would like to ask
> whether it is required to include <unistd.h> there. I am not using this
> header in majority of the cases why should I pay for it?

Because the config system needs it in order to figure out what features the
platform supports; I've no idea why your compiler is choking over this, it
really shouldn't: <unistd.h> is mandatory on POSIX platforms, I certainly
don't see why setting an STLport macro would cause this to happen.  In
anycase shouldn't STLport configure itself as single threaded unless you
specify -mt (which defines _REENTRANT) when compiling?

John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm