Live data from Hacker News

Linus Torvalds on C++

harmful.cat-v.org

41–50 of 190 posts

Re: Linus Torvalds on C++

#41
post #35
post #30

Earlier quoted context omitted.

It's that "if properly managed" bit that would be a nightmare from hell to manage... easier to just do it in C. What it's intended to do is rather different than what it's actually used for in real life..... code talks, anything else is just smoke, right? IF someone can come alnog and show us a better way in any language, then tehre's something to argue about, otehrwise, the guy who has working code wins over the guy…

I guess what I'm really interested in here is, if git isn't an appropriate project for C++, just what is?

AAA games, browsers... Really, anything where you need to have some abstraction but performance is still critical.

Re: Linus Torvalds on C++

#42
sigh not this flamewar repost again.

The fact that he leads with "language X sucks because it attracts type Y programmers" is quite possibly the worst, cheapest, and lowest attack I've ever seen in technology. It's sad that a technical hero like Linus would basically behave like such a tantrum-throwing child. It reflects poorly on the whole tech community.

Re: Linus Torvalds on C++

#44

sigh not this flamewar repost again. The fact that he leads with "language X sucks because it attracts type Y programmers" is quite possibly the worst, cheapest, and lowest attack I've ever seen in technology. It's sad that a technical hero like Linus would basically behave like such a tantrum-throwing child. It reflects poorly on the whole tech community.

I was sure there was a rule that this is only allowed to be reposed on Thursdays. My google fu is failing me on the rule though.

Today isn't Thursday is it?

Re: Linus Torvalds on C++

#46

In principle I agree that C is a more appropriate choice in many situations, but I think his pure hatred for C++ is kind of funny.

I think it's partly a gambit or defensive permission, or sort of an allergic reaction to having C++ suggested to him SO MANY TIMES over the last two decades.

Re: Linus Torvalds on C++

#47
Although it is true that certain languages give you the flexibility of writing "utter crap", I can also write pretty crappy unmaintainable code in pure C just as easily. Nevertheless, after 14 years of coding in C++, I love how beautiful my C++ code comes out. All that "OO crap" makes my code easier to understand, debug, maintain and extend. I would take that at the expense of how much more difficult it is to create binary compatible libraries in C++ (something quite easy in C). I can see how for a kernel, that would be more important.

Re: Linus Torvalds on C++

#48
post #20

Now this has me a bit confused, why no love for STL ? I wish Linus had added more detail. Is the complaint that the binaries are too big (not quite, if you strip them of the unnecessary symbols) ? or is it that it can be a tedium to go over the reams of error messages that compilers spit out when things go wrong. The second point I am willing to concede, it requires you to read messages inside out, which lisp does tr…

STL containers are essentially the opposite of what's used in many C programs, Linux kernel included. In C, in order to string several data items into a collection one would add a container-specific control element to the data item, and then feed a pointer to this element to the container code. Container sees only these elements, and nothing else. On one hand, accessing actual data item obviously requires casting and…

Boost.Intrusive does this, without the casting or offsetof'ing.

http://www.boost.org/doc/libs/1_47_0/doc/html/intrusive.html

Not that most of what you said isn't true. Just picking the nit that 'the container owns the data' holds only for the STL, not C++ in general.

Re: Linus Torvalds on C++

#50
post #29
post #28

Earlier quoted context omitted.

There are a few problems with STL when writing kernel or API code. One is due to it's completely generalized nature. Since it's not heavily optimized for either speed or memory use, it tends to perform rather poorly in both areas. Not that acceptable when you're making kernel code, where it's often better to write optimized data structures for the problem at hand rather than just relying on templated code. In that si…

So if the kernel uses STLPort, that means that every other program written on top of the kernel needs to use it. The Linux module API/ABI has worse problems than that already.

Oh sure, "We have problem A, let's add problem B, while solving nothing."

Please explain to me how this would fix anything? ;)

Post reply on HN