Subject: Re: [boost] [optional] generates unnessesary code for trivial types
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-01-26 13:23:17
Le 26/01/12 00:20, Simonson, Lucanus J a écrit :
> I don't personally think that the style of programming that optional is intended for is suitable for high performance/performance critical situations in the first place. Pass by reference and return a bool for a conditional return value. Pass the bool and the object separately for a conditional argument. Pass or return a pointer and check if it is null. Yes, my advice really is to not use optional if you want performance. Even if we did everything you can think of to make optional fast you are still better off designing your interfaces in such a way that you don't need it if your goal is performance. That copy that you are counting branches in is probably unnecessary in the first place. Safety, on the other hand, is also important. All this looking at assembly code generated by optional smacks of premature optimization. If you agree with the idea that optional is valuable because of safety considerations then write your application using optional and not worrying muc
> h about performance and get the functionality right then measure your performance and optimize the places where it matters by stripping out usage of optional or whatever else is slowing you down so you get safety most of the time (with most of the benefit) and performance where you actually need it. Life is about tradeoffs. Optional will never be perfect.
> I find that it is quite easy to write safe C++ interfaces without using optional, so I see no reason why you can't design code that is both safe and fast without it.
> I know the author of optional and you haven't convinced me that we should bother him.
the user can not always redesign an interface using optional<T> as he
could be not the owner (use of 3pp libraries).
I'm sure the author/maintainer of optional would adopt some patches if
it is probed a performance improvement for some specific cases.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk