Decorate a char* and char const* by pointer acquisition : good practice?

Question

Hello I wanted to poll the public about my idea of doing a string class (like std::string) that would have a feature of being able to work on buffers provided by the client.

What are the dangers that you forsee ? is it a classic smell ? etcaetera

I mean like so:

char ext[64] = {0};
my::string s(ext, my::string::acquire_RW);
size_t len = s.size();
size_t pos = s.find("zboub");
my::string s2(s);   // uses true (alloc+)copy semantic here.

So I forsee 2 strategies: acquire_RW and acquire_RO that would permit modification of characters in ext or not. And in the RO case for any non-const method, and RW cases in methods where buffer has to be expanded; it would alloc & copy at this moment only.

In a way, the my::string type becomes a decorator of the char* type.

Of course being careful of not freeing the external buffer before the decorator is left as a requirement to the client.

Thanks for sharing your concerns

Answer 1

The answer to 'good practice' is difficult. I would say, in general not good practice, but for some specific use cases very good practice. It all depends how well you can trust the client on the lifetime of the provided memory. In general: No trust. In special cases: OK.

There is one rather important thing to consider performance wise:

Do you plan to use implicit sharing (with copy on write and reference counting) of your allocated variants of your strings? Or do you plan to use value semantics (always copy, never reference)?

In multiprocessor and multithreaded environments value semantics are the preferred way for strings. The performance gain by using implicit sharing is destroyed by the necessary locking in multithreaded environments.

Note that your suggestion may still makes sense even when multithreaded: You can perfectly use copy-on-write when going from your external memory to the allocated variant (no locking necessary), and value semantics from then on (also no locking necessary). This would be best.

I would imagine your variant works well in very specific use cases where for example you memory-mapped some file with lots of strings and you do not want to store copies of these small strings and fragment memory.

However, in the general case I would not worry and just use std::string.

Answer 2

I think it's a great idea, but I would stick to read only; std::string is perfectly good for RW, unless of course there is a situation where you can save some memory allocation.

This is quite an optimisation though, so it may not be worth the effort, unless you know your static strings are causing you problems.