Slashdot Mirror
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++?
"C++" > "C" (as long as > has not been overloaded..)
Slashdot, fix the reply notifications... You won't get away with it...
Code in assembly, then you can come back to my lawn..
Sig ?
C++11 and C++14 added some nifty utility features which make the language worth considering as a replacement for C, even if you have no use for writing your own classes or complex templates (the latter being the usual reason why people would use C++).
Well C++ IS better than C. Of course C is also better than C++. As always, use the right tool for the right job.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
At some point, the developer community will wake up to just how evil C -syntax- is, and how much it has contributed to bugs and security holes.
enough sed. don't bash me.
If you post it, they will read.
This just in, slashdot diminishes usefulness of site for a day in same tired April Fools joke they do every year!
One editor was reported saying, "Yes, we've been beating this horse for twenty years now but rumors of the horse's demise many years prior have been grossly exadurated."
I ignore Anonymous Coward posts. If you want to discuss something, that's awesome. Log in.
I agree. Go is Better.
Really ? Wow just wow. You mean to tell me out of 6 billion people one of them thinks C is better than c++? No shit, in other news some people like Java over c++, some people like Microsoft over Apple, and yet others even use Snapchat instead of Facebook.
He favors automatic memory cleanup an trashes C for using marcos for it (which is indeed stupid) and favors destructors . But in that case he could just favor C# or Java. Both do the memory cleanup for you.
Also his examples look very cluttered. It looks more like a C++ lover who try to bash C.
[...] "adopting a subset of C to smooth out C's rough edges" [...]
FTFY — A little trick I picked up from John Carmack.
This is a fucking awful headline, about as credible as "Anonymous Coward Just Said Slashdot Fucking Sucks." Why should I give a shit what someone on Medium has to say? If I tweet that Perl sucks, will you post a story about that, too? The editors are worse than ever.
Seems like his gripe is actually with STL and possibly curl's interface, not C++ per se.
I like C++ (classes, exceptions etc) but generally avoid using STL except possibly for basic things like cout, strings and vectors. STL code becomes unreadable FAST, and quickly turns a simple problem into a giant pain in the ass, especially when debugging.
Set the handle to send a pointer to the struct. The handle expects a void *, so there’s an implicit cast from the struct’s pointer type to, effectively, nothing.
A void pointer is NOT a pointer to nothing. At least it better not be. :-)
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
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.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Back when I was doing my work in C, before I made the switch to C++, I developed my own set of practices that I later realized were attempts at doing what C++ did natively, including proto-classes that "isolated" variables and called member functions through a jump table (I know, I know...). So I found a lot of C++ to be pretty natural for my way of thinking. That said, C is still good, too, especially for smaller projects.
It's my most familiar language, back from when I was learning it on the schoolbus by reading K&R. I would still never choose C over a carefully-selected subset of C++ for a new project. There is just no advantage to keeping things more primitive except when it comes to very specific environments, like traditional Unix kernels. I think templates are very useful in limited doses and far superior than macros, inheritance is somewhat useful to almost any kind of CS problem, and the STL itself is a huge boon to software reliability and interoperability.
Of course, I also have no qualms with Java, so....
Brian Fundakowski Feldman
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.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
Online CS courses at colleges kick ass. They are the wave of the future.
I like the transparency of c nothing is hidden or implied it makes debugging simpler. And if your writing singletons All day every day, why use anything else. However if you heavily code data driven apps then why not use c++ too.
well there is a ++ in the name so.....
"I don't pitch OpenSUSE Linux to my friends, i let Microsoft do it for me
The problem is the ABI clusterfuck you get with compiled code, especially when mixing different C++ standards, different compiler versions (often with mangled C++ namespace mangling) and different library versions (which thanks to improper use of inheritance, operator overloading, public/protected/private namespaces, etc) end up leading to a morass of bugs in the application level code, especially if you are trying to build a project which doesn't have the exact versions of all of those used to build it documented (because it was institutional knowledge and nobody thought it was important to include!)
From a 'developing new code' point of view, C++ is nice. From a maintaining or improving existing code point of view, it is a huge clusterfuck, especially on systems that don't make ensuring slotting or abi versioning a priority (microsoft has gotten good about this since the win9x days, although they still constantly break API/ABI functionality with each new version or service pack, sometimes even in minor number releases, like the Win9x game breakage when DX8.1 came out on Windows 2000/XP...)
C++ is fine for end user applications, and CAN be fine for application libraries. But system level software and operating system kernels are DECIDEDLY NOT the place for it, unless a *LOT* of features are pared back and warnings increased for documenting how and where API/ABI changes happen between versions of code/compiled libraries and binaries.
As a master of C++, I think that C++ offers man yopportunities for misuse. But used properly, there is no really reason to "prefer" C over C++.
First, using a subset is wrong. There are times when each feature is useful, and times when features are not useful. I would say I almost never use volatile or multiple virtual protected inheritance. But when I do need multiple protected virtual inheritance, in those rare cases that I do, I'm very glad to have it. Volatile is almost never useful, but at times, I want to use it. For example, when I want to make damn sure a crypto key is scrubbed from RAM and not have my overwrite optimized out.
Let me go over what C has that C++ doesn't:
Dot-Constructors and an official restrict keyword. That's pretty much it. Restrict is supported by most C++ compilers anyway.
If I wanted to list the things C++ has but C doesn't, it'd take all day.
C++ is faster than C in practice because of templates (try std::sort vs qsort, std::sort is significantly faster), the disadvantages of C++ all involve misusing C++ features when they are not needed. They are not inherent flaws of the language.
That's why C++ is better than C, even though some people do stupid things with it.
I have been writing C since the early 80's and C++ since the early 90's. For large-scale robust systems, C++ is the way to go. It provides for greater degrees of abstraction, debug-ability, and clarity of intent. I only use C any longer for kernel development.
Sometimes, real fast is almost as good as real-time.
I tried a similar problem with ++ in for, if, while.. different flavour of unix(read compilers) gave unpredictable/unexpected results..get rid of doing multiple things in multiple ways
C++ is much better than C. It's much greater expressiveness makes it easy to clearly formulate what you are doing, and in far fewer lines of code too. Exceptions free you from all that tedious boilerplate, where every function call basically expands into three lines: error=function();if (error) handle_error (error);. RAII makes resource handling painless. It's massively more powerful standard library provide instant access to lots of useful datastructures and algorithms, and unlike C it's all typesafe too.
Is it hard to use? Hardly. I find C hard to use - just imagine having to write an application that uses strings, it'll be one giant mass of mallocs, strcats, strcpys, frees (don't forget any!), and will invariably end in buffer overflows and lost memory. Oh, and it will probably have a whole bunch of gotos for what they laughingly call 'resource management', Dijkstra's 1968 paper notwithstanding.
Do I disagree with all the criticism, then? No - but the horror stories that get posted here do tend to be worst possible cases, which pop up once in a very long while, rather than the daily occurrences some people make them out to be. It's been... I don't know, half a decade or so? since I last saw one of those horrifying template errors - and it's not for lack of templates in my code. It's not really a hard language either - sure, you _can_ write unreadable statements, but you can do that in any language so that doesn't mean much. It also gives you the tools to write much, much clearer code.
I always roll my eyes when people mention needing a 'cut-down C++'. That's lack of understanding, usually mixed with a liberal dose of unwarranted fear, and better advise would be "use common sense". For example, there is nothing wrong with overloading operators, but common sense indicates one should not change the meaning of those operators. Having your own number-like class is fine (for example, for complex numbers, bignums, money, whatever), and overloading operators for it is an excellent idea. Using operator+ to paint a widget or retrieve data from a database - maybe not so much.
So, yeah, C++ is an amazing language. Hmm, that makes me wonder if there will be an article on Medium now, revealing that someone on Slashdot just said that. I don't know that website, maybe they are not into clickbait so much...
If you don't know if it's overloaded or not, please don't call what you're doing software engineering.
You're going on about libraries.
C++ still supports the Standard C Library and raw pointers.
Your arguments, like your coding skills are weak.
I first started using C++ back in the 1980's.
I am a huge fan of classes. When C++ was basically a preprocessor for C which introduced the class keyword, I thought it was pretty cool.
When exceptions were introduced to the language I thought C++ was fairly complete as a language. If from there the designers of C++ had addressed the fragile base class problem, lambdas and some form of introspection, I think C++ would have been a fantastic language.
Instead, we got templates. I'm not a fan of templates.
And when we got the standard template library, I thought someone was smoking crack. Using the left shift and right shift operators to mean "input" and "output"? Really? Really?!?
When I write C++ I try to stick to using a subset of C++ which includes classes and exceptions. I use templates sparingly, only when they are really needed, and I refuse to use the C++ left-shift and right-shift operators. (I really feel like the person who designed that thought "how cool; we can override a shift operator to mean input and output!" But just because you can doesn't mean you should, and now we're stuck with this bit of syntactic bit of bullshit.
We're finally getting around to lambdas, though too late: Apple has already wedged blocks into a non-standard extension. And I'm not holding my breath on introspection or on fixing the fragile base class problem simply because the run-time implementation recommendation for classes way back in the late 1980's has become a baked in de-facto feature. (Sadly it would have been relatively easy to solve by introducing link-time assignment of the indexes in the virtual table pointer; that way, as the base class is recompiled the index references for the methods in the virtual table could be reassigned at link time. This also solves fragile access to public class fields; simply replace them with a standard getter and setter method which is accessed via the virtual table.)
I've programmed in both languages. Knowing C++ made me a better C programmer.
C++ done right is do vastly different from C that debating which language is better is beyond silly. This goes threefold if you look at C++14 programmed with the GSL - the right way to do C++ these days.
In a nutshell C is assembler 2.0 and C++ is assembler 3.0. C++ has massive inner api advantages over C that C tries to compensate for with libs such as boost.
Yet build with C++ without knowing what you are doing and of course you'll produce bad software. With C you simply won't get anywhere.
Wether you use one or the other these days is often a matter of personal preference more than anything else. C++ has massive ready-made power with the responsibilty that comes with it. Any programmer looking at these PLs will see the difference and adapt his style of coding accordingly.
We suffer more in our imagination than in reality. - Seneca
This all goes back to the early days and processors (PDP-11) with autopreincrement and autopostincrement flavors of register access. (e.g. a Push was a MOV R0 -(R6) ) Although B had it too, and comes from the PDP-7 days which had only an autoincrement
If you want "control of the metal", then you want both i++ and ++i.
C++ ain't that bad, it just seem to attract shit coders.
Trick reply. It's more like half a person, half a machine.
His name is...