Re: [boost] [optional] generates unnessesary code for trivial types
From: Domagoj Saric <domagoj.saric@littleendian.com>
Maybe I'm missing something, but I don't see the justification.
IMO it seems that, yes, you are making the same mistake as Lucanus, thinking about "The Universe" only as/through your POV of your personal problem domain: a) (optional models optionally holding an object) + (objects can be held by value and by reference) = optional<T&> perfectly logical I'm really not. Give me a use case. Do they make sense being passed as parameters/returns? Do they make sense being stored?
I just see some corner case of optional being turned into a replacement for regular pointer. Why not just make dumb_ptr<T>? If you want you can make it streamable and give it clean construction. What is it you really want from optional<T&>? Does anyone use it a lot? Is it like std::vector<bool>?
b) creating special cases (e.g. for T&) creates special problems in generic code My point exactly. I'd make it work for completeness but not bother to optimize.
Chris
On 10 February 2012 05:16, Hite, Christopher <Christopher.Hite@partner.commerzbank.com> wrote:
b) creating special cases (e.g. for T&) creates special problems in generic code My point exactly. I'd make it work for completeness but not bother to optimize.
While my main concern is the interface, here are the reasons I'd like to see it optimized: 1. If the implementation needs to special case references anyway. 2. The optimization is really easy; it probably takes less time to implement and test it than any one of us has spent writing any of the emails in this chain to discuss it. 3. The question on this particular optimization shows up on the Boost mailing lists like clockwork. The only thing that will stop it is by implementing the optimization, and that in itself is doing Boost community at large a great service. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
On 2/10/2012 2:54 PM, Nevin Liber wrote:
On 10 February 2012 05:16, Hite, Christopher <Christopher.Hite@partner.commerzbank.com> wrote:
b) creating special cases (e.g. for T&) creates special problems in generic code My point exactly. I'd make it work for completeness but not bother to optimize.
While my main concern is the interface, here are the reasons I'd like to see it optimized:
1. If the implementation needs to special case references anyway. 2. The optimization is really easy; it probably takes less time to implement and test it than any one of us has spent writing any of the emails in this chain to discuss it. 3. The question on this particular optimization shows up on the Boost mailing lists like clockwork. The only thing that will stop it is by implementing the optimization, and that in itself is doing Boost community at large a great service.
Hi People, As the author of Boost.Optional I wanted to let you know that I am following the entire thread (as all other threads about the library) even if I don't join the debate. I concurr with Nevin that at least some of the optimizations presented are embarrasingly trivial to even worth any discussion. OTOH, this is not the only update that the library needs, so be patient. FYI I'm currently working closely with Andrzej Krzemienski on a std proposal which, among other things, involves the long awaited update to the Boost implementation. Best -- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com
On Friday, February 10, 2012 19:32:08 Fernando Cacciola wrote:
FYI I'm currently working closely with Andrzej Krzemienski on a std proposal which, among other things, involves the long awaited update to the Boost implementation.
I'm very glad to hear it!
Fernando Cacciola wrote: > OTOH, this is not the only update that the library needs, so be patient. I'd be willing to do the work. I may not have to since Domagoj Saric has done most of the work and I just need to convince him to ditch the pointer. > FYI I'm currently working closely with Andrzej Krzemienski on a std proposal which, among other things, involves the long awaited update to the Boost implementation. Could you give a use case for optional<T&>. When reading the doc about I completely understand the other use cases: * return types * parameters * locals * members * expensive unnecessary default construction We could be having the same conversation about optional<bool>. Here the documentation is clear: it works as expected but is the user probably should be using tri-state. We could optimize optional<bool> to store ~0 to indicate unset. I personally don't think it's worth doing that, since use case is questionable. As far as I can tell optional<T&> is a type which can be easily confused with optional<T>, but is really equivalent to T*. It also allows for debates about the meaning of reassignment. I'm not dead set against this optimization. I'm just wondering if anyone will really benefit and if it's worth adding a specialization + tests. Side question: is streamablity going to be in your proposal? Chris
On 13 February 2012 01:15, Hite, Christopher <Christopher.Hite@partner.commerzbank.com> wrote:
We could be having the same conversation about optional<bool>. Here the documentation is clear: it works as expected but is the user probably should be using tri-state.
Why? The poster child is database access, where every field can be set or unset, and every set field has a value. Why would anyone want to special case access to bool to use a different type?
We could optimize optional<bool> to store ~0 to indicate unset.
Could you elaborate? I don't see how, at least not without changing the interface, as a "dereferenced" optional<bool> has to return a reference to bool whose address cannot change. Please look at vector<bool> to see the trouble caused when people changed the generic interface for a specific type.
As far as I can tell optional<T&> is a type which can be easily confused with optional<T>, but is really equivalent to T*. It also allows for debates about the meaning of reassignment.
If there are debates about about the meaning of reassignment, then it really is NOT equivalent to T*.
I'm not dead set against this optimization. I'm just wondering if anyone will really benefit and if it's worth adding a specialization + tests.
Do you honestly think it is more work than was put into writing your email message (let alone all the future threads that will inevitably keep coming up)? -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
Nevin Liber wrote: On 13 February 2012 01:15, Hite, Christopher <Christopher.Hite@partner.commerzbank.com> wrote:
We could be having the same conversation about optional<bool>. Here the documentation is clear: it works as expected but is the user probably should be using tri-state.
Why? The poster child is database access, where every field can be set or unset, and every set field has a value. Why would anyone want to special case access to bool to use a different type? I get that use case. You're writing a DB wrapper and you've got optional strings,doubles,ints, and bool should work with the exact same semantics. Sure then use optional<bool>.
We could optimize optional<bool> to store ~0 to indicate unset.
Could you elaborate? I don't see how, at least not without changing the interface, as a "dereferenced" optional<bool> has to return a reference to bool whose address cannot change. Sure, you could implement it with 1 byte (or whatever sizeof(bool) is) and store ~0 to indicate unset. operator*() can return the address of the byte. This works because you should never call this if it is empty.
optional<bool> ob=true; bool& b =*ob; //fine b=false; // legal ob=none; //b is no longer a valid ref = same as any other T You should never set b to ~0, but that is bad form anyway and most compilers give warnings when assigning ints to bools lke that. Consider this: int i=256; bool b=i; //is b 0? Still I don't recommend doing strange things like this. However if someone came and said "my DB app stores tons of optional<bool> and it's burning twice the storage it needs", well I guess it couldn't hurt right?
If there are debates about about the meaning of reassignment, then it really is NOT equivalent to T*. You can convert a T* to and from optional<T&>. So in that sense they are equivalent. Syntactically they are very close except when being assigned.
Chris
participants (4)
-
Andrey Semashev -
Fernando Cacciola -
Hite, Christopher -
Nevin Liber