Implicit sharing vs. c++ refereces

[karagog]

Code overhead ? You can write code that manages implicit shared data once, and then reuse it for most of your containers.

I don't mean you have to write code twice, I am talking about the space that this code occupies in the final executable. An executable that contains an implicitly shared QString is larger than one that contains a non-implicitly shared QString (intuitively this makes sense, because the implicitly shared QString has a more complex algorithm to manage the data).

What do you mean with memory overhead, a pointer to data and integer counter ?

Yes, admittedly it's a small overhead; almost not worth caring about. But my String class is only 12 bytes split between the stack and heap (pointer to begin, pointer to end, memory of the total capacity), and a QString must be at least 16 bytes (12 bytes for the pointer, length and capacity values, plus 4 bytes attached to the pointer for the reference counter. Does anyone have the actual size of a QString handy?) That's at least 33% larger than my class. Yeah, yeah, I know BFD it's a difference of 4 bytes! Plus at runtime with actual data in the container, the size of the container eclipses the size of the memory overhead. Like I said, almost not worth mentioning.

I failed to see a big runtime overhead either.

Runtime overhead is probably the biggest issue (although again it may be negligible for most applications). Incrementing and decrementing the reference counters upon construction, destruction or assignment is hardly an issue because it happens so seldom compared to all the other operations you carry out on a String. But you also have to count up every time you need check the reference counter, which is actually every time you change the data (need to check if there's another reference to the data somewhere, so it can detach). If you have a loop that iteratively assigns values to individual string elements, then this must check on each and every assignment that there is not another reference somewhere else. This is a runtime overhead that I don't deal with in my non-implicitly shared string class.

I guess more people will enjoy your code if its easy to use

They'll enjoy it also if it's faster and has a smaller code/memory footprint

I don't think there's an obvious "best" approach; I think it depends highly on the experience and skill of the developer and on the performance requirements of the application. It's nice to have implicitly shared objects if that makes coding easier for you, but if performance is critical I contend that c++ references are the way to go. And personally I find references easier to understand and follow, especially because with implicitly shared classes you have to think a lot harder about when the copy will actually happen (if you care when it happens).