7 ms·

> C died and C++ is newer and better version of it That's kind of my opinion. C didn't die for legacy reasons, but starting new project in C seems a nonsense

> C died and C++ is newer and better version of it That's kind of my opinion. C didn't die for legacy reasons, but starting new project in C seems a nonsense to me. C++ just has so many features that makes the development of programs and libraries easier, for almost no extra costs.

harry8 5y ago
This is a perfectly valid and fine opinion for many new projects. Possibly even most. The point were I dismiss this sort of thing is where it is "all" new projects.
Y_Y 5y ago
Maybe you're just an unusually talented coder, but I pay dearly for every little extra bit of C++ my code touches. It's often worth it, but never a freebie.
- mettamage 5y ago
  I'm distinguishing between a hobby perspective and a professional perspective. IMO that really depends on the project size and goal of the project. I've written a C++ project of about 1000 lines (algobot trader with some optimized data structures in keeping the order book consistent). I've written it in VS Code, used a GUI debugger and I haven't really paid for anything. Meanwhile, I have this friend that programs so much C++ that his mantra is "in C++ assume all tools are broken." When I hear his horror stories, oh dear! Heisenbugs come by every 2 to 3 months. So for small projects that aren't touching the lower OS/systems level parts, you're not paying any extra costs. However, the deeper and further you go, I'd fully agree.
  - fnord123 5y ago
    Are you sure you're not hitting heisenbugs every 2-3 months?
  - lmilcin 5y ago
    The issue is for small project you don't really require C++ over C. Because supposedly the price you pay for abstractions has better returns the larger the application is (and that is generally true). My largest C project was 60k lines of code. The code was very, very dense. It had a lot of functionality that had to be packed to as little code as possible (due to memory limitation). It had things like transactional log-based database working in very small, static amount of memory, point in time recovery (so if the application failed it could restore itself to a number of possible checkpoints before the failure), parsers for various protocols (BER-TLV, for example), a lot of cryptography and custom cryptographic protocols, a GUI framework for a small monochromatic screen and keypad, drivers for a bunch of devices (thermal printer, external pinpad, etc.), SSL, a lot of business logic, state machines for talking to a network host, etc.
- varajelle 5y ago
  What are these costs? Performance costs? Most of C++ abstraction are zero costs. There is always the possibility of misusing them, but you can also misuse C libraries. Learning costs? This is compensated by the fact that you don't have to re learn each project convention in C to emulate the same feature. Compile time costs? Yeah, that can be annoying. Costs of more bugs? In my experience, the better type system makes it unlikely.
  - Y_Y 5y ago
    Introducing complexity into the build system, error messages, my mental model, interoperation between different parts of the code, other developers are often unfamiliar with less popular parts of the language, modern stuff especially sucks for portability between compilers and OSes. That's just my experience of course, and it doesn't mean I don't profit from writing and selling cpp-based software every day.
  - publicola1990 5y ago
    Yes, also the huge benefits C++ offers in structuring large programs makes it well worth it to switch, even if one does not want the more fancy features of it.
bsder 5y ago
> for almost no extra costs No way. The mental costs alone are staggering. My standard observation was that to program C++ properly I always needed an entire shelf of books at hand and I used them daily. The fact that C++ still can't deliver an FFI/name-mangling/v-table/etc. standard that everybody can agree on tells me that it's too complex.
- varajelle 5y ago
  I would argue that you pay a harder mental cost in C because each project has to reinvent its own convention to emulate C++ features, and also because C allow for less abstraction which makes reasoning about the whole program more difficult I don't see the relation with the fact that msvc and GCC have chosen different c++ ABI. That's not telling anything about the complexity of the language.
  - flohofwoe 5y ago
    If you feel the need to emulate C++ features in C then you're just writing C code with a C++ mindset. Getting back to the "C way" takes a couple of months to get C++ out of your system first ;) Of course for some types of problems, C++ is indeed the better language than C, but very often other languages are even better suited (e.g. I turn to Python for most problem where C doesn't work well, for instance munching text files)
    - varajelle 5y ago
      I was referring to the things from the video, where RAII and generic types are emulated with complex macros. And where std::string(_view) is re-invented
      - flohofwoe 5y ago
        Fair point, but cleanup and string handling are hardly problems where C++ has a monopoly, or even particularly good solutions to offer ;)
      - 5y ago
pjmlp 5y ago
I wish, althought C++ was born on the same building as C (kind of) and has enjoyed first class support on UNIX, it has hardly taken its place at the kernel level or syscalls. So most UNIX/POSIX projects, even new ones, will default to C. Then there is the embedded space where almost 40 years later trying to use C++ instead of C is still an uphill battle, between embedded development communities, tool vendors, debugging tools, available libraries. Arduino and mbed are the exceptions, not the rule. Even Microsoft despite all their security talk around Azure Sphere, just releases a pure C SDK for it. Which is while I tend to rant about C, I also argue that tooling improvements related to security are more than welcomed, and knowledge about best practices when coding in C should be more widespread. It is the COBOL of systems programming languages (about 10 years younger) and it isn't going away for the foreseable future.
- lmilcin 5y ago
  > Then there is the embedded space where almost 40 years later trying to use C++ instead of C is still an uphill battle, between embedded development communities, tool vendors And why do you think this is so? When I was starting with embedded development I missed C++ as I felt compelled to reinvent same things that were given in C++. But then I grew up to learn there is a hefty price to pay for it and in embedded development those problems are blown due to properties of the environment and types of projects you build. It is one thing for a game to be constantly crashing and it is another if this is happening to an embedded device. When you develop embedded code it is way more important to understand exact consequences of your actions and C++ is trying to hide those from you as much as possible. There are also other requirements like being able to easily ascertain the amount of stack used, ability to use exclusively statically allocated memory, etc. that are conflicting with C++ or at least making it difficult to enforce them in C++. I am very happy to see Rust is overtaking C++ in embedded and is an answer to C problems without creating (too many) of its own.
  - pjmlp 5y ago
    It is a culture problem, something that only will change with mentality reboot. "CppCon 2016: Dan Saks “extern c: Talking to C Programmers about C++”" https://www.youtube.com/watch?v=D7Sd8A6_fYU https://www.youtube.com/watch?v=D7Sd8A6_fYU "Writing better embedded Software - Dan Saks - Keynote Meeting Embedded 2018" https://www.youtube.com/watch?v=3VtGCPIoBfs https://www.youtube.com/watch?v=3VtGCPIoBfs "Embedded & C++ - Meeting 2017 Keynote" https://www.youtube.com/watch?v=mNPfsUZb3vs https://www.youtube.com/watch?v=mNPfsUZb3vs In a way, the same kind of subculture in C++ that jumps in cries of horror if you happen to use std::vector/array/string with bounds checking enabled.
wruza 5y ago
Ah, right. And all these “my move constructor wasn’t called” — “one of subfields had non-moveable field” and other arcane topics, which only C++ forums have, are just little implementation details. C++ is good when you believe it is Curly Visual Basic with some AOT speed and is an implicitness nightmare when you really care.
- pjmlp 5y ago
  That is the beauty of C++. I can write VB/Delphi like code with C++ Builder, write raytracing algorithms in CUDA, or just have fun targeting ESP32.
enriquto 5y ago
> C++ just has so many features that makes the development of programs and libraries easier, for almost no extra costs. I respect your opinion, but mine is the exact opposite (I don't know how representative mine is, but I'm sure I'm not alone). The problem with C++ is that many of those "features" are actually "anti-features". From the top of my head: operator overloading, copy-constructors, constructors, destructors, function overloading. While these "features" may make correct code easier to write, they always make incorrect code much, much harder to understand. For example, you find a simple line of C++ that says "y=f(x);", and it can do anything: has the parenthesis operator been overloaded? and the copy constructor? how many times is a destructor called here? What are its side effects? What instance of f is called, if none of them is defined for the actual type of x? Every single line of C++ that you have to analyze is a terrifying nightmare like this one.
- jcelerier 5y ago
  > The problem with C++ is that many of those "features" are actually "anti-features". From the top of my head: operator overloading, copy-constructors, constructors, destructors, function overloading. While these "features" may make correct code easier to write, they always make incorrect code much, much harder to understand. > For example, you find a simple line of C++ that says "y=f(x);", and it can do anything: has the parenthesis operator been overloaded? and the copy constructor? how many times is a destructor called here? What are its side effects? What instance of f is called, if none of them is defined for the actual type of x? Every single line of C++ that you have to analyze is a terrifying nightmare like this one. I have yet to see any of this be an actual problem in real-world projects. I have seen on the other hand a lot of people coming with these abstract "this is gonna be a problem" ideas in mind, and never wanting to touch C again after working on actual modern C++ projects.
  - enriquto 5y ago
    > I have seen on the other hand a lot of people coming with these abstract "this is gonna be a problem" ideas in mind, and never wanting to touch C again after working on actual modern C++ projects. Well, I for one had the opposite experience. I started programming in C++, and writing, reading and debugging lots of C++ code. It was not "modern" C++, since I stopped doing so around 2006. I embraced C out of personal despair with C++, especially the C++ of other people. For my personal projects, I can still enjoy using "my" favorite subset of C++ (basically, without objects nor pointers, and building the data structures by composing stl containers). Yet, anytime I have to deal with an unknown piece of C++ it is a nightmare. Especially since it is very easy to hide the behavior of the code.
vadavaski 5y ago
You probably work with ultra high level stuff, which is the tip of the iceberg when it comes to programming. More than half of what is written around comes from drivers, embedded, engines, robots, controllers and kernel. And for those, you have nowhere to run but to use C down to its bottom. You might use some C++ to enforce some abstraction, iterate in a more fashionable way, but in the end, it's just C
pclmulqdq 5y ago
Honestly, I think the "killer app" for C++ was generics. If you could write a generic data structure in C without using macros (which are extremely hard to debug), nobody would have wanted C++. However, the Linux Kernel is stuck with AVL trees and primitive hash table algorithms due to complexity, while C++ programmers can blissfully use B-trees and fast linear probing hash maps without worrying about the data structure.

harry8 5y ago

This is a perfectly valid and fine opinion for many new projects. Possibly even most. The point were I dismiss this sort of thing is where it is "all" new projects.

Y_Y 5y ago

Maybe you're just an unusually talented coder, but I pay dearly for every little extra bit of C++ my code touches. It's often worth it, but never a freebie.

mettamage 5y ago
I'm distinguishing between a hobby perspective and a professional perspective. IMO that really depends on the project size and goal of the project. I've written a C++ project of about 1000 lines (algobot trader with some optimized data structures in keeping the order book consistent). I've written it in VS Code, used a GUI debugger and I haven't really paid for anything. Meanwhile, I have this friend that programs so much C++ that his mantra is "in C++ assume all tools are broken." When I hear his horror stories, oh dear! Heisenbugs come by every 2 to 3 months. So for small projects that aren't touching the lower OS/systems level parts, you're not paying any extra costs. However, the deeper and further you go, I'd fully agree.
- fnord123 5y ago
  Are you sure you're not hitting heisenbugs every 2-3 months?
- lmilcin 5y ago
  The issue is for small project you don't really require C++ over C. Because supposedly the price you pay for abstractions has better returns the larger the application is (and that is generally true). My largest C project was 60k lines of code. The code was very, very dense. It had a lot of functionality that had to be packed to as little code as possible (due to memory limitation). It had things like transactional log-based database working in very small, static amount of memory, point in time recovery (so if the application failed it could restore itself to a number of possible checkpoints before the failure), parsers for various protocols (BER-TLV, for example), a lot of cryptography and custom cryptographic protocols, a GUI framework for a small monochromatic screen and keypad, drivers for a bunch of devices (thermal printer, external pinpad, etc.), SSL, a lot of business logic, state machines for talking to a network host, etc.
varajelle 5y ago
What are these costs? Performance costs? Most of C++ abstraction are zero costs. There is always the possibility of misusing them, but you can also misuse C libraries. Learning costs? This is compensated by the fact that you don't have to re learn each project convention in C to emulate the same feature. Compile time costs? Yeah, that can be annoying. Costs of more bugs? In my experience, the better type system makes it unlikely.
- Y_Y 5y ago
  Introducing complexity into the build system, error messages, my mental model, interoperation between different parts of the code, other developers are often unfamiliar with less popular parts of the language, modern stuff especially sucks for portability between compilers and OSes. That's just my experience of course, and it doesn't mean I don't profit from writing and selling cpp-based software every day.
- publicola1990 5y ago
  Yes, also the huge benefits C++ offers in structuring large programs makes it well worth it to switch, even if one does not want the more fancy features of it.

bsder 5y ago

> for almost no extra costs No way. The mental costs alone are staggering. My standard observation was that to program C++ properly I always needed an entire shelf of books at hand and I used them daily. The fact that C++ still can't deliver an FFI/name-mangling/v-table/etc. standard that everybody can agree on tells me that it's too complex.

varajelle 5y ago
I would argue that you pay a harder mental cost in C because each project has to reinvent its own convention to emulate C++ features, and also because C allow for less abstraction which makes reasoning about the whole program more difficult I don't see the relation with the fact that msvc and GCC have chosen different c++ ABI. That's not telling anything about the complexity of the language.
- flohofwoe 5y ago
  If you feel the need to emulate C++ features in C then you're just writing C code with a C++ mindset. Getting back to the "C way" takes a couple of months to get C++ out of your system first ;) Of course for some types of problems, C++ is indeed the better language than C, but very often other languages are even better suited (e.g. I turn to Python for most problem where C doesn't work well, for instance munching text files)
  - varajelle 5y ago
    I was referring to the things from the video, where RAII and generic types are emulated with complex macros. And where std::string(_view) is re-invented
    - flohofwoe 5y ago
      Fair point, but cleanup and string handling are hardly problems where C++ has a monopoly, or even particularly good solutions to offer ;)
    - 5y ago

pjmlp 5y ago

I wish, althought C++ was born on the same building as C (kind of) and has enjoyed first class support on UNIX, it has hardly taken its place at the kernel level or syscalls. So most UNIX/POSIX projects, even new ones, will default to C. Then there is the embedded space where almost 40 years later trying to use C++ instead of C is still an uphill battle, between embedded development communities, tool vendors, debugging tools, available libraries. Arduino and mbed are the exceptions, not the rule. Even Microsoft despite all their security talk around Azure Sphere, just releases a pure C SDK for it. Which is while I tend to rant about C, I also argue that tooling improvements related to security are more than welcomed, and knowledge about best practices when coding in C should be more widespread. It is the COBOL of systems programming languages (about 10 years younger) and it isn't going away for the foreseable future.

lmilcin 5y ago
> Then there is the embedded space where almost 40 years later trying to use C++ instead of C is still an uphill battle, between embedded development communities, tool vendors And why do you think this is so? When I was starting with embedded development I missed C++ as I felt compelled to reinvent same things that were given in C++. But then I grew up to learn there is a hefty price to pay for it and in embedded development those problems are blown due to properties of the environment and types of projects you build. It is one thing for a game to be constantly crashing and it is another if this is happening to an embedded device. When you develop embedded code it is way more important to understand exact consequences of your actions and C++ is trying to hide those from you as much as possible. There are also other requirements like being able to easily ascertain the amount of stack used, ability to use exclusively statically allocated memory, etc. that are conflicting with C++ or at least making it difficult to enforce them in C++. I am very happy to see Rust is overtaking C++ in embedded and is an answer to C problems without creating (too many) of its own.
- pjmlp 5y ago
  It is a culture problem, something that only will change with mentality reboot. "CppCon 2016: Dan Saks “extern c: Talking to C Programmers about C++”" https://www.youtube.com/watch?v=D7Sd8A6_fYU https://www.youtube.com/watch?v=D7Sd8A6_fYU "Writing better embedded Software - Dan Saks - Keynote Meeting Embedded 2018" https://www.youtube.com/watch?v=3VtGCPIoBfs https://www.youtube.com/watch?v=3VtGCPIoBfs "Embedded & C++ - Meeting 2017 Keynote" https://www.youtube.com/watch?v=mNPfsUZb3vs https://www.youtube.com/watch?v=mNPfsUZb3vs In a way, the same kind of subculture in C++ that jumps in cries of horror if you happen to use std::vector/array/string with bounds checking enabled.

wruza 5y ago

Ah, right. And all these “my move constructor wasn’t called” — “one of subfields had non-moveable field” and other arcane topics, which only C++ forums have, are just little implementation details. C++ is good when you believe it is Curly Visual Basic with some AOT speed and is an implicitness nightmare when you really care.

pjmlp 5y ago
That is the beauty of C++. I can write VB/Delphi like code with C++ Builder, write raytracing algorithms in CUDA, or just have fun targeting ESP32.

enriquto 5y ago

> C++ just has so many features that makes the development of programs and libraries easier, for almost no extra costs. I respect your opinion, but mine is the exact opposite (I don't know how representative mine is, but I'm sure I'm not alone). The problem with C++ is that many of those "features" are actually "anti-features". From the top of my head: operator overloading, copy-constructors, constructors, destructors, function overloading. While these "features" may make correct code easier to write, they always make incorrect code much, much harder to understand. For example, you find a simple line of C++ that says "y=f(x);", and it can do anything: has the parenthesis operator been overloaded? and the copy constructor? how many times is a destructor called here? What are its side effects? What instance of f is called, if none of them is defined for the actual type of x? Every single line of C++ that you have to analyze is a terrifying nightmare like this one.

jcelerier 5y ago
> The problem with C++ is that many of those "features" are actually "anti-features". From the top of my head: operator overloading, copy-constructors, constructors, destructors, function overloading. While these "features" may make correct code easier to write, they always make incorrect code much, much harder to understand. > For example, you find a simple line of C++ that says "y=f(x);", and it can do anything: has the parenthesis operator been overloaded? and the copy constructor? how many times is a destructor called here? What are its side effects? What instance of f is called, if none of them is defined for the actual type of x? Every single line of C++ that you have to analyze is a terrifying nightmare like this one. I have yet to see any of this be an actual problem in real-world projects. I have seen on the other hand a lot of people coming with these abstract "this is gonna be a problem" ideas in mind, and never wanting to touch C again after working on actual modern C++ projects.
- enriquto 5y ago
  > I have seen on the other hand a lot of people coming with these abstract "this is gonna be a problem" ideas in mind, and never wanting to touch C again after working on actual modern C++ projects. Well, I for one had the opposite experience. I started programming in C++, and writing, reading and debugging lots of C++ code. It was not "modern" C++, since I stopped doing so around 2006. I embraced C out of personal despair with C++, especially the C++ of other people. For my personal projects, I can still enjoy using "my" favorite subset of C++ (basically, without objects nor pointers, and building the data structures by composing stl containers). Yet, anytime I have to deal with an unknown piece of C++ it is a nightmare. Especially since it is very easy to hide the behavior of the code.

vadavaski 5y ago

You probably work with ultra high level stuff, which is the tip of the iceberg when it comes to programming. More than half of what is written around comes from drivers, embedded, engines, robots, controllers and kernel. And for those, you have nowhere to run but to use C down to its bottom. You might use some C++ to enforce some abstraction, iterate in a more fashionable way, but in the end, it's just C

pclmulqdq 5y ago

Honestly, I think the "killer app" for C++ was generics. If you could write a generic data structure in C without using macros (which are extremely hard to debug), nobody would have wanted C++. However, the Linux Kernel is stuck with AVL trees and primitive hash table algorithms due to complexity, while C++ programmers can blissfully use B-trees and fast linear probing hash maps without worrying about the data structure.