Re: [boost] boost::optional<void>

Subject: Re: [boost] boost::optional<void>
From: Larry Evans (cppljevans_at_[hidden])
Date: 2010-03-01 12:11:19

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/development.html

).

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