Re: [boost] [optional] generates unnessesary code for trivial types

Subject: Re: [boost] [optional] generates unnessesary code for trivial types
From: Domagoj Saric (domagoj.saric_at_[hidden])
Date: 2012-01-27 11:29:51

On 26.1.2012. 0:20, Simonson, Lucanus J wrote:
> 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 opt
>   ional 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 see no reason why we can't have safe _and_ fast _and_ optional?

The rationale you gave is just typical premature pessimization apologetics that 
also somehow assumes that C++ is "safe and slow" and that you have to go "bare 
metal C" to have performance. Luckily that's just plain incorrect, to put it 
mildly. Sadly, that rationale nonetheless also too often gives us such bloatware 
as std::streams, lexical_cast or boost::filesystem...

When you design a such a generic library how can there be "premature optimization"?

-- 
"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