Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

Making up falsehoods

Posted Mar 27, 2008 7:01 UTC (Thu) by ncm (subscriber, #165)
In reply to: an "old beard" ? by felixfix
Parent article: Striking gold in binutils

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.

(Log in to post comments)

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.