|
Boost : |
From: Guillaume Melquiond (guillaume.melquiond_at_[hidden])
Date: 2004-02-24 14:02:54
Le mar 24/02/2004 à 18:31, Eric Niebler a écrit :
> Guillaume Melquiond wrote:
[...]
> > Yes it is a shortcoming of the interval regression tests (that doesn't
> > mean it isn't also a shortcoming of VC7.1). I only test for things that
> > could break in the current code, not for things somebody else could
> > change afterward :-).
> >
>
> IMO, I think you should add a test for this. It's a valid usage scenario
> which you support. You (and I, as a maintainer) want to know when it breaks.
Will do.
> > Wasn't there the idea of adding prefix and suffix headers to Boost? If
> > it was undef'd or pragma_push'd for all the libraries, it would avoid
> > changing these 800 occurrences. Or am I missing something?
> >
>
> Not all compilers support push_macro/pop_macro, and unconditionally
> removing users' macros is impolite, considering there are ways we can
> make boost code impervious to these macros.
No, it's not what I meant. I wasn't suggesting undef'ing once and for
all these macros. Since there is a suffix header, they could be
restored. Or is it impossible to do with basic preprocessing?
[...]
> I agree it's ugly. But not as ugly as the current solution in win32.hpp,
> which can silently change the meaning of users' code. You don't need a
> boost_min macro -- you can define your own interval_min/interval_max
> templates as follows:
>
> #define BOOST_EMPTY
> template< class T >
> inline void interval_min(T const &a, T const &b) {
> using std::min; min BOOST_EMPTY (a,b);
> }
>
> and now use interval_min instead of min everywhere. Perhaps we can do
> this once and call it boost_min, so everybody can use it. Opinions?
Seems fine.
In fact, it would be a bit more complex since min and max are not always
in the std namespace, they can also be in the root namespace (even if
they should not). The Interval library tests which compiler and standard
library are used in order to find the correct namespace. But it's only a
minor detail.
Regards,
Guillaume
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk