[boost] When is an optimization justified. Was Re: [review] The review of Boost.DoubleEnded starts today: September 21 - September 30

Subject: [boost] When is an optimization justified. Was Re: [review] The review of Boost.DoubleEnded starts today: September 21 - September 30
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2017-09-28 17:55:32

Den 26-09-2017 kl. 23:43 skrev Joaquin M López Muñoz via Boost:

> Hi, this is my review of Boost.DoubleEnded.

[snip]

> * The main characteristics of both containers are obscured by many 
> "extras" that feel
> insufficiently justified to me or even detrimental (I'll discuss in more 
> detail below), so my
> vote is for this fat to be removed prior to acceptance in Boost. I can 
> see much work
> and love have gone into adding this many niceties, and the author could 
> understansably
> resist to simplification, but libraries, in my opinion, should start 
> with a minimal and
> well grounded design and add more stuff as demand proves their need.

Joaquin & others,

Since many of the reviewers have had strong opinions about safety and 
optimizations, I think we need to establish when it makes sense.

As an example, consider this made up story. Assume that boost was around 
in 1992 and then Stepanov came around and wanted his new STL library to 
be reviewed by Boost. Boost members anno 1992 would immediately see that 
his vector had an unsafe operator[](size_t) which did not throw, but had 
a precondition, when violated, would lead to UB. Why would you want to 
save one branch or generate slightly smaller code? The reviewers then 
demanded that operator[](size_t) was removed from vector.

So ... have we as a community lost the strive for zero penalty, code 
that doesn't throw, code that may be well-received in constrained 
environments?

If not, could we at least entertain the idea of secondary class:

   devector<T> devec;
   ...
   devector_access<T> devec_access( devec );
   // a non-copyable class that stores reference to devector<T>
   devec_access.nongrowing_push_back( x );
   devec_access.uninitialized_resize( k );
   // etc

So whenever you have to do something a bit out of the ordinary, you do 
it via devector_access. That type is then in seperate header and 
documented under advanced usage.?

-Thorsten