3 ms·
'that is what the libc runtime, which is the foundation that every language ultimately reaches down to in the end, is built around.' Except, interestingly enou
by wickedchicken 15y ago
'that is what the libc runtime, which is the foundation that every language ultimately reaches down to in the end, is built around.'
Except, interestingly enough, Go code compiled with the standard compilers (5g, 6g, 8g, see http://golang.org/doc/go_faq.html#How_is_the_run_time_support_implemented http://golang.org/doc/go_faq.html#How_is_the_run_time_suppor...). The Plan9 expats are hell-bent on doing things their own way, I am 70% in agreement with them :).
- byuu 15y agoWell, Go code will eventually call into OS-level functions. And when your Linux kernel is built in C, the eventual calls to open(), etc will need null-terminated strings. So you will have to make a copy, eg std::string::c_str().
- Arelius 15y agoI was under the impression that std::string::c_str() did not make an allocation, but rather had the scope of the parent std::string, it does in fact return a const char* which can't be freed like normal. Either that, or nearly all code I've seen which uses it amuses memory leaks.
- byuu 15y agoI suppose it could allocate an extra byte anyway, and set that byte to null. It seems like that could cause issues with memory alignment if you go thinking every string is 256-bytes, but it's 257-bytes because of that. Not that big of a deal, of course. The length value in that case would also be invalid for C usage, because std::string does allow storing nulls inside the string, but it would eliminate the need for allocation.
- justincormack 15y agoThe Linux kernel does not mostly use null terminated strings either, except to communicate with user space. Nor does it use libc. And much of libc is not well designed for modern code. Mostky I ptogram to the system call API in C.