5 ms·
I understand that (one of my favorite books on my shelf is "C Interfaces and Implementations" that shows some of the cool stuff that you can do with any C imple
by TimJYoung 8y ago
I understand that (one of my favorite books on my shelf is "C Interfaces and Implementations" that shows some of the cool stuff that you can do with any C implementation, including "proper" strings), but they're not something supported in the compiler, which is, unless I'm mistaken, necessary for the reference count checks.
My point is that implementing a new string type has zero effect upon existing C programs if they don't use the new string type, so I'm confused as to why it hasn't been done. If a C developer doesn't want to use them, then "no harm, no foul".
- vortico 8y agoWell, then you have two string types. The language will instantly become complicated as we indecisively choose between two different string types each function in our APIs. I see no harm in adding more functions around the string type we already have, but as I mentioned in https://news.ycombinator.com/item?id=17248446 https://news.ycombinator.com/item?id=17248446, `snprintf` is the mother-of-all-string-functions that does everything you need, so not much else is needed.
- TimJYoung 8y agoI would argue that you still have one string type, while the traditional C "string" type is actually an array of characters, or a pointer to an array of characters. :-) Re: snprintf - yes I saw that and it definitely does do most of the heavy lifting, but it still is something that the developer needs to handle manually (I know, I know, not everyone should be using C...).
- vortico 8y agoNo, char* is definitely a string type. By having another one, that would be two. Believe me, working with C and C++ code and converting back and forth between std::string and char* is a nightmare. Let's not design that into the language itself.
- TimJYoung 8y agoIn C++, can't you just get a reference to the first character in the std::string and use it like a C-style string ?
- jcranmer 8y agostd::string isn't null-terminated. You need to use .c_str(), which allocates a copy that is destroyed when the string is changed (or is destructed).
- TimJYoung 8y agoAhh, yes, forgot about that - thanks !
- thestoicattack 8y agoIt seems[1] that since C++11 .data() and .c_str() are the same function. c_str() is also documented as having constant complexity. If it made a copy, wouldn't it have to be linear? [1] https://en.cppreference.com/w/cpp/string/basic_string/data https://en.cppreference.com/w/cpp/string/basic_string/data
- gpderetta 8y agoYes. Allocating on demand was a legal implementation before c++11. No standard library made use of the option and the latitude was removed in c++11. I think it is still allowed to null terminate on demand.
- hermitdev 8y agoIt doesn't have to make a copy. std::string is always null-terminated as of C++11.
- vortico 8y agoIn practice, all modern C++ compilers and standard libraries just set a null character to the c_str()[len] position and reallocate the string if the capacity of the string buffer cannot contain the extra byte. It is never a linear operation unless you're working with old or niche C++ compilers. In C++11 this is required in the standard.
- cozzyd 8y agoThere's also asprintf which is even easier to use (if you don't care about the dynamic allocation).
- vortico 8y agoIf only this existed in the C standard... You can call snprintf twice, the first time with a NULL buffer and zero-sized length, and the second with a newly allocated buffer with the size equal to the return value of the first snprintf call.