Archive
The “Void Star” Crowd
During the “Ask Us Anything” panel discussion at the “Going Native 2012” conference, one of the questions asked was: how do you get the “void *” guys to move forward toward a more type-safe and abstract C++ style of programming?“.
By “void *“, the questioner meant programmers who still cling to writing code like this:
instead of this:
The panelists admitted that it was a big challenge, and they gave the following suggestions:
- Ask them what problems they’re having and then show them the solution by doing it for them in C++ style. (Stroustrup)
- Set a personal example of increased productivity. (Alexandrescu)
- Show them compiler generated assembly output comparing the “void *” C-style code with a more expressive, less error-prone, more readable C++ equivalent. Odds are that the compiler-optimized C++ code will be much shorter than the hand-crafted C code. (STL)
Bjarne Stroustrup seemed especially frustrated at the pervasiveness of “void *” mindset. As a professor at Texas A&M, he said that as people come out of high school, most of them want to write games and they’ve convinced themselves and each other that, beyond a shadow of a doubt, “void *” is as fast as one can get. That’s exacerbated by the fact that many professors and “greybeards” still code in the type unsafe, barely readable, and error prone “void *” way.
I can sympathize with Bjarne and the panel. When I made the transition from C to C++, it took me what-seemed-like forever to “graduate” from arrays and naked pointers to containers and smart pointers and algorithms. Luckily, I did it in spite of myself. I can’t even remember the last time I used “void *” in any of the code I wrote.
Efficient Abstraction
In “The Design And Evolution Of C++“, Bjarne Stroustrup presents a tree-like picture on the history of programming languages and how they’ve influenced each other. For your studying pleasure, BD00 surgically extracted and augmented a slightly more C++ focused sub-tree. In other words, BD00 committed yet another act of plagiarism. I hope you like the result.
All through the 30+ years of C++’s evolution, Bjarne and the ISO C++ standards committee have maintained a fierce and agonizing determination to march to the tune of “efficient abstraction” over theoretical purity. Adding increasing support for abstraction without sacrificing much in efficiency is more of an art than science.
D&E is not just a history book. As the figure below shows, it won one of the “Software Development Productivity Awards” from Software Development magazine waaay back when. That’s because knowing “why” and “how” the (or any) language became the way it is gives a qualitative edge to those programmers over those who just know “what” the language is.
Cover of The Design and Evolution of C++
Sandwich Dilemma
In this dated, but still relevant paper, “Evolving a language in and for the real world“, Bjarne Stroustrup laments about one of the adoption problems that (still) faces C++:
Since the overarching theme of C++ is, and always has been, “efficient abstraction“, it’s not surprising that long time efficiency zealots and abstraction aficionados would be extremely skeptical of the value proposition served up by C++. I personally know this because I arrived at the C++ camp from the C world of “void *ptr” and bit twiddling. When I first started studying C++, its breadth of coverage, feature set, and sometimes funky syntax scared me into thinking that it wasn’t worth the investment of my time to “go there“.
I think it’s easier to get C programmers to make the transition to C++ than it is to get VM-based and interpreter-based programmers to make the transition. The education, more disciplined thinking style, and types of apps written (non-business, non-web) by “close to the metal” programmers maps into the C++ mindset more naturally.
What do you think? Is C++ the best of both worlds, or the worst of both worlds?
Broken Books
With the addition of features like auto, initializer lists, lambdas, and smart pointers, a lot of C++98 programming idioms and guidance have become obsolete now that C++11 is here. Thus, as Herb Sutter said at GoingNative 2012, a boatload of code examples in the best C++ books are now “broken“.
As a result, new and revamped versions of the books will take awhile to become available. Here’s Herb’s “estimated time of arrival” for several stalwart books:
In the meantime, you can feast your eyes on, and feed the left side of your brain with, these links:
- Bjarne Stroustrup’s C++11 FAQ page
- Wikipedia C++11
- Scott Meyers Overview Of C++11
- C++11 Features To GCC Compiler Map
- C++ Standards Committee Home Page
- GoingNative 2012
- C++11 Features in Visual C++ 11
- Clang Compiler C++11 Support
- Writing Modern C++ Code (Herb Sutter)
Do you know of any other good links to add to this post?
Vectors And Lists
In C++ programming, everybody knows that when an application requires lots of dynamic insertions into (and deletions from) an ordered sequence of elements, a linked list is much faster than a vector. Err, is it?
Behold the following performance graph that Bjarne Stroustrup presented during his keynote speech at “Going Native 2012“:
So, “WTF is up wit dat?”, you ask. Here’s what’s up wit dat:
The CPU load happens to be dominated by the time to traverse to the insertion/deletion point – and KNOT by the time to actually insert/delete the element. So, you still yell “WTF!“.
The answer to the seeming paradox is “compactness plus hardware cache“. If you’re not as stubborn and full of yourself as BD00, this answer “may” squelch the stale, flat-earth mindset that is still crying foul in your brain.
Since modern CPUs with big megabyte caches are faster at moving a contiguous block of memory than traversing a chain of links that reside outside of on-chip cache and in main memory, the results that Bjarne observed during his test should start to make sense, no?
To drive his point home, Mr. Stroustrup provided this vector-list example:
In addition to consuming more memory overhead, the likelihood that all the list’s memory “pieces” reside in on-chip cache is low compared to the contiguous memory required by the vector. Thus, each link jump requires access to slooow, off-chip, main memory.
The funny thing is that recently, and I mean really recently, I had to choose between a list and a vector in order to implement a time ordered list of up to 5000 objects. Out of curiosity, I wrote a quick and dirty little test program to help me decide which to use and I got the same result as Bjarne. Even with the result I measured, I still chose the list over the vector!
Of course, because of my entrenched belief that a list is better than a vector for insertion/deletion heavy situations, I rationalized my unassailable choice by assuming that I somehow screwed up the test program. And since I was pressed for time (so, what else is new?), I plowed ahead and coded up the list in my app. D’oh!
Update 4/21/13: Here’s a short video of Bjarne himself waxing eloquent on this unintuitive conclusion: “linked list avoidance“.
Ghastly Style
In Bjarne Stroustrup‘s keynote speech at “Going Native 2012“, he presented the standard C library qsort() function signature as an example of ghastly style that he’d wish programmers and (especially) educators would move away from:
Bjarne then presented an alternative style, which not only yields cleaner and less error prone code, but much faster performance to boot:
Bjarne blames educators, who want to stay rooted in the ancient dogma that “low level coding == optimal efficiency“, for sustaining the unnecessarily complex “void star” mindset that still pervades the C and C++ programming population.
Because they are taught the “void star” way of programming by teaching “experts“, and code of that ilk is ubiquitous throughout academia and the industry, newbie C and C++ programmers who don’t know any better strive to produce code of that “quality“. The innocent thinking behind the motivation is: “that’s the way most people write code, so it must be good and kool“.
I can relate to Mr. Stroustrup’s exasperation because it took perfect-me a long time to overcome the “void star” mental model of the world. It was so entrenched in my brain and oft practiced that I still unconsciously drift back into my old ways from time to time. It’s like being an alcoholic where constant self-vigilance and an empathic sponsor are required to keep the demons at bay. Bummer.
Admittance Of Imperfection
One of the traits I admire most about Bjarne Stroustrup is that he’s not afraid to look “imperfect” and point out C++’s weaknesses in certain application contexts. In his “Technical Report On C++ Performance“, Mr. Stroustrup helpfully cautions real time programmers to think about the risks of using the unpredictable/undeterministic features of the language:
Of course, C++ antagonists are quick to jump right on his back when Bjarne does admit to C++’s imperfections in specific contexts: “see, I told you C++ sux!“.
Here’s a challenge for programmers who read this inane blog. Can you please direct me to similar “warning” clauses written by other language designers? I’m sure there are many out there. I just haven’t stumbled across one yet.
Constrained Evolution
In general, I’m not a fan of committee “output“. However, I do appreciate the work of the C++ ISO committee. In “Evolving a language in and for the real world”, Bjarne Stroustrup articulates the constraints under which the C++ committee operates:
Bjarne goes on to describe how, if the committee operated with reckless disregard for the past, C++ would fade into obscurity (some would argue that it already has):
Personally, I like the fact that the evolution of C++ (slow as it is) is guided by a group of volunteers in a non-profit organization. Unlike for-profit Oracle, which controls Java through the veil of the “Java Community Process“, and for-profit Microsoft, which controls the .Net family of languages, I can be sure that the ISO C++ committee is working in the interest of the C++ user base. Language governance for the people, by the people. What a concept.
A Costly Mistake For Many
In “Learning Standard C++ as a New Language“, Bjarne Stroustrup gives a slightly different take on the waterfall method of software-intensive system development:
“… treating programming as merely the handmaiden of analysis and design doesn’t work either. The approach of postponing actual discussion of code until every high-level and engineering topic has been thoroughly presented has been a costly mistake for many. That approach drives people away from programming and leads many to seriously underestimate the intellectual challenge in the creation of production-quality code.“
If your company implicitly treats software engineers like “code monkeys” and great engineers strive to “rise” into coveted management positions ASAP because the unspoken ethos is that “coders” are interchangeable cogs, then your company most likely has made costly mistakes in the past and it will most likely do so again in the future.
The Emergence Of The STL
In the preface to the 2006 Japanese translation of “The Design and Evolution of C++“, Bjarne Stroustrup writes about how the C++ STL containers/iterators/algorithms approach to generic programming came into being. Of particular interest to me was how he struggled with the problem of “intrusive” containers:
The STL was a revolutionary departure from the way we had been thinking about containers and their use. From the earliest days of Simula, containers (such as lists) had been intrusive: An object could be put into a container if and only if its class had been (explicitly or implicitly) derived from a specific “Link” or “Object” class containing the link information needed by the compiler (to traverse the container). Basically, such a container is a container of references to Links. This implies that fundamental types, such as ints and doubles, can’t be put directly into containers and that the array type, which directly supports fundamental types, must be different from other containers. Furthermore, objects of really simple classes, such as complex and Point, can’t remain optimal in time and space if we want to put them into a container. It also implies that such containers are not statically type safe. For example, a Circle may be added to a list, but when it is extracted we know only that it is an Object and need to apply a cast (explicit type conversion) to regain the static type.
The figure below illustrates an “intrusive” container. Note that container users (like you and me) must conform to the container’s requirement that every application-specific, user-defined class (Element) inherits from an “overhead” Object class in order for the container to be able to traverse its contents.
As the figure below shows, the STL’s “iterator” concept unburdens the user’s application classes from having to carry around the extra overhead burden of a “universal“, “all-things-to-all people”, class.
The “separation of concerns” STL approach unburdens the user by requiring each library container writer to implement an Iterator class that knows how to move sequentially from user-defined object to object in accordance to how the container has internally linked the objects (tree, list, etc) and regardless of the object’s content. The Iterator itself contains the container-specific equivalent navigational information as the Object class in the “intrusive” container model. For contiguous memory type containers (array, vector), it may be implemented as a simple pointer to the type of objects stored in the container. For more complex containers (map, list) the Iterator may contain multiple pointers for fast, container-specific, traversal/lookup/insertion/removal.
I don’t know about you, but I think the STL’s implementation of containers and generic programming is uber cool. It is both general AND efficient – two desirable properties rarely found together in a programming language library:
…the performance of the STL is that it – like C++ itself – is based directly on the hardware model of memory and computation. The STL notion of a sequence is basically that of the hardware’s view of memory as a set of sequences of objects. The basic semantics of the STL maps directly into hardware instructions allowing algorithms to be implemented optimally. The compile-time resolution of templates and the perfect inlining they support is then key to the efficient mapping of high level expression of the STL to the hardware level.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 