I am writing some generic code and would like to handle "all values" the same way; however, I keep running into the problem of return void return types that need "special treatment". There is nothing I can do about it most of the time except template specialization. That said, it would be helpful if boost::optional<void> could have some sensible default implementation where it acts more or less like a boolean. As it is, I will probably provide my own specialization of boost::optional to simplify my templates. Any thoughts on this? Dan
I feel that boost::optional has no sensible implementation for optional<void>, since there's absolutely nothing optional when returning void; When the function returns (if no exception is thrown, of course), the 'void value' is returned. Therefore, optional<void> can't be a boolean as it only has one possible 'value' which always exists. Having said that, I can see that such implementation would ease things on your end. However, I can't see a way to incorporate it into the existing boost::optional. I'll be happy to hear (read) more opinions, though. On Mon, Mar 1, 2010 at 9:00 AM, Daniel Larimer <dlarimer@gmail.com> wrote:
I am writing some generic code and would like to handle "all values" the same way; however, I keep running into the problem of return void return types that need "special treatment". There is nothing I can do about it most of the time except template specialization.
That said, it would be helpful if boost::optional<void> could have some sensible default implementation where it acts more or less like a boolean. As it is, I will probably provide my own specialization of boost::optional to simplify my templates.
Any thoughts on this?
Dan _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Roman Kecher ... .. . http://cplusplus.co.il
Daniel Larimer skrev:
I am writing some generic code and would like to handle "all values" the same way; however, I keep running into the problem of return void return types that need "special treatment". There is nothing I can do about it most of the time except template specialization.
That said, it would be helpful if boost::optional<void> could have some sensible default implementation where it acts more or less like a boolean. As it is, I will probably provide my own specialization of boost::optional to simplify my templates.
Any thoughts on this?
Could you give some concrete examples of your problems? Otherwise it's hard to comment. -Thorsten
On Mar 1, 2010, at 5:24 AM, Thorsten Ottosen wrote:
Daniel Larimer skrev:
I am writing some generic code and would like to handle "all values" the same way; however, I keep running into the problem of return void return types that need "special treatment". There is nothing I can do about it most of the time except template specialization. That said, it would be helpful if boost::optional<void> could have some sensible default implementation where it acts more or less like a boolean. As it is, I will probably provide my own specialization of boost::optional to simplify my templates. Any thoughts on this?
Could you give some concrete examples of your problems? Otherwise it's hard to comment.
template<typename ReturnType, TypeName A1, ... > boost::optional<ReturnType> some_templated_method( A1 a1, ... ) { if( .... ) return a1 + ... else return boost::optional<ReturnType>() } The above template works for all functions up to N parameters but not for void functions. In my situation I have an active objects implementation where a "void" return value signifies "operation completed" so where as sequential code can take "operation complete" for granted, async code cannot. In my particular case, I was using a boost::optional to store the "future" value of the async operation, but had to duplicate and "tweak" several classes for the "void" case. The question is, does issuing a compile error on "sizeof(void)" make more sense than having an optional<void> which will work "properly" for everything except "cast to reference" and "cast to value"? Essentially, let there be compile errors about those methods missing if someone tries to use them, but other methods that return a pointer to T can return a NULL void* without issue. If you think about how optional<T> is implemented, a bool followed by sizeof(T) bytes, then if follows that a optional<void> would be a bool followed by 0 bytes.
-Thorsten _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 03/01/10 08:21, Daniel Larimer wrote:
On Mar 1, 2010, at 5:24 AM, Thorsten Ottosen wrote:
Daniel Larimer skrev:
I am writing some generic code and would like to handle "all values" the same way; however, I keep running into the problem of return void return types that need "special treatment". There is nothing I can do about it most of the time except template specialization. That said, it would be helpful if boost::optional<void> could have some sensible default implementation where it acts more or less like a boolean. As it is, I will probably provide my own specialization of boost::optional to simplify my templates. Any thoughts on this?
Could you give some concrete examples of your problems? Otherwise it's hard to comment.
template<typename ReturnType, TypeName A1, ... > boost::optional<ReturnType> some_templated_method( A1 a1, ... ) { if( .... ) return a1 + ... else return boost::optional<ReturnType>() }
The above template works for all functions up to N parameters but not for void functions. In my situation I have an active objects implementation where a "void" return value signifies "operation completed" so where as sequential code can take "operation complete" for granted, async code cannot. In my particular case, I was using a boost::optional to store the "future" value of the async operation, but had to duplicate and "tweak" several classes for the "void" case.
The question is, does issuing a compile error on "sizeof(void)" make more sense than having an optional<void> which will work "properly" for everything except "cast to reference" and "cast to value"? Essentially, let there be compile errors about those methods missing if someone tries to use them, but other methods that return a pointer to T can return a NULL void* without issue.
If you think about how optional<T> is implemented, a bool followed by sizeof(T) bytes, then if follows that a optional<void> would be a bool followed by 0 bytes.
You might be interested in the composite_tagged_seq.zip here: http://www.boostpro.com/vault/index.php?&directory=Data%20Structures Has a template composite_components::special_type<special_id Id>, here Id is one of {nothing_id,empty_id}. When used as one of the types in TypeSeq ofcomposite_tagged_seq<one_of,,TypeSeq>, the storage occupied is 0 bytes. composite_tagged_seq<one_of,,> is a tagged variant. The special_type<nothing_id> is used to indicate an invalid variant. This could be used to represent optional where the bool part indicates "uninitialized" (see: http://www.boost.org/doc/libs/1_42_0/libs/optional/doc/html/boost_optional/d... ). A later version of composite_tagged_seq on my local disk even allows specification of void in TypeSeq. In that case, using the project function results in a compile-time error. -regards, Larry
participants (4)
-
Daniel Larimer -
Larry Evans -
Roman Kecher -
Thorsten Ottosen