Re: Will value semantics make C++ die?
On 06.09.2013 18:35, Jean-Marc Bourguet wrote:
Martin Ba <0xcdcdcdcd@gmx.at> writes:
On 04.09.2013 21:49, Jean-Marc Bourguet wrote:
Martin Ba <0xcdcdcdcd@gmx.at> writes:
... disengaged optional<T> is simply treated as an
additional and unique value of T equal only to itself;
this value is always compared as less than any
value of T ...
- seems awful.
If you look at optional<T> as an array of size 0 or 1, it makes
perfectly sense.
Actually, no. How does it compare to arrays? Please explain?
As all other containers, a lexicographic sort.
Note: I thought about optional<T> being a model of container<T> where
the container can at most store one element of T (or be empty). Did you
mean this by "array"? I don't see how current optional<T> models this?
AFAIK, it doesn't provide the required interface of containers. But it
is one of the mental model which has been used for design the interface
of optional<>.
I still don't get how what optional does at the moment with regard to
the (comparison) operators has got anything to do with what a 1-size
container would "naturally" provide.
Optional allows:
std::optional<...> theValue;
....
if( theValue < MAX_ALLOWED )
{
// ...
}
That is, it allows comparing the "container"-type to it's underlying type.
No container I know of does that.
std::vector<...> theValue;
....
assert(theValue.size() == 1);
if( theValue < MAX_ALLOWED ) { ...
.... that doesn't make any sense.
I feel it's a very unfortunate design decision that the (comparison)
operators try to save you the dereferencing.
It may have it's uses in some generic code, but it IMHO bad for all
other code.
Note: I'm fine with the contextual conversion to bool, I don't see much
harm in that.
cheers,
Martin
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]