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

91–100 of 190 posts

Re: Linus Torvalds on C++

#91

Post by jgraettinger »

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…

My own experience is that RAII has been very useful in low-level work when used to capture cleanup/finalization. Results in fewer if-statements and SLOC.

Issues of real-time performance and new vs malloc vs in-place/nothrow new also seem like orthogonal concerns here. The larger problem is that yahoo who's using the wrong algorithm and/or maintaining driver code w/o benefit of code review ;)

Re: Linus Torvalds on C++

#92

Post by ansgri »

mikeash wrote: post #35
dedward wrote: 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?

Low-level image procesing library supporting multiple pixel formats. How would you support anything from float16_t to int64_t without templates? And with templates you can selectively rewrite functions for some types in assembly.

The API of that library, though, is pure C.

Re: Linus Torvalds on C++

#93

Post by richardw »

bronson wrote: post #31
nxn wrote: post #26

Earlier quoted context omitted.

Had he worked on any would that have been a valid excuse to be derogatory to others over something as childish as what programming language they use? If you're going to ask me if I had worked on any OS kernels or distributed version control systems, the answer is no. But I would also never degrade people who might otherwise be willing to help contribute to my projects based on some idiotic notion of programming langu…

Hint: someone saying that you should rewrite your project in his own favorite language is NOT someone that you should allow to help or contribute.

Very few programmers spring fully-formed into kernel-level hackers. The correct place to filter is at the code level, not the person level. The 'right' people have the ability to change their approach until the code passes the filter.

Re: Linus Torvalds on C++

#94

Post by huhtenberg »

helmut_hed wrote: post #58
huhtenberg wrote: post #32

Earlier quoted context omitted.

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…

I don't see this. You can have a container of pointers in C++ just as you can in C. No special ownership semantics is assumed, nor do you have to decide which is the "owner" any more than you do in C. Or the problem is the same, at any rate. Plus you're not constantly casting to things. You can have a container of smart pointers, too, if you really don't want to think about ownership.

Container of pointers is not exactly what STL containers are about, and smart pointers is a big can of worms in themselves as I'm sure you know.

Another angle to consider is this - if container control elements (like list_head) are stored in the actual data items, they are effectively pre-allocated, meaning that inserting an item into the container involves no heap activity, and this helps simplifying the (error handling) code quite a bit. I mean... all in all, even it seems hacky, it is a more elegant idea. STL to C-style containers is what Java is to C++ - something with all fun drained from it :)

Re: Linus Torvalds on C++

#95

Post by acqq »

helmut_hed wrote: post #58
huhtenberg wrote: post #32

Earlier quoted context omitted.

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…

I don't see this. You can have a container of pointers in C++ just as you can in C. No special ownership semantics is assumed, nor do you have to decide which is the "owner" any more than you do in C. Or the problem is the same, at any rate. Plus you're not constantly casting to things. You can have a container of smart pointers, too, if you really don't want to think about ownership.

No, that's not the subject. The subject is, as chancho also mentions here (http://news.ycombinator.com/item?id=3641718), something that's explained in

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

Since you can write C in C++ of course everything can be written in C++ too if you don't use C++ "common" libraries and roll your own infrastructure. Once you care about "guts" of your program enough that you have to care about allocations, you'd see that as soon as you're thinking about "containers" having "pointers" to "objects" you're probably on the wrong way. Because "objects" often contain pointers that make part of more data structures but also can be of different size (you can't even "sizeof" them) and also you want to be the one who controls when and where each of them is actually stored (in a sense of the memory block).

I've done these things in C++ without boost, more "in a C way" inside of the separate modules (those that were critical) and I still wouldn't use boost monster, the amount of code dependency is much smaller that way.

Also see groby_b's: http://news.ycombinator.com/item?id=3641890

Re: Linus Torvalds on C++

#96

Post by acqq »

groby_b wrote: post #72
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…

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?

Re: Linus Torvalds on C++

#98

Post by yannickt »

aidenn0 wrote: post #60
jmccaffrey wrote: post #23

Earlier quoted context omitted.

C++ actually has some performance advantages over C, especially relating to static polymorphism (qsort v. std::sort)

Technically you can do tricks like that with the C preprocessor, though it is a bit ugly and lacks automatic instantiation.

It is also not type safe.

Re: Linus Torvalds on C++

#99

Post by beagle3 »

jgraettinger wrote: post #91
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…

My own experience is that RAII has been very useful in low-level work when used to capture cleanup/finalization. Results in fewer if-statements and SLOC. Issues of real-time performance and new vs malloc vs in-place/nothrow new also seem like orthogonal concerns here. The larger problem is that yahoo who's using the wrong algorithm and/or maintaining driver code w/o benefit of code review ;)

My (admittedly short) experience writing kernel drivers with C++ was that RAII could be great help, but there's no way you can rely on any library you did not write yourself (and one that you wrote with the express intent to use for low-level work at that).

C++ code just tends to assume it's fine to do whatever crazy stuff it assumes needs to be done, like allocating 4 bytes at a time using new. C code is usually more careful about that, and quite a few packages offer control of their memory allocation in C. (Yes, C++ does allow you to overload new and delete, and have allocator traits, and more. Come back when you've actually implemented this for a library you did not write, and we'll discuss war stories if I can remember them. It was 2001, it was ugly back then, and I'd be surprised if it is better looking now).

Re: Linus Torvalds on C++

#100

Post by acqq »

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.

And more than that, he's right: if you care enough about things the kernel cares about, you really, really don't want C++ "idioms" in kernel. And you don't want to work with the people who don't understand that. So it's really convenient to piss such people off, just as he said:

"for something where efficiency was a primary objective the "advantages" of C++ is just a huge mistake. The fact that we also piss off people who cannot see that is just a big additional advantage."

Post reply on HN