Hello SaferCPP enthusiasts,
I'm finding it challenging to use the protectedX()-> pattern, especially when
fixing failures mechanically.
You need to examine a lot of context to decide if RefPtr<X> protectedX() {
return x; } can be defined inline in the header or if X is forward-declared. If
X is forward-declared you need to analyze the potential performance cost of an
out-of-line function call. Very tricky to do when we care about 0.25% with 98%
confidence! Or analyze if you could #include X.h without ballooning build times
or causing a circular dependency or causing some kind of verification failure I
still don’t understand on an Apple-internal bot. Very tricky to do across 9MM
lines of code and many platforms!
You need to examine a lot of context to decide if there are enough uses of x to
justify making a protectedX() helper. This can change forwards and backwards as
you edit code.
In our guidelines we say that we use this idiom to avoid declaring a local
variable unnecessarily.
Here are two alternatives to consider, which provide the same benefit:
* Use Ref { x }->
* Use x()->protected()->
I prefer Ref { x }-> because
* it does not require a local variable
* it tells my plainly what is happening
But if consensus favors x()->protected()->, I think that solves my problem too.
What do you think?
Thanks,
Geoff
_______________________________________________
webkit-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
