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?
Linus Torvalds on C++
41–50 of 190 posts
Re: Linus Torvalds on C++
#42The 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++
#43Re: Linus Torvalds on C++
#44sigh 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.
Today isn't Thursday is it?
Re: Linus Torvalds on C++
#45Re: Linus Torvalds on C++
#46In 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.
Re: Linus Torvalds on C++
#47Re: Linus Torvalds on C++
#48Now 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…
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++
#49Re: Linus Torvalds on C++
#50Earlier 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.
Please explain to me how this would fix anything? ;)