4 ms·

What exactly is a problem with C++’s strings, or especially Rust’s? Everything you mentioned can be controlled as explicitly as you want. The only problem is C

• coldtea 4y ago
  >What exactly is a problem with C++’s strings, or especially Rust’s? Everything you mentioned can be controlled as explicitly as you want. Everything else, however, cannot.
  • kaba0 4y ago
    Like what? C++ and Rust can do everything C can.
    • tourmalinetaco 4y ago
      They literally cannot. For one, neither C++ or Rust conform to standard C, meaning they already deviate from what C does on a basic level. Their industry uses are highly different as well. C is almost a requirement for embedded systems, and while C++/Rust can be used there, they’re simply too complex and in Rust’s case additionally too young to be adopted. C++, and possibly Rust (if it can get its act together), are more used in high level programming, as that’s what they’re built for. If C++ could do what C can, then why is the Linux kernel 98.5% C code? Wouldn’t it be better to use a more varied and powerful language? Or, maybe different languages have different use cases and cannot be directly slotted in to replace one another.
      • tialaramex 4y ago
        Linux isn't written in standard C. Not only does it not accept C's aliasing rules (hence the kernel is compiled with them disabled, which the standard doesn't offer), it doesn't even accept the memory model, because it had its own memory model first and it likes that one better. As a result to some extent GCC and Clang are also compilers for some sort of "Linux C" which is strongly reminiscent of the ISO standard language but distinct. And there's no reason you would choose C++ for a project where you'd otherwise use C on account of the (exaggerated) relationship between the two languages, the reason you'd do it would be that you want C++ features, and Linus doesn't want C++ features. Projects to "just" compile the existing Linux code but with C++ compilers failed AFAIK.
        • shrimp_emoji 4y ago
          I'll just leave this here: https://lkml.org/lkml/2018/6/5/769 https://lkml.org/lkml/2018/6/5/769 ;p And maybe this: https://dl.acm.org/doi/10.1145/3477113.3487274 https://dl.acm.org/doi/10.1145/3477113.3487274
          • flohofwoe 4y ago
            Unions for type punning is actually entirely valid in C, it's only UB in C++. (I agree though that the C standard isn't actually relevant in the real world, most C compilers treat it more or less as a 'suggestion', unless enforced with options like '-pedantic')
      • kaba0 4y ago
        So your answer is “because they are not C”…? What does language complexity has to do with anything? It will get compiled down to machine code, and both can be and are used for embedded. They occupy the exact same low-level niche as C, hell, they may be even more level as they can also do things like SIMD. Linux kernel is C because Linus doesn’t like C++, it’s that easy. And usually no, why would you use multiple languages in a project if you don’t have a good reason?
        • cozzyd 4y ago
          It is quite difficult to write idiomatic C++ without memory allocation, for one, which is often a requirement for embedded code or any high-availability code that is not allowed to have memory fragmentation. Sure, it's possible (you can write C in C++, for the most part, and to its credit, C++ has placement new). But many of C++'s niceties require memory allocation, making much of its value-add over C questionable.
          • pjmlp 4y ago
            It super easy, we did it all the time back in the MS-DOS days.
            • cozzyd 4y ago
              right, but that was pre C++ niceties like the STL :).
              • pjmlp 4y ago
                C++ compilers shipped their own collections, for Borland compilers it was BIDS. The first version used preprocessor macro tricks for generatic code, basically what Go folks re-discovered with //go:generate, we already had it in 1992. BIDS 2.0 already used templates. It was exactly because even C++ for MS-DOS provided safer library than C, that I was never that into C. It wasn't better than TP in features and safety, only in portability, and that I could get from C++ anyway.
• scoutt 4y ago
  Last time I checked "Formatting is Unreasonably Expensive for Embedded Rust" (1) And/or you need a crate like alloc, heapless, etc. For the sake of a sprintf "abstraction"... (1) https://jamesmunns.com/blog/fmt-unreasonably-expensive/ https://jamesmunns.com/blog/fmt-unreasonably-expensive/
  • orf 4y ago
    It’s not really a sprintf abstraction.
• kjs3 4y ago
  If all you do is write code on Linux/Windows/MacOS, C++ strings might be fine. Things are different in the wider world. Many places I use C don't even have a C++ compiler (embedded, in particular).
• flohofwoe 4y ago
  I don't even know where to start with C++ stdlib string problems, but being mutable and doing a unique heap allocation (above a certain length - a behaviour which however isn't even standardized) are definitely at the top of the list. std::string_view would have been a good thing if it hadn't added another memory corruption foot gun. A universal string type is one of those things where you can either have convenience or performance, but never both.
  • pjmlp 4y ago
    They are still better than str...() and mem...() all over the place, and all relevant C++ compilers have options to turn bounds checking on.