Was Linus Torvalds Right About C++ Being So Wrong? 757
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?
Write-only code. (Score:5, Insightful)
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.
Re:Write-only code. (Score:5, Interesting)
Maybe that's what it is. I write a lot of C code, some of it pretty good, but I just can't "get" C++. I appreciate the class stuff. Heck, I pretty much do the same thing using structs in C but past that, the rest of C++ just loses me.
Re:Write-only code. (Score:5, Interesting)
You can find some really elegant C++ code out there. I am quite fond of the Qt libraries, for example. But Qt is its own C++ dialect. The company I work for codes a lot of our software in C++, and it is really nice, clean, maintainable code. But we have a style guide that everybody has to follow, and that's how we pull it off. Essentially, we are not writing in C++. We're just using a C++ compiler to compile NomLang.
Re:Write-only code. (Score:5, Interesting)
You can find some really elegant C++ code out there. I am quite fond of the Qt libraries, for example. But Qt is its own C++ dialect.
Ditto on Qt. Qt can be a beautiful thing sometimes... but then comes pre-compile, which turns it into an anus-puckering nightmare for those who don't know you're using it ;) .
The company I work for codes a lot of our software in C++, and it is really nice, clean, maintainable code. But we have a style guide that everybody has to follow, and that's how we pull it off.
That should be the norm in any competent shop, though.
Mind you, I've seen shops where styles are horribly mixed-up. That usually happens when Company A buys Company B's codebase and nobody cleans up the stuff from Company B. OTOH, I've seen instances where different teams in the same company decide to become special snowflakes and go their own way, making life into a giant shit sandwich for DevOps, QA, or SCM to eat - especially when they have to point to something and say "...fix that, because it's breaking Jenkins/Tito/unit tests/etc... and WTF man, we have artifacts for a reason!"
But then, I just came out of a Java shop where they were using Geronimo, Jetty8, Jetty9... Java 1.6 and 1.7... all in the same 'effing overall product (just that the components sit on different servers.)
Long story short, it takes discipline to keep everyone rowing in the same general direction - enforced styleguides are a part of that. Discipline also keeps things from becoming an unmanageable mess, if the head coder has the spine for it.
Re:Write-only code. (Score:5, Informative)
Right now I'm doing just C and assembler (and the occasional scripting in something else). Sometimes it feels a bit archaic compared to a stripped down C++ style I'm more used to, but on the other hand there just aren't as many political fights over style so it's less stressful. The interesting thing about C is that newer standards don't tend to lots of new and experimental features, which is sort of the norm with C++. C tries to be stable.
Also a big part of my job when doing C++ was decoding the obtuse error messages for coworkers, and that almost never happens with C...
Re:Write-only code. (Score:4, Interesting)
I found, after decades of experimentation, that simplicity and consistency beats everything else if you want to produce reliable software. Now, I use C exclusively just so I don't have to deal with multiple different ways to do something because the C++ standards committee got a bee in its bonnet about the latest hot new concept that first came out in 1959 and was forgotten until last year.
The problem with possessing multiple ways to solve a problem is that every developer takes it as a personal challenge to find and use all the different ways. To make things easier I simply wrote a library containing those things that I usually need (sane string operations, c/line parsing, vectors, etc) and found that 90% of what you can do with X lines of fairly complex grammar in C++ can be done with around 1.5X of straightforward C grammer. I don't need the remaining 10% if it needs 300% cognitive effort to get.
The library is here: Extended C library, libxc [sourceforge.net], so help yourself (BSD license)
.
Documentation is over here: PDF link, but html available [lelanthran.com], although the documentation on the website is out of date. If you download the library source you get the full up-to-date docs.
Re:Write-only code. (Score:5, Insightful)
because the C++ standards committee got a bee in its bonnet about the latest hot new concept that first came out in 1959 and was forgotten until last year
Give one example of that ever happening. The C++ standards committee is notoriously conservative which is why the language evolves so slowly. This comes across as you just making shit up when you haven't got a clue.
The problem with possessing multiple ways to solve a problem is that every developer takes it as a personal challenge to find and use all the different ways.
That might be *your* problem but it isn't mine. Every decent place (staffed by true scotsmen of course) with project teams has things like coding standards and code reviews.
If your developers are committing crap code to the mainline then the trouble is that (a) your developers and (b) your process sucks. The thing is it will suck in any language.
The library is here: Extended C library, libxc, so help yourself (BSD license)
OK, I'll bite.
Well, if you think having XVEC_DEREF(some_vector, i, float) for resisable arrays but array[i] for builtin ones is better than having array[i] for both, well, then I guess we're just on completely different pages here.
The thing is there's massive syntactic overhead to your code. And the overhead is more like 1000% not 150%.
vector<float> = { 1.1, 2.2, 3.3, 4.4, 5.5, 6.6, 7.7, 8.8, 9.9};
works perfectly in C++, whereas that's 10 lines of C code!
And I was wondering how it worked underneath, and I had to dig into the code. So you're storing pointers to the elements, not the elements themselves! I never even realised that. Wow, so that means you can't even do:
xvector_ins_tail(tfar, &1f);
You have to do:
some_float_which_has_the_same_scope_as_tfar_and_is_never_reused = 1; //Do something error related here //probably a longjmp or goto. //Don't forget to free all that memory!
if(!xvector_ins_tail(tfar, &some_float...))
{
}
versus:
tfar.push_back(1.5);
It also means you're in nightmare memory management from hell since you now have to manage all those bits of memory by hand.
It *also* means that you have no memory locality since it's a big array of pointers, so performance will almost certainly be bad as well.
The equivalent C++ code to your xvector/main.c is something like:
And that gets us to line 90 or so. There's more, but you missed the error checking for if something isn't found in the xvector. It also took me a while to verify that all the allocations are matched by the respective free. It would be nearly impossible to be sure for less trivial code.
So, I'm not convinced you've made a case for C over C++ here.
Re:WHAT HAPPENED TO SLASHDOT!? (Score:5, Funny)
You're all talking about C++ and not LINUS TORVALDS! Have you all LOST your MINDS!? ;-)
Hey! He didn't even pick up a chair!
It's not a rant 'till someone has to place a furniture order with Staple's...
Re: (Score:3)
You're all talking about C++ and not LINUS TORVALDS! Have you all LOST your MINDS!? ;-)
I guess C++ is more controversial :D
Aren't all (but one) popular languages like this? (Score:5, Insightful)
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
Re:Aren't all (but one) popular languages like thi (Score:4, Insightful)
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.
Re: (Score:3)
Yep hence Vala, which transpiles to C-with-GObject.
Re:Aren't all (but one) popular languages like thi (Score:4, Funny)
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.
Re:Aren't all (but one) popular languages like thi (Score:5, Interesting)
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.
Re:Write-only code. (Score:5, Interesting)
I usually use C++ as "C with classes". No fancy stuff like STL or Lambda expressions. That works well, and most companies where I've worked use C++ that way.,
Re:Write-only code. (Score:5, Interesting)
STL and lambda are my main reasons for using C++. They're bloody awesome.
Here's my standard challenge for C people - I've given it many times in these sort of threads and not once gotten a real response that meets the specs. Show me the code (emphasis: show me actual code, don't just say "... this is how I'd do it" and a rough description), full code (emphasis: full) for a program launching a detached (emphasis: detached) thread, such that it can happen an arbitrary number of times with no guarantee that other threads will be done (emphasis, there can be more than one thread at a time), to run the function do_something(Foo a, Bar b) (emphasis: two arguments, arbitrary size) - where the values passed for a and b are variables local to the context that launches the thread (emphasis: local), so they need to be passed by copy, not reference.
This is not at all some sort of esoteric task - launching threads with nontrivial local arguments is pretty basic, there's millions of use cases for something like this. Here it is in C++11:
std::thread([=](){ do_something(a,b); )).detach();
Little short line of code. Surely for such an obvious, non-esoteric task, C can't be much harder, right? Any takers?
(Don't bother responding if your code can't meet all of the boldface conditions... in the real world, you can't simplify the system requirements to meet the deficiencies of your coding language)
Re:Write-only code. (Score:5, Informative)
The sample code will copy a and b twice, once to put them in the lambda closure, and then to pass them as arguments to do_something. Some may consider this wasteful (the easiest fix is to modify do_something to take the values as const references).
This is the general problem with C++, in that the shortest code is often the slowest. Adding const references to the declaration of do_something would remove the useless extra copy. The slowness is visible in C, where you would probably allocate a structure containing the copy of a and b, and have pthread_create call a function that copies them to the arguments to do_something and calls it, then deletes the temporary structure. This is equivalent to what the C++ compiles into but all the inefficiency is visible. This is the primary complaint about C++ verses C.
PS: I use C++ all the time and prefer it over C. But you do require a good knowledge of what it turns into, often stated in a pseudo-C, to figure out how and why things work and why slight variations (try using [&] instead of [=] in your lambda!) break in horrific ways.
Re:Write-only code. (Score:5, Insightful)
Only without optimization flags enabled. Otherwise the lambda will be inlined in most cases.
Compared to what alternative C algorithm? Still waiting here.... ;)
Beyond that, that's not how you optimize a program. You don't try to optimize the heck out of every last line; that's a recipe for an unmaintainable mess that's not actually that fast. You write clean, organized code, you profile it, and then you optimize where the profiling data tells you that you can make the biggest improvement. Trying to be "clever" and outsmart the compiler with every line of code "in the interest of performance" is how spaghetti code gets made
To reiterate my first post:
Yes, I knew exactly that people like you would come in and try to pass off a rough description as an implementation. The reality is that the implementation is such an utter, bug-prone PITA in C (compared to a trivial command in C++) that most people don't even bother. Which means that code gets underthreaded, which means that it performs terrible and is prone to lockups.
Threading is of course just the start here...
Re:Write-only code. (Score:5, Informative)
Only without optimization flags enabled. Otherwise the lambda will be inlined in most cases.
BZZT! Wrong! Think: what happens if a and b are local variables and the function creating the thread returns before the lambda runs? They must be copied to somewhere that is not destroyed by the caller returning. That copy is not in the correct location because they are created before the thread stack, so another copy is unavoidable. The only way to fix it is to make do_something take const references. Though it is true that if do_something was inline it would probably fix it.
Show me the code
Yes it is ugly and I never claimed otherwise. The problem is that C++ compiles into the equivalent of this and it is hidden behind the scenes. Here is is pretty obvious that I must not pass a pointer to a or b, not so clear in C++:
#include <pthread.h>
#include <stdio.h>
#include <malloc.h>
#include <unistd.h>
void do_something(int a, int b) {
printf("do_something %d %d\n", a, b);
}
typedef struct {
int a, b;
} lambda_args;
void* lambda_run (void *p) {
lambda_args* v = (lambda_args*)p;
do_something(v->a, v->b);
free (v);
return 0;
}
void thread_do_something (int a, int b)
{
lambda_args* v = (lambda_args*)malloc(sizeof(lambda_args));
v -> a = a;
v -> b = b;
pthread_t thread;
pthread_create (&thread, 0, lambda_run, v);
}
int main()
{
thread_do_something(1, 2);
thread_do_something(3, 4);
sleep (1);
return 0;
}
Re:Write-only code. (Score:5, Informative)
BZZT! Wrong yourself! And let this be a lesson to you to not be so haughty when replying. What you describe never happens. The lambda is built synchronously, but called asynchronously.
To prove it, try out the following code:
Compile it with "g++ --std=c++11 -S -O4" and check out the .S file (compare it to the -O0 version too). In the -O4 version you'll see the following:
You see that? It's pushing the local values directly onto the call stack. There is no intermediary step for the lambda.
Okay, so maybe my test case was too simple? Let's complicate it.
Try it again with -O4 with the if set to 0 or 1 and compare the two versions together. You'll see that they're exactly the same. In both cases, main is:
Re: (Score:3)
His code is constructing a lamda as a local value, not copying it anywhere, and directly calling it, then destroying it. When the call is done every detail of the lambda is known precisely, and this can be optimized (apparently g++ does so, too).
The original post constructs a lambda and passes it by value to the thread constructor and then exits before the lambda is used. This requires a and b to be copied. Later the forked thread executes the lambda. It is highly unlikely the locations of a and b in the la
Re: (Score:3)
This is the general problem with C++, in that the shortest code is often the slowest.
Well, that's better than the general problem when the shortest code in C normally leads to a crash or a memory leak. Yep, if you copy structs-with-pointers around like containers willy-nilly you soon screw up and get a leak or a segfault.
The other thing of course is that you have 1 line ot find the slowness, not 30 as in the C code.
Re: (Score:3)
Little short line of code. Surely for such an obvious, non-esoteric task, C can't be much harder, right? Any takers?
(Don't bother responding if your code can't meet all of the boldface conditions... in the real world, you can't simplify the system requirements to meet the deficiencies of your coding language)
Somebody else answered this already and I prefer the C solution. But this example seems rather contrived anyway. Let's do something much simpler: Write a matrix multiplication routine for arbitrary-sized matrices which is not allowed to use the heap.
void mat_mul(int A, int B, int C, double out[A][C], double in1[A][B], double in2[B][C])
{
for (int i = 0; i A; i++) {
for (int k = 0; k C; k++) {
out[i][k] = 0.;
Re:Write-only code. (Score:4, Informative)
(Don't bother responding if your code can't meet all of the boldface conditions...
Challenge accepted, see here for my first go that satisfies all the bolded conditions. Any further conditions you impose now will make you look even more like an ass than you already do for posing such a fanboyism challenge. Note well: there are literally only four lines of code to achieve this - I posted the other lines to give the readers some context.
struct foo_t {
// Start of challenge
// End of challenge, you're welcome
size_t one;
size_t two;
};
void *do_something (struct foo_t *array)
{
printf ("%zu, %zu\n", array[0].one, array[1].two);
}
#define THREAD_CREATE(fptr, type, a, b) do {\
type array[] = { a, b };\
pthread_t tmp;\
pthread_create (&tmp, NULL, (void *(*) (void*))do_something, array);\
pthread_detach (tmp);\
} while (0)
int main (void)
{
...
struct foo_t first, second;
...
THREAD_CREATE (do_something, struct foo_t, first, second);
...
...
}
in the real world, you can't simplify the system requirements to meet the deficiencies of your coding language)
As you can see above, no deficiency found - in the actual real world, as opposed to the one populated by inexperienced fanboys like yourself, the above solution would not be discarded from the solution set if it meant changing the codebase from C to C++.
You can now be an adult about the whole thing, accept that what you can do in C++ can be done in a readable manner in C as well. I don't think you will, though - I have a feeling you'll come up with another idiotic "C++ can do this, can C do this?" question, at which point I will once again be happy to smack you in the face with a solution like I did just now.
Consider yourself schooled.
Re:Write-only code. (Score:4, Insightful)
This is a potential problem with every single programming language ever. No exceptions. C is somewhere in the middle with that risk, but it is no where near the worst. I'd give that medal to Perl.
Re: (Score:3)
True, but for example while Scheme is highly extensible, there isn't a lot of really obscure syntax, nor is there a preprocessor. Anything that's Turing complete can develop widely divergent dialects, but C++'s dialects are notoriously obscure.
Re: (Score:3, Insightful)
This is a potential problem with every single programming language ever. No exceptions. C is somewhere in the middle with that risk, but it is no where near the worst. I'd give that medal to Perl.
The more powerful the language, the more it's like a loaded gun: You can use it responsibly and do amazing things with it, or you can put a bullet through your foot with it. Choice is yours... and the closer you get to bare metal with the language, the greater the chance of lead meeting foot at high speed.
Re: (Score:3)
The more powerful the language, the more it's like a loaded gun: You can use it responsibly and do amazing things with it, or you can put a bullet through your foot with it. Choice is yours... and the closer you get to bare metal with the language, the greater the chance of lead meeting foot at high speed.
Oddly, that brings to mind the famous quote from Bjarne Stroustrup himself...
"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"
I've only briefly looked at C++, but when I did, I understood what he meant. C++ lets you do some very complex, powerful and abstract things compared to C, but even in the small amounts I learned (and have since forgotten) you could see the potential for an overly confident smartass to misuse or fail to understand t
Re:Write-only code. (Score:5, Insightful)
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.
Less so than C, especially as used in the kernel. Seriously read some of the Linux kernel and compare it with any good C++ project. The kernel loses BADLY. The manually implemented virtual classes are not pretty and not type safe, and neither are all the ugly macros needed to do things that would safe, automatic and easy to read in C++.
Re: (Score:3)
I don't think you actually mean "virtual classes" here. But yeah, if you have to implement classes in C, maybe you should have used C++. One of C++'s problems is that it builds on C, though, so the fact that you can do some things, particularly classes, better in C++ than in C shouldn't be a surprise: that's the itch they were scratching.
Re: (Score:2)
I don't think you actually mean "virtual classes" here. But yeah, if you have to implement classes in C, maybe you should have used C++. One of C++'s problems is that it builds on C, though, so the fact that you can do some things, particularly classes, better in C++ than in C shouldn't be a surprise: that's the itch they were scratching.
I mean virtual tables, which is the implementation side of virtual classes. The kernel uses virtual tables extensively to describe interfaces of modules and especially drivers.
Re: (Score:3)
Sounds like that goes back to the "lack of standard ABI" problem. C lets you specify exactly what you want explicitly, but C++ has no consistent ABI, you get different results depending on which compiler you use.
Re:Write-only code. (Score:4, Informative)
Sounds like that goes back to the "lack of standard ABI" problem. C lets you specify exactly what you want explicitly, but C++ has no consistent ABI, you get different results depending on which compiler you use.
Not anymore. At least not on Linux. Intel wrote a C++ ABI for IA64 (Itanic), since it was the first of its kind it got adopted to a defacto ABI for all other architectures as well. This is what g++ has been using for over a decade, and what every other compiler is mimicking to stay g++ compatible.
Even a failed architecture can sow the seeds for good things in the open source world.
Re:Write-only code. (Score:4, Insightful)
Re:Write-only code. (Score:4, Insightful)
Actually, the kernel code is quite clear and understandable to any decent C programmer. I find it hard to consider it losing BADLY to anything.
Note that C++ isn't necessarily type safe either. It's not at all difficult to cast an object pointer to the wrong type and crash. It's no harder than it is in C.
Casting (Score:3, Insightful)
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!
Re:Casting (Score:5, Insightful)
Modern, properly designed C++ code is absolutely safer than C code. However, because C++ is a superset of C, you can obviously write code that's just as unsafe as C, simply by ignoring the best practices and writing "C with classes" (which many do). A lot of what you can do in C++ exists solely to provide backward compatibility, both with earlier versions of itself as well as with C.
C++ gives you the ability to create new types using objects, which you can operate on both through member functions as well as logical operator overloading (where it makes sense to do so). For instance, you could create a class for handling file paths (as opposed to using raw character pointers or arrays, or even C++ strings), and when that class is properly developed and debugged, you can then be confident that you no longer have to worry about accidentally creating a security vulnerability or introducing a crashing bug. Moreover, it can handle path-specific things, such as ensuring proper form when paths are concatenated. Even better, when compiled down, it's really no different than code written in C, since C++ still adheres to the "zero-overhead" principle for most features.
When people talk about C++'s "dangerous casts", they're almost universally taking about "C-style casts", which are discouraged in modern C++. Instead, you should use the more explicit casts, which either use static compile-time checking or even run-time checking as appropriate. Whenever you have to resort to a C-style cast in C++, you had better have a *very* good reasons (in many cases it's just a design failure). Nowadays, that also includes managing raw memory or raw pointers thanks to the addition of standardized smart pointers.
This is why C++ is almost universally used in the videogame industry (I work as a videogame programmer), because is strikes a reasonable balance between safety, advanced language features, and performance. It's also nicely compatible with C libraries, with which we often have to interface at the OS level, or when using 3rd party libraries. And finally, while "better" alternatives arguably do exist, C++ is also well supported and extremely ubiquitous across the industry. As the saying goes, "quantity can have a quality all it's own". This is important when trying to hire experienced developers, or looking on the web for solutions to a problem.
Re:Write-only code. (Score:5, Insightful)
Re: (Score:2)
Re: (Score:2)
Of course all C++ features have their uses. Otherwise they wouldn't exist. Every one of them scratches some itch.
Re:Write-only code. (Score:5, Insightful)
Sometimes wounds itch. When you scratch them, they break open and fester. C++ scratches exactly these itches.
Re:Write-only code. (Score:5, Insightful)
The same applies with Perl. And PHP. And Java. And Go. And Ruby. And Python. And Javascript.
I've also seen good C/C++, PHP, Java, Python, etc.
You can write crappy convoluted code that uses odd, unusual frameworks and features in every language. It isn't the fault of the language - it is the fault of the people (ab)using it.
Re: (Score:3)
Re:Write-only code. (Score:5, Interesting)
It's both. Type import this from the interpreter, and you'll get this:
While it doesn't always manage it, if you read the discussions and PEPs relating to the language's design it's clear that the idea of a "Pythonic" way of doing things is one of the top considerations.
Re:Write-only code. (Score:4, Interesting)
Are you comparing the complexity of Java vs C++ (as a language, not as a runtime)? Are you kidding?
You can write convoluted code in any language, this is true. But C++ code can be made UNREADABLE as well as convoluted. In Java, there is only the one way of writing things. You can architect them differently if you want, but there's usually one way to write them. In C++, you have a hundred. THIS is the problem with C++. And let's not even talk about macros which is one more way to write things. You can actually write your whole program only through macros. Macros are turing-complete. They're just a language inside the language... This is pure madness.
Re: (Score:3)
C++ templates are also Turing-complete at compile time.
When I tried learning a bit of LISP, the thing that struck me was that its metaprogramming language is also the runtime language, and I like that very much.
Re:Write-only code. (Score:5, Funny)
Re:Write-only code. (Score:4, Interesting)
Sorry, but the original Lisp got quite a few things wrong itself and by the time it got around to fixing it had missed the boat. Here's a sample
If modern Scheme had been introduced in 1965 instead of 1975 we might be today programming in some modern dialect of Lisp.
Now some fanboi will come and explain why these things aren't a bug but a feature in 3, 2, 1
Re: (Score:3)
Ugly and Complex is better than Ugly and Complex and Inconsistent.
Syntax and typo errors compile (Score:5, Informative)
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).
Re: (Score:3)
gahh. I just typoed my example!!! oops.
int (*foo)[20];
int *foo[20];
But I bet that error would even compile!
Re: (Score:3)
gahh. I just typoed my example!!! oops.
int (*foo)[20];
int *foo[20];
But I bet that error would even compile!
yeah but in principle that's not much different than
t = x+y*z; different than
t = (x+y)*z;
Except that people mostly remember algebra precedence. Sure 'c' precedence rules and postfix syntax has its warts (consider the typedef function), but your example isn't one of them...
For me the truly annoying things about C vs Fortran, is that C basically allowed to ignore your parenthesis from a equi-precedence, computational point of view where (x+y)+z != x+(y+z); Also, its definition of sequencing is kind of brok
Re: (Score:3)
x = x++; is basically undefined - How so? The code increments x, the "x=" part is harmless, again you are using redundant code that any halfway competent C programmer would not write in the first place.
I've been making a good living from C/C++ for 25yrs, I don't see your "problems", and I can't imagine the "workarounds" to be anything other than
Re: (Score:3)
C type declarator syntax is insane. I don't know any other language that prompted a creation of a separate utility [die.net] for the sole purpose of deciphering its types.
Array-to-pointer decay is also badly designed. Why exactly shouldn't I be able to pass arrays by value? Pascal lets you do that, for example. If I really want to pass it as a pointer, I'd just declare the argument as a pointer, and the language even has syntax for that. And this is especially damning when the language lets you write something like v
Almost got me (Score:5, Insightful)
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.
Full Disclosure (Score:5, Informative)
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?
Mod parent up (Score:5, Informative)
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?
Another troll-FP? *Excellent*! (Score:3)
No (Score:2, Insightful)
Re:No (Score:5, Insightful)
A clickbait article about a flamebait rant, commented on by trolls.
God bless Slashdot.
No (Score:3)
Flamefest thread (Score:5, Funny)
Re: (Score:2)
For programming C++?
Re: (Score:2)
What comes next, a thread on "is Emacs better than Vi"?
Well? Is it?
Re:Flamefest thread (Score:5, Funny)
You mean that EMACS is now a good OS because it finally has a decent text editor?
Ahhhh, C++ (Score:3, Insightful)
Re:Ahhhh, C++ (Score:5, Insightful)
Any language that allows the programmer to override the '=' operator is truly, verily, bad. That makes the language over-programmable and a write-only language when trying to maintain other developer's code. Java may have fewer features, but that doesn't stop the developers from getting stuff done.
Re:Ahhhh, C++ (Score:4, Interesting)
Any language that allows the programmer to override the '=' operator is truly, verily, bad.
This is, to my mind, the most fundamental problem with C++: it is impossible to look at a page of code in isolation and know what it does, with confidence. Any of the operators could have been redefined to do anything. This is not a theoretical problem, I encountered a code base of horrors that a nerd who though he was God's gift to nerd-dom dreamed up, which had numerous standard operators reassigned to make the code he wrote "look elegant". It was impossible to analyze or maintain.
When the meaning of a simple programming construct is indeterminate, the language that supports it has failed disastrously.
Re: (Score:3)
Java may have fewer features, but that doesn't stop the developers from getting stuff done.
This is a stupid argument. You could just as easily say, "Assembly language may have fewer features, but that doesn't stop the developers from getting stuff done."
Re: (Score:3)
Doesn't mean that it doesn't suck big time. TR1 sucked. The STL sucks. Templates suck. The original goal of c++ - c with classes - was good, but come on - this has gone way too far off track.
Feature Request (Score:4)
Need the ability to moderate an entire Article/Summary as Clickbait or Troll.
Python/C++ Combo (Score:5, Insightful)
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.
Re:Python/C++ Combo (Score:5, Interesting)
Re: (Score:3)
It's the programmers that matter, not the language.
Re: (Score:3)
And who is sent to this coding hell? Crappy programmers.
Re:Python/Fortran Combo (Score:5, Interesting)
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.
Re: (Score:3)
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.
Re: (Score:3)
But for me it is not one language but a pairing that has caught my heart.
I'm in the same boat, with the same languages. Python for convenience, C++ for speed. I also use C for really low level embedded (PIC) stuff, but that's it.
This combination gives me the optimal mix of portability and power for the problem domains I'm interested in, and at this point I don't see any reason to leave C++ for anything else. The big trick is to adopt and strictly adhere to a set of reasonable coding standards that keeps you from doing all the stupid things the language lets you do.
C++ demands a
Yes, he was wrong... (Score:5, Insightful)
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#.
Machine Beauty. (Score:5, Interesting)
In 1998 David Gelernter wrote a book [amazon.com] 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.
True across the board. (Score:4, Insightful)
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.
C++ is hard (Score:5, Informative)
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 [google.com]. So there;)
* Scott Meyers More Effective C++ p.35
What's he afraid of? (Score:3)
"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.
"FORTRAN in any language" (Score:4, Interesting)
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.
C++ Downfalls, Compiler and Internationalization? (Score:4, Interesting)
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.
Which pays more to use? (Score:3)
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
Horrible compared to what? (Score:5, Insightful)
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.
STL (Score:5, Informative)
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... [stackoverflow.com]. 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.
Re: (Score:2)
Re:Ugh (Score:5, Insightful)
Oh no, on the contrary. There are plenty of idiots who can write code in C++.
Re: (Score:3)
A better specified language, with fewer holes in its design, wouldn't have these problems between 'language' and 'compiler'.
Re: (Score:3, Informative)
I'd say I've seen just as much piss poor code written in Java and C#, but that'd be a lie. I've seen FAR worse code written in Java and C# than I have in C++ because the level of entry is much lower.
When I was in college, not understanding pointers means you didn't graduate. Now... I interview "C# Developers" who claim 10+ years experience who can't tell me the difference between pass-by-value and pass-by-re
Re:How much is it C++ and how much the compilers? (Score:5, Interesting)
Bad programmers can produce bad code in any language, including one as well/thoroughly specified as Ada. The difference, though, is that what that code actually does is less subject to interpretation by the compiler.
I've observed that two Ada programmers will argue, "Is this program legal?" If the program is legal, they both -know- what the compiler will do (modulo the rare compiler/optimizer bug, which was usually caught through the stringent compiler validation.)
Two C++ programmers will argue, 'What will my compiler do with this code?"
Re:C++ (Score:4, Insightful)
Re:depends upon what you're making (Score:4, Informative)
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 [microsoft.com]). 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).
Comment removed (Score:5, Informative)
Re: (Score:3)
Symbian, BlackBerry OS, Wii U System Software, OKL4.
I'm sure I left some out.
Re: (Score:3)
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...
Re: (Score:3)
Re: (Score:3)
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