Boost logo

Boost :

From: Gabriel Dos Reis (Gabriel.Dos-Reis_at_[hidden])
Date: 1999-12-14 19:45:03


Alan Griffiths <alan_at_[hidden]> writes:

| In message <flk8mmbft9.fsf_at_[hidden]>, Gabriel Dos Reis
| <dosreis_at_[hidden]> writes
| >Darin Adler <darin_at_[hidden]> writes:
| >
| >| > | There is a std::abs() template function, for the complex class.
| >| > | Therefore it is both legal to put the rational abs() function in the
| >| > ^^^^^
| >| > | std namespace and highly recommended since a generic algorithm should
| >| > | be able to use std::abs() on any numeric type including user defined
| >| > | types.
| >| >
| >| > 'legal' on which basis? If it is by the Standard, the chapter and verse.
|
| If I am trying to produce a version (carefully avoiding "specialisation"
| or "overloading" - those are implementation details) of a standard
| entity (e.g. std::swap, or std::abs) for a class of mine the logical
| namespace in which to place it is std.

This is exactky where we disagree. Since ::std is reserved for
implementation details, and you don't care about implementation
details, why would you insist on putting themin ::std?

Since boost::rational<T> abs(const boost::rational<T>&) belongs to
boost::rational<T> interface, I still don't the point to put it in
another namespace.

| My view is that this is where it _should_ go - 'legal' or not. (The
| fact that it appears to be illegal suggests that a defect report is the
| appropriate action.)

From an engineering point of view, i don't think that is that is the
place it should go.
As to the 'legal' issue, I don't think there is a defect entry to
fill, but you can always bring the issue to LWG.

[...]

| >| Kevlin Henney pointed out that, "The abs for complex is in terms of
| >| complex<T> rather than simply just T, and so although you would be
| >| permitted to specialise abs for complex< rational<T> > this does not give
| >| you general licence to specialise for rational<T>."
| >
| >Right. And right now there is no strong reasons to put it in
| >namespace std, apart from (probably) to make it look like standard :)
|
| A little contrived, but not unreasonable...
|
| template<typename number_type>
| struct example
| {
| static number_type abs(number_type x)
| {
| return std::abs(x);
| }
| };

Writing generic code is not a trivial issue. the snippet above does
make the assumption that number_type is coming from ::std.

If the intent were to make it works with every number_type then
surelly, the code needs to be fixed. Not the rules.

-- Gaby


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk