4 ms·

There are many object oriented string types for C in various independent GitHub repositories, but they're not really interesting for C programmers because they

There are many object oriented string types for C in various independent GitHub repositories, but they're not really interesting for C programmers because they enjoy the simplicity of null-terminated strings and moving data around with `for` loops.

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 ago
  Well, 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 ago
    I 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 ago
      No, 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 ago
        In 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 ago
        std::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 ago
        Ahh, yes, forgot about that - thanks !
        thestoicattack 8y ago
        It 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 ago
        Yes. 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 ago
  - cozzyd 8y ago
    There's also asprintf which is even easier to use (if you don't care about the dynamic allocation).
    - vortico 8y ago
      If 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.

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 ago
Well, 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 ago
  I 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 ago
    No, 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 ago
      In 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 ago
        std::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 ago
        Ahh, yes, forgot about that - thanks !
        thestoicattack 8y ago
        It 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 ago
        Yes. 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 ago
- cozzyd 8y ago
  There's also asprintf which is even easier to use (if you don't care about the dynamic allocation).
  - vortico 8y ago
    If 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.