On 2/2/2016 1:40 AM, Rob Stewart wrote:
What I am suggesting is that, perhaps, the std::vector people decided not to provide for uninitialized vector construction because a) they suspected that conditional initialization would be a small portion of all initializations and that the default empty state would be a fairly large portion, and/or possibly b) the compiler optimizer would deal with the redundancy in a significant portion of those conditional initializations, and/or c) the cost of the program being non-deterministic if a programming error slips by is unacceptably high.
Actually, vector would be quite dangerous to use without default initialization to establish its invariants. The same can't be said for an integer, though using the garbage value might be dangerous in some contexts.
Yeah, you're right. But how rare are those contexts? I mean it's not rare for an integer to be used as an index into an array. If you're saying that you agree with the decision to enforce mandatory default initialization of std::vectors, but uninitialized construction is ok for integers because the most catastrophic consequences would happen a lower percentage of the time, I dunno, it seems to me this argument is a judgement call that depends on how much lower that percentage is, and the magnitude of the real world benefits of foregoing default initialization. Maybe someone could do a sampling of code on github or whatever and actually measure those two factors, but until then I guess everybody has their own estimate of which factor outweighs the other. But I do want to point out the potentially high cost of not knowing if your code is deterministic. Consider some hypothetical online banking software written in C++. And let's say that a programmer accidentally forgot to set the value of an int before use, but just by luck the software behaved reliably in an acceptable manner on the tested and deployed environment. So after rigorous testing and a year or whatever of deployment, this software can be considered to be "well-tested" in it's deployed environment. But then let's say they want to upgrade their servers. Maybe with a different OS or OS version. Maybe the code is recompiled. When deployed on the new server environment, that uninitialized integer may get initialized to a different value (or range of values) and so you could not be so confident that it would continue to behave the same way. So it loses a lot of it's "well-tested" status. And that can be costly. So ideally what I would like is for boost to provide a set of types that when used in lieu of the regular C++ types, ensure that the code is deterministic. Or as deterministic as possible. Because being deterministic increases the value and effectiveness of testing.
Do you still prefer the single class with an extra constructor for "uninitialized construction" solution to the one I proposed?
It's hard to say. Adding a separate class or policy just to have the uninitialized case is heavy, but the overload may not apply to all specializations of the template.
Yeah, I'm not sure either. Separate classes does seem heavy. But at least it's compile-time heavy, not run-time. Anyway I wonder if this is all moot. Have you looked at all at the "safe numerics" library proposed in this newsgroup? The post from Jan 20 has links. That library seems use a template to generate classes of "safe" integers or whatever. registered_ptr should have no problem targeting those. I don't know how things work here, but it sounds like it's pretty far along the acceptance process. Interestingly, looking at the comments in their default constructor - constexpr explicit safe_base() { // this permits creating of invalid instances. This is inline // with C++ built-in but violates the premises of the whole library // choice are: // do nothing - violates premise of he library that all safe objects // are valid // initialize to valid value - violates C++ behavior of types. // add "initialized" flag. Preserves fixes the above, but doubles // "overhead" // still pending on this. } - it looks like they haven't decided on whether or not to do default initialization yet either :)