A Look at C++14 and Beyond: Papers Part 4 -- Meeting C++

And the final part 4:

A look at C++14 and beyond: Papers Part 4

This is the 4th and last part about the Pre-Bristol mailing and its papers. This series has given me a good overview, what is up in the future in C++. Still, some things are missing, not all will come to shine in this series. I have no papers with actual proposals skipped, but a few papers are only to find in the January mailing, and not in this one. One of them is for example a paper on filesystem, which should make it into C++14. However, there will be a follow up to this series. At the next meeting of my local C++ User Group we are going to have a video call with Michael Wong and other attendees of the meeting. This will be an interesting chat for sure, and help me refine my view on C++14 and C++17 Standards. I'll write this down in the follow up, featuring also some of the feedback that has come.

Before I start with the last 23 Papers, I'll want to shortly mention where this idea has come from. Last fall I saw two blog entries about the Portland Meeting, each naming a few favorite papers and a short summary of them. One was Japanese, and one was Korean, as far as I remember. I had never seen anything like this in the west, no blog, no site brought anything about the papers. Organizing Meeting C++ did not give me the time, to do something similar back then. The decision to cover all papers came, as I wanted to read through most papers any way, and most papers are worth reading. I'm not yet sure if I do something similar for the Chicago Meeting, as this is very time consuming, and therefore would like to state, that I do look for possible Sponsors helping me doing this.

But, lets get started on some papers...

Add a Comment

Comments are closed.

Comments (3)

0 0

David H Braun said on Apr 15, 2013 03:57 AM:

There are a lot of first-person references (lots of I's and me's), but no identification of who is writing. It's always good to put such information up front, at the top, but especially important when there are so many references to self. The official capacity and authoritative perspective from which the author is writing are also helpful to know.
0 0

David H Braun said on Apr 15, 2013 04:23 AM:

N3613, "'Static If' Considered" catches the eye, and its negative analysis of recent proposals has presumptive weight by mere fact that its authorship includes Bjarne Stroustrup. I'm eager to see the back-and-forth on this, including the next response from the principal proponents of "static if", which seemed at first review to be an exciting, powerful, and conceptually simple addition to the language. This paper ominously concludes that "future development of static if should be abandoned, and that alternatives such as “concepts-lite” approach should be pursued instead."
0 0

Ben Hanson said on Apr 16, 2013 05:08 AM:

First off, let me say that I've always found Bjarne's reasoning exceptionally clear and logical. One of the things that attracted me to C++ in the first place is the logic for why things are done the way they are (reading The Design and Evolution of C++ helped a lot here).

When I first read about the original concepts, I could see it was an ambitious project and it did strike me as somewhat overwhelming. I felt these fears were somewhat justified when concepts were abandoned for C++11. Around the same time I was tracking what was going on with The D Programming Language and was wondering if there there was going to be a serious competitor to C++ any time soon, with better meta-programming, a more modern syntax and all the cruftier parts of C left bleeding by the side of the road.

Then along came the static if proposal. At first glance, it seemed appealing from the point of view of C++ syntax was just getting too damn hard. On the other hand, maybe it was just too much of a hack and inviting disaster further down the road. It now seems Bjarne has formalised his opinion that he indeed considers it an ugly hack.

I haven't scrutinised N3613 in detail, but I can well see how he's arrived at that conclusion. I also trust his judgment. The parsing issues he mentioned make a lot of sense to me.

Overall, I still think the time is near to come up with a modern and up to date syntax to replace C++s. I no longer wonder if The D Programming Language will be that language - I simply don't believe in the design decisions that have been taken (although there are definitely some very good ideas mixed in there). In the end, maybe we will witness an evolution rather than revolution as things like C++ modules get introduced and C++ continues its modernising and starts to lead the field again.