5 ms·

C++ introduces a shit-ton of stuff that one often doesn't want, and even Bjarne Stroustrup (who many content has never seen a language feature he didn't want) h

C++ introduces a shit-ton of stuff that one often doesn't want, and even Bjarne Stroustrup (who many content has never seen a language feature he didn't want) has been a little alarmed at the sheer mass of cruft being crammed into recent updates to the standard. I know many C++ people think C++ is pure improvement over C in all contexts and manners, but it's not. It's different, and there are features implemented in C++ and not in C that could be added to C without damaging C's particular areas of greatest value, and many other features in C++ that would be pretty bad for some of C's most important use cases. C shouldn't turn into C++, or even C++ Lite™, but it shouldn't remain strictly unchanging for all eternity, either. It should just always strive to be a better C, conservatively, because its niche is one where conservative advancement is important. Some way to adopt programming practices that guaranteee consistent management of array and pointer length -- not just write code to check it, but actually guarantee it -- would, I think, perfectly fit the needs of conservative advancement suitable to C's most important niche(s). It may not take the form of a Rust-like "fat pointer". It may just be the ability to tell the compiler to enforce a particular constraint for relationships between specific struct fields/members (as someone else in this discussion suggested), in a backward-compatible manner such that the exact same code would compile in an older-standard compiler -- a very conservative approach that should, in fact, solve the problem as well as "fat pointers". There are ways to get the actually important upgrades without recreating C++.

kazinator 6y ago
> C++ introduces a shit-ton of stuff that one often doesn't want The point in my comment is that every single item in C++ was wanted and championed by someone, exactly like all the talk about adding this and that to C. > C shouldn't turn into C++ Well, C did turn into C++. The entity that gave forth C++ is C. Analogy: when we say "apes turned into humans", we don't mean that apes don't exist any more or are not continuing to evolve. Since C++ is here, there is no need for C to turn into another C++ again. A good way to have a C++ with fewer features would be to trim from C++ rather than add to C.
- nicoburns 6y ago
  Sure, but theres a vast space between the C and C++ approaches. You don't have to say yes to everything to say yes to a few things. I would suggest that better arrays are an example of something that pretty much everybody wants.
  - pjmlp 6y ago
    Apparently not everyone, otherwise it would be part of ISO C already, and it hasn't been for lack of trying.
    - apotheon 6y ago
      Not literally everyone, I would think, but the previous statement could, in theory, still be true. It would just require some people to want something else, conflicting with that desire, even more. I know, this is pedantic, I suppose. Mea culpa.
  - simias 6y ago
    But if you want better arrays you want operator overload to be able to use these arrays as 1st class citizens without having to use array_get(arr, 3), array_len(arr), array_concatenate(arr1, arr2) etc... You want to be able to write "arr[3]", "arr.len()", "arr1 += arr2" etc... To implement operator overload you might need to add the concept of references. If you want your arrays type-safe you'll need dark macro magic (actually possible in the latest standards I think) or proper templates/generics. If you really want to make your arrays convenient to use you'll want destructors and RAII. Then you'd like to be able to conveniently search, sort and filter those arrays. That's clunky without lambdas. And once you get all that, why not move semantics and... Conversely if you don't want any of this what's wrong with: struct my_array { my_type_t *buf; size_t len; } I don't think it's worth wasting time standardizing that, especially since I'd probably hardly ever use that since it doesn't really offer any obvious benefits and "size_t" is massively overkill in many situations.
    - loeg 6y ago
apotheon 6y ago
That should have said "many contend". Now it seems too late to edit.

kazinator 6y ago

> C++ introduces a shit-ton of stuff that one often doesn't want The point in my comment is that every single item in C++ was wanted and championed by someone, exactly like all the talk about adding this and that to C. > C shouldn't turn into C++ Well, C did turn into C++. The entity that gave forth C++ is C. Analogy: when we say "apes turned into humans", we don't mean that apes don't exist any more or are not continuing to evolve. Since C++ is here, there is no need for C to turn into another C++ again. A good way to have a C++ with fewer features would be to trim from C++ rather than add to C.

nicoburns 6y ago
Sure, but theres a vast space between the C and C++ approaches. You don't have to say yes to everything to say yes to a few things. I would suggest that better arrays are an example of something that pretty much everybody wants.
- pjmlp 6y ago
  Apparently not everyone, otherwise it would be part of ISO C already, and it hasn't been for lack of trying.
  - apotheon 6y ago
    Not literally everyone, I would think, but the previous statement could, in theory, still be true. It would just require some people to want something else, conflicting with that desire, even more. I know, this is pedantic, I suppose. Mea culpa.
- simias 6y ago
  But if you want better arrays you want operator overload to be able to use these arrays as 1st class citizens without having to use array_get(arr, 3), array_len(arr), array_concatenate(arr1, arr2) etc... You want to be able to write "arr[3]", "arr.len()", "arr1 += arr2" etc... To implement operator overload you might need to add the concept of references. If you want your arrays type-safe you'll need dark macro magic (actually possible in the latest standards I think) or proper templates/generics. If you really want to make your arrays convenient to use you'll want destructors and RAII. Then you'd like to be able to conveniently search, sort and filter those arrays. That's clunky without lambdas. And once you get all that, why not move semantics and... Conversely if you don't want any of this what's wrong with: struct my_array { my_type_t *buf; size_t len; } I don't think it's worth wasting time standardizing that, especially since I'd probably hardly ever use that since it doesn't really offer any obvious benefits and "size_t" is massively overkill in many situations.
  - loeg 6y ago

apotheon 6y ago

That should have said "many contend". Now it seems too late to edit.