Peter Dimov wrote:
David Abrahams wrote:
"Robert Ramey" <ramey@rrsd.com> 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