On 03-10-2013 22:01, Matt Calabrese wrote:
On Thu, Oct 3, 2013 at 8:59 AM, Thorsten Ottosen < thorsten.ottosen@dezide.com> wrote:
I can't create a broken std::vector by means of the constructor. At least I don't know how to. WhenI think about it, std::string can crash if you pass it null_ptr. Has anybody profitted from that? It leads to subtle run-time bugs, and I ran into that a few months back.
I think it's just clear that we have some ideological differences here. std::string should not be checking for null as a part of its documented functionality.
I think you misunderstood. The std::string constructor that takes a const char* cannot be passed NULL. Then add the fact that the string constructors are not explicit. Then add overloads into the mix, some with string, some with ints. I'm not a big fan of defensive programming, but the world of programming is complicated, and sometimes it makes sense to be a little defensive.
You forget that some people prefer to provide a nice log message and warn the users in a nice way instead of crashing the program.
If it's decided that that is what's important, then that's fine.
I guess it is important to some, and not to others. The thing is, even with 100% test coverage, we can't guarantee that some code won't contain an invalid non_null_shared_ptr at runtime at a customer. Yes, there is a bug in one part of the program, but it certainly matter for us that we don't have to take down the whole program, but can continue gracefully. -Thorsten