Archive

Posts Tagged ‘Andrei Alexandrescu’

Performance Per Watt

Recently, I concocted a blog post on Herb Sutter‘s assertion that native languages are making a comeback due to power costs usurping programming labor costs as the dominant financial drain in software development. It seems that the writer of this InforWorld post seems to agree:

But now that Intel has decided to focus on performance per watt, as opposed to pure computational performance, it’s a very different ball game. – Bill Snyder

Since hardware developers like Intel have shifted their development focus towards performance per watt, do you think software development orgs will follow by shifting from managed languages (where the minimization of labor costs is king) to native languages (where the minimization of CPU and memory usage is king)?

Hell, I heard Facebook chief research scientist Andrei Alexandrescu (admittedly a native language advocate (C++ and D)) mention the never-used-before “users per watt” metric in a recent interview. So, maybe some companies are already onboard with this “paradigm shift“?

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

Just As Fast, But Easier To Write

September 26, 2011 2 comments

I love watching Herb Sutter videos on C++. His passion and enthusiasm for the language is infectious. Like Scott Meyers, Herb always explains the “why” and “how” of a language feature in addition to the academically dry “what” .

In this talk, “Writing modern C++ code: how C++ has evolved over the years“,  Herb exhibits several side by side code snippets that clearly show much easier it is to write code in C++11 (relative to C++98) without sacrificing efficiency.

Here’s an example (which I hope isn’t too blurry) in which the C++11 code is shorter and obsoletes the need for writing an infamous”new/delete” pair.

Note how Herb uses the new auto, std::make_shared, std::shared_ptr, and anonymous lambda function features of C++11 to shorten the code and minimize the chance of making mistakes. In addition, Herb’s benchmarking tests showed that the C++11 code is actually faster than the C++98 equivalent. I don’t know about you, but I think this is pretty w00t!

I love paradoxes because they twist the logical mind into submission to the cosmos. Thus, I’m gonna leave you with this applicable quote (snipped from Herb’s presentation) by C++ expert and D language co-creator Andrei Alexandrescu:

Note: As a side bonus of watching the video, I found out that the Microsoft Parallel Patterns Library is now available for Linux (via Intel).

Improper Inheritance

January 5, 2011 Leave a comment

Much like Improper Inheritance (II) can wreck family relationships, rampant II can also destroy a project after large and precious investments in time, money, and people have been committed. Before you know it, BAM! All of a sudden, you’ve noticed that you’re in BBoM city; not knowing how you got there and not knowing how to get the hell out of the indecipherable megalopolis.

Here’s what the “C++ FAQ” writers have to say on the II matter:

Here’s what Stephen Dewhurst says in “C++ Gotchas” number 92:

Use of public inheritance primarily for the purpose of reusing base class implementations in derived classes often results in unnatural, unmaintainable, and, ultimately, more inefficient designs.

Herb Sutter and Andrei Alexandrescu‘s chapter number 34 in “C++ Coding Standards: 101 Rules, Guidelines, and Best Practices” is titled “Prefer composition to inheritance“. Here’s a snippet from them:

Avoid inheritance taxes: Inheritance is the second-tightest coupling relationship in C++, second only to friendship. Inheritance is often overused, even by experienced developers. A sound rule of software engineering is to minimize coupling: If a relationship can be expressed in more than one way, use the weakest relationship that’s practical.

On page 19 in Design Patterns, the GoF state:

“Favoring object composition over class inheritance helps you keep each class encapsulated and focused on one task. Your classes and class hierarchies will remain small and will be less likely to grow into unmanageable monsters.”

Let’s explore this malarial scourge a little closer with a couple of dorky bulldozer00 design and code examples.

The UML class diagram pair below shows two ways of designing a message. It’s obvious that a message is composed of a header and payload (and maybe a trailer), no? Thus, you would think that the “has a” model on the left is a better mapping of a message structure in the (so-called) real world into the OO world than the multi “Is a” model on the right.

I don’t know about you, but I’ve seen many mini and maxi designs like this implemented in code during my long and undistinguished career. I’ve prolly unconsciously, or consciously but guiltily, hatched a few mini messes like this too.

For our second, more concrete example, let’s look at the mixed design and code example below. Since the classes and member functions are so generic, it’s hard to decide which one is “better”, no?

By looking at the test driver below, hopefully the “prefer composition to inheritance” heuristic should become apparent. The inheritance approach breaks encapsulation and exposes a “fatter” interface to client code, which in this case is the main() function. Fatter interfaces are more likely to be unknowingly abused by your code “users” than thinner interfaces – especially when specific call sequencing is required. With the composition approach, you can control how much wider the external interface is – by delegation. In this example, our designer has elected to expose only one of the two additional interface functions provided by the Base class – the ifaceFunc1() function.

Like all heuristics in programming and other technical fields of endeavor, there are always exceptions to the “prefer composition to inheritance” rule. This explains why you’ll see the word “prefer” in virtually all descriptions of heuristics. Even if you don’t see it, try to “think” it. An equivalent heuristic, “prefer acceptance to militancy“, perhaps should also hold true in the world of personal opinions, no?

Loki Is Not Loco

December 27, 2010 Leave a comment

Never heard of “Loki”? Check it out here: The Loki Library.

The Loki team has developed the best philosophy for programming library design that I’ve ever seen. It’s not so abstract that you can’t figure out what they mean, and they know that the real bang for the buck comes from disciplined dependency management and small, flat components. Judge for yourself:

How about you? Have you seen better?

We’ve All Had Those Days

November 17, 2010 Leave a comment

OMG! Last night, when I was sittin’ near the fire in my dinner jacket, sippin’ my glass of cognac, smokin’ my pipe, pettin’ my dog, and intently reading  Sutter & Alexandrescu’s classic “C++ Coding Standards: 101 Rules, Guidelines, and Best Practices“, I came across this curious passage:

Can you remember a time when you wrote code that used the standard library (for example) and got mysterious and incomprehensible compiler errors? And you kept slightly rearranging your code and recompiling, and rearranging some more and compiling some more, until the mysterious compile errors went away, and then you happily continued on—with at best a faint nagging curiosity about why the compiler didn’t like the only-ever-so-slightly different arrangement of the code you wrote at first? We’ve all had those days…

What on earth are they talking about? That’s never happened to me. What about you?

C++ Naming Conventions

May 8, 2010 2 comments

For grins, I perused a few books written by several C++ mentors that I respect and admire. I was interested in the naming conventions that they personally use when writing code. Here are the results.

Scott Meyers (Effective C++):

class names – class PhoneBook {};

member function names – void addPhoneNumber(const std::string& pn);

member attribute names – std::string theAddress;

Note: no annotation to distinguish class member attributes from local function variables.

Bjarne Stroustrup (The C++ Programming Language):

I consider the CamelCodingStyle of identifiers “pug ugly” and strongly prefer underscore_style as cleaner and inherently more readable, and many people agree. On the other hand, many reasonable people disagree.

class names – class Phone_book {};

member function names – void add_phone_number(const std::string& pn);

member attribute names – std::string the_address;

Note: no annotation to distinguish class member attributes from local function variables.

Herb Sutter and Andrei Alexandrescu (C++ Coding Standards):

class names – class PhoneBook {};

member function names – void AddPhoneNumber(const std::string& pn);

member attribute names – std::string theAddress_;

Note: they use post-underscores to distinguish class member attributes from local function variables (int clientName_;  //is a class member)

When I’m not constrained by a specific naming standard, I use this one:

class names – class PhoneBook {};

member function names – void add_phone_number(const std::string& pn);

member attribute names – std::string the_address_;

Note: Like Herb & Andrei, I use post-underscores to distinguish class member attributes from local function variables (int client_name_; //is a class member).

%d bloggers like this: