On 09/04/2013 08:59 AM, Trevor Saunders wrote:
On Wed, Sep 04, 2013 at 10:32:17AM +0200, Richard Biener wrote:
On Wed, Sep 4, 2013 at 5:16 AM, <tsaund...@mozilla.com> wrote:
From: Trevor Saunders <tsaund...@mozilla.com>
bootstrapped on x86_64-unknown-linux-gnu with same test results as unpatched
r202185 ok?
That looks like a not too useful part-C++-ification of domwalk. A proper
C++-ification would include the use of functors and possibly templating it
on the user specific data type.
It's true this patch isn't that aggressive, I was thinking about going
farther incrementally. I also haven't quiet convinced my self inlining
all of domwalk.c or adding a whole bunch of explicit template
instantiations to domwalk.c was really a good idea. Are you saying you
believe the removal of the indirect calls is worth the extra code size?
So, what do you think is the advantage (other than dropping two or three lines
of code in the users)?
I'd say its the same as for all other raii things, you don't have to be
sure to free data when you're done with it, and imho reducing boiler
plate is a fairly good thing on its own.
More importantly, I think converting the walker to a C++ object with
methods ought to be rather straightforward. The state each optimizer
attaches to the walker naturally falls into a derived class.
I wouldn't go down templatizing it without a proof of concept which
shows there's a performance improvement.
RAII is a good model for things like handling mutexes and simple
allocation issues.
Jeff
