6 ms·
Linus basically says that C++ has "inefficient abstracted programming models". Looking at the STL, you only see some very basic abstractions: vectors, lists, ha
by marketer 19y ago
Linus basically says that C++ has "inefficient abstracted programming models". Looking at the STL, you only see some very basic abstractions: vectors, lists, hash tables, sets, and others. These are very well tested, and extremely optimized. Anyone writing a decent amount of code will undoubtedly run into a situation where they need such structures.
- jsjenkins168 19y agoAgreed. You would have to have to invest a considerable amount of time to beat the STL objects in terms of efficiency. I cant even think of a situation when you really could. Why try to reinvent the wheel? Seems like time wasted if you ask me.
- timr 19y agoThe arguments I hear most frequently are the same ones that Linus jumps on in this thread: the syntax is obtuse, the code isn't portable, and the language isn't truly high-level (i.e. it doesn't have built-in garbage collection). The first argument is (sadly) true -- C++ is ugly and complicated. A lot of that comes from the need for backwards compatibility with C (which isn't going to win any language beauty pageants, either), but a lot more of it comes as a consequence of the syntactic flexibility of the language. The second argument is mostly bunk. A decade ago, it was difficult to find a standards-compliant C++ compiler; today, it's fairly easy. Sure, there are dark corners of the language where certain compilers get funky, but that can be said of FORTRAN 77 compilers, too. In general, unless you're forced to work with a old compiler, or an old, unmaintained package, it isn't very difficult to write cross-platform C++ code. The third argument is just a straw man. Anyone who has read Stroustrup's book on the design of C++ knows why garbage collection and other "high-level" features weren't incorporated into the standard -- they didn't want to force users to adopt particular programming models or designs. Stroustrup has insisted that C++ be a flexible tool for many different types of programs and programmers; that attitude leads, somewhat inevitably, to complexity. But it makes me sad that so many people are bashing on C++ for not being "more like" other languages, when its biggest strength is probably its ability to mimic many features of those same languages, while still allowing for great efficiency.
- thomasptacek 19y agoYour third argument is fallacious. C++ is gradually incorporating everything you're talking about into the standard. Stroustrop has openly stated that lack of standardized threads were a mistake: you can't get much more environment-specific, model-specific than that.
- timr 19y agoStroustrup was referring to the standard library, and he wasn't advocating the inclusion of threads at all costs. C++ is still guided by the principle that you don't have to pay for what you don't use. That was the crux of my argument, and it continues to be true.
- thomasptacek 19y agoYou haven't refuted Linus. You've explained why the world works the way Linus says it does. But the impact is the same.
- Goladus 19y agoC is beautiful if you're standing on a motherboard staring up at it. If you think mostly in terms of how hardware works, C is a clean, powerful language. "The language isn't truly high-level" isn't the whole argument; which would indeed be a straw man. That's the main part that's tied to the "most C++ programmers suck" argument, though. He thinks the "pseudo high-levelness" of C++ encourages sloppy programming. Also there's another argument in there: Object-Orientation is overrated and often causes as many problems as it solves.
- timr 19y agoMost programmers suck in every language. If Linus' experience with C developers is that they are better than C++ developers, it's probably because he is familiar with the qualities of good C developers.
- 19y ago
- mojuba 19y agoto beat the STL objects in terms of efficiency string s = "string literal"; vector<int> v = {1, 2, 3}; // C++0x feature Any language with built-in string/array support will beat STL in initializing things, to start with. STL does dynamic allocation in these examples, in case you didn't know.
- aston 19y agoAre you sure about that? I don't really know the internals, but I would assume the implementation looks something like: Let the compiler put the array (of characters or numbers) somewhere where I can get them, and I'll take that pointer and keep it in my stack-allocated STL data structure. Any references that say you're right?
- mojuba 19y agoThe best reference is the source code. Let's look at the string. In C/C++ there is no reliable and portable way for your program to find out whether some (char*) points to a constant string literal or not. So the only oprion for a dynamic string implementation is to always copy any data the constructor receives to somewhere else, normally to the dynamic memory. As a result, any initialization involves dynamic allocation and copying of data in C++. At the same time languages that have built-in support for dynamic structures avoid this by creating proper structures in the constant segment. So a statement like string s = "abc" would do nothing but assign a pointer. This is a huge problem in C++ and even C++0x doesn't solve it unfortunately.
- thomasptacek 19y agoJustify that statement with evidence. Why would you assume hash_map would outperform a C hash table, or vector outperform a C VLA?
- jsjenkins168 19y agoThe times you are likely going to be able to beat STL is if you: 1) Have a highly specific algorithm where you know your memory characteristics very well, or 2) You are doing lots of memory allocation/deallocation. For example, something like vector<vector<myclass>> will be nasty in STL. Outside of that though it will be difficult. STL was designed with speed as the foremost objective. It is simply very hard to beat in MOST tasks (but not ALL). For example, Vectors dont do any bounds checking. Most STL vectors will have performance on par with a simple dynamically allocated array. Iterators are also not validated before accessing a container. So I wont say they cant be beat. They certainly can. But how much is your time worth? I guess it depends on your objectives and how critical every ounce of speed is. I understand there are probably situations with some where this type of thing is life or death.
- thomasptacek 19y agoI think you missed the word "evidence" in my request. I could have predicted that you believed STL was faster. But "it's faster because it's supposed to be faster" is a weak argument. Again I see people in this thread falling into the trap of conflating code reuse, a good thing, with C++, a dubious thing. Code reuse makes things faster, of course; it allows effort to be specialized. But C++ doesn't enable code reuse; it merely encourages it.
- jsjenkins168 19y agoHere are some benchmarks on sorting: http://theory.stanford.edu/~amitp/rants/c++-vs-c/ http://theory.stanford.edu/~amitp/rants/c++-vs-c/ Besides that, custom C vs. STL comparisons would need to be done case-by-case. Admittedly, an all-encompassing statement "STL is always faster than C" is unreasonable. It depends entirely on the situation and what you are trying to do. I'm simply saying that it is very difficult and probably more time consuming than it is worth (for MOST cases) to try to beat STL in C++. When I used to do lots of graphics programming I tried (mostly out of curiosity), but I always ended up just using STL. But maybe your experiences are different? Do you write your own arrays, hash maps, and sorting algorithms each time you use them? There are times when code reuse is A Good Thing. Like when the difference is negligible and it enables you to dedicate time to more valuable things, like building product features that users want. When it comes down to it, everything is always a matter of time. Please explain what you mean when you say "C++ doesnt enable code reuse, it merely encourages it". Just curious..
- thomasptacek 19y agoSurely you're not implying that vectors, hash tables, and sets are hard to write in C.
- jey 19y agoOK, then I want you to write me an efficient implementation of Red-Black tree deletion, and do it within an hour. (std::map and std::set are usually implemented with a Red-Black tree.)
- thomasptacek 19y agoWhat a silly argument. (a) STL's map and set weren't implemented in an hour. (b) Abstract data types (and, more generally, code libraries) predate C++ by decades. Six years ago, I took over as lead dev for a product now counting and statistically modeling a significant percentage of all the packets traveling across the backbones of virtually every tier 1 ISP in the world. One of the first things I did there, coming off 3 years of C++ development, was to backport the STLport Red-Black tree, from the "map" template to an "rbtree.c" library. My rbtree.c is faster than STLport's, and far easier to use. You don't need to read Meyers and keep a cheat sheet to avoid iterator invalidation to use it.
- portLAN 19y agolibavl. Next?
- thomasptacek 19y agoEww. Better to use C++ than AVL trees.
- portLAN 19y agohttp://www.stanford.edu/~blp/avl/ http://www.stanford.edu/~blp/avl/ * Binary search trees * AVL trees * Red-black trees
- 19y ago