[boost] Re: Boost header guidelines

From: John Maddock (John_Maddock_at_[hidden])
Date: 1999-10-02 06:21:13

Paul -
>That's a real disappointment. If so, I'd prefer to have the current
non-boost version...<

as you can continue to do....

<locale> is irrelevant to me - I don't need to worry about i18n issues.
What
are the issues with <iterator> and <memory>?<

Ok here are the problems that come to mind:

<memory>

std::allocator is non standard - there is no Rebind<U> nested template
class - either we have to allocate "chunks" of sizeof(T), and live with
inefficiency where sizeof(T) is large, or use a byte based allocator as the
default (cf SGI's allocators).  Fix requires alternate typedefs in
container class - so the minimum requirement is a BOOST_NO_STD_ALLOCATOR
macro (although possibly BOOST_NO_MEMBER_TEMPLATES could double up here).

<iterator>

There are no partial template specialisations allowed in VC6, so
iterator_traits<> fails for built in types (pointers), this makes some code
impossible, other code is possible but requires workarounds - for example
using a function return type to determine the iterator type (again cf SGI
STL).  Minimum workaround requirement is a macro BOOST_NO_PARTIAL_SPEC.

<locale>

Calling functions with explicit template args is not supported, so
use_facet and has_facet are non-standard. Another maco anyone?

Others:

MSVC can't deal with template function partial ordering - making some
useful algorithm overloads impossible - requires another macro
BOOST_NO_PARTIAL_ORDERING.

**this is not a diffinitive list** it includes only unsupported
compiler/standard library features, not compiler bugs (like occationally
flakey qualified name lookup).

My reasoning is that if I'm going to do a rewrite as part of a wider
pattern-matching stategy (as I'm planning), I may as well see how few
macros I can get away with in the short term, in the knowledge that by the
time the project is complete, VC7 will probably be out and about, and gcc
will have acquired <locale> support.

- John