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

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-06-26 07:02:35

----- Original Message -----
From: "Aleksey Gurtovoy" <alexy_at_[hidden]>

> 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.

Good point.

> 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.

That's funny; it worked for me with CW. Of course, I'm using a beta of the
next version, but I think they've always supported __declspec(dllimport)
.... when targeting Windows.

> I suggest we should remove the macro from this concrete definition, as all
> other templates in the library are defined without it,

Agreed.

> but that brings
> another issue to me - does the Metrowerks compiler really understand the
> '__declspec' specifications??

I think so... when targeting Windows!

> 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?

The bigger problem is that BOOST_DECL is set up to do this Windows-specific
thing for Metrowerks regardless of what platform we're targeting. The Mac
doesn't use declspec. Beman, take note!!

> 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
> ...

It's a fair idea. I didn't ignore your suggestion but decided this was
marginally better in the case of someone trying to do certain kinds of
generic programming...
now I see that the "advantage" is so marginal that it is practically
worthless.

So, I've taken all of your suggestions and uploaded a new version to the
vault. I will be out of the country Tuesday evening-Saturday. I will submit
this stuff to Beman for official release before I leave, so if you want
input, be quick about it!

-Dave