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?

Comments

Write-only code.

[mellon]

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.

[Anonymous Coward]

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.

[Anonymous Coward]

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:Write-only code.

[Carewolf]

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:Write-only code.

[mellon]

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.

[loonycyborg]

I definitely disagree here. All features of C++ have their uses and it's possible and necessary to master them all. This language is focused on getting the job done. Thus some of its design decisions don't look very nice. But it's the most usable language in its niche.

Re:Write-only code.

[mellon]

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:Write-only code.

[mellon]

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:Write-only code.

[KermodeBear]

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:Write-only code.

[schitso]

One of the nice things about Python is the very concrete idea of what is and isn't "Pythonic". I've never had too much difficulty jumping right in to something written in Python and having a good idea of what's going on.

Re:Write-only code.

[sjames]

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.

Re:Write-only code.

[Pieroxy]

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:Write-only code.

[Dwedit]

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.

[Anonymous Coward]

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.

[Penguinisto]

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:Write-only code.

[johanw]

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.

[grahamwest]

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.

[spiralx]

It's both. Type import this from the interpreter, and you'll get this:

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

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.

[wed128]

Sometimes wounds itch. When you scratch them, they break open and fester. C++ scratches exactly these itches.

Re:Write-only code.

[Anonymous Coward]

C is quite stable compared to various other language, even factoring the C99 implementation slowness or difficulty in. Since the C11 change of standardization policy, the language will be even more stable in the future.

Re:Write-only code.

[wed128]

Ugly and Complex is better than Ugly and Complex and Inconsistent.

Re:Write-only code.

[Carewolf]

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.

[Darinbob]

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.

[Rei]

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.

[Dogtanian]

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 the subtleties of these features and have things go wrong in a manner that was far more convoluted, non-obvious and hard to debug in a sadistically high-level manner than simply overflowing some poxy buffer.

AFAIK (and IIRC!) Java- which came after C++- is in many respects *less* powerful and more constrained in terms of what you can do (or at least makes you do it more explicitly) and some criticised this as dumbing down for industry that wanted "quantity over quality" programmers. Maybe so, but would you want to deal with some horribly subtle bug that was ten levels of abstraction away, all because some naive just-out-of-college programmer did something a bit too clever for his own good when overloading an operator?

Now that I think about it, I remember reading criticism of C#'s increased flexibility in operator overloading (compared to the language it was mostly a clone of, Java) as being A Bad Thing for the same reason.

Re:Write-only code.

[ChrisMaple]

The(nice(thing(about(Lisp(is(I(don't(have(to(use(it))))))))))).

Re:Write-only code.

[spitzak]

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.

[Rei]

The sample code will copy a and b twice, once to put them in the lambda closure

Only without optimization flags enabled. Otherwise the lambda will be inlined in most cases.

This is the general problem with C++, in that the shortest code is often the slowest

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

The slowness is visible in C, where you would probably

To reiterate my first post:

Show me the code (emphasis: show me actual code, don't just say "... this is how I'd do it" and a rough description

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.

[Alomex]

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

1. the only data structure available is the list. Scheme includes arrays and so much better for it
2. it doesn't have pointers, which means it is hell to build a complicated but very efficient data structure like threaded trees
3. (it(has(too(many(parenthesis) ) ) ) ). In part because it attempts to operate under the illusion that a function call like (ADD 1 2) is the same as the list (ADD 1 2) which it isn't and hence the setq and ' rigamarole. In fact back when Lisp was first introduced its creators thought that not long from there a version 2.0 would be introduced using more standard notation, like ADD(1,2) or even, _gasp_ 1+2.
4. The main flow control structure is recursion. Recursion can be very nice and elegant, but there are times where one needs a for loop or a while loop, and one can either shoe horn it under recursion, or simply make the language richer and include those control structures (see again Scheme) for things are best understood as a for or a while loop.
5. variables were a bit of a kludge which lead to juggling of partial results into function parameters

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:Write-only code.

[spitzak]

The sample code will copy a and b twice, once to put them in the lambda closure

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.

[Uecker]

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.;
              for (int j = 0; i B; j++)
                out[i][k] += in1[i][j] * in2[j][k];
          }
    }
}

Re:Write-only code.

[TheRaven64]

This is true. On Linux, the only compilers that I know of that use the same C++ ABI as gcc are clang, ICC, XLC, ARMcc, Open64 and Path64. If you're using something else then you may encounter problems.

Re:Write-only code.

[goose-incarnated]

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, so help yourself (BSD license)

.

Documentation is over here: PDF link, but html available, 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.

[goose-incarnated]

(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 {
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 {\

// Start of challenge
type array[] = { a, b };\
pthread_t tmp;\
pthread_create (&tmp, NULL, (void *(*) (void*))do_something, array);\
pthread_detach (tmp);\

// End of challenge, you're welcome
} 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.

[serviscope_minor]

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:Write-only code.

[Rei]

BZZT! Wrong! Think: what happens if a and b are local variables and the function creating the thread returns before the lambda runs?

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:

#include <iostream>

void do_something(int a, int b) { std::cout << a << b; };

int main(int argc, char** argv)
{
int a = 12, b = 23;
([=](){ do_something(a,b); })();
}

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:

main: .LFB1262:
leal 4(%esp), %ecx .LCFI6:
andl $-16, %esp
pushl -4(%ecx)
pushl %ebp .LCFI7:
movl %esp, %ebp
pushl %ecx .LCFI8:
subl $12, %esp
pushl $23
pushl $12
call _Z12do_somethingii

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.

#include <iostream>
#include <stdio.h>

void do_something(int a, int b) { std::cout << a << b; };

int main(int argc, char** argv)
{
int a, b;
scanf("%d", &a);
scanf("%d", &b);
std::cout << 34;
#if 0
([=](){ do_something(a,b); })();
#else
do_something(a,b);
#endif
}

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:

main: .LFB1262:
leal 4(%esp), %ecx .LCFI6:
andl $-16, %esp
pushl -4(%ecx)
pushl %ebp .LCFI7:
movl %esp, %ebp
pushl %ecx .LCFI8:
leal -16(%ebp), %eax
subl $28, %esp
pushl %eax
pushl $.LC1
call scanf
popl %eax
leal -12(%ebp), %eax
popl %edx
pushl %eax
pushl $.LC1
call scanf

Re:Write-only code.

[serviscope_minor]

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;
if(!xvector_ins_tail(tfar, &some_float...))
{ //Do something error related here //probably a longjmp or goto. //Don't forget to free all that memory!
}

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:

vector<float> sfar = {1.1, 2.2, ...};
 
for(const auto& f:sfar)
  cout << f << endl;
 
eg_t eg[] = {...};
 
vector<eg_t> teg, sub;
for(const auto& e:eg)
  eg_t.push_back(e);
 
for(auto e:teg)
{
  e.i += 2;
  e.f -= 5.0;
  sub.push_bach(e);
  cout << "Returning " << e.i << " // " << e.f << endl;
}
 
//Well, the nativea bit is basically already working in the C++ code since internally, std::vector uses a native array

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:Write-only code.

[friesofdoom]

I know debugging templates in c++ can be challenging for a rookie, but at least they /are/ debuggable. I'd like to see someone trying to debug some of those crazy macros... Talk about read-only code!

Re: Write-only code.

[spitzak]

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 lamda structure are in the memory location that the lambda function looks for them, so they must be copied (and memmove is explicitly not allowed by C++, you must use the copy or move constructor).

The fix is to make do_something take the arguments as const references, which are really pointers, and then the lambda caller can just make the pointers point at where a and b are in the lambda structure.

C++ would have been helped considerably if all arguments to functions were const references (with the compiler allowed to choose whether to copy or make a reference depending on which is more efficient). You could use volatile to make a non-const reference if needed (though most code I have seen use a pointer for out parameters). This apparently would break too much code, but is by far the biggest source of unexpected inefficiency in C++ and really should be fixed rather than having the code writers decide whether a copy or reference is faster.

Almost got me

[halivar]

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

[mu51c10rd]

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?

Re:Full Disclosure

[Anonymous Coward]

Slashdot used to do full disclosure, under its previous owner. Dice lacks even basic business ethics.

Re:Ugh

[mellon]

Oh no, on the contrary. There are plenty of idiots who can write code in C++.

Another troll-FP? *Excellent*!

[pla]

/ Grabs popcorn
// Dons asbestos armor

No

[Anonymous Coward]

Linus was not going overboard. In this rare instance, I'd argue he hasn't gone far enough.

Re:No

[boristhespider]

A clickbait article about a flamebait rant, commented on by trolls.

God bless Slashdot.

Re:How much is it C++ and how much the compilers?

[david.emery]

A better specified language, with fewer holes in its design, wouldn't have these problems between 'language' and 'compiler'.

No

[bhcompy]

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.

Flamefest thread

[fph il quozientatore]

What comes next, a thread on "is Emacs better than Vi"?

Re:Flamefest thread

[RailGunner]

Emacs lost that argument when it added a vi mode. :)
gVim FTW

Re:Flamefest thread

[sconeu]

You mean that EMACS is now a good OS because it finally has a decent text editor?

Ahhhh, C++

[segedunum]

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.

Re:Ahhhh, C++

[gnupun]

Although the language itself isn't truly, truly bad,

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++

[BarbaraHudson]

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.

Re:Ahhhh, C++

[crunchygranola]

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:Ahhhh, C++

[Yunzil]

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."

Feature Request

[Rhyas]

Need the ability to moderate an entire Article/Summary as Clickbait or Troll.

Python/C++ Combo

[EmperorOfCanada]

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.

Re:Python/C++ Combo

[Dan667]

why not Python and ANSI C? Then you have productivity and glue code of Python and the raw speed of C without all the clutter.

Re:Python/C++ Combo

[phantomfive]

I'd rather work with skilled programmers in assembly than lousy programmers in (whatever amazing language you have).

It's the programmers that matter, not the language.

Re:Python/C++ Combo

[radtea]

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 higher level of discipline and maturity from developers than most languages because Linus is right: it is incredibly easy to abuse. A bad programmer will write bad code in any language, but C++ makes it really easy for bad programmers to express themselves, and that's a bad thing. That doesn't mean the language is bad, but it does mean it should only be used where its advantages (portability, efficiency, expressive power) are sufficiently great to overcome its weaknesses (excessive complexity, mediocre type safety, excessive complexity.)

Re:Python/C++ Combo

[EmperorOfCanada]

Yup. Fully agreed. That is why enterprise languages exist. They aren't build for coding they are the devil's tools for building the 10th ring of hell (still under construction, 90% done, next milestone won't be missed just as long as that milestone is a report on why they are missing all the milestones)

And who is sent to this coding hell? Crappy programmers.

Yes, he was wrong...

[RailGunner]

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#.

Re:How much is it C++ and how much the compilers?

[RailGunner]

A better developer who understands what it is he or she is trying to accomplish would help more.

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-reference, and don't know the difference between the heap and the stack.

Machine Beauty.

[TechyImmigrant]

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.

Re:How much is it C++ and how much the compilers?

[david.emery]

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:How much is it C++ and how much the compilers?

[RailGunner]

Two C++ programmers will argue, 'What will my compiler do with this code?"

You have a very good point, but that's less about the language and more about the compiler. Arguably the most broken compiler was (and likely still is) Microsoft's Visual C++.

But somehow C# is "fixed". LOL.

linus was right

[MagicMerlin]

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.

True across the board.

[Frobnicator]

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.

Mod parent up

[amaurea]

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:

• Was Linus Torvalds Right About C++ Being So Wrong? [Dice]
• Do Tech Companies Ask For Way Too Much From Job Candidates? [Dice] [Hiring]
• 'Chappie': What It Takes to Render a Robot [Dice]
• Demand for Linux Skills Rising This Year [Dice] [Hiring]
• Who's Afraid of Android Fragmentation? [Dice]
• H-1B Visas Proving Lucrative for Engineers, Dev Leads [Dice*] [Hiring]
• In Space, a Laptop Doubles As a VR Headset [Dice*]
• What Does It Mean to Be a Data Scientist? [Dice]
• Which Freelance Developer Sites Are Worth Your Time? [Dice*] [Hiring]
• JavaScript, PHP Top Most Popular Languages, With Apple's Swift Rising Fast [Dice*]
• Building a Good Engineering Team In a Competitive Market [Dice*] [Hiring]
• What Makes a Great Software Developer? [Dice*] [Hiring]
• The Highest-Paying States for Technology Professionals [Dice] [Hiring]
• What Will Google Glass 2.0 Need to Actually Succeed? [Dice*]

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 hard

[Prien715]

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

Syntax and typo errors compile

[goombah99]

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:Syntax and typo errors compile

[goombah99]

gahh. I just typoed my example!!! oops.
int (*foo)[20];
int *foo[20];

But I bet that error would even compile!

Re:Syntax and typo errors compile

[slew]

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 broken too (e.g., x = x++; is basically undefined as the evaluation order of x = f() + g()), but usually, you can find ways to code around these problem, but they are kind of ugly.

Re:Syntax and typo errors compile

[TapeCutter]

(x+y)+z != x+(y+z); - correctly evaluates to false in C, the parentheses can safely be ignored because they are redundant and make no difference to the outcome.
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 removing the redundant syntax.

As for TFA - It's unsurprising that Linus rants about C++, sure he's a very smart guy, but he's also an arrogant and highly emotional attention whore who wants things done his way or not at all. When he can't support his opinion with a logical argument, he invariably resorts to personal insults. Actually he often resorts to personal insults even when he can support his opinion.

Re:Syntax and typo errors compile

[shutdown -p now]

C type declarator syntax is insane. I don't know any other language that prompted a creation of a separate utility 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 void foo(int a[42]) - i.e. using the array syntax - but then silently replaces it with int* a, and completely ignores the bound. That's bad bad. Throw in C99's static for array boundaries (which is still pass-by-ref, and still triggers decay, but requires the array bound to be respected or UB happens), and it gets into the hilariously bad territory.

Granted, C++ has all of that, too. But then it also has std::array, which behaves in a sane way (no pointer decay, can pass by value, can easily query length etc).

What's he afraid of?

[Marginal Coward]

"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.

Re:C++

[Anonymous Coward]

Life is tough, but it's tougher if you're stupid.

Re:depends upon what you're making

[swilly]

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).

"FORTRAN in any language"

[Todd Knarr]

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.

Aren't all (but one) popular languages like this?

[Anonymous Brave Guy]

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:C++

[gyroheli]

Good excuse for being lazy. I guess C++ is only for the iron willed. C++ is like a russian prison, you'll know who the men are real quick.

Re:Python/Fortran Combo

[goombah99]

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.

Linus was full of it

[Anonymous Coward]

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.

C++ Downfalls, Compiler and Internationalization?

[chaim79]

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?

[LordZardoz]

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

Re:Aren't all (but one) popular languages like thi

[Wootery]

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

[ziggystarsky]

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

[ziggystarsky]

What I really wanted to say: Just allowing casting does not mean loosing type safety. If you use casting and crash it's your fault.

The language is just not very type safe if you need to cast often during regular programming.

Re:Casting

[Dutch Gun]

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.

Horrible compared to what?

[hey!]

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.

Sure, but he's not wrong.

[jcr]

C++ is indeed a horrible language, and it attracts people who develop great pride in their memorization of needless complexity.

-jcr

STL

[SoftwareArtist]

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()
Python: s.split()
C++: ... 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.

Doing even really basic, common operations with STL requires way too much work and produces absurd, hard to read code.

Re:depends upon what you're making

[jcr]

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
 

Re:Aren't all (but one) popular languages like thi

[Rei]

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:depends upon what you're making

[tibit]

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:WHAT HAPPENED TO SLASHDOT!?

[FatdogHaiku]

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:Python/Fortran Combo

[goombah99]

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:depends upon what you're making

[Pseudonym]

The only major kernel written in C++ that I know of is Windows NT [...]

Symbian, BlackBerry OS, Wii U System Software, OKL4.

I'm sure I left some out.

Re:Aren't all (but one) popular languages like thi

[ChunderDownunder]

Yep hence Vala, which transpiles to C-with-GObject.

Re:WHAT HAPPENED TO SLASHDOT!?

[Carewolf]

You're all talking about C++ and not LINUS TORVALDS! Have you all LOST your MINDS!? ;-)

I guess C++ is more controversial :D

Re:Aren't all (but one) popular languages like thi

[Wootery]

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:Torvalds was RIGHT

[loufoque]

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.

Re:He's right

[loufoque]

C++ is a language for experts, but so is C.

Re:He's right

[serviscope_minor]

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.

C is just lean and C++ is Multi-Paradigm

[snake_case_hoschi]

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.

10x Logic Lapse

[pfg23]

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.