一个const字符串构造函数，不分配任何char内存？

Question

I'm trying to optimize some code I've written to handle several layers of an application protocol. I made liberal use of the std::string class, and strove for simplicity rather than premature optimization. The application is too slow, and valgrind & gprof show I'm spending significant time copy-constructing strings as a buffer moves upward through my stack.

It seems to me that, after copying chars from the system buffer to my lowest application buffer, I should be able to avoid copying the data any more: after all, it is not mutated as it moves up the stack.

My protocol format is a "transmission", consisting of one or more newline-terminated records , each consisting of several tab-separated fields , and terminated with a special token. Eg

RECORD 1\tHAS\tTHESE\tFIELDS\nRECORD 2\tLOOKS\tLIKE\tTHIS\nEND-OF-TRANSMISSION\n

This would be assembled in a single std::string called input_buffer.

The processing of a transmission involves extracting a record from the buffer and passing it to the next layer; extracting a vector of fields from the record and passing it to the next layer; storing the fields into a map. At each stage, data is being copied as new std::strings are allocated.

Is it possible to allocate a const string from an index into input_buffer, and a length ... without any copying being done? For example, RECORD 2 begins at offset 26 and is 24 chars long:

const std:string record (substr(input_buffer, 26), 24 );

I'm not familiar with the innards of a string object, but its performance guarantees seem to imply that somewhere there's a simple char sequence, and almost undoubtedly a pointer to those chars' memory. Could that pointer be initialized to memory belonging to another string?

(My compiler is g++ 4.7, but if this is something that requires 4.8, I'd appreciate knowing about that too.)

Answer 1

From what I understand, this sounds like a good candidate for boost::string_ref . You would simply do boost::string_ref input(input_buffer); and then pass string_ref s up the stack instead. The only thing you have to worry about is keeping the original buffer alive the whole time.