4

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

v.oddou
  • 6,476
  • 3
  • 32
  • 63
  • 1
    I always found that one of the STL issues was not giving a string that does not handle memory and just receives a const char* and size, and handles that – Alon Mar 26 '13 at 08:08
  • It would appear that C++17 `std::string_view` is exactly that. – v.oddou Mar 11 '19 at 06:14

2 Answers2

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.

Johannes Overmann
  • 4,914
  • 22
  • 38
  • Good answer :) Yes I planed on value semantics, but it is correct only with RO policy. Obviously if 2 clients refer the same buffer in RW, problems will arise if they don't cooperate. The multithread concern is one I was waiting to pop in the discussion. +1 for mentionning it. – v.oddou Mar 26 '13 at 08:43
0

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.

Alex Chamberlain
  • 4,147
  • 2
  • 22
  • 49
  • indeed RW appears more tricky. my alreay existing implementation (that always relied on internally managed buffers), was already supporting loose string size vs buffer size relation, so I thought it would be rather easy to allow every write that do not extend past the capacity. (since i set capacity to 0 in RO, and strlen in RW) – v.oddou Mar 26 '13 at 08:45