[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