|
|
|
Sponsored Link •
|
Summary
C++ is too complex? Or just super-powerful? Or a confusing mix of both truths, not amenable to being tied down and categorised? There's an elephant wandering round the living room, and it's time someone offered it a chair. (Or a bun.)
|
Advertisement
|
In the mid-1990s I had the jaw-sagging gall, not to mention incredible naivety, to think that I knew almost all of C++. I can actually remember a conversation with a similarly humility-challenged friend where we estimated that we probably knew 98% of C++. A couple of weeks later I read an article about the new mutable keyword, and it's been downhill ever since.
In recent years C++ has gone "Modern", which means to say very powerful but also, alas, very esoteric and undiscoverable. If you've written a non-trivial template library involving any kind of meta-programming, then you've likely learned a lot, and got yourself a very powerful tool. However, it's equally likely that you've created something impenetrable to all but the most ardent and cunning code explorers.
What's to be done about this situation? This is the basis of my current interest in C++. I do not have the right answer, and I'm not convinced I'm going to find it, but I do know lots of wrong ones. The fruits of this search - assuming there'll be some - are the parts of my next book, Extended STL, that are as yet unwritten. Unfortunately, or maybe fortunately, I suspect they'll also be the most important (non-technical) parts.
Use policies for everything? The computer says eh-erh! Portability: compromised. Efficiency: compromised. Discoverability: plummets with each template parameter.
Rely on standards This is the approach of the STL, and it works very well. Unfortunately it's quite fragile and limiting. Containers, iterators and algorithms: Great! Adaptors and function objects: not so great! There are a host of alternative approaches, such as Eric Niebler's FOR_EACH, mine and John Torjo's Ranges (which can handle collection types beyond the limitations of the STL), Lamba, etc. But all of these have problems of their own, the most significant of which I'd suggest is that they're complex and impenetrable.
Get the compiler to deduce the lot This involves using TMP to detect, deduce, decode and diagnose all your problems. Alas, there's no better way to expose compiler inconsistencies and limitations. Nor of losing your potential user base: discoverability hits -ve values.
Live with the current limitations In some ways, this is the best approach. Perhaps we, as C++ programmers, spend too much time looking for neat new ways of programming instead of doing neat new programming of new things? Maybe it's because I'm a library writer, but sometimes it feels like I'm just spending my time discovering new gaits to running at a standstill. Perhaps the anachronistic, gauche, peurile, boring, constrained kind of programming that one must need perform in Java and .NET is better in the long run, because one stops worrying about smart new ways of extending the language, and just gets on with programming the task at hand?
It looks pretty negative. So why do I spend most of each working day doing and enjoying C++ design and development? It's powerful, it's efficient, it can be wonderfully expressive, and it's fun. But it can be just so hard. Does it have to be that hard? I look forward to hearing your thoughts. (And if they're useful, they could end up in Extended STL and you could end up having a gruff Yorkshireman in your debt.Have an opinion? Readers have already posted 38 comments about this weblog entry. Why not add yours?
If you'd like to be notified whenever Matthew Wilson adds a new entry to his weblog, subscribe to his RSS feed.
 | Matthew Wilson is a software development consultant and creator of the FastFormat, Pantheios and STLSoft libraries. He is author of the books Imperfect C++ (Addison-Wesley, October 2004) and Extended STL, volume 1 (Addison-Wesley, 2007), and is currently working on his third, Breaking Up The Monolith: Advanced C++ Design Without Compromise. He has published over 60 articles on C++ and other topics, and has served as columnist and contributing editor for C/C++ Users Journal. Matthew believes that code should be discoverable and largely self-documenting, and lives up to that by being a hopeless documentor. He can be contacted via http://www.imperfectcplusplus.com/ or stlsoft@gmail.com. |
|
Sponsored Links
|
Digg
del.icio.us
Reddit