Boost logo

Boost :

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-06-18 17:57:55

----- Original Message -----
From: <jsiek_at_[hidden]>

> This seems like the right solution to me... it worked well just now
> for the iterator adaptor implementation I just posted. I suggest we
> add a new file, boost/iterator.hpp with this workaround. A first cut
> at this file is in in the vault.

I'm trying to merge the appropriate changes into operators.hpp so that I can
get gcc support with the native libs to work. This archive contains numerous
changes, including changes to config.hpp (a common situation when someone is
trying to make improvements), which may or may not be relevant to what I'm
trying to do. I am not the maintainer of config.hpp, and Jeremy's
improvements include an additional file (iterator.hpp). In addition, there
appear to be many trivial differences between his version of operators.hpp
and the release version. This is all making my job difficult as maintainer
of operators.hpp.

So I am asking for the following:
1. Proposed improvements to operators.hpp be posted in a separate archive
from such things as the indirect_iterator stuff.

2. Proposed improvements be based on the current release version, with as
few changes as neccessary to make the difference in functionality

3. Guidance as to how we are going to manage changes to config.hpp. We are
generating lots of libraries in the vault that come with customized versions
of config.hpp. This is making testing difficult at best. Perhaps the best
solution would be to release libs with any proposed config.hpp customization
in a separate file *not* called config.hpp.

Also Jeremy,

you have posted a file called ct_if.hpp in this archive, with the following

/* */
/* (c) Tobias Neubert, Krzysztof Czarnecki, and Ulrich Eisenecker 1998 */
/* */

Was this intentional?

Boost list run by bdawes at, gregod at, cpdaniel at, john at