Re: [boost] Views library in vault

From: Dave Abrahams (abrahams_at_[hidden])
Date: 2000-04-20 21:57:14

on 4/20/00 10:17 AM, Moore, Paul at paul.moore_at_[hidden] wrote:

> Is this just true for std::swap? Or does it apply to other functions in
> std::? 

The latter.
 
> Given that there seems to be a defect in the standard

I would say it's "an issue". It is not clear whether this is a defect or
intentional. IMO it would be better if we have function template partial
specialization, but that doesn't make this a defect.

> I'd say Boost needs
> to have some sort of view on what acceptable code should do. The options
> seem to me to be
> 
> 1) Accept code which extends std:: functions, as an interim measure. This is
> nasty as (a) it prejudges the committee's decision on the defect report, (b)
> it introduces undefined behaviour, and (c) someone needs to keep track of
> where this is done, so as to fix it when a committee response to the defect
> report is available.

I caution you that the committee's decision is probably a long way off and
is quite likely to be different than you or I might like. Changing the rules
of the standard after it has been approved and people have written lots of
code to it is no small matter.

> 2) Require all accepted code to stick to the letter of the standard on this.

For the time being, I think this is the only appropropriate policy.

> This means that boost code must use the existing std::swap, which may not be
> efficient (worse, may not be nonthrowing if the class has a throwing copy
> constructor??!?)

Q. Where is it written that std::swap() is supposed to be efficient or
nonthrowing?

A. It isn't.
(except when used on the standard containers, where it is guaranteed to be
nonthrowing, but not neccessarily efficient).

> And it offers no real recourse to classes which need to
> extend other std:: functions (cf rational and abs).

Classes do not *need* to extend std:: functions. You and I may not like it,
but there are alternatives.
 
> 3) A compromise - require code to put non-conforming code in an #ifdef block
> (BOOST_EXTENDS_STD, maybe)? Users can switch this on or not as they please,
> and the ifdef documents where the problem exists.
> 
> 4) Require all code to use something like Alan Griffiths' workaround
> template<typename Y>
> void myswap(Y& lhs, Y& rhs)
> {
> using std::swap;
> swap(lhs, rhs); 
> }
> which seems to give the desired effect as long as the user also uses the
> same workaround. This is the best conforming answer available (AFAIK), but
> requires users to implement workarounds in their code

What workarounds are required of users?

> - which will probably
> remain in maintenance for evermore... Is there any mileage in having a
> boost::myswap()? I can't work through the implications of this...

No, but there might be some mileage in writing a boost::swap() ;)