In The Community: Meet James McNellis

This is the second installment in the "In The Community" series spotlighting members of the C++ / developer community. Today we meet James McNellis, a developer on the Visual C++ team and community guy.

James is a developer on the Visual C++ team, which he joined this past July. As a member of this team, he builds awesome C++ libraries and is currently doing work on the C Runtime Libraries (CRT). Prior to joining the Visual C++ team, he was a developer on the Blend for Visual Studio team where he worked on the XAML designer for Windows Store apps. James has been programming in C++ for 15 years and has worked on a wide variety of projects, from embedded robotics software to 3-D simulation.

I love C++ because it makes it easy to build large software systems that are correct, maintainable, extensible, and high-quality. It enables high levels of abstraction without sacrificing performance. It has one of the most magnificent language features ever—templates—which, among many other wonderful uses, allow us to build generic components that are as efficient as any type-specific components that we might consider building instead. It has first rate support for value semantics, which make programs easier to reason about. There are C++ toolchains for most major platforms, and with a bit of work it's possible to build libraries that will run practically anywhere. Flexibility, performance, and portability are all extremely important.

What do you like most about C++?

Object lifetimes are deterministic, there are rules specifying exactly when objects are created and destroyed, and those rules apply consistently to all objects of all types. I think these fundamental language rules are largely the reason why C++ is so awesome. They enable resources to be managed uniformly (via RAII) and make it possible to build complex systems easily by aggregating small, composable parts. They make it easier to build programs that exhibit correct behavior, in both nominal and error cases.

I took the C++ object model for granted until I spent time working on a large system implemented in C#, which does not have deterministic object lifetimes. C++ has many splendid features, but the object model with deterministic object lifetimes was the thing I missed most.

Least?

The syntax of the language. C++ inherits a bucket of syntactic oddities from C (e.g., the declarator syntax), then adds some quirky syntax "features" of its own (e.g. the most vexing parse). None of these issues are particularly horrible on their own, but it's aggravating because there are so many quirks and corner cases. C++ with a simpler, cleaner, easier to learn and teach, and more consistent syntax would be a truly wonderful language. But then, of course, such a language wouldn't be C++ .

What advice would you give new C++ developers?

Don't make the mistake of assuming that C++ is just like [insert language with which you are already experienced]. Idiomatic, correct, well-written C++ is quite different from similarly high-quality code written in other popular languages, including Java and C#. C++ best practices are quite different from best practices in other languages. The best way to learn to program in C++ is to obtain a good book and learn how to write idiomatic C++ from the start. You'll save a lot of time and avoid much pain and suffering.

Do you have any favorite C++ favorite authors or books?

I recommend C++ Primer 5th ed. by Lippman, Lajoie, and Moo as both an introductory text and a reference text for C++. It presents C++ with an emphasis on modern C++ style, covers much of C++11, and discusses many best practices. (Of particular note: dynamic allocation using 'new' isn't discussed until page 449, and one of the first statements is that it is "notoriously tricky.")

Stack Overflow, of course! Stack Overflow isn't just a great place to find answers when you're trying to solve a problem. Reading through answers to C++ questions, even if those questions aren't immediately relevant to what you're currently working on, is a great way to learn about parts of the language with which you're not familiar. There are many C++ experts and enthusiasts who contribute on Stack Overflow and there's a ton of very useful, very readable information. You'd have a hard time finding a better community of friendly, helpful experts. As a starting point, consider perusing the C++ FAQ, containing frequently asked questions with great answers.

I also encourage everyone to contribute answers. I've been using C++ for a while, but I didn't really, truly start learning the language until I started contributing on Stack Overflow. There's a big difference between being able to write code in a language and being able to explain clearly and concisely how and why that code works (or doesn't work). Helping others by helping to answer their questions is quite rewarding and is a great learning experience.

James is a jolly decent chap. I've bounced questions off him in the past and always learnt something new from the answers.

Tristan

8 Jan 2013 7:48 AM

James answers are another round of inaccurate statements about C++.

Speed. This is single benefit from using this language, but speed have nothing in common with language. C++ is compiled to native code, and only OS is platform for C++ application. There is not GC, runtime check for types, security, etc. Any language compiled to native code and running without additional platform, can be as fast as C++.

'It enables high levels of abstraction without sacrificing performance'. Frequently using vtables can slow down performance. C++ is not as high abstractive as other languages. When you implement some absctractive ideas in C++, then performance drops. Your CxxReflect will tell you sad news about performance, under havy load. Try to implement LINQ with the same level flexibility on C++, and maintain high performance - good luck.

Components. C++ does not have defined standard for creating components, similar to NET assemblies. After create component you must share compiled dll, with headers and possible templates with specific code. Your component can be used only with another C++ application with relative ease. For another languages/palforms you must create some wild solutions to use this component. Weak componentization of C/C++ is primary reason for wide using of COM. Compare this to simple and elegant NET assemblies with metadata, code, versioning and other related features.

Portability. Every labguage is portable, because is not dependent on any OS/CPU/system. Portability is related to used libraries, not language itself.

Flexibility. C++ is most unflexible language of others popular languages. There are no extensions methods, integrated queries, reflection, compiling services and others. Using macros in C++ is dark and dangerous game.

C++ is old and relative primitive language, and was great 20 years ago. This language is havy loaded with primitive tricks and hacks, that cannot be easy removed/replaced/fixed to equalize other and better languages. ISO want to fix these problems with C++17, but this is impossible without creating new language, maybe ++C :)

> Try to implement LINQ with the same level flexibility on C++, and maintain high performance - good luck.

It's been done already, multiple times (i.e. there are multiple implementations).

> C++ is old and relative primitive language, and was great 20 years ago.

Your opinion of C++ is old and relatively primitive. ;-]

Nathan Monteleone

8 Jan 2013 11:53 AM

I knew you couldn't stay away from C++ for long :)

Diego Dagum

9 Jan 2013 9:01 AM

Hi @Tristan,

I believe you are doing a free interpretation of James's words.

I believe that James's words are framed to the context "C++ faster than managed languages". Other native languages can achieve comparable or higher speed levels. That wouldn't invalidate a choice for C++, considering other trade-offs. You could decide to go with C, which offers even higher speed levels. But C resigns the OO paradigm entirely. You can even go with Assembler if performance is the most critic aspect (I did it when that was the case, which fortunately wasn't often).

It's true what you said about componentization in C++ vs. .NET, although I have some conceptual discrepancies. Componentization isn't a language feature. It is a platform one. As Microsoft provides both the Windows platform and the .NET framework, it can architect .NET's componentization to play nicely with Windows. That's a plus for .NET over the Windows platform. I don't expect that component model to survive if I need to invoke a Java component from a Mono app in Linux. I hope I'm making clear with this example that componentization depends more on platforms than programming languages per se.

There are probably not absolute answers about language choices. James offered good reasons to choose C++. You offered good caveats to keep in mind about it. For the next project that needs to be built, it should be picked the language that best deals with the project constraints. Let's learn more than one language just in case and let's never say "never-ever".

- Speed and abstractions: yes, in theory, any language compiled to native machine code can be as fast as C++. But C++ enables a lot of literally zero-cost abstractions. In most other languages, you have to settle for a C-like subset if you want maximum performance. Most of the C++ standard library is literally optimal, it has zero overhead, it is as performant as if you'd hand-coded everything line by line. I don't know of another language for which that is true.

You are right, of course, that vtables have a cost, but I don't see the relevance of that. The nice thing about C++ is that you can get pretty far without incurring that cost. Look again at the standard library, or specifically, at the STL subset. There are no vtables in std::vector, std::map, std::transform or std::find. That is in stark contrast to the equivalent functions and data structures in pretty much any other language I can think of.

- Components: if you read what James said, it's pretty clear that he wasn't talking about components in the .NET assembly sense, and yes, that's one area where C++ is lacking. His mention of "type-specific" should be a hint that by "component" he simply means a self-contained generic chunk of code. std::vector is a component, as is std::find, as is any other reusable function or class. James is simply pointing out that with C++ and templates, you can write such small "components" which are readily reusable *and* efficient. Yes, it would be nice if C++ also had something like assemblies, but that's not what James meant.

- Flexibility: now that's subjective, isn't it? However, Linq *has* been reimplemented in C++ several times by different people. It's doable, and it performs *better* than in .NET, because in .NET it is based on the aforementioned vtable lookups: everything operates on a IEnumerable<T> type, whereas the C++ implementation using templates can operate on the actual types themselves. There are no extension methods, that is true, but then there are free functions. I don't see how the absence of *one* arbitrary feature signifies anything in terms of flexibility. There's no general-purpose reflection, but again, with the flexibility of C++, you can get surprisingly far without it, with type traits and other metaprogramming tricks. I think that's what flexibility means: the ability to do something without adding a dedicated language feature for it. C# had to add new features in order to implement Linq. C++ didn't. C# had to add specific language features dedicated to reflection. C++ can't do quite as much in terms of reflection, but it can get surprisingly close *without adding any actual reflection to the core language*.

James' statements about C++ are accurate. Yours aren't. You do mention a couple of actual weaknesses of the language, but they're buried in a mix of factually incorrect, subjective and just irrelevant statements.

@James McNellis Impressive work! How the name C++/CX got chosen? From existing slang WPF/VB.net or WPF/C#, XAML/C++ seems more intuitive to native development. With C++/CX almost every post targeting native Win devs seems to include disclaimer clarifying on managed CLI. Your series does fine job of disclosing the whys. How about parallel series touching the same technique as the corresponding post from yourself, but more closely focusing on the how that's fitting into whole sample built over the course of this parallel series?

The build videos do that job too, but its too much at once. The stable pace of series of posts is nice. Also, once more, your team is an inspiration to work, thnx. keep up. :)