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