On Tue, Jul 28, 2009 at 9:53 PM, Roland Steiner <rolandstei...@google.com>wrote:
> > I definitely like the general idea, but I don't think a NeverNull template > is worth it in the general case, for the following reasons: > > First, I don't hink you can catch even a meaningful subset of all cases of > NULL assignment at compile time. OTOH, writing a template class that wraps a > non-null pointer has its use mainly in order to annotate header files, and > to "auto-insert" the ASSERT. In cpp files it's just a cosmetic difference to > ASSERTs, and enforcing the use throughout would probably change far too much > code, and run into other cumbersome details in addition to the ones I > mention below. > > OTOH in order to be consequent, one would also need to use NeverNull<X> in > return values, e.g., > > NeverNull<foo> bar() const; > > Implementing such a function would have to be conscious of the fact that a > NeverNull<X> must always be initialized. i.e., you cannot write > > NeverNull<foo> Baz::bar() const > { > NeverNull<foo> returnValue; > ... compute returnValue ... > return returnValue; > } > Couldn't you just create a "const foo&" constructor and a "(foo)" operator in your NeverNull template class to get around this? The constructor would have an ASSERT to check that the value is not NULL, so (in theory) it'd just be a dumb wrapper in release mode. It's _possible_ modern day compilers would be smart enough to handle this. That said, I think the only way to talk inteligently about the performance implications is for someone to try it out on some popular code paths.
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev