From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2005-03-09 14:51:29
"David Abrahams" <dave_at_[hidden]> escribió en el mensaje
> "Peter Dimov" <pdimov_at_[hidden]> 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
>> A string can never be output "correctly", no matter what the delimiters
>> ("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
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
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.
A non-empty optional<T> with value: lexical_cast<T>(<text>)
<text> can be an empty string
An empty optional<T>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk