On 2013-08-23, at 09:50 , David Kastrup <d...@gnu.org> wrote: > Frédéric Bron <frederic.b...@m4x.org> writes: >> >> Of course I am not speaking of new strings created in the function! >> That would be stupid. But if you return a member of an object for >> example, it is stupid to return a copy of it (I do not know if this >> happens, however). > > Not every object is persistent. Again: references create life-time > issues. Messing with them, particularly in the case of a basic > conceptually scalar data structure like "string" only makes some remote > sense when there is positive proof that there is a serious performance > impact for known implementations.
Two choices have been mentioned. One is 1) void function(std::string); 2) void function(const std::string&); In my professional experience, we usually pass a structure by reference when it can't fit in a register. We always use (2) with strings that the function will not modify. We also pass smart pointers by const reference when the function will not create new references to the pointee. Dangers of premature optimization: * wasting your resources on something ineffective because you haven't measured * harming performance because you haven't measured * harming maintainability without an offsetting benefit Those don't apply. We know from experience that passing strings and smart pointers by value has been a problem. Passing by const reference improved performance and had little impact on maintainability. So, although it is true that most calls are not performance hot spots, this habit lets us spend our limited time worrying about other things. We don't want to be taught the same lesson many times. The other choice is 3) std::string getSomeMember() const; 4) const std::string& getSomeMember() const; Reasonable people might disagree, but IMHO this is premature optimization. It is better to use (3), trust the compiler to do return value optimization, and wait for profiling to prove that there is any problem. I share David's concern that (4) can lead to bugs, and as above, not having to worry about those details frees a contributor to focus on the goal. Regards, -- Dan _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
