[PATCH] D33776: [libcxx] LWG2221: No formatted output operator for nullptr

Agustín Bergé via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Dec 13 12:06:54 PST 2017


K-ballo added inline comments.


================
Comment at: include/ostream:225
+    basic_ostream& operator<<(nullptr_t)
+    { return *this << (const void*)0; }
+
----------------
Quuxplusone wrote:
> mclow.lists wrote:
> > lichray wrote:
> > > Oh, common, I persuaded the committee to allow you to print a `(null)`  and you don't do it...
> > I think that `(null)` is a better thing to output here than `0x0`.
> Are you two implying that
> 
>     *this << (const void *)0;
> 
> does *not* print `(null)`? It certainly should, IMO. (I mean, it'll call `num_put` for `void*` in the current locale, but I would naturally expect that to print `(null)`.)
> Anyway, whether the current locale prints null as `(null)` or not, there is great potential utility in using the same format for all pointers, as K-ballo is doing here. I'd really like to be able to
> 
>     std::ostringstream oss;
>     oss << nullptr;  // equivalently: oss << (void*)0;
>     void *p;
>     std::istringstream(oss.str()) >> p;  // should read in a null pointer, not derp out
> 
> FWIW, it looks like libc++ currently *does* print null pointers as `(nil)`, which is not quite the same thing as `(null)`. libstdc++ prints them as `0`.
> https://wandbox.org/permlink/yAM6tjMzvEX9HhhE
It's been a while now, but I seem to recall that the reason we settled on `(*this) << (const void*)0` was precisely so that it would go through `num_put`, as the rest of the pointers do. As I read back on the specification, however, I am no longer sure that such an implementation is conforming. Maybe if we were to call the facet directly...

I am no longer interested in this issue. If anyone wants to take over control I would be happy to yield it; otherwise, I'll implement whatever I'm instructed to.


https://reviews.llvm.org/D33776





More information about the cfe-commits mailing list