Re: [boost] [optional] std::tr2::optional
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.
I managed to come up with the following interface for initializing and un-initializing. My goal was also to not introduce in-place factories. template< typename... Args > optional( tr2::in_place_t, Args &&... args ) noexcept( noexcept(T{std::forward<Args>(args)...}) ) the first parameter is a /tag/, much like std::piecewise_construct for pairs. We use it like this: tr2::optional<W> { tr2::in_place, i, str, 1, &g }; The tag indicates that we request an 'in place' initialization of W with remaining arguments.Next functions are more natural: template< typename... Args > void initialize( Args &&... args ) noexcept( noexcept(T{std::forward<Args>(args)...}) ) // for deferred initialization. void uninitialize() noexcept // so that it spells similar to 'initialize' bool is_initialized() const noexcept // as in boost Regards, &rzej
On 21.11.2011, at 18:24, 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(); } };
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.
I managed to come up with the following interface for initializing and un-initializing. My goal was also to not introduce in-place factories.
Initialize sounds slightly wrong. I like the notion of optional as something like a single-element container, which would lead to the names emplace() for in-place construction, clear() for resetting to the none-state, and empty() as the test function. (Maybe with a positive filled() too.) Sebastian
On Monday, November 21, 2011 19:36:20 Sebastian Redl wrote:
I managed to come up with the following interface for initializing and un-initializing. My goal was also to not introduce in-place factories.
Initialize sounds slightly wrong. I like the notion of optional as something like a single-element container, which would lead to the names emplace() for in-place construction, clear() for resetting to the none-state, and empty() as the test function. (Maybe with a positive filled() too.)
+1. I like emplace very much.
participants (3)
-
Andrey Semashev -
Andrzej Krzemienski -
Sebastian Redl