I’ve been meaning to post a link to Vincent Lextrait’s nice (and actively maintained) catalog of what languages are used to build what modern and major mainstream software:

The Programming Languages Beacon

This table contains a list of major software products or utilities, with details about the programming languages used to implement them. Information on this is difficult to find, and a few small mistakes might have escaped the author‘s attention. Corrections, suggestions for additions or even references are welcome. …

A nice data point to use to show that the world is built on C++ (and its C subset).

The table was compiled without bias on the part of the person who compiled it; he’s just trying to gather information. If you think a language is under-represented, send mail to Vincent with specific project data (make sure it’s something you know of first-hand or can point to an authoritative source) and I’m sure he’ll be glad to add it.

Nicely put… Christian Lindholm:

Most companies (including web startups), he said, are looking to “wow” with their products, when in reality what they should be looking for is an “‘of course’ reaction from their users.”

Simple and obvious beats flashy. So many great designs are obvious in retrospect.

Hat tip to John Gruber.

Followup on this earlier question, @bilbothegravatar asked:

@Alf, @Herb – I don’t quite get the [[noreturn]] example. While it may (not) compile on VC++, (as far as I understand) it does not carry any semantic meaning, and, what’s more, it is *perfectly* safe for any compiler that sees [[noreturn]] to just ignore it — the runtime behaviour vs. VC++ shouldn’t be changed at all.

So how is [[noreturn]] in the same camp as “restrict” ??? (I agree it may(?) be in the same camp as final and override.)

I will quote Bjarne: (http://www2.research.att.com/~bs/C++0xFAQ.html#attributes)
> There is a reasonable fear that attributes will be used to create language dialects.
> The recommendation is to use attributes to only control things that do not affect the meaning
> of a program but might help detect errors (e.g. [[noreturn]])
> or help optimizers (e.g. [[carries_dependency]]).

Yes, this argument was used. I’m (even) more conservative than Bjarne on this one.

People spoke up for two main different views on the question, “what does it mean to say [[attributes]] should not affect language semantics?” For convenience I’ll label these as the “weak” and “strong” views. Both views agree that if a program is valid both with and without the attribute, it should have exactly the same meaning both ways. Where the two views/camps differ is on whether it counts as “changing the meaning of the program” if a program that is valid if the attribute is ignored is rejected (fails to compile) if the attribute is observed:

• The “weak” view says that’s okay because it didn’t really change the meaning of code that could ever execute, it just caused it to fail to compile. (I know, [[noreturn]] seems like it’s doing that… but it actually doesn’t quite meet this definition in my opinion, see below.)
• The “strong” view, which I strongly support, says that calling a program illegal not only is the most dramatic semantic change possible, but also should be considered a nonconforming extension because it rejects code that is legal in the standard. (I know, [[noreturn]] in particular is standard… but it’s still problematic for this reason, see below.)

On principle, I do not like opening the door to let compiler writers use [[attributes]] as an excuse to not respect legal ISO C++ programs. And I say that as someone who works on a C++ compiler team and actively does C++ language extension design, and having the excuse of disabling part of ISO C++ that I don’t like by throwing in an [[attribute]] could be useful. Don’t get me wrong, there are corner cases of C++ I would like to turn off, but I try hard (and so far successfully) to refrain from doing such a thing without ISO C++’s blessing because it would break source code portability. Encouraging the view that nonstandard [[attributes]] can be a legitimate excuse to reject conforming C++ programs strikes me as putting a live grenade in a public square with a “pull me” tag on the pin. The whole point and primary benefit of having an ISO standard for C++ is to guarantee source portability; this weakens that, and for that reason I view it as a dangerous position to take.

However, in general the “weak” interpretation prevailed, and on those grounds [[noreturn]] and [[carries_dependency]] remained an attribute. I didn’t fight it because at least we got to remove [[final]], [[override]] and [[base_check]] as attributes, which was my primary concern since those would see far more use, and as long as we fixed those I was happy to say I could live with the others in order to get a consensus standard.

Post-Mortem: Assessing [[noreturn]]

Disclaimer: The following is an informational analytical exercise, not a public lobbying for a change. I support where we ended up as a whole to get C++11, it is probably too late to tweak [[noreturn]], and I consciously didn’t pursue making the following arguments at the time because [[noreturn]] (and [[carries_dependency]] are so rarely used that I can live with them, and you have to be willing to give some ground to get a consensus standard – the important thing was to get [[final]], [[override]], and [[base_check]] out and then stop while you’re ahead.

With that disclaimer in place, let me present counterarguments to show why I believe that in an ideal world [[noreturn]] shouldn’t be an attribute because it really is a keyword in [[attributes]] clothing and doesn’t actually meet either the weak or the strong view:

• I don’t think that [[noreturn]] meets the bar set by the weak view, because it does more than just cause programs to fail to compile. In my opinion, adding [[noreturn]] does change the meaning of a conforming program, because the C++11 standard says in 7.6.3/2: “If a function f is called where f was previously declared with the noreturn attribute and f eventually returns, the behavior is undefined. … [Note: Implementations are encouraged to issue a warning if a function marked [[noreturn]] might return. —end note ]” – Even if respecting a [[noreturn]] did cause a compiler to reject some code (which is not required by the standard, and is not even mentioned even in the non-normative note which just talks about maybe issuing a warning), that means that void f(); and [[noreturn]] void f(); do not have the same semantics – returning from the first is always defined behavior (if you do it), and returning from the second is undefined behavior. This isn’t just a language-lawyerly argument either – the reason the standard says “undefined behavior” here is because that’s how the standard explicitly gives latitude to optimizers – it’s saying that “a compiler optimizer may assume the function doesn’t return, and optimize the code in ways that could cause different execution (even catch-fire semantics) if f ever actually does return.” Telling the compiler it may rely on this attribute to have meaning is, to me, clearly giving the attribute a language meaning and so changes the program’s semantics if it is present. So I don’t think it’s actually true that the presence of [[noreturn]] doesn’t affect language semantics.
• It also doesn’t meet the strong view and discourages portability, by opening the door for using nonstandard attributes as a reason to reject conforming code. Now, it’s true that [[noreturn]] is in the standard itself, and so we might be tempted to say it’s not like a nonstandard attribute in this way that reduces portability, but it is – you cannot reliably write portable C++11 code under the assumption that [[noreturn]] has no semantic meaning and can be ignored. That’s because adding [[noreturn]] really does change the meaning of a function declaration (by adding guarantees that the optimizer can use, as described above) and so you really need to treat it as though it were a language keyword – because it is, just dressed in [[attributes]] clothing.

So in my view [[noreturn]] is a keyword dressed in [[attributes]] clothing.

Having said all that, experts do disagree, and the two camps have simply had to agree to disagree on this question – we got unanimous consensus on the standard, even though [[noreturn]] and [[carries_dependency]] are a bit of a sore point, because everyone was satisfied enough that we at least averted having [[final]], [[override]] and [[base_check]].

Motti asked:

While you’re dealing with reader’s Qs….

In your keynote in “Going Native” you mentioned that type inference should almost always be used, except for some obscure cases with expression templates.

Yes. To give people context, the idea is when declaring local variables, prefer to use auto to deduce the type. For example:

auto x = begin(v);

This seems like a rather serious wart on the language,

It’s a wart, but I don’t know about “serious” – it doesn’t come up that often. Still, your question is quite apropos:

part of the power of expression templates (to my understanding) is that they can be dropped in by a library implementer and thus improve the clients’ code without their knowledge.

Was there any discussion to allow type authors to opt-out of type inference? (e.g. by allowing an “operator auto()”). If this wasn’t discussed for C++11 is it being discussed for C++1y?

Yes, and even exactly that spelling has been suggested. I’ll take that as a +1 for discoverability if we name it that!

(For people reading this comment, if it doesn’t make any sense I wrote about it last year in my blog http://lanzkron.wordpress.com/2011/02/21/inferring-too-much/)

In the comments on last week’s interview, MichaelTK asked:

@Herb: You mentioned two things I don’t fully understand in your talk.

1) Why would C++ be a better choice for very large scale applications than NET/Java? I mean the zero abstraction penalty (which is more a JIT compiler issue and not intrinsically hardwired into C#) , okay, but besides that?

2) C++ really only has a few language features which actually let you write faster code in theory. In practice, JIT compilers are just not good enough, yet, to fully optimize on C++ pace and that’s one of the main reasons why C++ excels at efficiency.

No, the reasons go deeper than that. I’m actually giving a talk at Lang.NEXT on Wednesday which focuses exactly on the managed/native divide. I’ll post a link next week.

In the meantime, short answer: C++ and managed languages make different fundamental tradeoffs that opt for either performance or productivity when they are in tension.

Why does Microsoft not put effort into a static C++ like compiler for C#/NET, say in manner of NGen, so that C# actually has even the slightest chance of being competitive with C++?

Actually, Microsoft has been actively investing in that for over a decade. So have Java vendors. I expect those efforts to continue.

Otherwise, saying C++ is more efficient than C# is not a theoretical issue, but caused by bad JIT compilers.

This is a 199x/200x meme that’s hard to kill – “just wait for the next generation of (JIT or static) compilers and then managed languages will be as efficient.” Yes, I fully expect C# and Java compilers to keep improving – both JIT and NGEN-like static compilers. But no, they won’t erase the efficiency difference with native code, for two reasons.

First, JIT compilation isn’t the main issue. The root cause is much more fundamental: Managed languages made deliberate design tradeoffs to optimize for programmer productivity even when that was fundamentally in tension with, and at the expense of, performance efficiency. (This is the opposite of C++, which has added a lot of productivity-oriented features like auto and lambdas in the latest standard, but never at the expense of performance efficiency.) In particular, managed languages chose to incur costs even for programs that don’t need or use a given feature; the major examples are assumption/reliance on always-on or default-on garbage collection, a virtual machine runtime, and metadata. But there are other examples; for instance, managed apps are built around virtual functions as the default, whereas C++ apps are built around inlined functions as the default, and an ounce of inlining prevention is worth a pound of devirtualization optimization cure.

Second, even if JIT were the only big issue, a JIT can never be as good as a regular optimizing compiler because a JIT compiler is in the business of being fast, not in the business of generating optimal code. Yes, JITters can target the user’s actual hardware and theoretically take advantage of a specific instruction set and such, but at best that’s a theoretical advantage of NGEN approaches (specifically, installation-time compilation), not JIT, because a JIT has no time to take much advantage of that knowledge, or do much of anything besides translation and code gen.

More in the talk on Wednesday (for those who are at the conference) which will go live online next week… I’ll blog about it when it’s up.

Referring to C++ AMP, a reader emailed me to ask:

Are you going to replace restrict keyword with new C++11 attribute feature [[]] ?

No, because restrict is a language feature and [[attributes]] are specifically designed to be ignorable and shouldn’t be used for things having language semantic meaning. During the ISO C++11 process, I was heavily involved in a long battle to try to prevent keywords dressed in [[attributes]] clothing from sneaking into the standard; for example, C++11 final and override used to be [[final]] and [[override]] in pre-final* drafts and I led the charge against that, and with the help of likeminded people it was overturned.

* pun intended