Re: [boost] [optional] generates unnessesary code for trivial types
On Tuesday, February 07, 2012 17:00:04 Andrey Semashev wrote:
Do I understand it correctly that optional_with_traits is an advanced replacement for optional? If so, will the good old optional be optimized? No, optional will be ("isA") optional_with_traits. It's just a work around. I'd prefer to redefine optional: template<typename T, typename Traits=optional_traits<T> > class optional;
That might in rare cases it could break user code like: mpl::quote1<optional> Personaly I doubt that this is such an issue, but have the best of both worlds I can define a temporary "optional_with_traits" which when boost goes to 2.0 we could deprecate and add the parameter to optional. template<typename T, typename Traits=optional_traits<T> > class optional_with_traits; template<typename T> class optional : public optional_with_traits<T> {...}; Do we gurantee boost users that templates will never add default parameters?
BTW, I would really like to see optional< T& > optimized to store T* internally. I'm going to say something provacative here. I agree with Lucanus. I see no reason for optional<T&>. As far I can tell you could use a T*. The only justification I can think of is on system without memory protection you can build checks into operator*().
Maybe if you're mixing code with old libraries where T* might imply ownership you might use optional<T&> to imply no ownership and some temporary validity. Perhaps we should define a new "smart pointer" called dumb_ptr<T> which can't be assigned into auto_ptr,unique_ptr,shared_ptr, or any pointer type which implies ownership. Maybe I'm missing something, but I don't see the justification. Chris
On Wednesday, February 08, 2012 19:05:26 Hite, Christopher wrote:
Do we gurantee boost users that templates will never add default parameters?
This would be a breaking change, so yes, such a change should be avoided if possible. Personnally, I didn't grasp the benefit of using these traits to justify the breakage. What will be traits used for, what will it provide?
BTW, I would really like to see optional< T& > optimized to store T* internally.
I'm going to say something provacative here. I agree with Lucanus. I see no reason for optional<T&>. As far I can tell you could use a T*. The only justification I can think of is on system without memory protection you can build checks into operator*().
Maybe I'm missing something, but I don't see the justification.
optional< T& > is a useful thing when you want to apply operators (such as relation operators or streaming) to the referred value. In generic code you don't have to specialize for pointers to do the right thing. I'm going to use this property in my Boost.Log library.
On 8 February 2012 17:18, Andrey Semashev <andrey.semashev@gmail.com> wrote:
optional< T& > is a useful thing when you want to apply operators (such as relation operators or streaming) to the referred value. In generic code you don't have to specialize for pointers to do the right thing.
+1 here. Please keep the interfaces the same, unless you have a *very* compelling reason not to. (Unless, of course, you are one of those who *likes* vector<bool>... :-)) -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
Den 09-02-2012 09:59, Nevin Liber skrev:
On 8 February 2012 17:18, Andrey Semashev<andrey.semashev@gmail.com> wrote:
optional< T& > is a useful thing when you want to apply operators (such as relation operators or streaming) to the referred value. In generic code you don't have to specialize for pointers to do the right thing.
+1 here. Please keep the interfaces the same, unless you have a *very* compelling reason not to.
+1. optional<T*> cannot optimize the bool away, because it can be null. So optional<T&> is both more efficeint and more handy. -Thorsten
On 8.2.2012. 19:05, Hite, Christopher wrote:
On Tuesday, February 07, 2012 17:00:04 Andrey Semashev wrote:
BTW, I would really like to see optional< T& > optimized to store T* internally. I'm going to say something provacative here. I agree with Lucanus. I see no reason for optional<T&>. As far I can tell you could use a T*. The only justification I can think of is on system without memory protection you can build checks into operator*().
Maybe if you're mixing code with old libraries where T* might imply ownership you might use optional<T&> to imply no ownership and some temporary validity.
Perhaps we should define a new "smart pointer" called dumb_ptr<T> which can't be assigned into auto_ptr,unique_ptr,shared_ptr, or any pointer type which implies ownership.
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 b) creating special cases (e.g. for T&) creates special problems in generic code -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman
participants (5)
-
Andrey Semashev -
Domagoj Saric -
Hite, Christopher -
Nevin Liber -
Thorsten Ottosen