<div dir="ltr">Hi Howard,<div><br></div><div>Glad to see your keeping watch. Thanks for the input and I agree on all points.</div><div>I don't want to offer an opinion on if this code should be accepted.</div><div>However I want to offer a couple of points on the current implementation.</div>
<div>- The overload accepts const rvalues. </div><div>- Only the ostream operator implements the DR. The istream operator is implemented as specified.</div><div><br></div><div>If we choose to keep the current implementation I believe we should consider disabling the overload for const rvalues and bring the istream iterator in line with the ostream iterator.</div>
<div><br></div><div>/Eric</div><div><br></div><div>P.S. I would prefer if we could keep this conversation on the actual review. Please consider making an account for future discussion. </div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Aug 8, 2014 at 8:54 PM, Howard Hinnant <span dir="ltr"><<a href="mailto:howard.hinnant@gmail.com" target="_blank">howard.hinnant@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If every design decision fastidiously adhered to every single detail of the standard, we would never get a better standard next year.<br>
<br>
The bug report shows that something that is made easy by libc++ is made harder by a strictly conforming implementation. The bug report does not show any downside. Thus the question we should be asking here is:<br>
<br>
Should libc++ conform to the standard, or should the standard be changed to agree with libc++?<br>
<br>
The latter is what is often done to improve the standard for the entire C++ community. I’ve personally done this dozens of times. When you get to the meeting, the question is often asked:<br>
<br>
Is there any field experience for this improvement?<br>
<br>
If the answer is yes, and it is positive, the committee can be swayed to make an improvement.<br>
<br>
So, do the people here believe that the standard spec is better than the libc++ implementation? Or do they wish only to blindly follow the current standard spec and have no wish for the standard spec to improve in the future?<br>
<br>
Imho, never deviating from the standard results in mediocrity and stagnation in technological progress. Wildly deviating from the standard results in chaos. And an engineer will seek an optimum between these two extremes.<br>
<br>
Howard<br>
<div><div class="h5"><br>
On Aug 8, 2014, at 10:24 PM, Eric Fiselier <<a href="mailto:eric@efcs.ca">eric@efcs.ca</a>> wrote:<br>
<br>
> Hi mclow.lists, danalbert,<br>
><br>
> This patch fixes ostreams operator<< so that it properly returns an lvalue reference.<br>
> It also forces the input and return type to be basic_ostream. This is inline with the standard.<br>
><br>
> It appears as though <a href="http://cplusplus.github.io/LWG/lwg-closed.html#1203" target="_blank">http://cplusplus.github.io/LWG/lwg-closed.html#1203</a> was implemented even though it was never accepted (and is now closed).<br>
><br>
> <a href="http://reviews.llvm.org/D4835" target="_blank">http://reviews.llvm.org/D4835</a><br>
><br>
> Files:<br>
> include/ostream<br>
> test/input.output/iostream.format/output.streams/ostream.rvalue/return_value.pass.cpp<br>
><br>
> Index: include/ostream<br>
> ===================================================================<br>
> --- include/ostream<br>
> +++ include/ostream<br>
> @@ -1044,18 +1044,13 @@<br>
><br>
> #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES<br>
><br>
> -template <class _Stream, class _Tp><br>
> +template <class _CharT, class _Traits, class _Tp><br>
> inline _LIBCPP_INLINE_VISIBILITY<br>
> -typename enable_if<br>
> -<<br>
> - !is_lvalue_reference<_Stream>::value &&<br>
> - is_base_of<ios_base, _Stream>::value,<br>
> - _Stream&&<br>
> ->::type<br>
> -operator<<(_Stream&& __os, const _Tp& __x)<br>
> +basic_ostream<_CharT, _Traits>&<br>
> +operator<<(basic_ostream<_CharT, _Traits> && __os, const _Tp& __x)<br>
> {<br>
> __os << __x;<br>
> - return _VSTD::move(__os);<br>
> + return __os;<br>
> }<br>
><br>
> #endif // _LIBCPP_HAS_NO_RVALUE_REFERENCES<br>
> Index: test/input.output/iostream.format/output.streams/ostream.rvalue/return_value.pass.cpp<br>
> ===================================================================<br>
> --- /dev/null<br>
> +++ test/input.output/iostream.format/output.streams/ostream.rvalue/return_value.pass.cpp<br>
> @@ -0,0 +1,34 @@<br>
> +//===----------------------------------------------------------------------===//<br>
> +//<br>
> +// The LLVM Compiler Infrastructure<br>
> +//<br>
> +// This file is dual licensed under the MIT and the University of Illinois Open<br>
> +// Source Licenses. See LICENSE.TXT for details.<br>
> +//<br>
> +//===----------------------------------------------------------------------===//<br>
> +<br>
> +// <ostream><br>
> +<br>
> +// template <class charT, class traits = char_traits<charT> ><br>
> +// class basic_ostream;<br>
> +<br>
> +// template <class charT, class traits, class T><br>
> +// basic_ostream<charT, traits>&<br>
> +// operator<<(basic_ostream<charT, traits>&& os, const T& x);<br>
> +<br>
> +#include <ostream><br>
> +#include <type_traits><br>
> +<br>
> +int main()<br>
> +{<br>
> +#ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES<br>
> + {<br>
> + typedef decltype(std::ostream(nullptr) << "testing...") T;<br>
> + static_assert(std::is_same<T, std::ostream &>::value, "must be lvalue");<br>
> + }<br>
> + {<br>
> + typedef decltype(std::wostream(nullptr) << "testing...") T;<br>
> + static_assert(std::is_same<T, std::wostream &>::value, "must be lvalue");<br>
> + }<br>
> +#endif // _LIBCPP_HAS_NO_RVALUE_REFERENCES<br>
> +}<br>
</div></div>> <D4835.12323.patch>_______________________________________________<br>
> cfe-commits mailing list<br>
> <a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
<br>
</blockquote></div><br></div>