jorlow at chromium.org
Tue Jul 28 22:05:08 PDT 2009
On Tue, Jul 28, 2009 at 9:53 PM, Roland Steiner <rolandsteiner at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev