On Fri, Oct 14, 2011 at 10:48 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
2011/10/14 Ion Gaztañaga <igaztanaga@gmail.com>: but we currently have no
push_back preconditions for push_back, insert, etc. and this can be a great source of mistakes.
I agree. And unlike at() vs. operator[], in this case we are moving enforcement of the class invariants from the class itself the caller, just to save an "if" check.
That if check can be quite a difference after its called for the billionth time in an inner loop, though you address this just below. :-)
I really don't want to see a policy controlling this; rather, have unchecked_push_back and unchecked_insert for those who need every ounce of performance at the expense of safety.
I definitely see a lot of clarity in implementing it this way. I just wish there was a nicer name than unchecked_push_back. Policies could be both a blessing and a curse. It makes it extraordinarily easy to switch from checked to unchecked push back in a large code base without going through everything by hand. You can test your code with the checked policy, then turn it off to get the performance. On the other hand, maybe you should be going through all the code when you want to switch from checked to unchecked to make sure there are no dependencies on that policy that would become a bug.