3 ms·
Ooh, I have a good one for this. If you have a C++ `std::string` object passing into a C API that takes a null-terminated `char *`, there's a convenience method
by wnissen 4y ago
Ooh, I have a good one for this. If you have a C++ `std::string` object passing into a C API that takes a null-terminated `char *`, there's a convenience method `std::string::c_str()` to produce the C string from the C++ one.
char const* inputFilename = std::string("path/to/file").c_str();
call_to_C_API(inputFilename);
Boom. You can typically access `inputFilename` until the next allocation on the stack, but it will almost always go bad quickly. This isn't allocation on the heap, which usually requires another level of indirection, but you get the idea.
- cesarb 4y ago> This isn't allocation on the heap, which usually requires another level of indirection, but you get the idea. Isn't it allocating in the stack due to the "small string optimization"? Making string contents longer (or using a C++ standard library which doesn't have a "small string optimization" in the first place) would be enough to have it be allocated in the heap instead.
- verall 4y agoNo, with longer string contents the std::string will internally allocate and store on the heap, but as the containing std::string is a temporary it will be pop'd of the stack (stack pointer moved, which is why it works "sometimes") and its destructor called at the end of the statement (at the semicolon), freeing the heap allocated memory (which, as parents are discussing, may still work because nothing has yet overwritten the recently freed memory). Changing it to: call_to_C_API(std::string("path/to/file").c_str()); Makes it valid because the std::string object will live until the semicolon.
- deleted 4y ago[deleted]