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++.
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.
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.
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...)
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.
Modules are coming in C++1z (the next revision of the language) most likely. That should solve many of the (real) problems with #includes.
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?
"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.
I haven't read Linux's rant against C++ for a while, but he is correct that C++ isn't a good choice for an OS kernel. The only major kernel written in C++ that I know of is Windows NT, and it uses only a subset of C++ language features. In particular, it disables exceptions, disables RTTI, removes new/delete, and it doesn't have the standard library. Microsoft wrote their C++ compiler with this in mind, and there is a compiler flag to disable kernel unfriendly features (documented here). For everyone else, it's easier to just say that the C++ subset for kernel development is C (minus the standard library).
For non kernel use, C++ is superior to C in the hands of an expert programmer, but mediocre programmers who don't understand the language tend to write absolutely horrible code. And you can't take an expert C or Java programmer and expect them to write expert C++ code with just a few weeks practice. C++ is one of those languages that you have to dedicate a lot of time to, but it can be worth it if you require highly optimized code, have low latency requirements, or have low space requirements (areas where higher level languages like Java don't do well).
I wouldn't use it for most firmware either. Firmware often has size constraints that C++ is less than friendly about. It also often runs in a limited environment that may not be friendly to C++.
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. That's what the kernel is written in.
Jesus saves and takes half damage.
C++ = all the performance of assembly language + all the ease of use of assembly language.
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.
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
C++ is a fairly modern, high-level language where it's fairly easy to produce type-safe, grounds-up designs that use zero unsafe C features. And if you must call into C or precambrian C++, you can wrap those in type- and otherwise safe wrappers.
The "esoteric" things in C++ are precisely the things that let you use it as a high level language, and not as Java or C. C++ offers a higher level of abstraction than Java, at least since the arrival of C++11. About the only mainstream feature still absent from C++ is free-form introspection. It's already possible to use template machinery to create types with full introspection, but any such approach doesn't apply to the types created manually using plain C++ syntax. The other feature is imperative compile-time programming, also known as LISP macros, but then only LISP really has those and nothing else IIRC.
A successful API design takes a mixture of software design and pedagogy.
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."
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.
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!
C++ is a disaster for kernel development.
I honestly have no idea, so: why?
Honestly asking out of ignorance, not malice, Sad that I have to note that, but I digress...
Are there any notable kernels written in modern C++ (or even C++98)? I've never bothered to keep track of what kernel was written in which language, so I'm sure my knowledge is sorely lacking in this area. Hurd? Mach? Any of the many RTOS kernels?
You do not have a moral or legal right to do absolutely anything you want.
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.
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.
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."
The only major kernel written in C++ that I know of is Windows NT,
Apple uses a subset of C++ known as "kernel C++" for drivers in OS X and iOS. Back in the NeXTSTEP days we used Kernel Obj-C, and it's very sorely missed.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
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
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.
There aren't, because C++11 is, well, a standard for 4 years only, and C++98 implementations were spotty well into the middle of the following decade. Finally, not that many people are writing kernels from scratch...
A successful API design takes a mixture of software design and pedagogy.
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.
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..."
I agree (and I have a similar number of years coding experience, but not with C and C++). Diving straight into writing code might feel productive, but is a recipe for disaster.
In most times, most places, by most people, liars are considered contemptible. - Ursula Le Guin
Tell that to the makers of BEOS. https://haiku-os.org/legacy-docs/benewsletter/Issue2-25.html There is also a Wikipedia page.
Lack of ABI makes using C++ to define a system call interface impossible/impractical.
Fragile base classes make use of inheritance in a kernel impossible/impractical.
Etc.
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
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});
And especially watch Mr. Meyers's talk "The Last Thing D Needs" (https://www.youtube.com/watch?v=48kP_Ssg2eY). tl;dw version: The last thing D needs is to require someone like Scott Meyers; don't make D so perversely convoluted that one can make a living explaining it to people.
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?
Nothing MORE. Nothing LESS
The only thing new in this world is the history that you don't know.[Harry Truman]
Symbian, BlackBerry OS, Wii U System Software, OKL4.
I'm sure I left some out.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Back in the mid 1990s I worked on a complex ATM (Asynchronous Transfer Mode) networking driver for OS/2 that was written in C++ and it was actually quite elegant compared to the Windows NT driver which was written in C. It had more functionality yet was less than 1/3 the amount of code. It used new and delete as well as templates but other than that it was somewhat limited in its use of C++. Granted, C++ has evolved quite a bit since then but it showed me that C++ can be used for low-level stuff. Performance was actually quite good, at least as good if not better than the C counterpart. The code was also easier to debug and tended to have far fewer bugs than the 360KLOC C driver. This driver was around 100KLOC of mostly C++ with a small amount of assembly and some C for the OS bindings. It included the full signalling stack, lan emulation and all the other various parts needed for an ATM stack.
Adding features was also much easier than the C driver. The code base was also used for other operating systems and compilers as well (i.e. AIX running on Power).
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
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.
And the huge volumes of crappy code upon which the entire shaky foundation of internet is built.
Yep hence Vala, which transpiles to C-with-GObject.
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.
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.
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.
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.
Yes, they use zero unsafe C features. They use unsafe C++ features.
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.
One of my favourites is cocos2d-x which uses C++ for mac, win, iOS, Linux, and android.
There is an interesting project called Kivy which allows for android and iOS Python development. But while very cool needs a bit more ripening for primetime.
"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?
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.
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.
There are two bad ways to code in C++: the C way and the Java way.
You're talking of inheritance, that's something you use in the Java way.
C++ is a language for experts, but so is C.
C++ is a pragmatic language, not an idealistic one.
It has everything yes, it's a strength not a weakness. All the tools are at your disposal, and you're still free to build your own style with them.
OK, so given the argument from Linus was C in favour of C++, I assume this is things where C++ falls down compared to C++.
From accidentally instantiating a dozen copies of an object to double-freeing it,
lolwot?
Those are classic problems, especially the double free in C. C code is littered with that crap. I write C++ and I haven't had a memory leak or double free in probably 8 years now. And truse me, it's not because I'm so super-awesome. It's because I use the tools C++ provides as intended.
std::vector, other STL containers, shared_ptr, auto_ptr (and now unique_ptr). And never ever ever delete in user code.
If you have problems with double free in C++ in this decade, the problem lies with you or your codebase, not C++.
From the start, C++ has undefined behaviors built right in,
Uh yeah? Given the whole linus rant was C versus C++, almost all of C++'s undefined behaviour is inherited directly from C.
SJW n. One who posts facts.
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.
There shouldn't even *be* an option to forget something that screws you over like that.
Every major compiler warns about that and has done for years.
And there are also some good reasons for not wanting virtual destructors because they can introduce unacceptable performance penalties in high performance code.
Check out any of the libraries that do fixed-length linear algebra stuff. They use (internally) quite complex systems of derivations to allow the resulting classes to have all the features you expect.
The resulte is that something like Vec supports all the operations you expect from linear algebra, but has precisely the same overhead as double[3]. If you had to have virtual destructors then you'd have to write the code C-style to get good performance.
The result would be code that is ultimately much less clear and therefore much harder to debug.
SJW n. One who posts facts.
Gah slashdot. That should be Vec<3>, not Vec.
SJW n. One who posts facts.
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'
Do you know why they didn't use new/delete? They are simply syntactic sugar to create a less error prone version of malloc/free.
Follow those two rules and (usually) the code will turn out ok.
I am very small, utmostly microscopic.
Which kernel would that be?
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.
Not while it still suffers from the fragile base class problem.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
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! ^^
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.
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
Out of curiosity, what is in that subset? Is it pretty much the same as what MS uses as described above? i.e. the only valuable thing that it brings to the table is RAII?
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
Which C++ features do you consider unsafe? Just going through a C program and replacing arrays, raw pointers, and C-style strings with vectors, smart pointers, and C++ strings will eliminate a great many chances to screw up.
"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
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.
Out of curiosity, what is in that subset?
As I recall, they don't allow you to use multiple inheritance, templates, or C++ exceptions. You can find the full details in Apple's IOKit documentation.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
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.
My favourite: an uncaught exception (like from map.at()) causes the program to exit with no trace of where the problem originated.
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.
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.