Linus Torvalds on C++ • Hacker News Board

Re: Linus Torvalds on C++

#151

Post by acqq » Tue, Feb 28, 2012, 1:17 PM UTC

cageface wrote: post #136

acqq wrote: post #127

Earlier quoted context omitted.

Dates are irrelevant if you really want to control where something gets allocated. Last time I've checked there weren't the level of control described in the linked articles in "standard" C++. If you know how I can achieve it, please write, but please don't dismiss my need with "you wouldn't notice everything is fast enough it's 2012."

Can you name any language that does give you that level of control in its standard collection classes? At least C++ gives you the power to define your own if you really need to.

"C++ gives you the power" exactly because there's full C underneath -- once you avoid "standard" containers, "OOP," "STL," "boost" and "best C++ practices" you can still malloc and place structs where you want. Sometimes you really need that level of control, and you get it from C. AFAIK, Google's Go simply just says "we don't give you that level of control." That's why C won't be fully replaced with Go. And that's also what "omg I need C++" people don't understand. I don't blame them for not knowing, they didn't have to work on such problems.

But I blame them when they insist that what they do is enough for everybody. It isn't.

Re: Linus Torvalds on C++

#152

Post by GiganteX » Tue, Feb 28, 2012, 1:31 PM UTC

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…

Linus is full of BS. To say that STL and Boost is total crap, that he likes to piss off C++ coders, and that he actually seems unable to see the advantages of C++ to C.. only shows his own ignorance, and that he has a huge chip on his shoulder. I'm very disappointed.

Re: Linus Torvalds on C++

#153

Post by GiganteX » Tue, Feb 28, 2012, 1:35 PM UTC

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…

Everything that C is, C++ is as well. The single simple feature that I don't have to declare all my variables in the beginning of the method but where it's actually used is enough to kick the ass of C to the curb. Then there's the rest of the features including the little thing known as OO...

To object against C++ with the argument that incompetent coders can do bad things... well, it's nonsense. Incompetent coders can do bad things in ANY language. For competentt coders thugh, C++ means increased productivity and resusability, and in the end, that's what counts.

Re: Linus Torvalds on C++

#154

Post by jpatte » Tue, Feb 28, 2012, 1:54 PM UTC

slowpoke wrote: post #143

Valdemar wrote: post #128

Earlier quoted context omitted.

> Portability concerns are huge for git. Oh, is that why Git has such great support for Windows?... ...

"Portability" doesn't necessarily mean "runs on every system ever made". As pointed out by your parent, it runs on pretty much all UNIX flavors , even the ancient and obscure ones. If you want to blame anything for the abysmal git functionality on Windows, it should be Windows, not git.

IMHO, "being portable" is more about "being available to many users" than "being available to many systems". Focusing on ancient and obscure systems (used by who, exactly?) while ignoring systems used by a large potential users population doesn't make a lot of sense to me. And I don't see how you can blame that on these major systems either.

Willing to specifically support archaic but important systems who desperately needs git (idk, NASA supercomputers perhaps?) is fine, but that's kind of a niche strategy; it's not about portability anymore.

Re: Linus Torvalds on C++

#155

Post by icebraining » Tue, Feb 28, 2012, 1:56 PM UTC

GiganteX wrote: post #153

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…

Everything that C is, C++ is as well. The single simple feature that I don't have to declare all my variables in the beginning of the method but where it's actually used is enough to kick the ass of C to the curb. Then there's the rest of the features including the little thing known as OO... To object against C++ with the argument that incompetent coders can do bad things... well, it's nonsense. Incompetent coders c…

The single simple feature that I don't have to declare all my variables in the beginning of the method but where it's actually used is enough to kick the ass of C to the curb.

You're about twelve years outdated: https://en.wikipedia.org/wiki/C99

Re: Linus Torvalds on C++

#156

Post by lallysingh » Tue, Feb 28, 2012, 1:59 PM UTC

cageface wrote: post #120

acqq wrote: post #96

Earlier quoted context omitted.

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.

In standard-land, not so long ago. The process is slow.

As for the Lakos allocator model, two issues come up:

(1) You get an allocator pointer in everything.

(2) Each allocator still doesn't get to be simple: if the container passes the allocator down to its elements, the allocator has to worry about very differently-sized allocations. E.g. rb-tree nodes and the contained types.

Re: Linus Torvalds on C++

#157

Post by lallysingh » Tue, Feb 28, 2012, 2:01 PM UTC

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…

Honestly one of my favorite things about C are that the symbols resolve uniquely. Efficient C++ code often involves templates, and good luck trying to get a tag-lookup tool that can resolve template specialization rules...

Re: Linus Torvalds on C++

#158

Post by Anirak » Tue, Feb 28, 2012, 2:13 PM UTC

Linux torvalds sounds like an asshole.

Re: Linus Torvalds on C++

#159

Post by pdmccormick » Tue, Feb 28, 2012, 2:24 PM UTC

WalterBright wrote: post #110

C'mon, guys, that posting was 4.5 years ago. It's old news, and has been repeatedly hashed to death.

The good thing about hashing something repeatedly is that the result is always the same!

Re: Linus Torvalds on C++

#160

Post by tommorris » Tue, Feb 28, 2012, 2:32 PM UTC

jpatte wrote: post #154

slowpoke wrote: post #143

Earlier quoted context omitted.

"Portability" doesn't necessarily mean "runs on every system ever made". As pointed out by your parent, it runs on pretty much all UNIX flavors , even the ancient and obscure ones. If you want to blame anything for the abysmal git functionality on Windows, it should be Windows, not git.

IMHO, "being portable" is more about "being available to many users" than "being available to many systems". Focusing on ancient and obscure systems (used by who, exactly?) while ignoring systems used by a large potential users population doesn't make a lot of sense to me. And I don't see how you can blame that on these major systems either. Willing to specifically support archaic but important systems who desperatel…

Git was built specifically to scratch the itch of Linux kernel developers.

Linux kernel developers tend to like making sure the Linux kernel works on as many obscure architectures as possible. See https://en.wikipedia.org/wiki/List_of_Linux_supported_archit...

Making sure Git is portable across system architectures is quite important.

Also, portability in the "being available to many systems" thing is important for a lot of developers. I build stuff that currently has to deploy on SPARC/Solaris, but there are plans to make it so that in the not-so-distant future, all that stuff will be moving to virtualized clusters of x86_64 Linux. Portability in the narrow UNIX sense is pretty damn important to a lot of people.