|
Boost : |
From: Robert Ramey (ramey_at_[hidden])
Date: 2005-06-27 21:53:30
Peter Dimov wrote:
> David Abrahams wrote:
>> "Robert Ramey" <ramey_at_[hidden]> writes:
>>
>>> 1) as written above, it fails to compile on a conforming compler.
>>> This is because the << operator takes a reference as its argument.
>>
>> Why is it a good idea for << to take its 2nd argument by non-const
>> reference??
>
> To trap non-const cases and refuse to compile them. ;-) (Back to
> square
> one.)
Actually that's not funny- its true
But also the prototypes specializations of save all use const.
e.g. member funciton
template<class Archive>
void save(Archive &ar, unsigned const int) const;
and
template<class Archive, class T>
void save(Archive &ar, const T &t, unsigined const int)
So I orignally made
operator<<(Archive &ar, const T &t) as it seemed natural and consistent to
me. Of course this produces no errors as it converts a non-const to a
const.
However upon encountering examples like my extrapolation of peter's above, I
concluded I wanted to be able to trap a probabe mis-use of the library such
as illustrated by the previous example - and I didn't want to throw the
opportunity away. Also, I came upon a warning somewhere that the compiler
may copy a value when converting to a const. Now I don't know if that
applies to const references and in fact I never saw it happen with any of my
compilers.
So my motivation was and is purely practical. I expected that the only
people inconvenienced by this are those that are inconvenienced by const in
general. And that they would handle it the same way. They would just
grumble and apply a const_cast and forget about it. I'm certainly not
prohibiting that.
Robert Ramey
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk