On Sat, Jan 22, 2011 at 12:19 AM, Peter Dimov <pdimov@pdimov.com> wrote:
Dean Michael Berris wrote:
1. The overhead of maintaining that table of reference counts may be significant if you have a lot of strings created in your application.
No table is needed; the reference count is just placed before the string data in the allocated memory.
Interesting. That can work, although you'll run into all sorts of load/store issues and alignment requirements. Of course much like anything that needs to be shared across threads too, so it's not that bad.
3. The reference count almost always will be implemented with atomic counters to be efficient. In cases where the hardware doesn't support these (in embedded environments)
...
Copying the string requires a memory allocation, which also grabs a lock. You're not likely to have a lock-free allocator if you don't have atomic operations.
Yeah, I agree. So never mind that limitation, it's going to be a limitation anyway with anything that has to be synchronized. :)
2. In the case that you do have strings copied around, consider the case in multi-threaded applications where you have different threads running on different cores.
Copying the string data outweighs the reference count update because of the allocation.
Right. So I guess I can be convinced that ref counting in strings would be just fine. I can't wait to get that so that I can make cpp-netlib just use these smart strings throughout. :D -- Dean Michael Berris about.me/deanberris