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