On 04/15/2010 11:45 AM, Bruce Simpson wrote: > On 04/15/10 19:26, Ben Greear wrote: >> On 04/15/2010 09:10 AM, Bruce Simpson wrote: >>> On 04/15/10 07:48, Ben Greear wrote: >>>> ... >>>> I'm not too sure. It might be that horribly complex template >>>> thing that builds callbacks methods. If I were to tackle it, I'd >>>> probably change some callback signatures to pass in const string& >>>> and then see what broke and try to work backwards from there... >>>> >>> >>> Futzing with 'string' might be a noop, because many STL implementations >>> ref-count the internal string representation (GNU libstdc++ does, for >>> example). >> >> Yeah, looks like it wouldn't save much..but would still save a little, >> and should be cleaner code. > > I'm not sure what you mean by cleaner code here. > > It's difficult for me to assess this further without seeing sample code.
It's a personal preference..and it saves a small bit of stack space and ref-count increment/decrement. But, probably it's a small thing and not worth much worry, and certainly some time it's not at all convenient or useful to pass by reference. >> There might be other areas where we are passing stuff by value that >> could be const foo& as well..but I haven't looked hard. > Input arguments are generally passed by value (and constified) already. > Output arguments are passing values back to the glue wrapper which > invokes them. They are then responsible for output marshaling. As a > side-effect, they can't be const and remain references; they'd have to > become pointers. Ok, I haven't yet looked closely enough to understand the limitations of callbacks. > The usual practice for profiling code size changes, in static binary > footprint, is to use 'nm' and 'size' a lot. You can profile RSS at load > time using Exmap. If you're looking for a source to crib scripts from, > please see my posts on the Apache JIRA thrift-users list from around 4 > months ago. Thanks, Ben -- Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
