Boost logo

Boost :

From: Gabriel Dos Reis (Gabriel.Dos-Reis_at_[hidden])
Date: 2001-01-24 22:23:25

"Moore, Paul" <paul.moore_at_[hidden]> writes:


| Questions
| ---------
| 1. Should Boost libraries only look in std:: for functions specified in the
| standard? This effectively requires users of the libraries to overload names
| in std::, and prejudges the committee's decision on issue (2) above.
| 2. As an alternative, should Boost libraries use Koenig lookup on compilers
| where it is supported, and use std:: for compilers where Koenig lookup is
| not supported? This results in a difference in user interface between
| compilers. For this to be reasonable, I'd say we have to advertise the
| overloading of names in std:: as a workaround for lack of Koenig lookup,
| which then makes it harder to switch to overloading std:: as a recommended
| approach should the committee decide this is OK.

Well, judging from the disussions amoung the LWG members, it is not at
clear that the committee is leaning towards removing that restriction
-- contrary to what you stated earlier.

Certainly this is a torny issue. Do you think just Boost would start
advertising to dereference a null pointer would make the committee to
change its mind about dereferencing null pointer? I know you didn't
say that. But the cases are comparable.


| 4. Specific to the rational library, would anyone have any strong objections
| if I were to implement abs() without using an existing abs() function on the
| underlying integer type? Apart from the Koenig lookup issues, I don't really
| want to break the use of rational<long long>, rational<__int64> and the
| like.

Why can't boost defines its own wrappers for such functions when they
are missing? That would also helps users having a broken std::abs for
standard types. Something like

        namespace boost {
                using std::abs;
                template<typename T> T abs(T) { /* ... */ }

-- Gaby

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