Re: [boost] [optional] std::tr2::optional
* Use nullptr instead of boost::none? - this will make some uses of optional pointers harder, but will make usage more clear in other cases.
I don't think nullptr is a good choice here because of the complications you mentioned. Actually, I would prefer traditional clear() and empty() methods for clearing and testing for value presence. The operator safe_bool() and operator!() may also be present in the interface for brevity in conditional expressions.
Interesting. It looks like optional can be seen as a special container with the maximum size of 1, and then functions like clear() or empty() come as natural. On the other hand it can be seen as a pointer-like entity with value semantics, and then functions like reset() and literal nullptr come as natural. I withdraw my suggestion to use nullptr. Function reset() would be a better choice. I also find reset() preferable to clear() because reset can be extended to accept parameters and the name does not become confusing; similarly to unique_ptr::reset(). Also, if someone likes the assignment-of-"none" syntax, in C++11 there will be a similar syntax available: std::tr2::optional<T> op = {}; op = {}; Interestingly, boost::optional did have a reset function (now deprecated) which was replaced with boost::none assignment. I wonder what was the reason for this replacement. Regards, &rzej
On Saturday, November 19, 2011 18:26:25 Andrzej Krzemienski wrote:
Also, if someone likes the assignment-of-"none" syntax, in C++11 there will be a similar syntax available:
std::tr2::optional<T> op = {}; op = {};
Wouldn't that be confusing with creating a filled optional with the value constructed with empty initialization list? If there is assignment-of-none syntax, it should probably be more explicit, pretty much like the current "none" keyword.
On Saturday, November 19, 2011 18:26:25 Andrzej Krzemienski wrote:
Interesting. It looks like optional can be seen as a special container with the maximum size of 1, and then functions like clear() or empty() come as natural. On the other hand it can be seen as a pointer-like entity with value semantics, and then functions like reset() and literal nullptr come as natural.
Ok, I have no strong preference between reset() or clear() for making the optional empty. However, a explicit empty() member would be useful anyway. class MyClass { optional< int > m_x; public: bool has_x() const { return !m_x.empty(); } }; With the current interface I should have written has_x() in a more obscure way, like !!m_x or m_x.get_ptr() != NULL.
I withdraw my suggestion to use nullptr. Function reset() would be a better choice. I also find reset() preferable to clear() because reset can be extended to accept parameters and the name does not become confusing; similarly to unique_ptr::reset().
I think, providing the reset() member with construction semantic is not a good idea because it would make imposible in-place default construction. There should be another method that would handle construction. In another post I suggested assign() but I'm happy if someone comes up with a better name.
participants (2)
-
Andrey Semashev -
Andrzej Krzemienski