On 2/3/16 4:00 PM, Raphaël Londeix wrote:
Writing correct code is not considered a major problem by most programmers and organizations which depend on code. Code that works most of the time is considered good enough.
Well, good enough is perfect in most projects. However, I do like simple drop-in wrappers that prevent stupid mistakes to ever compile, or that abort on overflows.
About the construction topic, I think that a good compromise could be to choose a safe default (always initialize to 0) but to allow one to be explicitly unsafe:
safe<int> i; // i == 0 safe<int> j(boost::uninitialized); // undefined
It happens that the developer knows that initialization will be done later, or has already been done (mapped memory for example).
The problem with this is that the usage of safe<int> changes the meaning of the program. Example: one has the following program int i; // i not initialized .... // program has weird behavior in order to find the cause of the weird behavior someone makes the following change: safe<int> i; // i now initialized to 0 ... // program has no weird behavior This means that usage of safe<int> hides errors - which is even worse than before. I'm actually most inclined to require an initialization. In this case the attempted fix would safe<int> i; // compile time error ... // program doesn't compile so in order to use safe integer one is forced to be explicit and use safe<int> i = 0; // compile time error ... // program has no weird behavior Then someone says - take out the safe stuff - it's slowing things down! (true or untrue doesn't matter). So the fix would be: int i = 0; // compile time error ... // program has no weird behavior The only problem is that someone is going to say: "Wait - I don't need initialization! it's non-optimal". He might be right" but I doubt it matters. but safe integer isn't exactly equivalent to int any more it has different behavior - I hate it when this happens. So the best would be to include an initialization bit inside safe<int> uh-oh another howl. Robert Ramey