Hacker News Reader

Comment by overgard | Hacker News Reader

It's worth noting that C++ in 2007 was a lot different than C++ in 2016. There were a lot of valid complaints back then which have since been addressed. (I know personally in 2007 I hated C++, but I find it pleasant to use now.) The compilers are massively improved, the STL is a lot more stable, tools and IDE's are vastly better, some of the new language features are a huge help (lambdas, simple type inference, range based loops, override keyword, etc.) I'd still use C for an operating system, but things have definitely improved massively.

View on HN

If I understand correctly, Linus was not only dismissing C++, but also the object-oriented programming paradigm. His main concern was creating abstractions that result in inefficiencies which most of us consider not bad enough for writing userland software.

What's interesting is Stroustrup proudly states that C++ provides "cost-free abstractions". I'm not too familiar with C++ implementations; is it fair to say that?

What's interesting is Stroustrup proudly states that C++ provides "cost-free abstractions". I'm not too familiar with C++ implementations; is it fair to say that?

C++ was invented when efficiency was measured in instruction counts and processor cycles, so he optimized his language in those terms.

Processors are much more complicated now, and cache alignment and branch prediction and pipelining are much more important for efficiency than counting the number of instructions something takes.

But even then C++ is basically cost free if used correctly. Of course I am not comparing it with some hypothetical hand optimized assembly, but specifically when considering cache alignment C++ has massive advantage in this area compared to languages like Java. Compared to C there is nothing in C++ that would make cache alignment more difficult by design.

It's fair, in a sense that it's possible to implement cost-free abstractions in C++.

However, you have to know what you're doing: some of the C++ abstraction mechanisms will cause the compiler to insert executable code at places a C programmer might find unexpected (e.g constructor and destructor calls).

In one word, you still have to learn how to use the language properly, and it's difficult - but definitely worth it.

Interestingly enough, some of the abstraction mechanisms provided by C++ (templates, inheritancy, polymorphism, ...) can also be partially simulated in C, with a lot of effort (the Linux kernel makes a heavy use of them (macro-powered)).

It's just that C++ makes those things easy to do ... allowing your incompetent teammates to easily shoot you in the foot.

> is it fair to say that?

If the programmers wouldn't be dogmatic it would be possible, but most are. It's "we use boost/smart pointers/whatever for everything" programmers that produce the mess that I also wouldn't like to have in the kernel.

Often, but not always.

One example is calling virtual functions. There's an extra memory lookup to resolve the function call at runtime.

Almost all the time, that extra single memory lookup is irrelevant. But just occasionally, that cost can have an impact.

In principle it's no different to C - you need to understand the basics of what code the compiler is going to generate to do what you're asking it to. In C++ the constructs are much more complicated and that mapping becomes less clear.

Yes, and a little bit off topic but I say the same things about Java too. Java 8 is also great and I hated Java 6. But I love Java now and I like C++ too although much of my C++ looks like C.

Certainly, but the useful, stable subset of C++ with reasonable advantages over C with its cruft (e.g. setjmp/longjmp vs. exceptions) was already much larger than {}.

Reply on news.ycombinator.com