6 ms·

Calm down my friend. Why should C++ be exactly like C? There are reasons that C is a declining language. Also, I don't get why you think they have obnoxious att

Calm down my friend. Why should C++ be exactly like C? There are reasons that C is a declining language. Also, I don't get why you think they have obnoxious attitude? They do go into detail for each point, I don't think your characterization is fair.

_bxg1 6y ago
If anything it seems like C++ is the one in decline. C is still the only option for lots of use-cases; C++ is a) succumbing to feature-bloat and b) having different parts of its userbase siphoned off by Go, Rust, Swift, even C# (games; both Unity and Godot).
- jonstewart 6y ago
  C++ has been greatly reinvigorated this past decade with language and compiler modernization. Few C++ programmers decamped to Go; most of Go’s adoptees came from Python. Go doesn’t have all that much to offer a C++ programmer.
  - dodobirdlord 6y ago
    > Go doesn’t have all that much to offer a C++ programmer. Concurrency and parallelism without debugging hell is huge.
    - gumby 6y ago
      C++ will be getting a concurrency model, likely in C++23. As with other language features the position papers and implementations refer not only with their authors’ experience with C++ efforts (libuv, asio, pthreads) but other languages as well, such as go.
    - pjmlp 6y ago
      C++20 offers both with very nice graphical debuggers, which Delve isn't really a match for.
      - abjKT26nO8 6y ago
        What graphical debuggers for C++ do you recommend?
        pjmlp 6y ago
        Visual C++ ones.
        abjKT26nO8 6y ago
        That's not really an option for me when I debug C++ that is run on a Linux or Android TV. It also wouldn't be an option when I used to work with C++ that was used on Linux servers. That's a big chunk of C++ use. While I have your attention, I see your comments here in C++ threads quite often. You seem to like the language and at the same time you have some experience with simpler languages like Oberon. My experience with C++ has been that people happily go on to create giant inheritance hierarchies, with no restraint for multiple inheritance to the point that it's so unmanagable that nobody knows where things go and what actually happens. With all that inheritance, they lose track that the same thing has actually been copied tens of times between different classes and now these tens of classes have code that is basically copy-pasted and who knows what benefit anyone has from all this inheritance. Google engineers are one of the offenders when it comes to overuse of inheritance. Then, modern C++ allegedly fixes some warts, but IME it introduces more of them. E.g. the initialization fiasco (I honestly can't say with 100% confidence what braces do when you initialize std::vector). Then there is this thing that when you create a lambda like so: [&] { ... } And then move it to a function which will create lambdas of this form, just with different captures: std::function<void()> create_lambda(args...) { return [&] { ... }; } The second version will crash later when you run the lambda. Because it turns out that "[&]" just copies the stack pointer and isn't syntactic sugar for enumerating all the variables that you capture. This was non-obvious to me and it was really hard to track down the first time I encountered this problem. I think "[&]" is broken. Similarly, std::thread crashing in destructor when the user doesn't call std::thread::join, nor std::thread::detach. The ambiguity of syntax... I just don't buy that "modern C++" makes things particularly better. It sometimes makes them worse. Don't you experience the same fatigue as I do? EDIT: Oh, I just remembered another thing: at a previous job we discovered that MinGW's implementation of std::random_device just returned 0 every time. It is major facepalm for MinGW, but also for the C++ standard for making this behaviour allowed (yes, it's actually compliant with the standard). And even after it was fixed, there are still systematic issues with this whole randomness API. E.g. you can't actually seed it properly[1]. [1]: https://codingnest.com/generating-random-numbers-using-c-standard-library-the-problems/ https://codingnest.com/generating-random-numbers-using-c-sta...
    - adev_ 6y ago
      > Concurrency and parallelism without debugging hell is huge. There is plenty of libraries in C++ that haves you concurrency and parallelism without debugging hell. Hell in concurrent code comes when you have shared state, and that is valid for both Go and C++. Using shared Golang Map in multi-threaded code is a very good example of deathtrap, even if it's in Go.
- vips7L 6y ago
  Swift? I didn't know it had much use outside of mac/iOS. It seems like a cool language otherwise.
  - _bxg1 6y ago
    It just recently got official support for Windows and Linux, and it had low-key Linux support for a while before that. I've heard of people writing web servers in it. Like Go, it compiles directly to native machine code.
    - vips7L 6y ago
      Isn't it still slower than GO because of referencing counting?
      - _bxg1 6y ago
        Depends what you mean by slow. Go is garbage-collected, Swift is reference-counted. Each has advantages and disadvantages. But also, that doesn't apply to stack-allocated values. It's not as simple as one being faster than the other.
- pjmlp 6y ago
  The only thing keeping C around are FOSS UNIX clones and embedded developers that are religiously stuck with C89 and their PIC compiler extensions. Even Arduino like boards use C++ nowadays. Unity and Godot have their graphics engine written in C++. Rust, Swift are dependent on LLVM, written in C++. Go, it isn't really in the same league of programmer expressiveness.
  - worik 6y ago
    I have spend the quarantine hacking in C. On FreeCIV. Still used lots and lots of places
    - pjmlp 6y ago
      Same can be said by any programming language, C is the Cobol of systems programming languages, so as long as there UNIX FOSS clones it won't go away.
    - hannofcart 6y ago
      Freeciv fan here. What are you working on in it?
      - worik 6y ago
        Forked Attitude AI and making a rules based AI
  - saagarjha 6y ago
    There are lots of performance sensitive tools, language runtimes, and cross-platform libraries written in C.
    - pjmlp 6y ago
      And even more written in C++. Should we start counting which ones?
      - 6y ago
cozzyd 6y ago
It makes C++ much less useful to write a library in (or, you have to maintain a fragile C layer). I take it you've never had to deal with a libstdc++ ABI boundary before?
- google234123 6y ago
  You can continue working in a world without the small string optimization if you want. There is already precedent.
  - CoolGuySteve 6y ago
    I want a world where the compiler knows when it can use that optimization instead of me bludgeoning it with a global define. Like you said, it's not even that far fetched.
    - gumby 6y ago
      It’s a library feature not as compiler feature so you can’t really get out of telling the compiler which library to use, Eben if what you say is nothing (meaning “default library”)
- adrianN 6y ago
  Maintaining a C layer is standard practice for many libraries because that enables their use from a variety of programming languages. Consequently, the tooling around that is quite mature.
  - cozzyd 6y ago
    Sure, but if C++ had a stable ABI, then it would be more practical to directly wrap it. SWIG has some support for C++, after all, and there are a lot of C++ wrappers (e.g. ROOT, pybind11 and Boost.Python can all automagically generate python bindings for C++), but guess what happens when you mix libraries compiled with different std::basic_string ABIs...
throw_m239339 6y ago
> There are reasons that C is a declining language. Unfortunately, it is not. C++ is certainly too complicated, that's why it failed at replacing C, and that's why Rust will fail at replacing C as well.
- dodobirdlord 6y ago
  Fortunately for Rust it's very easy to use a simple subset of the language. Lots of tough borrowing issues don't show up if you stick to the stack, and you can get very far with just the stack and some heap allocated vectors and maps. Not everybody needs to implement an async runtime.
- pjmlp 6y ago
  It only failed on UNIX FOSS clones and embedded C only boards. All major C compilers are written in C++ nowadays. Apple OSes use C++ for device drivers, GPGPU programming and their compiler infrastructure. Google OSes use legacy C drivers for Linux and everything else is a mix of C++, Java, Rust, using micro-kernel like architecture where each driver gets their own process. On Windows it has been long considered persona non-grata and everyone advised to either move to C++ or adopt Clang (also provided via VS installer) if they insist in using C. VC++ only supports C to the extent required by ISO C+++ compliance. One of the reasons OpenCL lost to CUDA was the initial refusal of Khronos to offer similar C++ tooling, making many researches jump to NVidia.
  - saagarjha 6y ago
    > Apple OSes use C++ for device drivers Embedded C++, and the kernel is pure C.
    - pjmlp 6y ago
      Embedded C++ is a C++ subset, it is as valid C++ example as those embedded C dialects that aren't able to fully support the ISO C standard library, yet people still call them C. And as of Driver Kit introduction, 100% full C++ is now an option. In a couple of years from now, when the full transition of kernel extensions to user space modules is complete, the kernel will be the only C piece left. Which Apple most likely won't bother to rewrite due to the historical baggage of mixing BSD with Mach code that probably no one is willing to re-write.

_bxg1 6y ago

If anything it seems like C++ is the one in decline. C is still the only option for lots of use-cases; C++ is a) succumbing to feature-bloat and b) having different parts of its userbase siphoned off by Go, Rust, Swift, even C# (games; both Unity and Godot).

jonstewart 6y ago
C++ has been greatly reinvigorated this past decade with language and compiler modernization. Few C++ programmers decamped to Go; most of Go’s adoptees came from Python. Go doesn’t have all that much to offer a C++ programmer.
- dodobirdlord 6y ago
  > Go doesn’t have all that much to offer a C++ programmer. Concurrency and parallelism without debugging hell is huge.
  - gumby 6y ago
    C++ will be getting a concurrency model, likely in C++23. As with other language features the position papers and implementations refer not only with their authors’ experience with C++ efforts (libuv, asio, pthreads) but other languages as well, such as go.
  - pjmlp 6y ago
    C++20 offers both with very nice graphical debuggers, which Delve isn't really a match for.
    - abjKT26nO8 6y ago
      What graphical debuggers for C++ do you recommend?
      - pjmlp 6y ago
        Visual C++ ones.
        abjKT26nO8 6y ago
        That's not really an option for me when I debug C++ that is run on a Linux or Android TV. It also wouldn't be an option when I used to work with C++ that was used on Linux servers. That's a big chunk of C++ use. While I have your attention, I see your comments here in C++ threads quite often. You seem to like the language and at the same time you have some experience with simpler languages like Oberon. My experience with C++ has been that people happily go on to create giant inheritance hierarchies, with no restraint for multiple inheritance to the point that it's so unmanagable that nobody knows where things go and what actually happens. With all that inheritance, they lose track that the same thing has actually been copied tens of times between different classes and now these tens of classes have code that is basically copy-pasted and who knows what benefit anyone has from all this inheritance. Google engineers are one of the offenders when it comes to overuse of inheritance. Then, modern C++ allegedly fixes some warts, but IME it introduces more of them. E.g. the initialization fiasco (I honestly can't say with 100% confidence what braces do when you initialize std::vector). Then there is this thing that when you create a lambda like so: [&] { ... } And then move it to a function which will create lambdas of this form, just with different captures: std::function<void()> create_lambda(args...) { return [&] { ... }; } The second version will crash later when you run the lambda. Because it turns out that "[&]" just copies the stack pointer and isn't syntactic sugar for enumerating all the variables that you capture. This was non-obvious to me and it was really hard to track down the first time I encountered this problem. I think "[&]" is broken. Similarly, std::thread crashing in destructor when the user doesn't call std::thread::join, nor std::thread::detach. The ambiguity of syntax... I just don't buy that "modern C++" makes things particularly better. It sometimes makes them worse. Don't you experience the same fatigue as I do? EDIT: Oh, I just remembered another thing: at a previous job we discovered that MinGW's implementation of std::random_device just returned 0 every time. It is major facepalm for MinGW, but also for the C++ standard for making this behaviour allowed (yes, it's actually compliant with the standard). And even after it was fixed, there are still systematic issues with this whole randomness API. E.g. you can't actually seed it properly[1]. [1]: https://codingnest.com/generating-random-numbers-using-c-standard-library-the-problems/ https://codingnest.com/generating-random-numbers-using-c-sta...
  - adev_ 6y ago
    > Concurrency and parallelism without debugging hell is huge. There is plenty of libraries in C++ that haves you concurrency and parallelism without debugging hell. Hell in concurrent code comes when you have shared state, and that is valid for both Go and C++. Using shared Golang Map in multi-threaded code is a very good example of deathtrap, even if it's in Go.
vips7L 6y ago
Swift? I didn't know it had much use outside of mac/iOS. It seems like a cool language otherwise.
- _bxg1 6y ago
  It just recently got official support for Windows and Linux, and it had low-key Linux support for a while before that. I've heard of people writing web servers in it. Like Go, it compiles directly to native machine code.
  - vips7L 6y ago
    Isn't it still slower than GO because of referencing counting?
    - _bxg1 6y ago
      Depends what you mean by slow. Go is garbage-collected, Swift is reference-counted. Each has advantages and disadvantages. But also, that doesn't apply to stack-allocated values. It's not as simple as one being faster than the other.
pjmlp 6y ago
The only thing keeping C around are FOSS UNIX clones and embedded developers that are religiously stuck with C89 and their PIC compiler extensions. Even Arduino like boards use C++ nowadays. Unity and Godot have their graphics engine written in C++. Rust, Swift are dependent on LLVM, written in C++. Go, it isn't really in the same league of programmer expressiveness.
- worik 6y ago
  I have spend the quarantine hacking in C. On FreeCIV. Still used lots and lots of places
  - pjmlp 6y ago
    Same can be said by any programming language, C is the Cobol of systems programming languages, so as long as there UNIX FOSS clones it won't go away.
  - hannofcart 6y ago
    Freeciv fan here. What are you working on in it?
    - worik 6y ago
      Forked Attitude AI and making a rules based AI
- saagarjha 6y ago
  There are lots of performance sensitive tools, language runtimes, and cross-platform libraries written in C.
  - pjmlp 6y ago
    And even more written in C++. Should we start counting which ones?
    - 6y ago

cozzyd 6y ago

It makes C++ much less useful to write a library in (or, you have to maintain a fragile C layer). I take it you've never had to deal with a libstdc++ ABI boundary before?

google234123 6y ago
You can continue working in a world without the small string optimization if you want. There is already precedent.
- CoolGuySteve 6y ago
  I want a world where the compiler knows when it can use that optimization instead of me bludgeoning it with a global define. Like you said, it's not even that far fetched.
  - gumby 6y ago
    It’s a library feature not as compiler feature so you can’t really get out of telling the compiler which library to use, Eben if what you say is nothing (meaning “default library”)
adrianN 6y ago
Maintaining a C layer is standard practice for many libraries because that enables their use from a variety of programming languages. Consequently, the tooling around that is quite mature.
- cozzyd 6y ago
  Sure, but if C++ had a stable ABI, then it would be more practical to directly wrap it. SWIG has some support for C++, after all, and there are a lot of C++ wrappers (e.g. ROOT, pybind11 and Boost.Python can all automagically generate python bindings for C++), but guess what happens when you mix libraries compiled with different std::basic_string ABIs...

throw_m239339 6y ago

> There are reasons that C is a declining language. Unfortunately, it is not. C++ is certainly too complicated, that's why it failed at replacing C, and that's why Rust will fail at replacing C as well.

dodobirdlord 6y ago
Fortunately for Rust it's very easy to use a simple subset of the language. Lots of tough borrowing issues don't show up if you stick to the stack, and you can get very far with just the stack and some heap allocated vectors and maps. Not everybody needs to implement an async runtime.
pjmlp 6y ago
It only failed on UNIX FOSS clones and embedded C only boards. All major C compilers are written in C++ nowadays. Apple OSes use C++ for device drivers, GPGPU programming and their compiler infrastructure. Google OSes use legacy C drivers for Linux and everything else is a mix of C++, Java, Rust, using micro-kernel like architecture where each driver gets their own process. On Windows it has been long considered persona non-grata and everyone advised to either move to C++ or adopt Clang (also provided via VS installer) if they insist in using C. VC++ only supports C to the extent required by ISO C+++ compliance. One of the reasons OpenCL lost to CUDA was the initial refusal of Khronos to offer similar C++ tooling, making many researches jump to NVidia.
- saagarjha 6y ago
  > Apple OSes use C++ for device drivers Embedded C++, and the kernel is pure C.
  - pjmlp 6y ago
    Embedded C++ is a C++ subset, it is as valid C++ example as those embedded C dialects that aren't able to fully support the ISO C standard library, yet people still call them C. And as of Driver Kit introduction, 100% full C++ is now an option. In a couple of years from now, when the full transition of kernel extensions to user space modules is complete, the kernel will be the only C piece left. Which Apple most likely won't bother to rewrite due to the historical baggage of mixing BSD with Mach code that probably no one is willing to re-write.