|
an "old beard" ?an "old beard" ?Posted Mar 27, 2008 2:33 UTC (Thu) by felixfix (subscriber, #242)In reply to: an "old beard" ? by tialaramex Parent article: Striking gold in binutils
The problem many of us commenters have with sylware's comment is that it is ludicrous to expect a modern system to rely only upon C and avoid anything fancier. I commented on that above -- but I want to say a little more in response to this. I avoid C++ like the plague for my own purposes, for, I think, pretty much the same reasons -- it is far more complex for not much gain. It's been a long time since I did anything with C++, so maybe these comments will be rusty too, but two bad memories come back. One is malloc/free in C, as horrible as they are and easy to abuse, turning into three pairs of calls (new/delete and new array/delete array) -- mix them and have an instant mess -- not just in the two new ways, but in the additional traps of mixing them up. How can that be considered progress? The other bad memory was needing to specify virtual if you wanted to override methods -- what is the point of object oriented if overriding wasn't the default? The entire language struck me as more of a rushed standard to beat other OO versions of C, and then one pile of rushed patches to the spec after another. Nevertheless, some people get along better with C++ than others do with C. Forcing everyone to write in C will simply result in more bad matchups between personalities, projects, and tools. Old beards like UNIX because it is a system of tools which allow the users and developers to pick the right combination for them and the job. If forcing everybody to use C were the answer, it wouldn't be UNIX, it would merely be Microsoft "my way or the highway" but on the C highway instead of the C++ highway.
(Log in to post comments)
C++ features and performance Posted Mar 27, 2008 5:34 UTC (Thu) by zlynx (subscriber, #2285) [Link] Two of the problems you mention are caused because C++ is all about performance. Any language feature that will slow things down requires the programmer to explicitly use it. Array new is a separate function because it has to store the number of elements in the memory allocation. Making new and array new the same would waste a size_t for every alloc. Virtual has to be specified because it slows down the function calls. I have personal recent experience with virtual. I used virtual functions in an interface base class. After I got done profiling, I did explicit calls to class functions instead of virtuals in the derived classes and one use of dynamic_cast and then using the pointers with a template function. The code was over 20 times faster. The real killer wasn't the indirect jump, it was how virtuals block inlining and most compiler optimization, since it can't know what function will really be called.
Making up falsehoods Posted Mar 27, 2008 7:01 UTC (Thu) by ncm (subscriber, #165) [Link] What the commenters above are expressing is simply fear of learning. (Read a modern C++ program, and you won't find any calls to "new" or "delete", array or otherwise. "Virtual" isn't the default because it's only rarely the right thing. It's been years since I typed the keyword "virtual" in my own C++ code.) If you don't chafe at the lack of expressiveness in C, Java, or C#, it can only be because you're not trying to express much of anything. Ian chose C++ not just because he "prefers" it (whatever that means). He chose it because it's demonstrably better at expressing complex solutions to complex problems. For an easy problem, any old language will do. Most problems are easy, and most programmers spend their lives solving one easy problem after another. They can use whatever toy language they first encountered, and never learn another thing. People drawn to hard problems want the sharpest tool they can get. Right now C++98 is that tool. (C++09 will be a sharper tool.) Nothing else even comes close, and nothing on the horizon looks like it will. That's too bad, because a language equally powerful but a tenth as complex ought to be possible, but none seems to be forthcoming yet.
Making up falsehoods Posted Mar 28, 2008 2:34 UTC (Fri) by wahern (subscriber, #37304) [Link] You don't chafe at the lack of lexical scoping? Nested methods? You don't pine for proper tail recursion? People complain that C++ doesn't have threads built in, and the standard retort is invariably that the next standard will provide built in mutexes and other sugar. But that's not expressive. If you want expressive concurrency, checkout Limbo's channels or Erlang's messages. Just because you can approximate something doesn't mean you've captured its expressiveness. And how is a language where the majority of the operators and modifiers are English keywords, wrapped in an endless series of punctuation marks, expressive? Reading overly wrought C++ code can be like reading a court reporter's short-hand, except you can never be sure what the proper translation is from one compilation unit to the next--certainly not from one project to the next. And if you keep it clean, you're not exercising all those expressive features. Combine GCC extensions like the typeof() operator and statement expressions, and/or some M4 pre-processing, and you end up with code only nominally less readable than template definitions, yet just as type-safe. The first step to solving a complex problem is to first reduce it to a set of simple problems. You then choose tools which best solve the simple problems. (Of course, most problems are really simple, so its sensible to use any one general purpose language.) I see these gargantuan C++ projects, and I think to myself C++ is more of a plague than anything else. Some people tout KIO as the greatest thing since sliced bread; but I'm sitting on the sidelines, thinking I wish my non-KDE applications could benefit from that. Some "solution", that feat of super-charged object-orientation, walled up behind a language that says "my way or the highway". That kind of expressiveness is light years behind fopen()--usable in C, C++, Perl, Awk, Java, C#, Lua, TCL, Python, Haskell, Ada, and nearly any other language one could find on their system. People claim that C++ is "multi-paradigmatic". Oddly, it fails to provide the most useful and expressive alternative paradigms out there. And with all the nice shiny features, even all the tried-and-true paradigms--like process modularization--are too often left out in the cold. If you've got the world's greatest set of hammers, everything looks like a nail. If you like C++, great. It is... a language. Just like any other, except a little more practical than most, and much more widely used (due in large part to near universality in the Microsoft community). I don't use C++, because I routinely use more than a half-dozen other languages--and the one that binds them all: C.
Making up falsehoods Posted Mar 29, 2008 7:56 UTC (Sat) by ncm (subscriber, #165) [Link] It's no crime not to like any particular language. (Lord knows I loathe my share of them.) When you have to invent one falsehood after another to justify your dislike, though, it makes you look silly, or dishonest. I know of plenty to dislike in C++; they tend to be inconveniences in features entirely lacking in other languages. But, for the record... Lexical scoping, we have. Tail recursion? Pass; over twenty-five years using C and C++, every time I have been tempted to leave a tail recursion in my code, changing it to explicit looping has turned out to make the code clearer and more maintainable. (Certainly there are languages that do or would benefit from it, but C and C++ seem not to need it.) Nested "methods"? Coming, more or less, in C++09. Also coming are mutexes and atomics, but more important is that they can be built into whatever higher-level apparatus you prefer. The great lesson of C was that anything you can build into a library, you are better off without in the core language. (For C, particularly, that was I/O. People miss how revolutionary that was thought, then.) C++09 adds enormous power for library writers, to enable easier-to-use libraries, which will in turn make the language markedly more competitive against scripting languages.
Making up falsehoods Posted Apr 3, 2008 18:05 UTC (Thu) by jchrist (guest, #14782) [Link] I'm genuinely curious. If "modern C++" programs don't use new/delete or virtual, how do you dynamically allocate/deallocate memory? What do you use instead of virtual functions?
C++ new and delete Posted Apr 7, 2008 0:49 UTC (Mon) by pr1268 (subscriber, #24648) [Link] how do you dynamically allocate/deallocate memory? A big push for "modern" C++ programming is to use the standard library's container classes, e.g., vector, list, deque, etc. instead of arrays created with new and delete. The primary rationale for using dynamically-allocated memory in the first place is to defer until execution time reserving only as much space as is needed (since memory is a scarce resource). The C++ containers have a rich set of methods which allow array-like operation while managing the dynamic allocation (and subsequent releasing) of resources at the library level (instead of making the programmer do it him/herself with new and delete). I can't speak for why virtual methods are seldom described in literature, but my intuitive perception is that they're this philosophical concept in computer science (object-oriented programming in particular) whose existence programmers are expected to know but avoid using unless no other practical solution exists--kind of like recursion.
I see I have to be more explicit Posted Mar 29, 2008 7:21 UTC (Sat) by felixfix (subscriber, #242) [Link] You all seem to be concentrating on the limbs of the trees I mentioned, ignoring the entire forest. I know perfectly well why C++ has all those warts, speed. But languages progress by more than merely adding hundreds of new steam gauges (to use a quaint hardware engineers' term) to an engine to allow ever finer control of it. Anyone who is familiar with radial engines, those wonderful noisy big round engines on WW II planes, will understand my comparison of C as the R2800 and C++ as the Wright 3350 (hope I got that "right") which was the complex culmination of radial engine technology. What was needed was not such a finicky beast but a new way of thinking, the jet engine, especially augmented with a glass cockpit which only shows you those instrument readings you need to know, such as only engine temps which are out of spec. C++ is horrible because it added complexity without benefit. It has all the hallmarks of kluge piled on top of kluge, patched and held together by duct tape. 3 times as many malloc call pairs and the additional trap of mixing them up? I doubt C++ gained triple the benefit, and to say that the compiler, even while knowing the types, could not choose the right calls based on type, beggars the imagination. I would be embarrassed to rely on such a sorry excuse for an excuse. If virtual should only be used when absolutely necessary, then it was designed wrongly. That is what I was complaining about, not the rationale for each additional complication. All these complicated additional features screamed loud and clear that the basic design was flawed beyond redemption; it's too bad no one was brave enough to say the emperor's clothes were darned to nothingness. That is why C++ disgusts me and I avoid it like the plague.
I see I have to be more explicit Posted Mar 31, 2008 2:51 UTC (Mon) by ncm (subscriber, #165) [Link] Ignorance is a poor basis for criticism. If you don't understand the purpose for any given feature, you will be ill-equipped to evaluate the benefits available from using it. By all means avoid C++ if you like. Most programmers are not intelligent enough to use the language effectively, and should stick to solving easy problems with trivial languages, and leave the hard work to professionals.
|
Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds
Powered by Rackspace Managed Hosting.