"David Abrahams" <dave@boost-consulting.com> escribió en el mensaje news:uwtsgbzti.fsf@boost-consulting.com...
"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
If you want to be unambiguous, it has to be more like:
[hello] <- a non-empty optional<std::string> [] <- a non-empty optional<std::string> (the string is empty) _ <- an empty optional<T>
My preference is
hello
_
A string can never be output "correctly", no matter what the delimiters are ("a] [b").
I disagree. You can generate escapes:
[a\] \[b]
or if you like,
[a\]\ \[b]
Well, I hope that by now it is obvious why I didn't add this operator to begin with. Since it can always be added externally in the context of the client code, I simply decided to let her/him do that, using whatever format suits in that context. But I suppose I could provide *some* IO even if imperfect. I see 2 distinct purposes for operator << One is to provide a readable output, the other some form of serialization. Given that we have the serialization library, I believe it is (or has to be) its job to provide a suitable encoding scheme to fully "textualize" and "parse" an optional<T>. Specially since to parse it back you may also need to encode the type. If I would only focus on providing a readable output, I would take Peter's suggestion and simply use "_" or some such as a textual empty optional<>. However, this totally breaks any chance to parse it. Ryan's suggestion supports parsing, and so does Joel's, which is much terser, so I like it better. But I agree with David that his suggested format is even less ambiguous. Therefore, so far, I'm taking Joel's + David's proposal: It supports some form of simple parsing (if you know the type) and provides a somewhat readable output as well. [<text>] A non-empty optional<T> with value: lexical_cast<T>(<text>) <text> can be an empty string _ An empty optional<T> Best, Fernando Cacciola