rolandsteiner at google.com
Tue Jul 28 21:53:34 PDT 2009
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
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
... compute returnValue ...
Similar cases may also arise in other cases, when initialization is
non-trivial. So either one must us a tailored implementation, or use plain
pointers for the main computation. Both are somewhat defeating the purpose,
since they cause additional overhead.
Second, I believe that even if NeverNull<X> is a POD class, such wrapping
classes tend to defeat some compiler optimizations that would be performed
on raw pointers otherwise, so I'd be surprised to not see any performance
degradations. Whether or not they are significant, I can't say.
On Wed, Jul 29, 2009 at 8:55 AM, Adam Barth <abarth at webkit.org> wrote:
> On Tue, Jul 28, 2009 at 4:29 PM, Jozwiak, John<jjozwiak at qualcomm.com>
> > Isn't the C++ "reference" annotation
> > char & x;
> > tantamount to declaration of a pointer
> > char * x;
> > to whom NULL assignment, as detectable at compile time, is a compile-time
> I'm not sure what you mean by "as detectable at compile time," but
> I've certainly fixed crashers that were caused by NULL references.
> Templates should give you stronger properties, although you might have
> to do some fancy footwork to make subtyping work correctly.
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev