[webkit-dev] NeverNull<T>

[Jeremy Orlow]

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...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090728/0124ff7e/attachment.html>