Re: Speed of passing a string by value vs. const reference
On 6/3/2013 4:46 PM, James Kanze wrote:
The only involved party I see is implementer of the function.
And anyone who has to include the header.
When I'm client of the function and look at the sig, I'm interested in
the nature of params. It it's pure input param, I could not care less if
it is by val or const&.
Those not using sig annotations can do the same using old-fashioned
comment at the implementation site.
Maitainance-wise I fail to see the difference using either approach.
Maintainance-wise, you're proposing that the signature of a
function depend on its internal implementation. And you don't
see a difference there?
I meant /significant/ difference. Just because there is no artificial
restriction to do everything in a single way where multiple ways are
usable it does not imply an overall overhead. At least I didn't notice it.
Especially considering it a rare case that fits the 'don't sweat over
the small stuff' category.
The "don't sweat over the small stuff" is one of the worse
cliches to be proposed. Writing correct programs is all about
paying attention to detail: the small stuff.
Those are not the same concepts. "Small stuff" is CN Parkinson's bike
shed. The thing that is 0.01% of your monetary budget but is happy to
swallow weeks in discussion.
The alternatives we discuss are both correct. That is the detail we must
care about. Choosing one over other will not alter correctness.
Herb's early work
explaining the ins and outs of exceptions is fundamental, but a
lot of his later stuff recommends more anti-patterns than
anything else: "use auto whenever possible"
Well, possibly there are different interpretations of "wherever
possible". And I do use auto in most contexts possible. Finally. It
always bugged me that I must break DRY SPOT in order to fix common
sub-expressions. The occasions where I want to put in the type are just
very very rare. And where in existing code it differns from auto, I
bet over 90% to be error or unintentional.
And where I mean to fix the type I just do that. it does not match the
"wherever possible" case. I see that you might interpret it in a pure
technical way. I do not. Where fixed type is part of the requirement,
coding idea, etc, there it is is not possible to substitute with a joker.
(and skip all of the advantages of C++ type checking),
The checks work fine where the expression is used. Where repeating the
type, well or badly it is not a service.
>"always use standard smart pointers"
I missed that advice -- what was the context? Instead of what? It's
probably good idea these days replace boost::shared_ptr to std:: one.
(Just a wild bet, I'm not using either currently or in the past, but for
And unique_ptr finally makes sense for many use cases.
I have no plans to part with my auto_ptrNC and auto_ptrDC (no-copy and
deep-copy versions with same reset/release/get interface and simple
policy) as long as std:: has nothing to offer in the slot, but if that
happened I'd be glad to switch over eventually, and use std:: for new code.
(std::shared_ptr only works if *all* pointers to an
object are shared_ptr. Including 'this'. In the rare cases
where a reference counted pointer is useful, there are better
solutions than std::shared_ptr).
You don;t have to convince me about right tool for the right thing.
"Don't sweat the small stuff"
is another example of an anti-pattern: the real rule would be
more along the lines of "don't ignore any detail, no matter how
You completely misrepresent that one. It's one of the oldest wisdom of
resource allocation to put your effort where it produce the most effect
(one parallel of the 20/80 rule). I'm lazy to fetch the book, but in
Coding Standards where the idea is introduced in item 0 there is a list
and explanation that makes perfect sense.
The detail that fits here is not ignored as being unseen, but refused
the fuss around, being evaluated as insignificant.
And just to avoid misunderstanding: if you have an installed policy that
input params are mandatory to be const&, have it enforced over the code
base and beaten in the culture -- I certainly would not go against it.
It's a working and consistent system. And breaking existing uniformity
is a step downwards.
But if the codebase is diverse to start with or uses guide like I
(hopefully) said earlier, again I would not bother to force it to a