Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linus Torvalds on C++

harmful.cat-v.org

Post reply on HN
Print view View original

111–120 of 190 posts

Re: Linus Torvalds on C++

#111

Post by tspiteri »

jlarocco wrote: post #83
srean wrote: 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…

The STL is a huge leap over C, but it could be so much better. On one hand, it's not particularly good for really low level coding, as other people have explained. But on the other hand, it's not really convenient for higher level coding, either. To see what I mean, compare the interfaces of std::string [1] and Qt's QString [2]. Common, simple things like converting numeric data to/from string, splitting into substri…

I think that std::string does not support conversions as part of the class because those operations do not need direct access to the internal data of the string class. They could be written as helper functions (as opposed to member functions) easily without loss in efficiency. Member functions are used when they need direct access to the private fields. For example, C++11 has a new group of functions, std::to_string(...), and their counterparts std::sto*(...), which are not member functions [1].

[1] http://en.cppreference.com/w/cpp/string/basic_string

Re: Linus Torvalds on C++

#112

Post by tspiteri »

pavanky wrote: post #80
mikeash wrote: post #14

Earlier quoted context omitted.

If I understand what proponents of C++ say, C++ is supposed to be suited best for medium-level programming where abstraction is helpful but low-level constructs and speed are still helpful. It's supposed to give you many of the benefits of higher level languages while still giving you high performance. It's intended to be widely portable but still easily hook into special OS-specific facilities. This description soun…

The problem with C++ is, it is not language that has been built from scratch. It is just a layer upon layer upon layer upon C written by various people for various usecases. So there is no way to "properly manage" a C++ project. Unless it is maintained by one single person (or few like minded people)

I was going to disagree with you by saying that those layers are there for a reason; and they are there for a reason, mainly backwards compatibility. But thinking a bit more, I have to agree with you that still, those layers are the problem with C++. If you want to maintain old code, you would have to be conversant with loads of different idioms, it is as if you are maintaining multiple languages, starting from C and going on to the latest C++.

To write new code, C++ can be very clean, and C++11 is a huge step in the right direction for this. But to maintain code, especially code written by someone else, C++ can be a little bit hard. And it can never be easier than maintaining C code, because maintaining C code is a subset of maintaining C++ code.

Re: Linus Torvalds on C++

#113

Post by zoul »

groby_b wrote: post #78
redthrowaway wrote: post #41

Earlier quoted context omitted.

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

There's a large faction in AAA games that thinks C++ is a stupid idea. It's debatable who's right in that debate, but good points are being raised. The problem is not so much that C++ is a worse language than C - it's that it makes it insanely easy to shoot yourself in the foot in hideously complex ways that take forever to unravel. See e.g. two phase name lookup - http://blog.llvm.org/2009/12/dreaded-two-phase-name-…

It’s a great pity that Objective-C doesn’t get more attention in this regard. It’s C, so it features all the simplicity, elegance and existing APIs. And at the same time it offers a good, simple and flexible object model with almost no surprises. The performance can be very good, too, as proved by the Apple runtime, and you can always drop to lower-level tricks or plain C when you need it. The syntax takes some getting used to, but then turns into another advantage, since it’s very self-descriptive. Again, it’s a shame it gets so little attention outside the Apple world, because it would be a perfect match for many use cases.

Re: Linus Torvalds on C++

#114

Post by lclarkmichalek »

Maro wrote: post #109
sirclueless wrote: post #43

Earlier quoted context omitted.

And everything to do with the fact that it was written by C++ programmers.

Doom3 was written in C++ by John Carmack. https://github.com/mtrencseni/doom3

I imagine he had some help with that. And a lot of what he's been talking about recently is about tools for keeping code quality high; he obviously places a premium on good code over working code.

Re: Linus Torvalds on C++

#115

Post by nwmcsween »

burgerbrain wrote: post #62
nxn wrote: post #6

Earlier quoted context omitted.

Haven't seen it. I've seen many other examples of Torvalds being an ass, but I don't bother to keep track really. It does make me wonder though how he's able to get away with responses like that, when most other "founders" (not sure what the proper term here really is) would have the majority of their users/supporters just go elsewhere. EDIT: ... Let alone have supporters who get defensive enough to start downvoting…

"It does make me wonder though how he's able to get away with responses like that" The man delivers.

He delivers personally but Linux as a kernel is a pile of crap, mass duplication mdadm vs dm posix capabilities vs actual unretarded capabilities... Linus is good at coding but absolutely horrible at direction and that's exactly what Linux needs a direction for the better instead of evolution of substandard abstractions.

Re: Linus Torvalds on C++

#116

Post by shin_lao »

kabdib wrote: post #55

I use C and C++ extensively (30+ years writing C, 25 or so writing C++). I much prefer C when writing systems-level code. It's simpler and a lot more predictable. You don't get the illusion that things like memory management are free. I /have/ written drivers in C++. Here you have to be very careful about memory allocation (calling 'new' in an interrupt handler is usually death, though I've also written very speciali…

#include is hardly going to work at the first insertion that will call the allocator.

The argument "let's use a castrated language to avoid mistakes" falls short. What about communication within the team?

Properly used and tailored, the STL is extremely adequate to kernel development. The power of the template engine enables the compiler to do some very clever optimizations.

More information: http://www.osronline.com/article.cfm?article=490

Re: Linus Torvalds on C++

#117

Post by wisty »

nxn wrote: post #6
stephen_g wrote: post #5

Has anyone really not seen this in the last two years? Anyway, Linus may be a very experienced C programmer, but that doesn't mean his opinion on C++ carries much weight... I'd be more interested on what someone who actually has a lot of experience in using C++ says. Especially with modern C++ and recent tools, libraries etc, which are very different from what was around five or ten years ago. I suppose it is nice fo…

Haven't seen it. I've seen many other examples of Torvalds being an ass, but I don't bother to keep track really. It does make me wonder though how he's able to get away with responses like that, when most other "founders" (not sure what the proper term here really is) would have the majority of their users/supporters just go elsewhere. EDIT: ... Let alone have supporters who get defensive enough to start downvoting…

If Torvalds is either nice 99.99% of the time, and 0.01% of the time gets involved in flame wars, guess which gets reported?

Re: Linus Torvalds on C++

#118

Post by Maro »

lclarkmichalek wrote: post #114
Maro wrote: post #109

Earlier quoted context omitted.

Doom3 was written in C++ by John Carmack. https://github.com/mtrencseni/doom3

I imagine he had some help with that. And a lot of what he's been talking about recently is about tools for keeping code quality high; he obviously places a premium on good code over working code.

My point is, you can write good, readable, performance, large-scale codebases in C++. Note that Carmack wrote his previous engines such as Quake3 in C, and switched to C++ at some point. I think one of the reasons was that as their programming team size grew from 5 to 50 at id, C++ started making more sense for them. If you look at a book like "Large Scale C++ Software Design", the subset of C++ it uses is about the subset that I think makes sense in practice, roughly C with classes. To be fair, I think that was the language subset that actually worked in compilers at that time.

Irrespective, I don't doubt that C is a valid and perhaps better choice for writing an OS kernel. There's less abstraction in C, and you have to worry less about making sure you don't use a language feature of C++ that has a hidden cost.

https://github.com/mtrencseni/quake3

The book I mentioned, "Large Scale C++ Software Design":

http://www.amazon.com/Large-Scale-Software-Design-John-Lakos...

Re: Linus Torvalds on C++

#119

Post by fauigerzigerk »

aidenn0 wrote: post #57
droithomme wrote: post #7

Earlier quoted context omitted.

"I'd be more interested on what someone who actually has a lot of experience in using C++ says." I have considerable experience with C++, going back to when it was called C with Classes and you used a preprocessor to convert C with Classes code to C and then compiled the C. What Linus says is pretty much true. I don't expect it to matter though since when people say "I'd be more interested on what someone who actuall…

I don't like C++ but the FQA isn't a very good critique of it. It's basically "Why didn't Bjarne write the language the way Yossi would have?"

Isn't every critique of programming languages necessarily very personal? After all, programming languages are languages. They help people develop and express ideas, and we don't know a whole lot about how creativity actually works and how it is influenced by the tools we use in the process.

Take inconsistencies for instance. An inconsistency between two things means that one but not the other can be inferred by applying a particular principle. But who chooses the principle that is applied to decide whether or not there is an inconsistency?

There is no shortage of "principles" in people's heads, many of which are not at all formal, maybe not even explicitly stated and they might not be called principles at all. They may be complex webs of associations, habits, or patterns that apply in some but not in other application areas.

Another such thing is the balance between generality and special casing. You could probably find out empirically what level of either is outside of what most people can use productively. But no individual is most people. So everyone has to decide what makes them personally productive.

The only regrettable thing is that so few people even try to find out.

Re: Linus Torvalds on C++

#120

Post by cageface »

acqq wrote: post #96
groby_b wrote: post #72

Earlier quoted context omitted.

Instead of writing an endless reply, I suggest you read the EASTL white paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n227... Essentially, listing all the hoops EA went through to have a useable STL for games. (And for programming purposes, AAA console games and OS kernels are pretty close)

And also what Bloomberg saw C++ lacking: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n185... I'd still like to see how both these papers influenced last C++ standard at the end (I admit I didn't try to follow) -- is there finally a "standard" way to do all that?

Notice the dates on these papers though. 2005 and 2007 are a long time ago in C++ compiler land. I'm using the STL in very low latency DSP code with zero problems. You have to make sure you don't allocate memory in realtime callbacks but that's just as true of malloc.
Post reply on HN