[SOLVED] const reference to QString
I have a general question concerning QString usage. I recently discovered that QString was part of the "implicit shared classes.":http://qt-project.org/doc/qt-4.8/shared.html@
With implicitly shared classes: " you can pass instances of these classes as arguments to functions by value without concern for the copying overhead." ("source":http://qt-project.org/doc/qt-4.8/implicit-sharing.html)
However, in Qt's API, generally methods take a QString const reference rather than a QString value. This is my question, why is this so? Also, if I write an API based on Qt, should I try to avoid a new level of indirection by taking a QString value in argument rather than a const ref to QString?
Thanks in advance,
Using the const reference method for arguments you explicitly state that the original value will not be altered and because reference method is sort of a pointer operation no copy will be made. When using the value method argument the QString will be copied when the original value is altered by the code. When the QString is not altered it will not be copied, so no difference to reference arguments.
Might be best to stick to one way of doing things, my preference is always to use const if applicable. This to avoid unwanted value changes at the calling position.
To add to Jeroentje@home's point: "const correctness":http://stackoverflow.com/questions/136880/sell-me-on-const-correctness improves the maintainability of your project.
Another minor thing to consider:
For large objects, copying an implicitly shared object is much much faster than copying a non-implicitly shared object.
However, passing a const reference is still a little bit faster than copying an implicitly shared object, because a reference counter (integer) needs to be updated when (i) a new copy is made, and (ii) when one of the copies is destroyed.
[quote author="JKSH" date="1383576039"]
However, passing a const reference is still a little bit faster than copying an implicitly shared object, because a reference counter (integer) needs to be updated when (i) a new copy is made, and (ii) when one of the copies is destroyed.[/quote]
It didn't occurred to me that the overhead of using implicitly shared classes, even tiny, was still superior to the usage of a const reference.
If you find the answers good enough, place [SOLVED] in front of your first post!
So, first use const reference instead of copy arguments
Second use implicitly shared classes if const reference is not possible
Done, sorry for not doing this before. And thank you both for the help again.
You're welcome :)
Actually, I just came across this discussion. It looks like C++11's rvalue references and move operations can provide even better performance than const references:
However, this requires extra low-level coding. I think it's worth taking the effort if you're creating a library, but not if you're creating an application (unless it's a heavy number-cruncher).