Archive
Find The Bug
The part of the conclusion in the green box below for 32 bit linux/GCC (g++) is wrong. A “long long” type is 64 bits wide for that platform combo. If you can read the small and blurry text in the dang thing, can you find the simple logical bug in the five line program that caused the erroneous declaration? And yes, it was the infallible BD00 who made this mess.
Hacrobatics
It’s funny how attitudes, preferences, and likes-dislikes change over time via personal experience and the acquisition of new knowledge. Having transitioned from a C background over to C++ quite awhile ago, I used to think pre-processor macros were a kool feature that came along for the ride. However, after having been burned multiple times by scope-ignoring macros, I learned to hate the damn little buggers. The scorchings made me fully appreciate the addition of “const“, templates, and inline functions to C++ in order to wean people off of “hacros“.
Maintaining a “hacro” laced program can drive anyone up a wall because:
I’m bummed, but not surprised, at how many people still think that “hacros” are a kool and useful feature of C++.
New Native Languages
The editor of Dr. Dobb’s Journal, Andrew Binstock, has put together a nice little slideshow summary of four “modern” native (native = no virtual machine running underneath the code) programming languages here: New Native Languages. As the figure below shows, these relatively new languages are D, Go, Vala, and Rust.
According to Andy, “older” native languages like C11 and C++11 “can have the feel of a past era onto which contemporary elements have been grafted“. I don’t agree with his “grafted” assertion, but I have to begrudgingly agree with him when he says:
The upshot is that to be truly expert in C++ requires far more education and far more effort than comparable mainstream OO languages (notably, Java and C#). – Andrew Binstock
Since I have much admiration for “D” creator Walter Bright and co-evolver Andrei Alexandrescu, I’ve been following the evolution of their language from afar. These two guys really know C++ inside and out; warts and all. Thus, unlike the 1995 Sun marketing proclamation that “Java is what C++ should have been“, Walter and Andrei are truly evolving D into “what C++ should be” – which is not just an OO language. Plus, they are being very gracious about it.
The IDEs Of March
I’m an Integrated Development Environment (IDE) man. I like the way IDEs (Eclipse, Visual Studio) provide an overarching dashboard overview and uniform control over the tool set needed to build software. Plus, I’m horrible at remembering commands; and as I get older, it gets worse.
How about you? Are you an IDE user or a command line person?
Relentless Assault
Microsoft’s Herb Sutter is a whirling dervish. Since the ISO approval of the C++11 standard last fall, he’s been on a crusade to promote C++ via several comparative assaults on Java and Microsoft’s own C#.
Herb’s latest blitzkrieg occurred at the lang.next 2012 conference (video link, slides link). In this slide, Herb summarizes some of the C++11 features that close the productivity and safety gap relative to C# and Java.
In this next slide, Herb contrasts C++11’s adherence to its more open “trust the programmer” philosophy against the more closed “we know what’s good for you” C#/Java philosophy.
Unless the large movement of business applications to the cloud is the latest fad du jour, the following two slides show that the largest software development and maintenance costs will shift from labor to compute efficiency. Thus, it doesn’t matter how programmer friendly your language is and how low the salaries you pay are, you might find that your costs are going up because of power drain in massive data centers and time spent frantically optimizing VM-based code that’s relatively slower and bigger.
In closing, Herb, the nice guy that he is, backs off a bit with this “the right tool for the right job” slide:
Is Herb stretching the truth and exaggerating the improvements offered up by C++11? The fact that I wrote this post obviously means that I don’t. What about you, dear reader? What say you?
The Old Is New Again
Because Moore’s law has seemingly run its course, vertical, single processor core speed scaling has given way to horizontal multicore scaling. The evidence of this shift is the fact that just about every mobile device and server and desktop and laptop is shipping with more than one processor core these days. Thus, the acquisition of concurrent and distributed design and programming skills is becoming more and more important as time tics forward. Can what Erlang’s Joe Armstrong coined as the “Concurrent Oriented Programming” style be usurping the well known and widely practiced object-oriented programming style as we speak?
Because of their focus on stateless, pure functions (as opposed to stateful objects), it seems to me that functional programming languages (e.g. Erlang, Haskell, Scala, F#) are a more natural fit to concurrent, distributed, software-intensive systems development than object-oriented languages like Java and C++; even though both these languages provide basic support for concurrent programming in the form of threads.
Likewise, even though I’m a big UML fan, I think that “old and obsolete” structured design modeling tools like Data and Control Flow Diagrams (DFD, CFD) may be better suited to the design of concurrent software. Even better, I think a mixture of the UML and DFD/CFD artifacts may be the best way (as Grady Booch says) to “visualize and reason” about necessarily big software designs prior to coding up and testing the beasts.
So, what do you think? Should the old become new again? Should the venerable DFD be resurrected and included in the UML portfolio of behavior diagrams?
Metadata Code Bloat
In many of his (terrific) talks and lectures, Herb Sutter often says that “always on garbage collection“, “default virtual dispatch“, and “metadata” are valid reasons as to why managed language programs written in C# and Java are typically slower and bigger than native languages like C++ and C. I understand the first two issues, but not the “metadata” argument. Thus, I asked Herb to “splain dis to me Lucy“.
Here’s my question and Herb’s gracious answer:
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++
The Lost Decade?
I think you’ll be hard pressed to find many knowledgeable C++ programmers who won’t admit that managed languages provide higher per-programmer productivity than native languages (because they’re easier to learn, have bigger libraries, and are not as “picky“). Likewise, I think you won’t find many “reasonable” managed language advocates who won’t admit that native language programs are more efficient (smaller and faster for a given solution) than their managed language counterparts. Having said that, take a look at this chart:
According to Herb Sutter, efficiency has(will) usurped(usurp) productivity as the dominating cost factor for software-intensive products in this decade (battery life in mobile devices, power consumption in the data center). Agree?
If you’re interested in watching the video and/or downloading Herb’s slides, here’s the link: “C++ and Beyond 2011: Herb Sutter – Why C++?“.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 