Someone on Medium Just Said C++ Was Better Than C (medium.com)

Developer David Timothy Strauss is publishing a call to code "straightforward, easy-to-reason-about approaches" -- in an essay titled "Choosing 'Some C++' Over C". (Alternate title: "C++ for Lovers of C." The problem with just picking C++ is that most criticism of it is legitimate. Whether it's the '90s-era obsession with object orientation and exceptions or the template errors that take up an entire terminal window, there have been -- and remain -- rough edges to C++. But, these rough edges are avoidable, unlike the problems in C that get worse with modern event and library programming. The opinionated essay calls for "adopting a subset of C++ to smooth out C's rough edges," arguing that C++ offer a better, type-safe approach for event-driven design (as well as destructors to avoid memory allocation leaks). Are there any readers who'd like to weigh in on the advantages of C versus C++?

Comments

Indeed

[hcs_$reboot]

"C++" > "C" (as long as > has not been overloaded..)

Re: Indeed

[Anonymous Coward]

Trick question. There is only one ada programmer.

I use awk

[jlowery]

enough sed. don't bash me.

Undefined behavior

[Immerman]

Not quite, it is in fact undefined.

C++ is the post-increment operator, it increments the variable, but then returns the original value. Therefore, since C started out as 0x11, C++ will evaluate to 0x11 while modifying C to be 0x12 as a aside effect.

Therefore, if you were > optimistic you could try to claim that "C++ < C", expecting the operations to be evaluated left-to-right and thus be evaluated as "0x11 < 0x12". However, C++ doesn't specify the evaluation order of operators, which means that "C" might end up being evaluated before "C++", in which case the comparison would be evaluated as "0x11 < 0x11" instead. The only thing you can be sure of is that C++ will NOT be greater than C.

Basically, as a rule of thumb you should never modify a variable within a line of code if the value of that variable will matter anywhere else within that same line. http://en.cppreference.com/w/c... - discusses undefined behavior halfway down the page.

Re:Actually what the guy wrote was

[Dutch Gun]

People who know and like C will continue to use it. Giant legacy projects written in C (like the Linux kernel) will continue to use C, of course. C++ 11, IMO, is not going to convince C programmers to switch. Rather, it's a love letter to existing C++ programmers due to the radical way it transformed the language.

It's still ugly as hell, and has sharp corners that will slice your fingers and toes off if you're not careful (we ARE talking C++ here). Even so, for the first time, using just the core language and libraries (Boost doesn't count), I can completely avoid manual memory management in 99% of the cases, almost like using a garbage collector, but with the advantages of destructors for non-memory resources. Raw pointers are almost a thing of the past, except for some very rare exceptions, and move semantics means your APIs can look like you always wanted them to while still remaining efficient. It's hard to describe how different the language feels pre and post 11.

In my opinion, C++ 11 simply makes C++ far better at creating large, high-performance libraries and applications (in my case, videogames) because of the confidence that robust ref-counted resource management gives you.

I worked on a C++ device driver

[AaronW]

In the 1990s I worked on a complex device driver for OS/2 for ATM networking (asynchronous transfer mode). The driver was around 100K lines of C++ code however only a subset of C++ was used. Surprisingly the use of C++ worked out quite well. We had an equivalent driver for Windows NT that was written in C that was over 300K lines of code. The C++ codebase was a lot more reliable and easier to work on, despite all the work that was done to make C++ work in kernel mode under OS/2. The C++ driver actually had more functionality than the C driver and it was faster as well with a smaller binary. Also, as I said, it was a subset of C++, especially in the performance critical code. The driver in question included the entire ATM signalling stack and implemented full LAN emulation support with both Ethernet and Tokenring plus it could emulate multiple networks (ELANs, equivalent to VLANs) simultaneously. When I implemented multiple ELAN support I was afraid it was going to be a nightmare, but due to the way it was architected in C++ I ended up only having to change a few lines of code, changing a pointer to the LANE class to an array of pointers.

For the signalling stack and ILMI C++ worked out especially well due to the event and message based nature of it and the various state machines. For LAN emulation it made it easy to support both Ethernet and Tokenring by having a few virtual functions in the main LANE class.

There was no exception handling support and none of the more complex C++ features were not used. It used templates but that was also somewhat limited.

Having destructors was also quite nice, making it easy to clean up resources.

Despite being C++, debugging wasn't too bad though at the time the OS/2 kernel debugger basically ran at the assembly level.

If the infrastructure is in place I can certainly see using C++ in the kernel and device drivers.