Journal Articles

CVu Journal Vol 27, #2 - May 2015 + Programming Topics
Browse in : All > Journals > CVu > 272 (9)
All > Topics > Programming (877)
Any of these categories - All of these categories

Note: when you create a new publication type, the articles module will automatically use the templates user-display-[publicationtype].xt and user-summary-[publicationtype].xt. If those templates do not exist when you try to preview or display a new article, you'll get this warning :-) Please place your own templates in themes/yourtheme/modules/articles . The templates will get the extension .xt there.

Title: Standards Report

Author: Martin Moene

Date: 02 May 2015 17:18:48 +01:00 or Sat, 02 May 2015 17:18:48 +01:00

Summary: Mark Radford reports the latest from the C++ Standards meetings.

Body: 

Hello and welcome to my latest standards report. Not only is it my latest report but, it will also be my last, because I’m not continuing as Standards Officer after the forthcoming AGM (that is, forthcoming at the time of writing, it will have happened by the time this report appears in print).

The next full C++ WG21 (ISO) committee meeting is not until May. It will be held from the 4th – 9th May in Lexana, KS, USA. Unfortunately the pre-Lexana mailing isn’t yet available – and probably won’t be by the time I have to submit this report for publication – so I won’t be able to discuss it. The only thing that’s happened since my last report is the meeting held in Cologne, Germany, in the final week of February, by the Library Working Group (LWG). Therefore, while I have a little information on C standardisation progress, the majority of this report will be concerned with the Cologne LWG meeting.

The Cologne LWG meeting

The Cologne meeting set out to review all the papers that make up the inputs into both the Concurrency TS and the Library Fundamentals TS v2. The objective being to move things along by having the papers reviewed and updated in time for the Lexana meeting. If this could be achieved, then further work on the papers at Lexana will be minimised or (ideally) not necessary at all. Note that there was much more on the agenda for Cologne. However, I can’t report everything, so I’ll focus on the Concurrency TS and Fundamentals TS v2 because these are listed in the meeting agenda as being the highest priorities for the week.

The inputs into the Concurrency TS consist of three papers: ‘C++ Latches and Barriers’ (D4281), ‘Atomic Smart Pointers’ (N4162), and ‘Improvements to the Concurrency Technical Specification (Working draft)’ (N4123). Inputs into the Fundamentals TS consist of six papers: ‘Generic Scope Guard and RAII Wrapper for the Standard Library’ (N4189), ‘Extending make_shared To Support Arrays’ (N3939), ‘Multidimensional bounds, index and array_view’ (N4346), ‘Const-Propagating Smart Pointer Wrapper’ (N4372), ‘make_array’ (N4315), and ‘Source Code Information Capture’ (N4129).

Concurrency TS

‘C++ Latches and Barriers’ (D4281) was a paper that received quite a lot of time. The version under discussion had the number N4392 at the top of it, so I’m assuming that’s the number it will go by in the pre-Lexana mailing, although it was discussed as the (not publicly available) draft paper D4281. This paper has been through a few revisions, the most recent to appear in a mailing being N4204 in the pre-Urbana mailing. D4281 focuses on wording for the Concurrency TS. Further, Concepts have been removed from this edition.

I’ll give a short summary of what latches and barriers are. A latch is a synchronisation object which maintains a counter and blocks all participating threads until the counter is decremented to zero, at which point all the threads are unblocked (see N4204 for an example). A barrier causes a number of threads to block until all threads catch up, at which point all the threads are unblocked. There are two types of barrier: barrier and flex_barrier. In the latter case, when all the threads catch up and before all threads proceed, one thread is released to execute the completion phase, i.e. code passed to the flex_barrier’s constructor in the form of a function object.

The group discussed this paper four times during the week, with some of the discussion being at a very detailed level. Also, the draft changed during the week because the authors were able to provide updates in response to comments passed on to them from the meeting. At the end of the Friday session it was decided to hand the paper back to SG1 (Concurrency and Parallelism) for them to review it once more with the recent changes, and to move it to ‘ready’ status assuming they are satisfied.

‘Improvements to the Concurrency Technical Specification (Working draft)’ (N4123) was discussed on Wednesday and Thursday. Much of the discussion centred on getting the wording right. Actually the paper being reviewed wasn’t strictly N4123, rather it was N4107 with N4123 merged in i.e. the meeting reviewed the working draft of the Concurrency TS plus the improvements. Unfortunately it is not clear to me, from the minutes of the discussion, what the actual conclusion was. However, it is listed as having ‘revisions expected’ on a document status page (on the WG21 internal wiki). I’m assuming this means a revised paper, which addresses issues raised in Cologne, is expected to be available for Lexana.

‘Atomic Smart Pointers’ was not discussed as it was moved to ‘ready’ in Urbana i.e. it was not necessary for the Cologne meeting to discuss it further.

Library Fundamentals TS

‘Generic Scope Guard and RAII Wrapper for the Standard Library’ (N4189) takes the well known RAII idea and generalises it. There are two variations: one just executes a function on destruction, while the other holds a resource for which it executes a ‘deleter’ on its destruction. The discussion of this paper that went into some detail. For example: the headers it describes are quite fine grained, whereas the library has traditionally preferred coarser headers. The reason for this is build speed: touching the file system will slow down the build. The conclusion was to have just one header. This may seem picky, but it is an example of the responsibility the standards committee has i.e. its decisions affect all C++ users. In any case there were several issues that lead the meeting to conclude that this paper is unlikely to be ready in time to make it into Fundamentals v2. The conclusion was to return the paper (with comments) to the Library Evolution Working Group (LEWG) for further work.

‘Multidimensional bounds, index and array_view’ (N4346) proposes library components to enable contiguous memory to be viewed as multidimensional. Note the more recent versions have concentrated on proposing formal wording without giving an overview. To get the overview you need to go back to an older version, N3851, which can be found in the pre-Issaquah (January 2014) mailing. Again, the discussion was detailed and several issues were raised. However, the conclusion was that the paper was in good shape to make progress at the forthcoming Lexana meeting, provided it is revised to address the issues raised in Cologne.

‘Const-Propagating Smart Pointer Wrapper’ (N4372) offers help with the problem that it is possible, in a const member function, to call non-const member functions on some (smart) pointer types (because C++ considers the underlying pointer type for treatment as const, not the object it points to). It proposes propagate_const, a wrapping smart pointer that has const and non-const operator-> overloads, that return a const pointer and non-const pointer, respectively. This paper was discussed three times during the week: on Monday when some issues were raised, on Tuesday after the author (Jonathan Coe, who was at the meeting) had made some revisions, and again on Wednesday following further revisions. At the end of the Wednesday discussion the meeting concluded that the paper was ready to make progress at Lexana.

‘make_array’ (N4315) proposes a simple utility for constructing a std::array (the paper points out that we have make_pair() and make_tuple(), but we lack the analogous creation function for std::array). In this case the discussion was short and and conclusion was that this is another paper in good shape for Lexana.

‘Source Code Information Capture’ (N4129) is a proposal for a library class (well, struct) source_context: when source_context is constructed, by way of implementation ‘magic’, it gets information such as the line number, the file name and function name of its construction. The idea is to avoid having to sprinkle macros (e.g. __FILE__) throughout the code, in order to have this information available in the code for logging purposes, for example. This paper was not discussed in Cologne because the author (Robert Douglas, who was unable to attend) intends to revise the paper and present the revision at the Lexana meeting.

‘Extending make_shared To Support Arrays’ (N3939) was not discussed as the LWG is awaiting a further revision.

C standardisation

Before I finish, I have a little information on C standardisation progress.

There has been a slight hiccup with part 2 of their floating point TS. There were some staff changes at ISO, and this lead to confusion about the status of this TS, with the result that it was published in error. The published version has not been reviewed by the floating point study group, or by WG14. When this reviewing has been done, a corrected version will be published. Meanwhile parts 3 and 4 (of this TS) are going through the DTS ballot. An early draft of part 5 (N1919) is now available.

Finally

That brings me to the end of my final standards report. Thank you to those people who have provided me with support and feedback over the three years I’ve been writing these reports. I assume Jonathan Wakely, as the only candidate, will be elected to take over as Standards Officer. I wish him well and step down knowing the standards reports are in safe hands.

Notes: 

More fields may be available via dynamicdata ..