Archive
The Renaissance That Wasn’t
In the thoughtful and well-written article, “The Rise and Fall of Languages in 2012”, Andrew Binstock rightly noted that the C++ renaissance predicted by C++ ISO committee chairman Herb Sutter did not materialize last year. Even though C++ butters my bread and I’m a huge Sutter fan, I have to agree with Mr. Binstock’s assessment:
In fact, I can find no evidence that C++ is breaking into new niches at a pace that will affect the language’s overall numbers. For that to happen, it would need to emerge as a primary language in one of today’s busiest sectors: mobile, or the cloud, or big data. Time will tell, but I feel comfortable projecting that C++ will continue to grow in its traditional niches and will advance at the same rate as those niches grow.
Nevertheless, if you buy into Herb’s prognostication that power consumption and computing efficiency (performance per watt) will overtake programmer productivity as the largest business cost drag in the future, then the C++ renaissance may still be forthcoming. Getting 2X the battery life out of a mobile gadget or a .5X reduction in the cost to run a data center may be the economic ticket that triggers a deeper C++ penetration into what Andrew says are today’s busiest sectors: mobile, the cloud, and big data. However, if the C++ renaissance does occur, it won’t take hold overnight, let alone over the one year that has passed since the C++11 standard was hatched.
It’s tough to make predictions, especially about the future – Yogi Berra
My C++11 “Move” Notes
Being a slow learner, BD00 finds it easier to learn a new topic by researching the writings from multiple sources of authority. BD00 then integrates his findings into his bug-riddled brain as “the truth as he sees it” (not the absolute truth – which is unknowable). The different viewpoints offered up by several experts on a subject tend to fill in holes of understanding that would otherwise go unaddressed. Thus, since BD00 wanted to learn more about how C++11’s new “move” and “rvalue reference” features work, he gathered several snippets on the subject and hoisted them here.
Why Move?
The motivation for adding “rvalue” references and “move” semantics to C++11 to complement its native “copy” semantics was to dramatically improve performance when large amounts of heap-based data need to be transferred from one class object to another AND it is known that preserving the “from” class object’s data is unnecessary (e.g. returning a non-static local object from a function). Rather than laboriously copying each of a million objects from one object to another, one can now simply “move” them.
Unlike its state after a “copy“, a moved-from object’s data is no longer present for further use downstream in the program. It’s like when I give you my phone. I don’t make a copy of it and hand it over to you. After I “move” it to you, I’m sh*t outta luck if I want to call my shrink – until I get a new phone.
Chapter 13 – C++ Primary, Fifth Edition, Lippman, Lajoie, Moo
Chapter 3 – The C++ Programming Language, 4th Edition, Bjarne Stroustrup
Chapter 3 – The C++ Standard Library, 2nd Edition, Nicolai M. Josuttis
Overview Of The New C++ (C++11), Scott Meyers
Hyped And Valueless
In “Major Software Development Trends for 2013”, the editors of InfoQ asked its readers to rank several software development trends in terms of their “adoption readiness” and the “value proposition” they offer. As you can see below, the 623 voters (so far) think that “the resurgence of C++” is the least valuable and least adoptable among the 16 listed trends.
My take, and I fully admit to being totally biased for C++11, is that the vast majority of voters are web, mobile, or IT business application developers. They don’t develop real-time and/or safety-critical systems where C and C++ excel. Hell, just looking at the list of trends, you can tell that they are all geared toward web/mobile/IT applications. But that makes sense because the market for those types of apps dwarfs all others and that’s what’s driving the relentless innovation that keeps the software industry fresh, new, and brutally exciting.
Milliseconds Since The Epoch 2
Over a year ago, I hoisted some C++ code on the “Milliseconds Since The Epoch” post for those who were looking for a way to generate timestamps for message tagging and/or event logging and/or code performance measurements. That code was based on the Boost.Date_Time library. However, with the addition of the <chrono> library to C++11, the code to generate millisecond (or microsecond or nanosecond) precision timestamps is not only simpler, it’s now standard:
Here’s how it works:
- steady_clock::now() returns a timepoint object relative to the epoch of the steady_clock (which may or may not be the same as the Unix epoch of 1/1/1970).
- steady_clock::timepoint::time_since_epoch() returns a steady_clock::duration object that contains the number of tick-counts that have elapsed between the epoch and the occurrence of the “now” timepoint.
- The duration_cast<T> function template converts the steady_clock::duration tick-counts from whatever internal time units they represent (e.g. seconds, microseconds, nanoseconds, etc) into time units of milliseconds. The millisecond count is then retrieved and returned to the caller via the duration::count() function.
I concocted this code from the excellent tutorial on clocks/timepoints/durations in Nicolai Josuttis’s “The Standard C++ Library (2nd Edition)“. Specifically, “5.7. Clocks and Timers“.
The C++11 standard library provides three clocks:
- system_clock
- high_resolution_clock
- steady_clock
I used the steady_clock in the code because it’s the only clock that’s guaranteed to never be “adjusted” by some external system action (user change, NTP update). Thus, the timepoints obtained from it via the now() member function never decrease as real-time marches forward.
Note: If you need microsecond resolution timestamps, here’s the equivalent code:
So, what about “rollover“, you ask. As the highlight below from Nicolai’s book shows, the number of bits required by C++11 library implementers increases with increased resolution. Assuming each clock ticks along relative to the Unix epoch time, rollover won’t occur for a very, very, very, very long time; no matter which resolution you use.
Of course, the “real” resolution you actually get depends on the underlying hardware of your platform. Nicolai provides source code to discover what these real, platform-specific resolutions and epochs are for each of the three C++11 clock types. Buy the book if you want to build and run that code on your hardware.
C++ Predictability
Did you know that…
I clipped this snippet from the slides that accompanied this interview: “David Intersimone of Embarcadero interviews Bjarne Stroustrup to to kick off their CodeRage 7 conference.”
Uniform Initialization Failure?
On our latest distributed system project, we’ve decided to use some of the C++11 features provided by GCC 4.7. Right off the bat, I happily started using the “uniform initialization” feature, the auto keyword, range-for loops, and in-class member initializers.
While incorporating uniform initialization all over my crappy code, I either stumbled into a compiler bug or a flaw in my understanding of the feature. I don’t know which is the case, and that’s why I’m gonna ask for your help figuring it out in this “normal” blog post.
Behold the code that the compiler explodes on:
But Mr. Compiler, I’m trying to initialize a non-const reference (std::mutex& mtx_) lvalue with an rvalue of the exact same same type, another non-const reference (std::mutex& m). WTF?
Next, observe the change I had to make to satisfy the almighty compiler:
I’m bummed that I had to destroy the “elegance” (LOL!) of the product code by replacing the C++11 brace pair with the old style parenthesis pair of C++03.
Since little things like this tend to consume me, I explored the annoyance further by writing some little side test programs. I found that the compiler seems to barf every time I try to initialize any reference type via a brace pair – so the problem is not std::mutex specific.
So, I’m asking for your help. Is it a compiler bug, or a misunderstanding on my part?
Update A (12/1/12)
I’ve come to the conclusion that the issue is indeed a compiler bug. While searching for the cause, I found the following paper and set of initializer list examples on Bjarne Stroustrup‘s web site:
According to the man himself, my exploding code should compile cleanly, no?
Update B (12/1/12)
After further research, I’ve flip-flopped. Now I don’t think it’s a problem with the compiler. It’s simply that the std::mutex class is not designed to support an initializer list (of one)? In order to support uniform initialization, I think a class must be explicitly designed to provide it via some sort of constructor syntax that I haven’t learned yet. Thus, unless all the classes used in a program explicitly provide initializer list support, the program must use “mixed initialization” in order to compile. If this is true, then bummer. Uniform initialization doesn’t come “for free” with C++11 – which is what I erroneously thought.
Update C 12/5/12
After yet more research and coding on this annoying issue, I discovered that whether or not brace style initialization works for references is indeed type specific. As the example below shows, brace style initialization compiles fine for a reference to a plain old int.
In the process of experimenting, I also discovered what I think is a g++ 4.7.2 compiler bug:
Note that in this case, I’m trying to brace-init a member of type Base, not a reference to Base. There’s something screwy going on with brace initialization that I don’t understand. Got any advice/insight to share?
A Glimpse Into C++11PL4
At Microsoft’s Build 2012 conference, ISO C++ chairman Herb Sutter introduced the new isocpp.org web site. On the site, you can download a draft version of Chapter 2 from Bjarne Stroustrup‘s upcoming “The C++ Programming Language, 4th Edition“. As I read the chapter and took “the tour“, I noted the new C++11 features that Bjarne used in his graceful narrative. Here they are:
auto, intializer lists, range-for loops, constexpr, enum class, nullptr, static_assert.
Since I’m a big Stroustrup and C++ fan, I just wanted to pass along this tidbit of info to the C++ programmers that happen to stumble upon this blog.
Patience Grasshoppa, Patience
It won’t arrive for awhile, but it’s on its way: the C++11 rendition of Bjarne Stroustrup‘s “The C++ Programming Language“.
In case you didn’t already know, the C++11 editions of these tomes are already available for your consumption:
But of course, you did already did know this. There are gifted copies of each of these references on your and your colleague’s desks because your company cares about you, your productivity growth, and continuously enhancing the quality of its revenue-generating product portfolio. That’s why it obsesses over little, but simultaneously huge, things like this for you, its products, and its future well being. It’s a quiet, low-key, low-cost, win-win-win situation that makes you feel warm and fuzzy each day you walk in the door to joyfully add your contribution to the whole.
And puh-leeze, no comments from the hip and cool Ruby, Python, Java, Go, Scala, C#, etc, peanut galleries. On this bogus blawg, only pope BD00 is approved to promote or trash other programming languages, ideas, groups, concepts, institutions, traditions. Well, you get the idea.
Note: I created the above image at says-it.com. It’s a wonderful site, so hop on over there and give it a whirl.
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.
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?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 