Slashdot Mirror
Was Linus Torvalds Right About C++ Being So Wrong?
Nerval's Lobster writes: Perhaps the most famous rant against C++ came from none other than Linus Torvalds in 2007. "C++ is a horrible language," he wrote, for starters. "It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it." He's not alone: A lot of developers dislike how much C++ can do "behind the scenes" with STL and Boost, leading to potential instability and inefficiency. And yet there's still demand for C++ out there. Over at Dice, Jeff Cogswell argues that C++ doesn't deserve the hatred. "I've witnessed a lot of 'over-engineering' in my life, wherein people would write reusable classes with several layers of inheritance, even though the reusable class wasn't actually used more than once," he wrote. "But I would argue that's the exception, not the norm; when done right, generic programming and other high-level aspects of C++ can provide enormous benefits." Was Linus going overboard?
The problem with C++ is that it's way too easy to write write-only code, because the language has so many features that nobody but language experts understand all of them. So we all program in different dialects, and then scratch our heads when we read other peoples' code.
I always get halfway through a Nerval's Lobster summary before my anger/indignation/smug validation gives way to the sad realization that Dice has trolled me yet again.
I'd the this 'real language' to get rid of those god-awful headers and support ^ as exponentiation - something so commonly used. Less bloat would be nice too.
Why OpalCalc is the best Windows calc
Could we stop having Dice articles submitted by Nerval's Lobster? Why not fully disclose that the story was submitted by the corporate parent of Slashdot?
Oh no, on the contrary. There are plenty of idiots who can write code in C++.
/ Grabs popcorn
// Dons asbestos armor
C++ deserves all the hate it gets. Life is too short and mental health too precious to become an expert in C++.
if you're writing an OS or firmware? sure, use C++, it exposes abilities you might need
but you can shoot your foot off easily doing esoteric things with C++ that other languages just don't allow you too do easily, because for 99% of programming tasks they aren't necessary. other languages provide straightjackets and limited functionality in low level tasks that, well, for safety reason you actually want, it protects you
maybe those esoteric things are important to do. but usually they aren't
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
I've found a lot of the stuff C++ does that people come to hate with a passion is a direct result of what the compiler does, rather than anything the programmer intended.
+1
Linus was not going overboard. In this rare instance, I'd argue he hasn't gone far enough.
The ability to fuck it up is a good thing, because there's a spectrum, and you can also knock it out of the park.
What comes next, a thread on "is Emacs better than Vi"?
My first program:
Hell Segmentation fault
Although the language itself isn't truly, truly bad, the only thing that made it tolerable was a library like Qt. STL and Boost are so shocking it isn't even funny, as well as the attitude amongst many that they are some kind of 'standard'. That's where C++ really did go off the rails.
Need the ability to moderate an entire Article/Summary as Clickbait or Troll.
I have read maybe 1 billion articles about language X being better than language Y and in many cases it is pure religious fanaticism; someone has committed to a language and now justifies that commitment with zealotry. A very common refrain about any given language is how many people write poor code in that language. This argument is often reserved to support the more "sophisticated" languages. For instance it is pretty much a gold medal sport to crap on PHP; and yes there is lots of terrible PHP which probably stems from the fact that it is often someone's first language and that someone is self teaching.
Then other languages are looked at as toy languages by those who resent them, Python would often be a victim here.
Then there are the wonderful charts of speed which in theory would justify everyone using ASM optimized to their CPU.
But for me it is not one language but a pairing that has caught my heart. Python and C++ do just about everything I want. Python is just so damn productive. Then I use C++ for where Python falls down on speed or the environment itself is not conducive to C++ (embedded and multi-platform Mobile).
But to answer his cry about people over-engineering things with silly STL uber inheritance type crap. That is where oddly enough the zealots of C++ are their own worst enemies. They love C++ so much they are giving it a bad name. Many people use STL in some purist way that completely blows Keep It Simple Stupid out of the water.
But I really do hold a special revulsion for anyone who claims that their language "Enterprise" which translates to me as so shitty that nobody will notice that most of your drone developers are also shitty.
If you care about performance, the ability of C++ to "run on the iron" is a valuable tool to have in your arsenal. Add in inline assembler, and IF YOU KNOW WHAT YOU'RE DOING you can write blazing fast code in C++ and still provide a sensible code architecture.
There's no sense in blaming the language for the abuses developers have written -- you might as well indict English for the horrible spelling and grammar of many Americans...
If you know what you're doing, C++ is a terrific, powerful language suitable for a plethora of projects. On the other hand, if you don't know what you're doing, well, I guess there's Visual Basic or C#.
There are good features and there are bad features. If you don't like funky object features don't use them. Destructors are great for end of scope clean up. Having to rely on exceptions to catch constructor errors suck.
The deal breaker for me is the poorly designed header system. I cannot write a class without truly hiding its inner working. I have to put all of my variables in the header even though they have nothing to do with the functionality i expose to the external callers.
I add an irrelavant variable and everybody who includes my header needs to recompile.
For me c++ and gets in the way of mental separation of functionality into modules and libraries. So i suspect they were not designed by people who actually worked on large projects. They look good on paper and in the classroom no doubt.
In 1998 David Gelernter wrote a book that effectively argues that elegance and beauty in engineering are essential features that lead to benefits beyond the merely aesthetic.
He is still right.
The 'elegant' and 'concrete' example in TFA is ugly and hard to follow, even with plenty of understanding of lambda expressions and languages that offer them. I have other, better high level language options and other, better low level language options. C++ fails the test. C++ is not for me.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Yeah, great idea, let's take a language whose roots are in the 1970s and break backwards compatibility to increase its appeal to young people with six digit slashdot IDs.
If C++ looks bloated to you, (a) define bloat and (b) name some languages you have used, that you consider not-bloated. Good answers are available to both questions; I want you know yours.
Pretend that something especially witty is here. Thanks.
All C++ developers shunned for writing in a language considered to be crappy and producing crappy programmers making crappy programs, feel free to drop by and spend some time with us PHP devs, we'll share tips on how to not feel so bad about all the mockery and abuse.
Yes
My professor at HPU once told us the advantage of the C Language was that it was loosely typed. and the biggest problem with C was that it was loosely typed. fun stuff... C++ just built on that... and from prior comments, I'd say there are as many lovers as haters of C++... but, I'm not a coder, just a lowly sys admin and my preferences really don't matter. (I learned top down programming in PASCAL... so...)
"Over at Dice"
Excuse me, Dice owns Slashdot.
Mandatory disclosure, please.
Dude, the original poster who claimed that C++ is bloated probably loves him some Java or C#, both of which are arguably even more bloated that C++ is, since the "bloat" of C++ is the STL and Boost... which is comparably smaller than .NET, Swing, JavaFX, etc.
I agree that C++ sucks and all my coworkers who can't code worth a shit use it, but I wonder what he recommends
Modules are coming in C++1z (the next revision of the language) most likely. That should solve many of the (real) problems with #includes.
then you're going to write bad code in any language.
I've used many languages including C, C++, Java, Pascal so let me express that a language and the libraries that come with a language are so closely tied together in most programers minds that they don't actually know what is the language and what isn't. *grumble* Java project with three different XML parsers in it *grumble* My biggest problem with C++ is people don't use it right. Like in C people write allocators rather than use "new". Really? If you think you are smarter than the guys doing the language lib and compiler then go write your own language. They use STL until their code looks like the aftermath of a Blendtec video. And they have dozens of classes inside a single .cpp because #ifndef #include #define #endif is a horrible mess. So yes Linus is correct even today, bad programers use C++ and make a mess. Linus is wrong however that this is somehow limited to C++. What Linus should be saying is language designers trying to do elegant, need to know not to cross the line and throw in the every last buzzword. Generics are nice, functional programing can rarely be useful, ability to redefine operators probably goes too far, if you feel the need for more than a single String type then you are almost certainly wrong, pick one of: new/free, reference counted or garbage collected.
Linus was right (I didn't agree with him when he wrote that but I do now). Jeff doesn't answer any of the major issues with c++: Lack of standard ABI (preventing interop with other languages), insanely complex grammar, years of paradigm shift, action at a difference, lack of abstraction away from computers, etc. Java/C# have completely displaced it in the business world and C still dominates system programming. C++ would be already obsolete except that it caught a big with the gaming industry...real-time games can't tolerate GC languages and C is considered too baroque to many developers.
And from what I've seen they specialize in beating dead horses for clicks.
Linus is doing systems level work. At systems level work, there are a lot of mediocre and bad programmers who use the common language of C++. Those who know c well are unlikely to be the mediocre and bad programmers.
That is really a truism across all fields and languages.
In the business world with business logic, there are a lot of mediocre and bad programmers who use the common language of Java. You can filter out many of them by adding a skill requirement of some other less-used languages inside that realm of business software development.
In a field where everyone is doing Ruby development and you don't want mediocre/bad Ruby programmers? Require them to also demonstrate proficiency in another language.
In a field where everyone is using C#? Require them to also demonstrate proficiency in C++ or some other language.
If you only require a single thing you can get unskilled individuals with only a single skill. If you require multiple skills you are more likely to get more talented individuals, since the talented, higher producers tend to pick up a wide range of skills.
//TODO: Think of witty sig statement
I just looked through Nerval's Lobster's last 15 contributions. All were article submissions, Nerval's Lobster doesn't appear to comment on anything. Here's the list:
Every single one of them is from dice, though only a few of them actually make that explicit (the non-explicit ones are marked [Dice*]. A large fraction of them are related to human resources and hiring people, which I've marked [Hiring]. So its like Nerval's Lobster is using Slashdot as advertising and recruitment channel for Dice.
The average quality of these submissions was very low in my opinion - lots of vacuous pointy-haired-boss buzzword stuff. Very un-nerdy. How did these get through submission moderation? Were they even subjected to it?
Linus makes the argument for SYSTEMS level code. Jeff even agrees in his article about systems level code. Why is it that every time linus opens his mouth everyone blows it way out of proportion. he is a systems level guy, someone who likes hacking away at that layer of code that most software developers are remotely aware that exists. So of course he is going to prefer a language, that allows him to write elegant code while minimalising foreign dependices and useless api calls that usually dont work like the doccumentation states.
Who ever this Jeff guy is, go find something useful to do.... like CODE, rather than create a crevat from someone elses argument for the sake of proving a point (which you failed horribly at by failing to understand the standing point of the original author) and no you are not smarter than linus was in 2007, you are just an annoying journalist using a community new site to promote your self through company affiliations..
Listen people from DICE, this is the stuff we hate. Its blatantly obvious and insults the intelegence of most people here because we know that this is corporate drivel and not a community submitted news story. maybe we could change the colour of all dice sponsored stories to a red banner as opposed to the normal /. green?
"C++ is like those freakish experiments that only take place at the infancy of a new science. C++ is to computer science as Frankenstein's monster was to the field of anatomy. A monstrous abomination that surprisingly draws some love from a minority of strange people that swear they understand it." - Paymon Yamini Sharif
C++ was the first popular fast OO language. As such, there's a lot of confusing cruft left behind. Consider overloading the && operator or || operators. You should never do this*. But someone will come along and do it anyway. You can't get rid of the feature because of backwards compatibility and yet it's miserable. We can go down the list from polymorphic arrays to calling virtual functions during constructors. All things one should never do, but the language keeps them there for the sake of backwards compatibility.
Languages like Java fix some of these problems by explicitly not allowing operator overloading (which is heavy-handed) but enforces some readability.
As others have said, using good 3rd party libraries like Qt makes the language tolerable, but in the legacy applications I've supported, there's no shortage of programming faux pas made possible by the language (like assumptions about the order of static variable destructors -- which is compiler dependent). As a programmer, it can be fun and productive since simply using the better parts of the language can make programs easy to write and read. As a maintainer, it's a smorgasbord of bad programming practices which the language makes no attempt to prevent.
That said, Linus really likes the new version of Subsurface based on Qt. So there;)
* Scott Meyers More Effective C++ p.35
-- Political fascism requires a Fuhrer.
C itself has so many pitfalls. For the best tour review the underhanded C contest. "features" like automatic concatenation of consecutive character strings means that if you leave out a comma in a list, the adjacent array element entries are concatenated rather than throwing a syntax error. That list will now not match the declared array size (one short, so there's a null or random pointer in the last element) but the compiler allows initialization listed mismatched to the array sizes. Character strings have to be declared one longer than the initialization string length (room for the unstated \0) but are accepted by the compiler if they don't giving an unbounded string length.
it's mind boggling to realize that
int (*int)[20];
int *int[20];
are different things.
the number of different ways an array argument in a function can be written makes code hard to grasp: is it a pointer, an array, a reference? many work alike but then fail in different ways.
The most common of all pitfalls and hard to read codes are the in-line initializations that pop up in function arguments and what not. this leads to classic blunder of writing = when you mean ==.
Perhaps the most insane thing is that If you declare an external function with the wrong prototype then any mismatch in the argument count leaves or takes something off the stack. Holy cow..... I mean what the hell? Why would any language ever ever ever let you leave a orphan argument on the stack, or worse pop one off that was not yours? This is very useful for the underhanded C folks however.
While I know there's little love for fortran, it's worth noting that none of those things is even possible in Fortran, so its an existence proof that there's not any necessity for those to exist and that it doesn't limit the power of the language to remove them. It's very fair to say that no simple typo will ever compile in fortran (yes very complicated offsetting typos can compile).
Some drink at the fountain of knowledge. Others just gargle.
"It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it."
That seems like a strange statement coming from someone who is one of the best programmer's on the planet - and who works closely with some of the others.
I don't disagree that C++ provides a lot of rope for substandard programmers to hang themselves with (and I've seen that done by someone who created layer upon layer of useless classes), but I assume Linus Torvalds doesn't hang out with too many "substandard programmers." So what's he afraid of?
Although C++ may not be for everybody, and it's far from ideal, I think it's generally a pretty good solution for the problems it's trying to solve. And it's not just me: it's notable that it dominates its niche as the primary C-inspired, object-oriented, compiled language.
The major problem with C++ is that it's popularity means there's more crap code written in it by bad programmers than any other language. But, to borrow from a quote, a bad programmer can write bad C++ in any language. I've had plenty of experience with bad programmers and bad code, and the problems rarely stemmed from the language used. They usually stem from the programmer not understanding the language or the environment and from an all-too-common mule-headed desire to design their part of the software the way they want it to work rather than in a way that fits with the rest of the software. Languages where this isn't a problem are typically new enough that there's only been one "right way" to do things taught. C++ is old enough that there's a variety of approaches built up over time, leading to the problem.
As for C++ being so popular, that's because well-written C++ can beat most other languages in performance. I've learned one thing over the decades: good engineering in software is a great priority as a developer, but from the business side it's irrelevant. Business cares that it gets the correct results and it runs fast enough. It could be the worst Rube-Goldbergesque contraption under the hood, but as long as it gave the right results and performed like a Formula 1 car they'd be ecstatic. C++ makes it easy to achieve that in the complex software common in commercial environments.
.NET and Swing don't change the language, they add APIs. STL and Boost ... Well, let's not even get started. In C++ you can write your entire program with the C99 preprocessor, there is not even any need to write C++ to do things. The preprocessor itself is turing complete. Talk about over engineering.
Write boring code, not shiny code!
This is all true, but I'm not sure how it's any different to almost any other popular language.
Java and C# have also evolved a lot of new language features in recent years. For many types of software, the way the code looks will also be heavily influenced by which libraries and frameworks are used in that project's stack.
It's the same story for web development. We have different flavours of JavaScript (ES5 in most browsers today, but ES6 just around the corner and supporting a wider range of programming styles), Python (2 vs 3), and so on. And with these more dynamic languages, the style is often even more guided by a framework if you're using one.
Even if you're not using pervasive third party frameworks or libraries, any project of non-trivial size is going to adopt its own conventions and build its own abstractions to suit its particular needs, and then the rest of its code will again become its own dialect written in terms of those conventions and abstractions.
In fact, I can't think of any mainstream language except for C that doesn't suffer from the "dialect" problem to some extent. And that's because C is a 20th century language in a 21st century world, so lacking in expressive power that it can't support any of these modern, high-productivity development styles and abstraction tools. Its ubiquity, portability and simplicity are assets, but they are effectively its only redeeming features in 2015, and as time goes by it will be necessary for fewer and fewer projects to choose C for those reasons.
"There are only two kinds of languages: the ones people complain about and the ones nobody uses." -- Bjarne Stroustrup
"If you attack a tool based primarily on not liking the people who use it, you're still just a bigot, no matter how famous you are." -- Anonymous Slashdot poster
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
C++ = all the performance of assembly language + all the ease of use of assembly language.
C++ is very powerful. (Much like gasoline)
You can write high performance systems code that is well structured and easy to read and maintain. (rare, but possible)
You can write garbage that is bloated and fully ofuscated while still following perfect OO practices. (much more common)
The problem is to have the good sense to restrain how clever you get when using it.
C is less of a problem in this manner because is has less ways to get clever.
One can still make quite a mess with it.
Witness another example that is both horrible and wonderful.
The Linux kernel.
Python might be clean, but I can't build Android apps in it (yet, and not using a product officially supported by Google).
I can write high-performance engines in C++ (which can out perform equivalent Java code), and then port that code to Android, Windows, Linux, or pretty much anything.
C++ is really frustrating for developers who don't like working with low-level code. Those of us who do can make good use of object inheritance for code organization. Of course you don't need objects for that...you can do it all in straight C. But most (excluding Linus) of the people who hate C++ hate it because of how similar it is to C.
And, of course, anything can be done wrong. The pain of mistakes is felt more poignantly in C++, producing a need for greater vigilance. That is a challenge that few are ready to accept.
Have you got a source to that? I know it has been suggested numerous times, but I've yet to see anything to state that it's actually picked to go into the standard.
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
I have discovered late in the game that Python + Fortran is almost magical. It's better than Python C++. when you are needing fast algorithms or code close the metal (SIMD or GPU) then fortran provides all the muscle that you need without all the baggage of c++. You offload complex class and memory allocation to the python.
The amazing thing I really like about the fortran is that it compiles so damn fast compared to C++ that it's easy to write a python program that generates optimized fortran and then compile it at run time rather than simply pre-compile a C++ library to include. The fortran is cleaner looking and its hard to make typos. The limits and ugly bits of fortran are pretty much not a concern since those chores can be offloaded to the python.
Some drink at the fountain of knowledge. Others just gargle.
Languages run the gambit from script kiddie interpreted languages that were designed for children to cut and paste examples from the internet to esoteric languages meant to be used only by doctoral students doing research. C++ is a nice middle ground that requires some expertise to use correctly, but offers immense power if you take the time to develop that expertise. I've written 3d accelerated GUIs with it, I've written mathematical algorithms with it, I've written real-time embedded applications with it. All to great success. Of all the languages I've encountered in my 14+ years as a software engineer, C++ by far covers the broadest spectrum of possible applications.
Any Popular Language Attracts Dolts.
Just look at Java, Php, BASIC, ... and now, Python.
Was Linus wrong? Maybe not. Does it only apply to C++ - definitely not.
It's not operator overloading, not class inheritances (per se), not any of the features "only language experts understand", but that an entry into a program code segment can do a vast amount of work that is absolutely not coded in that program, that understanding the code requires far more than the code in front of you.
Default constructors. And, yes, this is down to class inheritances, but only if they do something with the constructors that isn't going to be obvious, hence my point. You need to know what other code does too now.
EVERY higher level language has this problem.
Hell, if you have a language that all it does is make pointers safe, but otherwise no higher than C, you may not know what it is *actually* doing. Which is not necessary when the code works, but when it doesn't, can be harder to work out why than the dangliest C pointer corruption.
This must be prefaced by mentioning that I have little experience with C++ code, the industry that I am in (Safety Critical Avionics software) absolutely refuses to use the language. In fact, the only thing I can really comment on are the reasons given to me as to why it is not used in this industry.
Compiling repeatability
Part of Safety Critical Avionics is that the binary must be perfectly re-creatable. At any time if an issue comes up someone must be able to rebuild the configuration used for compiling (versions, software packages, patches, etc.) and get a perfect match to the released binary, bit-for-bit perfect. Somehow most C++ compilers and libraries are unable to achieve this, using the same exact machine (no patches or changes) and compiling at a different time gives a different result. This has been demonstrated on several different compilers, using nothing other than standard libraries.
Code-to-binary and structural coverage analysis
For DO-178B Level-A software (paraphrase: "If this software fails, people die.") there is an analysis performed matching every line of code to a block of assembly, verifying that the compiler didn't add anything in that will cause issues. This prevents using some optimization options in C as that makes things too unreadable. However that also excludes C++ STLs and Boost libraries, as once you get into those libraries the traceability breaks down into impossibility very quickly.
Internationalization
On the side our company works on non-safety-critical software projects as companies need our help and we are looking for work. One of those side jobs is taking an application written over several years for a research facility and making it ready to be sold internationally. The project uses C++ and is converting X11 and Motif to QT, at the same time updating it to go from hard-coded English to strings that can be translated to multiple languages. The amount of cursing I hear from those engineers dealing with the internationalization of C++ far outweighs everyone else in the company on all other projects, apparently the design of the C++ language made many decisions that make such efforts very difficult.
So, mostly hear-say but from trustworthy and knowledgeable people, which is why I rarely touch the language.
DEMETRIUS: Villain, what hast thou done?
AARON: Villain, I have done thy mother.
Shakespeare invents 'your mom'
Austin Lounge Lizards
I have mod points and I am not afraid to use them
I have noticed (in myself, as well ) that when learning a new area of C++ the tendency
is to use the new hammer on everything that looks like a nail - in other words, EVERYTHING...
I have had to become rather self-critical about what tool ( C++ has many ) to use for a specific task...
I submit that the same applies to ALL programmers enthused about a new tool... in ANY language...
So the programmers are at least half of it.
The other half is half-ass completed or poorly designed APIs ( MS, SUN), compilers that are not quite implemented (MS, SUN),
and the incoherence of volunteers developing modules and add-ons to languages ( Python, maybe PHP, RUBY )
that are not competely tested, or have quirks that are not documented ( work-arounds ).
Most of this part comes from the 'GET IT OUT THE DOOR" mentality that has produces OSs that need >500 MByte updates,
versions that fill in the 2.xx with xx being from 01 to 99, and worse than the MS 'DLL HELL", where things require different
versions to operate properly, or at all...
Bah - this is not engineering, where methodology/planning/foresight/completion/testing/documentation is a standard. .NET - just like VB6.
This is software, where the latest and greatest of anything might not be complete, but is so new and shiny that the
young software people expose their inner blondes. Or the old software people skoff and try to keep the thing they spent
years learning...
XML is just structured text, DOM is just structured text, stylesheets are just more text that acts like
program directives, MS wants to back away from
STL is just a new way to do what can be done through inheritance, with many more caveats...
and Adobe Flash, Macromedia SW, and all the Intertubez Tuulz are just ways to make proprietary
things workable, and esy to use...
Looks like I just might be cynical - or maybe dead-on.
Set aside for a moment about which programming language you like to use the most, and how much it upsets you that "People you Do Not Know also Do Not Like what You Like". Many of us are employed to work on projects we did not start. In most cases, you are not going to start a job and tell people 'Henceforth, all code shall now be implemented in the One True Language'.
Assuming that, which language is going to get you paid the most and make you most employable?
I am a game developer, and I have worked on consoles and currently on mobile games. I have used mostly C++. But I have had to work with pure C and C#. Being able to write good code in C++ is primarily responsible for me being employed.
END COMMUNICATION
Good to see a decent post in a deluge of trolls trolling trolls under a troll article posted by Dice Co. shill er I mean Nerval's Lobster.
"Politicians and diapers must be changed often, and for the same reason."
I see lots of responses from folks attacking the flippant parts of Linus's comments like they were deciding factors. This tells me that you're not getting it. Maybe you've never used C++ for significant projects, or really only relied on the C-like portions of C++ and eschewed the other stuff.
The fact is, he barely even touched upon the real problems with C++, only mocked and ridiculed people who favor it. This wasn't an argument, this was just an insult.
However, if you want reasons, you can get them from one of the best sources possible. Find or purchase a copy of Effective C++ and More Effective C++ and while you're reading them, keep track of all the 'gotchas' that will tank your programs. From accidentally instantiating a dozen copies of an object to double-freeing it, you should swiftly realize that most of the code you wrote was a time bomb, hidden away in a layer or two of abstraction. That 98% of the code you've ever seen that's larger than a handful of classes is like this.
If that's not enough for you, look up the various ISO/IEC standards, and look for all the parts that are explicitly aimed at reducing ambiguity. From the start, C++ has undefined behaviors built right in, leaving it to the compiler to determine how syntactically correct code will perform. They're still trying to fix them; I hear c++17 is on the horizon, but in 2007, it was just a field of landmines if you started using the advanced features like templating or multiple inheritance.
The short version is that it was not a very good language. In the race to produce "C with classes," delivery was prioritized over quality, new features rather than stability, and the standards committee, partly in an attempt to maintain backwards compatibility, has produced a fair mess with overly complex syntax.
I've written a lot of c++ code, and I can't believe anyone who also has would prefer it to C, or something newer like Java, C#, or even scripting languages. I really have to assume that if you really vehemently stick to it, you're either a C++ guru with a few books and a decade of conference presentations, or you're a novice who hasn't done enough to understand the limitations.
A lot of developers dislike how much C++ can do "behind the scenes" with STL and Boost, leading to potential instability and inefficiency.
What does that even mean? Isn't the same true of any library in any language? And can't they also lead to greater stability and greater efficiency?
systemd is Roko's Basilisk.
One can achieve amazing things with C++. But doing it well requires that one be a genius. Not everyone is a genius. Non-geniuses need to use simpler tools like VB.NET to get useful things done. Naturally, non-geniuses will find C++ hard and hence will hate it. The reason they attack it, however, is because they recognize the great things that have been done with it.
If C++ was some obscure language that nobody used, nobody would care how horrible it is. But precisely because many geniuses have made such profitable use of C++, the non-geniuses are confronted by it and are unable to compete. So, they attack.
Attack away. Meanwhile, I will stay busy writing engines that scream!
I can't think of any mainstream language except for C that doesn't suffer from the "dialect" problem to some extent
What about GObject?
As you say, C is a very bare-bones language, so it's not uncommon to see the object-oriented wheel reinvented as a C library, incompatible with the other such reinventions.
Casting is telling the compiler to do what you want. It's like saying "Shut up! I know what I'm doing, this thing is a XY pointer, even if you can't figure it out yourself."
In every language (which supports casting) you can make an error while casting by claiming something that isn't correct. Surprise!
I have programmed in C for 30+ years and C++ for 20+ years. For complex systems, I like C++. Unfortunately, starting with C++11, the language standards committee has forgotten the KISS principal, and that is probably what irritates Linus more than anything (not sure, just reading between the lines), as well as myself. I have written "object-oriented" code in C, but some of my projects could not have been written effectively in C, but C++ let us do some amazing things, and much simpler and quicker than doing them in C.
I personally don't think there are idiots who can write "decent" code in C++, and there are plenty who can write horrible code in C. Some parts of the Linux kernel make me shake my head in despair! Writing decent code in any programming language is not for idiots, but for people who are thinking about what they are doing, modeling it rationally, and then committing that model to code. I like to start with UML - it allows me to look at the data structures, relationships, behaviors, and then understand what I have missed. I spend 80-90% of my time modeling, and 10-20% writing code. That has allowed me to create reliable systems in 1/2 or less time than other approaches.
C++ is a disaster for kernel development.
I honestly have no idea, so: why?
It's obvious to me Bjarne Stroustrup doesn't have a clue regarding C++ and programming for that matter.
Can we please apply Betteridge's law of headlines both to the story title and the question at the end of the summary?
Interesting. Do you have a web reference with a how to or example? I like the idea of using python to generate code; I have done it in the past to generate a multi-thousand line shell script (actually an xjobs script, but whatever) to generate animated movie frames.
You said a lot to say this. It's obvious to me Bjarne Stroustrup doesn't have a clue regarding C++ and programming for that matter.
Compared to C, sure. C was conceived in a spirit of pragmatic minimalism that's easy to love. I remember learning C from the K&R book back around 1980. That book was so thin it was practically a pamphlet next to books that taught you other languages. Everything about C was so neat, and trim, and cogent -- even the book everyone learned it from. That plus The Unix Programming Environment and perhaps Software Tools and you were cooking with gas.
It's natural to compare C++ to C; the very name encourages you to do so. It was to conceived to dovetail and build upon C. But it was conceived with an almost diametrically opposite kind of philosophy. C chucked out all the precious features that designers were putting into languages in the late 60s and early 70s and went with a tiny set of proven useful features. C++ implemented every bell and whistle anyone had ever dreamed up for object oriented programming, which was largely an academic topic that was full of clever but impractical notions. Well, it turned out that a lot of those things like operator overloading and multiple inheritance weren't all that useful in the judgment of later language designers, but you can hardly blame Bjarne Stroustrup from knowing that in advance.
It's practically impossible to overstate the practical success of C++. It took what was for most practicioners a theoretical idea (object oriented programming) and made it the way everyone programs by default. But you can't expect someone who loves C to love C++, which has almost none of the virtues that people admire in C.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
C++ is indeed a horrible language, and it attracts people who develop great pride in their memorization of needless complexity.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Yet from what I've read, the Joint Strike Fighter project used large quantities of C++ in their systems.
That's like saying words are bad because we've read some bad poems written with words.
I think all things that come from Linus are bad because he's said a few stupid things.
You can argue about whether C++ is a horrible language (I lean toward "yes") in itself, but the libraries are what really push it over the edge. STL is hands down the worst collections framework I've ever encountered. Consider just a few examples of how you do some common operations with it, compared to doing the same things in Java and Python.
1. Check whether a string s ends with a suffix t.
Java: s.endsWith(t)
Python: s.endswith(t)
C++: s.rfind(t) == s.size()-t.size()
2. Check whether a collection c contains an element e.
Java: c.contains(e)
Python: e in c
C++: c.find(e) != c.end()
3. Split a string s into tokens based on whitespace.
Java: s.split() ... do you really want to know? Ok, check out http://stackoverflow.com/quest.... There you will find dozens of proposed solutions (many of them quite indecipherable), along with lots of debate about which one is best. The top voted solution has a comment on it (with several hundred votes) saying that it's a bad solution and you shouldn't use it.
Python: s.split()
C++:
Doing even really basic, common operations with STL requires way too much work and produces absurd, hard to read code.
"I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."
... compared to KCML! Kvetching heard of it? Try and keep it that way lol!
Honestly, I find a random program written in C to be on average FAR less maintainable than one written in C++, usually because they end up reinventing the wheel about 50 times, usually poorly. The C program that I work on at work is one gigantic mass of poor wheel reinvention over and over again. Its impersonation of objects and inheritance (for sending message) is terrible, utterly terrible, it's almost impossible to build and send a message without messing up in some way due to all of the interconnected pointers. The macros they use to try to "simplify" it only make it worse. Some parts of the code have macros nested literally dozens of levels deep.
"Are you hungry? I haven't eaten since later this afternoon." -- Primer
Torvalds: C++, your father made you /wrong/!!
C++: Nooooo, baw
Linus is often right, but opinions are just that, they can not be proven one way or the other.
While C is my "native" language (having programmed in it since the mid 80s), C++ is definitely my "favorite" language -- and that includes the STL. Yes, people can fuck it up, but if you have fucked up enough code in the past, and have learned which end of the sword to grasp, C++ can be a very, very precise and very effective weapon.
I was a total n00b when studying C++ in college, having only dabbled with BASIC, Pascal, C and ARM assembly before. But C++ surely felt way over the top.
void (*signal(int, void (*)(int)))(int)
with signal as a function that takes one int and one pointer to function that takes one int and returns void, and which in turn returns a pointer to function which takes an int and returns void. Thankfully, this shit is seldom seen in most applications of C, except in very specialized cases.
The rest of cases it's nothing mind-warping if you know the rules.
True enough. It's always mildly amusing when someone criticizes a programming language for having features that let a programmer hide behaviour... and then advocates using macros in C instead.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
But who is Nerval's Lobster and why is it his job to post submissions with links to Dice.com?
You're all talking about C++ and not LINUS TORVALDS! Have you all LOST your MINDS!? ;-)
"Flyin' in just a sweet place,
Never been known to fail..."
It is mind-bending to see so much people who call themselves C programmers, and judge c++ based on what terrible things you can do with it...
News flash : you can write horrible, horrible code in C. Actually much much worse code than you could ever dream of in C++. At least C++ provides type safety unless you explicitly try to work around it.
But the fact remains that idiomatic, good C++11 or even C++14 code is much more readable, much more safe and much faster / easy to write than C11 for anything non-trivial.
I really don't understand Linus' argument about horrible programmers of C++. From my experience, bad C++ programmers write "C style" C++, so basically, bad C++ programmers are C programmers that were told to use classes, i.e. people who don't know C++.
The amount of cursing I hear from those engineers dealing with the internationalization of C++ far outweighs everyone else in the company on all other projects
To be honest you'll hear anyone writing C making almost definitely the same complaints if they need to internationalize and localise software. Internationalization is easy if someone has already put the messages into message catalogs (but usually ugly) localisation is the hard part if you also need to add support for multi-byte languages. Dealing with character strings that can be a series potentially multiple byte sequences breaks a heap of crappy optimisations that people write for the C and other single byte locales (I hate EILSEQ).
STL and Boost are (collections of) LIBRARIES (most of which are excellent 0-overhead, and type-safe). Are you trying to tell me there doesn't exist one single bad C library ?
I write DO-178B Level-A software for a living in C++. This is exactly the kind of rhetoric that I hear from a regular basis from people that refuse to change from how things were done 20 years ago in avionics. There is guidance from the FAA on how to handle object oriented technology but you probably haven't read it because refuse to touch the language. We don't use templates period (no STL obviously), no multiple inheritance, no operator overloading, on and on... That said there is an advantage to using the language and I'm just so tired of hearing avionics people saying things like the language is not certifiable and digging into a bunch of uninformed assumptions. Grats on being the grumpy old man at your company.
and I say this as a professional C++ programmer. Nothing is straightforward. There are many ways to do anything, and every one of them has edge cases which don't do what you expect. It's got classes, templates, and functional stuff, all of which has bad syntax and works poorly together. It's got two things going for it, inertia from existing codebases and lack of any better on-the-metal language (unless you're willing to restrict yourself to C, which seems like a good idea much of the time).
Ask a C++ compiler implementor about it sometime.
This must be prefaced by mentioning that I have little experience with C++ code, the industry that I am in (Safety Critical Avionics software) absolutely refuses to use the language. In fact, the only thing I can really comment on are the reasons given to me as to why it is not used in this industry.
Compiling repeatability
This is plain wrong. I mean it is not even wrong, if you do work in this industry then this is a lie.
Lots of software in lockheed martin's plane is in C++ for instance. Hell some technical chief officer of Lockheed even gave a talk about the SF++ coding guidelines they use @ cppcon14.
On your other points : I design software for safety critical components in Nuclear power plants, and C++ has replaced Ada in most devices in the last 5-10 years.
The last 2 years we wrote a complete full scale numerical simulation of the Command room of the powerplant, in C++/ QT / QML. Internationalization was done using QT mechanism and it works great... You had you wrap all your strings in "tr()". BOOM. Done.
Last but not the least : C++ != (Boost || STL)
C++ is a language specification. Boost is a collection of libraries, most excellent, some terrible. YOU DO NOT HAVE TO USE IT. The std c++ library (STL died 10 years ago, way to be a la page...) is as you could have guess a library. You don't have to use it either.
ANd BY THE WAY : most of the C std library sucks too, and is prohibited to use by MISRA C. So stop reading or hearing FUD. Read the std specification if you want, or better yet read a good recent book about C++14 like the one from Bjarne S. You'll see.
I agree with you on the compiler thing though. that is quite true.
What's stopping you? Define your own classes for numbers. Or write a preprocessor.
Contribute to civilization: ari.aynrand.org/donate
> writing "C with classes" (which many do)
Is it only me that are interested in writing "C++ without classes"?
We have a couple systems at our company. One, fairly straightforward OO host system, the other a truly embedded legacy pure C system. When it comes to writing unit tests, polymorphism wins hands down. We have to "re-invent" this in the C-only system to get unit testing working. PIA.
Yet, we don't use C++ in planes, but it's used on the Mars Rover. There's no life at stake, but there are still billions invested in it, it's not risk-free and yet it makes sense and was successful.
I suggest you watch the talk from the CppCon 2014 conference where they explain how they did it: https://www.youtube.com/watch?v=3SdSKZFoUa8
I'm not trying to say that you should definitely switch to C++, but maybe some requirements are over protective and could be reevaluated. Also, compilers change a lot over time and could very certainly achieve what you need if your industry was working with them.
As for your concerns about internationalization, a lot of those can be solved with some tooling. I don't believe it's the role of the language to do anything about that, but one of an external library (which you could change if you want) and the related tools. You're not internationalizing C++, you're internationalizing some strings in your app, which you can do in so many good, but also horrible ways, depending on your requirements.
C++ has many, many problems, but almost exactly none of the significant problems with the language were identified or enunciated by Linus Torvalds. All of his rants on the subject read like "Al Capone is a horrible person, because he cheated on his taxes".
The STL is a case in point. It is, by far, one of the best parts of C++. The word "virtual" doesn't appear anywhere in its source code. Yes, the error messages are verbose; that's a compiler issue. Its only significant weakness is the allocator abstraction.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
google F2Py. You will find lots of tutorials. Most significantly you may notice that f2py is integral to scipy.
as for compiling fortran on the fly, this can be done through scipy as well or you can use system calls. Exactly how you do it depends on what compiler your system used.
Some drink at the fountain of knowledge. Others just gargle.
You can write some damned ugly C++, it's true. You can write some very nice C++ as well, especially if the guy who writes your libraries puts some effort into making sure your code doesn't have to be hideous. The boost guys do a pretty good job of it. Sure occasionally there's some overengineered fuckery (Looking at YOU, boost::program_options) but once you wrap your head around it, it really isn't that hard to read. I wrote a similar library to bind environment variables to C++ variables with type conversion and without the lisp style syntax, and it really isn't that different.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
From Ken Thompson, inventor of Unix, in a 2009 interview:
"I would try out the [C++] language [at AT&T] as it was being developed and make comments on it. It was part of the work atmosphere there. And you'd write something and then the next day it wouldn't work because the language changed. It was very unstable for a very long period of time. At some point, I said, no, no more. In an interview I said exactly that, that I didn't use it because it wouldn't stay still for two days in a row. When Stroustrup read the interview he came screaming into my room about how I was undermining him and what I said mattered and I said it was a bad language."
"[C++] certainly has its good points. But by and large I think it's a bad language. It does a lot of things half well and it’s just a garbage heap of ideas that are mutually exclusive. Everybody I know, whether it’s personal or corporate, selects a subset and these subsets are different. So it’s not a good language to transport an algorithm—to say, "I wrote it; here, take it." It’s way too big, way too complex. And it’s obviously built by a committee. Stroustrup campaigned for years and years and years, way beyond any sort of technical contributions he made to the language, to get it adopted and used. And he sort of ran all the standards committees with a whip and a chair. And he said "no" to no one. He put every feature in that language that ever existed. It wasn't cleanly designed—it was just the union of everything that came along. And I think it suffered drastically from that.
From a 2011 interview, after Ken Thompson, Rob Pike, and Robert Griesemer had created the Go language:
"When the three of us [Thompson, Rob Pike, and Robert Griesemer] got started, it was pure research. The three of us got together and decided that we hated C++. [laughter] ... [Returning to Go,] we started off with the idea that all three of us had to be talked into every feature in the language, so there was no extraneous garbage put into the language for any reason."
Nothing MORE. Nothing LESS
The only thing new in this world is the history that you don't know.[Harry Truman]
C++ is like a house that has gone through many additions. It has become grotesquely verbose. It is riddled with awful constructs like dynamic cast and "casting away constness." I still like C a lot. It is small, fast, smart and, sometmes, merciless. But that's OK. It's OO cousin has become a steatopygean monster.
Yet from what I've read, the Joint Strike Fighter project used large quantities of C++ in their systems.
You mean that fighter that is still over-budget, over schedule and the software systems still don't work?
This is also true in safety critical automotive. I have never seen C++. It is just dumb to use it.
"you are full of bs", but apparently doesn't apply to the "code of conduct"
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b0bc65729070b9cbdbb53ff042984a3c545a0e34
And the huge volumes of crappy code upon which the entire shaky foundation of internet is built.
Yes, good comment. I was a long-time C++ dev before I switched to C# in 2001, with the occasional forays back to C++/Boost and some Java in the intervening years.
For me, C# wins hands down. You may not write an OS in it, or a FPS, but for LOB apps it wins for me hands down. They took Java and threw out the hairy bits, and added lots of nice things. LINQ for example.... pure magic. And a super-comprehensive API with a great IDE that's as comfortable to me as a pair of old jeans.
I have never been able to write as much useful customer-oriented code in in any other language as I have for C#. And with the recent opening up of the .NET Core I hope for a long future with it!
Yep hence Vala, which transpiles to C-with-GObject.
Interesting! Do your comments apply to commercial Fortran compiler(s), open source, or both?
Here's a question - is there any equivalent of STL in pure C? A robust container library is a huge,huge thing.
I have been part of projects that specifically chose C++ because of Boost and STL - we would rather live with style guides and linting tools,rather than without STL.
The only thing worse than macros in C is macros in C++. Because doing fancy shit with templates AND macros is more than the sum of it's parts.
"There are plenty of rebuttals to his attack, but I’ll just make two points. First, he obviously knows his stuff. Second, C does have its place if you’re writing systems-level code that you want as tight and portable as possible. That latter concern aside, though, this is the 21st century: Why write dozens of lines of code when a single line of code (as with C++) will do it?"
This sums up the authors point of view well: completely fucking lazy.
I swear, if I hear another person ask my why I don't just use Boost I will fucking stab them.
You don't have to write your entire application in the C preprocessor. Or in templates. Although if you are coming from a language like Perl I can see how they might be attractive.
Pretend that something especially witty is here. Thanks.
It's a great expressive language.
Sorry C++. Sprinkles are for winners.
Loonix Toreballs is an egomaniac whose value is greatly overrated.
C++ is a VERY powerful system, but it is too much. The C language has 90% of what you need. Any non-trivial C application will end up re-implementing basic features in C++. The problem comes when C++ becomes, in the eyes of its developers, its own language. If used as "C with classes," many of the problematic issues are gone.
All that being said, bad developers will find a way to write bad code.
The real problem is that people are idiots. The vast majority of programmers I've seen are substandard. These so called "experts" write crappy software in any language. Including C. Or Python. Or Matlab. Or C++.
Then there is the other problem of people being set in their ways. Sometimes superior technology (or approach) is ignored because people do not like to change or learn something new. Because people are comfortable in their bubble.
And this is simply the human nature. People are idiots and you cannot cure stupid. And people are set in their ways.
What does that add up to? People will attack anyone and anything that they do not understand, or are too stupid understand. It doesn't matter what that is really.
C++ is one of the most powerful programming languages (if not the most powerful). It allows a skilled person to write very high level software rapidly, or write very low level software that is very efficient. Anyone that does not see that is either an idiot or they are set in their way.
Obviously, with great power comes great responsibility. A crappy programmer will do bad things with it, just like any other language.
But again, you cannot cure stupid.
A fair comparison is Linux vs LLVM.
Linux is written in clean fast readable maintable C with GCC extensions.
LLVM is written in C++.
Go ahead and look.
Here's a link I found that gives approximate timelines to various features. Nothing is set in stone of course, because it's difficult to predict what sort of issues may come up that would prevent timely adoption. The committee has a tendency to just drop a particular proposal rather than letting it slow down the whole process.
Irony: Agile development has too much intertia to be abandoned now.
Linus was most definitely correct. I've been using C++ for decades; most of the time in most of the places I've worked, as a nicer version of C. Some of the places decided to go "template crazy" and ended up with unmaintainable code (and extremely difficult to debug as well). The very worst part of C++ is that missing something arcane (like forgetting to put "virtual" on a destructor) can lead to hours and hours of debugging fun. There shouldn't even *be* an option to forget something that screws you over like that.
There aren't enough bad words to fully describe how bad C++ is as a programming language. Take every single possible pitfall present in C - and there are may - and then magnify that by bolting a totally kludged class and inheritance structures on top of that.
"Bloated" as in so many different ways to do things that only the person who wrote the code can understand it. Too much redundancy basically.
Decent languages? Try D. C# is bloated too, but at least it offers managed memory and you can fall back to non-managed code at any stage.
Why OpalCalc is the best Windows calc
The only problem with C++ is there are too many idiots out there who can only write software in dumbed down languages
Isn't C++ just a dumbed-down version of C?
It makes the simple complicated. It takes a road over flat and level earth and adds steep curves and hairpin turns. What's not to like? You can easily write object oriented-like code in C. You don't need destructor functions unravelling a spinlock. Yet C++ will cheerfully do this for you. We have piled abstraction on top of abstraction. There are a lot of C++ programmers who 'just let the computer figure it out'. It can lead to inefficient programs and a loss of 'feel' for the hardware. I don't think Torvalds got it wrong. One of the real gems of C is that its a complete, compact language. You can get any piece of C to interact with any other piece. Its quite efficient. It takes the Strunk and White effect to language definition. The C language definition was made with pith in mind. C++ on the other hand, is like most other object oriented languages. The language definition doesn't quite fit the encyclopedia britannica, and new volumes have to be added every year to capture all the latest extensions and add-ons. You are required to keep up to date with all the depricated pieces too, and rip them out as needed. You will end up with more volumes in the set, but some of the books will have large chunks missing. What's not to like?
I find every criticism Torvalds points out about C++ is even more true about C.
This is why I use Delphi.
Compiling repeatability
Part of Safety Critical Avionics is that the binary must be perfectly re-creatable. At any time if an issue comes up someone must be able to rebuild the configuration used for compiling (versions, software packages, patches, etc.) and get a perfect match to the released binary, bit-for-bit perfect. Somehow most C++ compilers and libraries are unable to achieve this, using the same exact machine (no patches or changes) and compiling at a different time gives a different result. This has been demonstrated on several different compilers, using nothing other than standard libraries.
That is weird, we check some binaries into svn, there are exactly 3 out of twenty that change every commit since they contain the SVN revision number every other binary only changes when we actually modify some code.
Compiling C++ is so much slower for such a large codebase. The savings from the compile time are already a strong enough argument.
The thing is, there's a whole spectrum that you're dismissing with "reinventing the wheel". Sometimes you're not actually "reinventing", just building an appropriatel sized one for the task at hand, rather that grafting on an oversized wheel with unneccesary chrome alloy rims etc, just because it's already there. The line between these things is fuzzy, and people often get it wrong, but no system will ever be fool-proof.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
A long time ago,I read a book about object oriented programming in x86 assembler. In fact, if I needed to code assembler today, I would use those methods.
I code in C# these days because I'm too old to spend 2 years writing pretty C or C++ code to do what I can don in a month with a modern language and library.
I code very similar in C, C++ Assembler and C#. I use the same algorithms and patterns. I just write much cleaner code much faster.
I have little respect for people who talk about optimization and don't employ garbage collection to run structured cleanup during idle cycles.
Was Linus going overboard?
Of course he was - much as I respect him for his eminent work, he is a primadonna, and he likes to be controversial.
I suppose it will always be a matter of taste, what you think of a particular language. Personally, I like C++ a lot. The great strength of the language is that it allows you to express similar constructs in a similar way - take the concept of the iterator: it basically allows you to loop over any set of objects with a simple for() loop, by hiding away all the house keeping that goes into finding the initial object, getting to the next one and determing the end conditions. This means that you as a programmer are able to show the essential loop to whoever comes to read your code, instead of drowning them in details. Of course, it also means that there are more things to understand - C++ is a demanding language.
I think what makes C++ code horrible isn't the language as much as the programmers, who don't quite understand the purpose of the powerful features and who insist on applying every damn thing in every program. Just because you can make complex class hierarchies with templates, multiple inheritance and overloading, it doesn't mean you have to do it all the time; a god programmer will always strive to write code that is easy to understand - if using advanced, object features help you do that, then it is right to do so, but very often more basic code will do the job.
Well written C++ makes it easier to spot the way the program works; but you can't write well in any language unless you are a master of the language. It is in many ways unfortunate that it is called C++ because it makes you think that it is 'C and a bit'; but C is an extremely simpe language compared to C++, and if you come to C++ thinking that your good understanding of C means that you are obviously going to understand C++ just like that, then it is hardly a surprise that you end up writing horrible, showy code.
Never had heard of the Linus Torwalds rant on C++, but reading it has me second-guessing my C++ ambitions. Linus has strong opinions, no doubt, and he doesn't tiptoe around the issue, but more than once have I found myself agreeing with him and also seeing why I would call other people names - because often quite widespread ideas and notions about programming are notably stupid, and Linus doesn't stop short of pointing those out.
What he has to say about C++ actually makes me weary about the PL. ... Gotta look into this.
We suffer more in our imagination than in reality. - Seneca
>> I can't think of any mainstream language except for C that doesn't suffer from the "dialect" problem to some extent.
Java because it doesn't have a pre-processor - which is a very good thing. People may style the language differently but everything is still just Java. I can't redefine the language semantics like C.
Look at Objective C. It's just an API with a bunch of pre-processor directives to make the language look different. I can't think of another language except C++ which has such a severe "dialect" problem as C.
Linus is just a backwards and sttuborn dude that cannot grasp the factual superiority of C++ over other languages.
He is just an arrogant guy that for already a considerable amount of time is backwards and outdated!
I work developing high performance embedded operating systems, and we use C++ because we can do much better code, both on maintenance point of view and mainly better performance than C.
Vala is surely the most ironic language yet.
GObject: because we don't want to use a whole new programming language just to add objects to C.
Vala: because GObject is better approached using a whole new programming language.
People reinventing the wheel always say their approach is more efficient. They forget that all the extra features they don't use (or don't understand) are just left out at compile time. So what they do is just add code bloat.
The rant from Linus is famous and old. I don't understand why people are still discovering it today and why they feel the need to discuss it.
Linus doesn't like C++ as a systems programming language. He doesn't want any in his project. He never claimed that C++ was bad for everything, he just thinks it's bad for what he does (some people agree, some don't).
And he pretty much hates most other programming languages much more than he hates C++. He thinks that Java is horrible for everything for example.
Wish i could upvote this, but I already commented. It describes exactly my feelings about lisp.
Point 2 pretty much means you just want a simple abstraction on top of assembly, and for that you need simple and stupid code with a minimalistic language.
It's the only good point that you've made as to why you couldn't use C++ to match your requirements.
Cython seems to connected these rather well.
Linus is possibly right with one thing:
> It's made more horrible by the fact that a lot of substandard programmers use it
C is simple and lean. Doing complicated stuff which is not required is not easy and prevents system-level software messed up with unrequired abstraction layers and patterns, which you can ususally find in the typicall Java-Software. Because Java make it especially easy and popular to use abstractions and patterns by so called "Software Architects". Spring with Inversion-of-Control and Aspect-Orientiered-Programming (non-readable source-code!) and Hibernate make especially reading source-code a big pain (it not longer readable source, it's a lot of spaghetti XML and annotations with weird bugs).
> In other words, the only way to do good, efficient, and system-level and
> portable C++ ends up to limit yourself to all the things that are
> basically available in C.
C++ is a Multi-Paradigm, one of this paradigms is low-level/system-level programing with simple C-Like code.
The offers a how lot of new features which make programming on high-level easier, faster and safer like RIAA and Smart-Pointers, Templates and STL-Containers, modern I/O-Stream and Strings and finally OOP.
Personally I tend to say, that OOP is an important part of C++, but the biggest achivement so far are Templates* and the STL. They allow both creation of big software projects. If done right, this big software is not complex software.
* Java doesn't offer the convenience of Templates, basically because Generics are just Autoboxing for Safety but nothing more.
People reinventing the wheel always say their approach is more efficient. They forget that all the extra features they don't use (or don't understand) are just left out at compile time. So what they do is just add code bloat.
The problem with relying on compiler optimisations is that the compiler rarely knows the valid or most likely forms of input. This is why anyone concerned with performance will explicitly specify quicksort/bubblesort/whatever rather than just calling "sort" and letting the compiler choose.
I agree that some people take this too far, and basically "micromanage" their code, but then people also go too far the other way at times.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Follow those two rules and (usually) the code will turn out ok.
I am very small, utmostly microscopic.
No, anyone concerned with performance will write the code first, profile and then optimize. Given a more expressive language you can get to the correct-but-needs-optimization much faster and therefore spend more time on optimization.
SJW n. One who posts facts.
The biggest problem in C++ is they won't add anything new. They keep overloading what's already there, usually punctuation marks. The lambda syntax is terrible, for example, overloading the [ ] operator. Each time something new is added to C++, the same keywords and punctuation get more overloaded. The result is a mess. If you're going to add new stuff, add new keywords. Add new syntax. Make it look new. If it breaks something, then it's new, it's supposed to. The alternative is the mess you have now.
/ Grabs popcorn
/// Swallows prednisone to partially alleviate the symptoms of terminal asbestosis.
Not Always Necessary. Sometimes you know from the very beginning that your list will be mostly ordered, and you choose your sorting and searching algorithms accordingly. In some cases it really is pretty trivial. In general, though, I do agree with the principle of "optimise late". We just have to remember that there are no absolutes.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
This has been demonstrated on several different compilers, using nothing other than standard libraries.
[citation needed]
google f2py and you will find lots of tutorials. but it not complicated and after you customize the paths and options for your particular compiler then compiling from within python takes just a couple lines, and then you import the result.
almost any compiler can work in principle. I used open source compilers because 1) I wanted to be able to share my work 2) numpy and scipy come distributed that way. but I know from the mail lists people used commerical compilers as well such as compaq visual fortran. I did once use a commercially curated distribution called enthought. Since I didn't want to have to maintain two compliers I made the choice to use the one I used to compile scipy or numpy, which is almost any, but on your specific computer you have probably installed numpy in either binary or source form using some package manager, or if its a mac the one that came with the computer. f2py is in most package managers. By using the package manager route this also simplified getting the paths to libraries set up correctly as well-- but that's just a general property of package managers not specific to f2py.
I've done this now using different package managers and different compilers and the only problems I've had were in the package managers themselves when dependencies got broken, but again that's the packagemanager woe no specific to f2py.
You can do all the sorcery right from scipy itself. since scipy and numpy can use fortran order arrays, you can pass things in and out directly without thinking about them as objects. they just show up as fortran arrays.
Some drink at the fountain of knowledge. Others just gargle.
As stated, these are the reasons others at my company have given me for why they don't use it. I don't have the direct experience to challenge this, nor do I have the authority to make a decision to use C++ on a project, I'm brought in after those decisions are made and the work is started.
I would actually love to learn more about the language and use it, especially if it actually has application to the Avionics world.
DEMETRIUS: Villain, what hast thou done?
AARON: Villain, I have done thy mother.
Shakespeare invents 'your mom'
I've recently started to think that C++ should be broken into subsets of syntax and features that are enforced by the compiler rather than just coding standards and process.
Yay me! ^^
I thought that someone should point out that std:thread is part of the standard C++ 11 library but pthread_create is not part of the standard C library.
std::thread is portable code, pthread_create is not.
No, anyone concerned with performance will write the code first, profile and then optimize.
Absolutely. That's why any good C++ programmer writes
void some_function(big_class data)
first, and only uses
void some_function(const big_class & data)
after profiling confirms that their code is as slow as everyone knew it would be.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Regarding repeatability: the language is fully deterministic, and compilers have as much of an incentive to be consistent as they do otherwise. If you can't get repeatable builds, then the problem is with your build environment/process more than anything else. Aside from hardware entropy sources, computers are, by design, deterministic, so if you can't reproduce a build it is because you haven't constructed a proper build closure. Certainly there is nothing about C++ that makes builds any more non-deterministic than say, C. Debian actually has a project for this: https://wiki.debian.org/Reprod..., and you may find some helpful information there. You'll notice nothing they've run in to is specific to C++.
Regarding code-to-binary structural coverage analysis. Certainly I can imagine the argument that as you get to higher and higher levels of abstraction, it becomes harder for humans to track all the transformations all the way through to assembly. One solution is to restrict the levels of abstraction you work with. I would argue that is still error prone and you are better off with using theorem prover type automated solutions (and in general, languages built around provability like ML or Coq) rather than manual verification. Even better would be to perform the verification on the compiler itself rather than the code it compiles. That said, C++ compilers do a pretty good job of tracking the origin of each bit of code they generate, which ought to make it easy to have the machine inform you of the origin of any particular code block, and C++ also does a great job of letting the programmer decide what level of abstraction they want to work with and only making the runtime pay for the abstractions they are using. Its stronger type safety also helps ensure that there aren't "hidden" code paths do to programmer error. Of course, optimizers really complicate this, so you may need to turn them off as you mentioned.
Internationalization. That sounds like an old project... one that predates the C++ standard (which means a lot of bad C habits are involved). C++ is actually very well set up for internationalization, particularly because it is so agnostic about how stings are handled. Languages like Python, Perl & surprisingly Ruby have made all kinds of unfortunate decisions around internationalization that make it look like you are fine with internationalization, but it actually blows up in your face. As an example, ICU is probably one of the foremost libraries out there, and its primary language targets are C++ & Java. The C++ target has the virtue that you can pretty much just drop in ICU strings in to a well structured C++ program and all is well in the world, where as the Java one is a bit of a pain to take advantage of (fortunately, Oracle periodically syncs the ICU code in with the JDK, but that means you have to wait for a JDK update to get the latest ICU solution).
sigs are a waste of space
Perhaps not the best example of a successful software project. ;-)
sigs are a waste of space
Don't listen to him. With all due respect for Torvalds accomplishments, he's not always right. Half the people here bashing C++ don't know the language. C++ right now is irreplaceable for its strength to provide C level performance with high level language structs, and better yet, directly compatible with C so you can use the mass of C libraries without jumping hoops. For people who bash operator overloading, try to write matrix and vector computation without it, it's painful. And those who avoid STL miss out big time. STL though syntactically not pretty, is very mature and rock solid high performance generic container. As a programmer who has mainly been using C++ for 15 years, I will say it's not a pretty language and easy to shoot yourself in the foot. But it provides a wealth of language features that allow you to do pretty much anything. I do hope something nicer comes along to replace C++ while preserving its strength, but so far none is on the horizon.
Both perspective are right, and the usefulness of C++ increases with experience. Look at your old code. Does it make you cringe? If not, then Linus' quote applies to you.
We need to acknowledge the fact Linux Torvalz (tee-hee) is being utterly illogical (odd for a 10x programmer) when he utters that a language is bad because there are so many bad programmers using it. There are bad programmers in any language. If there's a preponderance of bad programmers using C++, it's not because the language is bad, but because it has been so popular (and powerful) for so long.
LOLOLOL i hope you are joking and trolling. if not, wow.
Compiling repeatability: this complaint is news to me. I'd like to see something I can check.
Code-to-binary coverage: this is an excellent reason not to use C++, and to be careful in how you use C.
Internationalization: I haven't noticed it being harder in C++ than in other languages. It's a pain no matter what language is used, and it can be made worse by programming decisions made early on. Fortunately, all the internationalization projects I've been on were of small programs. I'd be interested in learning why it would be harder in C++ than in C, for example.
In short, C++ is not for every use, and your is one it isn't suited for.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
C++ fails in separating interface and implementation. Then you need to exactly know the interfaces by including the header. So you lock yourself to it. Objective C solves this with messages.
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
Somehow most C++ compilers and libraries are unable to achieve this, using the same exact machine (no patches or changes) and compiling at a different time gives a different result. This has been demonstrated on several different compilers, using nothing other than standard libraries.
That's because some compilers (I know VC++ does that, probably others, too) embed a timestamp in the image. Nothing else actually changes, and the timestamp is not used by the image itself.
This does break some other binary verification scenarios, so, IIRC, there was a compiler switch added at some point that prevents this and allow bit-identical output given bit-identical input.
You can so stupid things in any language if you like.
In Common Lisp, it's common to use code generation using Lisp macros (much more similar to C++ templates than the C/C++ preprocessor). It's elegant, powerful, and I've never seen it considered overengineering.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Compiling repeatability - Are you sure? I have not checked recently, but last time I did, this was no the case
Code-to-binary and structural coverage analysis - If you don't like STL and Boost, don't use them (I don't) and instead, roll your own. BUT, what standard libraries does C provide if you don't want to roll your own? None? Really? Wow, so you HAVE to roll your own? Using macros instead of templates? LOL, how is the STL in C++ a bad thing when compared to NOTHING in C ??
Internationalization - C++ is not the problem... "X11 and Motif to QT" That's the problem. "updating it to go from hard-coded English to strings" that's the problem. Starting with what sounds like a crappy code base, that's the problem. This would be akin to converting a Winforms application to WPF, in other words, practically impossible, you might as well re-write it, or the front end at least. I'm actually in the process of converting an application from winforms to WPF, and I've not done anything other than re-write all the front end code from scratch so far.
C++ is fine for kernel development. Some C++ features are seriously unsuited to kernel development. It's at least arguable that enough features of C++ are unsuitable that you may as well use C.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Sub-title: Is Linus really a programmer
Illogical statement: "C++ is a horrible language," he wrote, for starters. "It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it.""
Unnatural extension of logic: "Automobiles are a horrible invention," he wrote, for starters. "It's made more horrible by the fact that a lot of substandard drivers use them, to the point where it's much much safer to stay off the road and just park them."
Or, my favorite: "English is a horrible language," he wrote, for starters. "It's made more horrible by the fact that a lot of substandard humans use it, to the point where it's much much easier to generate total and utter crap with it."
Listen to Alex Stephanov talks (=the original author of STL) He mentions on several occasions that he pulls his hair off when he sees how people use STL.
From a C background, I still struggle to understand modern C++ code, in part because the complexity level of the code is not being added to, but multiplied. Templates (for instance) took something I could generally understand, and multiplied the complexity. Keywords relating to templates and generic programming seem to get added every iteration, and most recently we seem to have lambda functions (why?). As a oprevious poster said, there are now many ways to solve a particular problem in C++. While that is true in most languages, the intent of most programmers is generally directly visible from scanning the code, and (I hope) comments. Not always so with C++. I still like the language, but it seems to be going the way of PL/1 - too many features. It's always possible to add a feature to a language, very hard to remove it.
You don't have to but other people might. And when it's your turn to maintain their code, then, oh shit... But it shouldn't since it's C++, you're supposed to be fluent with it.
Write boring code, not shiny code!
Just that it's the wrong language for most modern programming tasks. Virtualized runtime environments w/ dynamic garbage collection and scores of other great features like Java, .NET, Python, Ruby make C++ totally obsolete for *most* programming tasks. Still there are many areas where C++ is the right tool such as drivers, os internals, network development, debugging tools, etc. Saying that languages that execute in a virtual runtime environment are much better is like saying that C++ is a much better language than ASM86 or IBM 360 BAL.
I admire C++ developers for what they can do. I am a C# developer and I've started to learn C++ a few times over the past 15 years. Every time I try to learn C++, I just decide that there's nothing that I can use it for in my daily job (I'm a web developer), so the effort to learn it correctly is too great for the return I'd get from learning it. Sure, I could hack my way through it, but something tells me it's a language that needs to be written elegantly or it could wind up being a mess. I learned C in school, but I've never used it on the job. I'm glad there are people out there that have the chops to code in C++, even if they are creating some messes. I still can't get my head around the more advanced memory management topics, so I take the lazy man's approach and depend on the garbage collector and the IDisposable interface.
Michael Earls http://cerkit.com/
Consider that in 2007, neither C++1 nor C++14 were out.
Cool lets look for more articles from 2007 and post them as new stories......
Both languages have their place. If your primary job is system level programming - C makes a great deal more sense. If you are doing applications then C++ might be a better trade off.
There is one DO-178B C++ compiler for safety critical avionics. The Greenhills C++ compiler is certified. That is also why there is a JSF C++ coding standard. There are many parts of the language that would produce non compliant code if you were to use those features. I don't know anything about internationalization, but I wholeheartedly agree with the optimizer settings. When you have to inspect assembler optimizers are just cruel and inhumane. And that is when they are working. I once had a DO-178B compiler (not c++) optimize out a statement with side effects, that took me a while to spot.
This isn't a problem with C, it's a problem with your developers and review process. I maintain dozens of interconnected C applications, libraries, and SQL code for a popular line of consumer electronics products (15 million installations)... Our code does have some sticky points, but that's due more to a few bone-headed developers than language. Either way it's far from the disaster you describe.
All systems are fool-proof if you get to define what a fool is :-)
Well played :D
Actually, back before move semantics, I had a function along the lines of:
void foo(blah, vector& return_value);
It was being called repeatedly, hundreds of times a second. On a whim during optimizing, I made the return value a proper return value. It increased the runtime by about 0.1%, so I left the "slow" version in since it looked better.
But yes, you're right, no simple saying ever covers a complex world.
For example if you know code needs to be fast, you better pick an architecture up front which is optimizable, otherwise you know 100% you're going to be screwed later on.
SJW n. One who posts facts.
The ABI *to the kernel* is not standard. That isn't what the thread is talking about, it's talking about the ABI standard when coding TO THE COMPILER. IOW, do you have to have a lot of conditional compiles or even different libraries and calls to solve the same problem? If you do, you don't have a kernel that can be compiled on multiple platforms, you have multiple kernels.
Think of a game using DX vs a game using OGL. The code won't be the same for almost all of the graphics calls. That would not be the same program.
Think of a game using Windows 7 with DX10 or with DX11. They would be the same program.
I realise this would not let you complain about Linux, because you've heard people complain that they can't release binary drivers for Linux because the "ABI is not stable", but have understood nothing about it, and therefore have misapplied it just so you can whine.
Sorry.
as an old k&R type strousup and c++ sucky,sucky!!
As someone who was taught C++ as a way to introduce one to programming in college, I have to agree.
Later, many years later in fact, when I discovered C, I was a much happier person. Everything is so much simpler in C starting with the syntax and ending with compiler optimization and debugging.
By comparison, one could say the same about using ECMA^Wjavascript versus CoffeeScript. JavaScript has many features most of which are good, however the syntax gets in the way. CoffeeScript "fixes" that by making code simpler without sacrificing on features.
This sig can be distributed under the LGPL license
As a matter of interest, what do you use?
C and ADA are the two languages I've run into for actual safety-critical projects
For Non-safety-critical, non-flying software, mostly C.
For testing environments (runs tests on the software/hardware and collects the results) C# and Python seem to be the popular choices. However very few of them have been "Tool Qualified" (i.e. proven to be 100% accurate in their assessment of if a test passed or failed), mostly out of laziness and managers being scared of the toolqual process.
DEMETRIUS: Villain, what hast thou done?
AARON: Villain, I have done thy mother.
Shakespeare invents 'your mom'
No, that's when Emacs WON that argument. Emacs is what you want, no matter what you want or how often you change your mind.
Vi is only what you want if you want vi.