#140 closed enhancement (fixed)
Pass strings as "const std::string &" not "std::string"
Reported by: | Olly Betts | Owned by: | Olly Betts |
---|---|---|---|
Priority: | lowest | Milestone: | 1.0.13 |
Component: | Other | Version: | SVN trunk |
Severity: | minor | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Operating System: | All |
Description (last modified by )
Most modern compilers seem to implement std::string using PIMPL, so the class is just a single pointer and pass-by-value may be more efficient.
MSVC is the notable exception I'm currently aware of. Macro magic is one possible solution. Or perhaps benchmarking will reveal moving helps non-MSVC without penalising MSVC much.
Either way, most of the library passes by const ref, but some of the internals pass by value, and we should standardise!
Change History (9)
comment:1 by , 18 years ago
Blocking: | 120 added |
---|
comment:2 by , 17 years ago
Blocking: | 160 added; 120 removed |
---|---|
Operating System: | → All |
comment:4 by , 17 years ago
Description: | modified (diff) |
---|---|
Milestone: | → 1.1 |
comment:5 by , 17 years ago
Blocking: | 160 removed |
---|
comment:6 by , 16 years ago
Milestone: | 1.1.0 → 1.1.1 |
---|
If this lead to changes, we'd still be API compatible so bumping to 1.1.1.
comment:7 by , 16 years ago
Milestone: | 1.1.1 → 1.1.7 |
---|
comment:8 by , 16 years ago
Milestone: | 1.1.7 → 1.1.1 |
---|---|
Owner: | changed from | to
Status: | new → assigned |
Summary: | Benchmark if passing "const std::string &" or just "std::string" is better → Pass strings as "const std::string &" not "std::string" |
OK, I've just microbenchmarked this for GCC 4.3.3 on x86-64 Ubuntu jaunty and const std::string &
parameters are a little faster than std::string
ones. Also, looking at the generated assembler shows it's more compact too!
So this bug can become "fix passing std::string by value to pass by const ref instead".
Marking for 1.1.1, as I don't think there are many of these and they should be grep-able.
We're certainly not going to change the internals of 1.0.x in such a sweeping way at this point, but it would be worth benchmarking this before 1.1.0 if we can.