GoingNative 2012 Day 1 is just concluding, and we’re getting ready for Day 2 tomorrow with more C++11 information and panels.
Day 2 kicks off tomorrow at 9:30am U.S. Pacific time, with the theme “C++11 Today and Tomorrow.” Day 1’s focus was entirely about C++11 as it exists today; Day 2 is partly about C++11 right now, and partly about forward-looking material about where compilers and the standard itself are heading.
In the morning:
- First I’ll give a talk on C++11, VC++ and Beyond. After a couple of Microsoft-specific announcements at the beginning, the bulk of the talk is about C++11 today – what the key features are that will change C++ coding style, idiom, and guidance the most; tips on how to use those particular features well and the common initial mistakes we’re seeing people make as we’re all learning this together as an industry; how C++11 adoption is progressing throughout the industry from libraries to compilers to books; and finally some concluding thoughts about future directions of ISO C++, starting with the next standards meeting which begins in just three days.
- Then we’re excited to have Google’s Chandler Carruth with us to talk about the Clang compiler, a “reimagining” (sorry) of gcc that we think is one of the most exciting investments in the C++ world today and something people will want to know about. (Note: No hidden meaning here; the VC++ compiler team isn’t planning to switch to Clang or anything, we’re just really excited to see this as yet another part of the investment pouring into C++ across the industry and want to help people know more about it.)
In the afternoon, we switch to forward-looking topics, and the two talks are about proposals that will begin to be considered at next week’s ISO C++ meeting:
- Andrei Alexandrescu has agreed to deliver a brand new talk on “static if” for C++. I personally invited Andrei and Walter Bright to propose this feature for ISO C++ based on his experience with it in D, and Walter and I will be presenting the proposal next week at the Kona ISO C++ meeting.
- Bjarne Stroustrup and Andrew Sutton cover the latest in the still-active C++ concepts effort as the final talk of the event. We decided to request that particular talk because, even though concepts are not ready to come into ISO C++ again in the short term, they are still very interesting and people constantly ask about them, so we wanted to cover that important topic.
- Finally, we’ll cap the event with an extended 90-minute Q&A panel with all the speakers. Again, you can tweet questions to #ch9live or #GoingNative during any of the talks and we’ll cover as many of them as possible at the end of the talk, but especially be ready to tweet your questions during the panel which is entirely reserved for extended Q&A. This is your chance to pick the brains of a Who’s Who of modern C++, and it’ll be the fourth time in this event that Bjarne will be on stage – he is graciously expending himself for our benefit this week, so take advantage of his availability, and that of the other speakers!
I hope you enjoy it. Repeating the graphics and links for convenience:
Sutter’s Mill 
> If you don’t have the right bricks you can’t build proper houses.
And if you try to build a house using “array_ref”, there won’t be any time for “xml_node”. The analogy broke down somewhere in there, but my point is simple: *time* is the biggest issue.
Every day spent talking about “array_ref” means a day not spent talking about JSON parsing, XML parsing, or any number of the other major things that Herb wants.
Personally, I believe that the committee should be doing things like “array_ref” and such. But I also believe that they shouldn’t be doing things like JSON/XML parsing and whatnot.
Think about it. Should an “xml_node” return an “array_ref” of its children, or a linked list as is traditional in XML processors? Should JSON arrays return “array_ref”? If so, what type? Should we incorporate Boost.Variant into the standard, so that the JSON parse tree is well-typed, or do we use the typical enum and union syntax?
The little things *massively* affect the big things. You don’t want to spend years standardizing XML parsing and then decide that the user should be able to get an “array_ref” of attributes or something.
> But I have no idea what “array_ref” and such are for.
See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3334.html
> Those are minor trivialities
If you don’t have the right bricks you can’t build proper houses.
> But even simpler things like array_ref/data_ref/str_ref, shared_array, a range interface for all algorithms are even more important.
The range stuff I can understand. But I have no idea what “array_ref” and such are for.
Furthermore, when it comes to “getting something done”, range-based algorithms aren’t something I see as an impediment to my work. They’re a nicety, some good quality-of-life stuff, but nothing more than that.
If the argument is that people want to use other languages because they have a larger, more feature-rich standard library, they’re *not* talking about range stuff or shared_arrays. Those are minor trivialities compared to networking and such.
> This stops being possible when C++ has a gigantic standard library.
Isn’t a large part of the standard library just portable C++?
> Porting for example, Python to another platform is an arduous task.
Is it? I’d expect most of it to be written in a portable language.
I do find it kinda strange that Herb seems to focus on higher level libs. IMO lower level libs are more important to get standardized first. Standard binary (a)sync file/network IO for example would be great.
Having standard compression and crypto would be welcome too.
But even simpler things like array_ref/data_ref/str_ref, shared_array, a range interface for all algorithms are even more important.
You can’t do high level stuff without getting the low level stuff right first.
Going Native was absolutely excellent from all involved.
I did have one question. In your Day 2 keynote, you really pushed hard for a much, *much* larger standard library. And I find this disconcerting, for one very important reason.
The first language ported to *any* platform is C. No question about that. The reason being? It’s vital to compiling the OS, but also because it’s tiny. C compilers are small and simple; they can easily be bootstrapped. The C-standard library is similarly microscopic.
What is the second language ported to any platform? C++. Why? For similar reasons to C. Important software is written using it. But also, its standard library is fairly small. You don’t have to port much more than some basic file IO. `std::vector` is pretty cross-platform. You need to port `std::streambuf`, and a few OS and locale-related functions. But that’s it.
This stops being possible when C++ has a gigantic standard library. Porting for example, Python to another platform is an arduous task.
The reason languages like C#, Java, and Python can have immense standard libraries is that there is only *one* implementation of them. OK, there are a couple of Java implementations, and .NET has one in the form of Mono. But these are generally also-rans as far as implementations go. There is one .NET implementation: Microsoft’s. That’s the standard. There is one Java implementation: Sun/Oracle’s. That’s the standard. There is one Python implementation.
C++ has 3 major implementations: GCC+libstdc++, Visual Studio, and Clang&libc++, as well as a plethora of minor ones (ICC, etc). You are asking all of these developers to implement some pretty heavyweight code. XML parsers (that’s pretty substantial for real XML, which means XML IDs, DTDs, XInclude, etc), JSON parsers, sockets, and other stuff. That’s a *lot* of work. And that means a **lot** of bugs.
To make this even remotely feasible, you would need the various C++ interests to create an open-source repository for most of these libraries so that they can share implementations. At which point… all you have is Boost that just happens to be shipped with your compiler.
I just don’t see this as a good idea.
Plus, there’s the very real possibility of the standards committee screwing them up. Take an XML parser. Is that going to be properly C++ized, so that it meshes well with standard algorithms? Will it’s DOM-style interface be an iterator-compatible interface? How does that affect parsing performance? Will the parser be able to be in-situ like RapidXML for that added bit of performance, or will it have to do something else? What parts of XML will it include? Will XSD be included as well (I hope not, because that makes it much more complex)? Will it offer several different styles of parser (reader/writer, SAX-style push parser, and DOM-style tree), or will it just force one on you? How do you deal with Unicode in XML? Does the parser provide a small set of Unicode encodings that it supports, and if you don’t use them, you’re out of luck? Or is it extensible in some way? What’s the interface for extending it, and does it differ between the three parser styles?
The thing about XML parsing today is that you can pick up what you want off the shelf. If I need serious XML processing, I go to LibXML2. It is a full, proper XML parser that has many styles of parsing files. It
C#, Java, and Python were all defined by *fiat*. For better or worse, their APIs were developed by one tiny group/person, who said, “Our API will look like this!” The committee could easily get bogged down in minutiae over these libraries.
And if they don’t, if the committee basically just rubber-stamps proposals, then we could very easily get a big problem: one thing in the standard doesn’t really work well with other things in the same standard. One of the points of a standard is interoperability: all the pieces work together. With C++, this is mostly true, but there are… odd places. `iostream` really looks out of place next to the STL-derived containers and algorithms. A bit of glue was added with the streambuf iterators, but then… do we really need the iostreams if we can just create a streambuf and input/output iterate over them with algorithms?
Big libraries are not something that committee-based standards are really capable of doing. C# may be an ECMA standard, but that’s because Microsoft did most of the work internally and just said, “Hey, review this and make sure it’s not stupid.” If we’re going to have dozens of contributors for library components running in and dropping code, basically saying, “standardize this pretty much as is,” that’s going to be a real problem.
I get the problem, I really do. Standard libraries are the first stop for people looking for a way to solve problems. And XML, JSON, etc, are problems that a lot of applications need solving. But I don’t think direct standardization is the way to go for these things. It could very easily do more harm in the long-run, creating buggy standard libraries with esoteric, poorly-constructed interfaces that nobody uses anyway.
Personally, I’ve always felt that C++, like C, should have standard libraries that are very general. They should provide common utilities that could be used in pretty much any program. They shouldn’t be providing specific functionality that would be called for directly by design.