Can I do a null copy of std :: string in C ++ from a const char * array?

Question

Profiling my application shows that it spends almost 5% of the CPU time on line distribution. In many places, I create C ++ std :: string objects from a 64 MB char buffer. The fact is that the buffer does not change while the program is running. My analysis of calls to std::string(const char *buf,size_t buflen) is that the string is copied because the buffer may change after the string is created. It's not a problem. Is there any way to solve this problem?

EDIT: I work with binary data, so I can't just pass char *s . Also, then I would have the significant overhead of constantly scanning for NULL, which std::string avoids.

Answer 1

Binary data? Stop using std :: string and use std::vector<char> . But this will not solve your copy problem. From your description, if this huge 64 MB buffer never changes, you really shouldn't use std :: string or std::vector<char> , or it's not a good idea. You really should go around the const char * pointer (const uint8_t * will be more descriptive of binary data, but under covers it's the same thing, ignoring sign issues). Skip the pointer and the length of size_t, or pass the pointer to another end pointer. If you do not like to go around individual discrete variables (pointer and buffer length), create a structure to describe the buffer and ask everyone to use them instead:

 struct binbuf_desc { uint8_t* addr; size_t len; binbuf_desc(addr,len) : addr(addr), len(len) {} } 

You can always reference your 64 MB buffer (or any other buffer of any size) using binbuf_desc objects. Note that binbuf_desc objects do not own the buffer (or its copy), but simply a descriptor, so you can simply pass them everywhere without worrying that binbuf_descs creates unnecessary copies of the buffer.

Answer 2

If the string does not change, and if its service life is guaranteed to be longer than you intend to use this string, do not use std::string .

Instead, consider a simple C-wrapper for a string, such as the proposed string_ref<T> .

Answer 3

There is no portable solution. If you tell us which toolchain you are using, someone might know the trick specific to your library. But for the most part, the std::string destructor (and the assignment operator) is about to release the contents of the string, and you cannot release the string literal. (The exception is the exception, and in fact a little row optimization is a common case that misses the release, but these are implementation details.)

The best approach is not to use std::string when you don't need / don't need dynamic allocation. const char* still works great in modern C ++.

Answer 4

It seems that using const char * instead of std::string is the best way to go for you. But you should also consider how you use strings. Perhaps an implicit conversion from char pointers to std::string objects may occur. This can happen, for example, when calling functions.