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.
> * 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
> 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
If not, could we at least entertain the idea of secondary class:
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 );
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.?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk