Re: [boost] operators.hpp release candidate material uploaded

From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2000-06-26 01:38:36

David Abrahams <abrahams_at_[hidden]> wrote:
> Includes updated documentation, cleanup of all the recent changes, true
> STLport compatibility (as far as I can tell). So much work has happened
> recently that I wanted to give people a chance to test it and make sure it
> still works with your compilers/libraries. See:
>
> operators_release.zip

Great work, Dave!! A few small issues I am concerned about:

1) The documentation still says that

>The test program has been compiled and run successfully with:
>...
> * Microsoft Visual C++ 6.0 SP3 (Single template argument form only.)

It (the comment in brackets) is not actually true - the test program uses
the two-argument form of the templates with the trailing '2', and MSVC
handles them without any problems (almost, but we've already fixed that
one). I suggest we should remove the comment.

2) struct 'boost::iterator' in the 'iterator.hpp' file is defined as:

 template <class Category, class T, class Distance = std::ptrdiff_t,
            class Pointer = T*, class Reference = T&>
struct BOOST_DECL iterator :
...

and Metrowerks Codewarrior 5.3 doesn't like the BOOST_DECL here (which is
defined in our 'config.hpp' header as '__declspec(dllimport)' ) - it causes
numerous number of errors during 'operators_test' compilation.

I suggest we should remove the macro from this concrete definition, as all
other templates in the library are defined without it, but that brings
another issue to me - does the Metrowerks compiler really understand the
'__declspec' specifications??

And if it (or some other compiler) does that by default, but does not in the
'strict' or 'ansi' mode, how users of a boost library, which uses the
BOOST_DECL macro, would compile the library in such mode? The only way I see
now is to modify the 'config.hpp', which is not that I would like to do...
Thoughts?

3) The 'random_access_iterator_helper' definition contains the following
#ifdef code:

struct random_access_iterator_helper
  : equality_comparable<T
...
#ifndef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
  , addable<T,D
  , subtractable<T,D
#else
  , addable2<T,D
  , subtractable2<T,D
#endif // BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
...

Is there a reason why not to write just

struct random_access_iterator_helper
  : equality_comparable<T
...
  , addable2<T,D
  , subtractable2<T,D
...
??

--Aleksey