Archive for the 'C++0x' Category
06-19-2008
Sophia Antipolis - A Standards Meeting Reviewed (Part 2)
Concurrency is a hot topic, not just for C++0x but across IT in general as the hardware we use on a daily basis transitions from the serial single-core world many of us grew up with into the parallel multi-core world on sale today. Entry level desktop PCs have been dual core for some time now, and even mobile phone platforms are routinely dealing with multiple CPUs. While the legacy of single-core hardware will take some time to fade completely, modern software development must address the fact the it is generally now running on machines that genuinely exectute in parallel with a shared memory architecture.
This challenge goes to the heart of the C++ specification which is designed in terms of an abstract machine that all implementations must emulate. The existing standard specifies a machine largely inherited from C with no notion of parallel execution, so the very foundation the standard is built on needs updating!
The lowest level of this work is known as the memory model. This part of the standard defines the notion of parallel execution, threads and race conditions, and the dependency between the order of operations that a compiler must enforce. To an extent this limits the range of optimizations available to compilers compared to a single-threaded execution, but also gives developers the guarantees they need in order to write programs without unexpected side-effects, such as the infamous double-checked lock idiom that frequently fails to work as expected in the presence of optimizations (some performed by the CPU itself, rescheduling instructions after compilation!)
Most of the memory model work has been resolved at earlier meetings, and focus has moved towards libraries and higher-level abstractions to make concurrent development practical. However, even at this meeting a number of fundamental proposals were adopted. Probably the most far-reaching proposal goes under the snappy name of "Minimal Support for Garbage Collection and Reachability-Based Leak Detection". First up, this does not mean C++0x just became a garbage collected language! However, this carefully crafted proposal inserts just enough requirements into the memory model to make a GC implementation practical and reasonable, so while GC is not a required feature we should expect to see garbage collected implementations in the future, although I expect many will come with a compiler switch to enable or disable the feature. The cost of this feature is that some currently valid programs will find they rely on undefined behaviour in C++0x. Generally, unless the GC switch is thrown, that undefined behaviour will continue to do exactly what it does today, so I expect few programs will break out-of-the-box.
To enable GC two new ways of describing pointer values have been defined. A safely derived pointer is what you get from calling a memory allocation routine such as malloc or new, or a copy of such a pointer. A reconstituted pointer is what you get when you start playing tricks with the value, such as using bitmasks or storing it in an integer variable. When you restore the pointer value it is now reconstituted and it is no longer guaranteed to be safe to deference such a pointer. This is the freedom that allows a garbage collector to reclaim memory. If this kind of behaviour is important to your program (and there are various well-documented idioms using these techniques, not least storing pointers in the Tag property of VCL components!) then you can call a new library function declare_reachable before ‘hiding’ your pointer. Reconstituted pointers to an object previously declared as reachable can be safely deferenced, until after a later call to declare_unreachable. This effectively gives us a way to tell the garbage collector about hidden pointers, so it does not collect too early. This nice thing about this formulation in terms of reconstituted pointers is that it is not specific to garbage collection. I am curious to see what other interesting applications turn up such as improved memory-leak detection tools.
Next time I will talk more about library support for concurrency.
Posted by Alisdair Meredith in C++0x | No Comments »
06-17-2008
Sophia Antipolis - A Standards Meeting Reviewed (Part 1)
Those following the process of developing the next C++ Standard will know that we have just got back from our latest meeting in the south of France hosted by INRIA, the reknowned French research institute.
To give you a flavour of a typical standards meeting, we typically see around 60 delegates from all corners of the C++ community. Obviously compiler and library vendors are present with a very strong stake in the standard they will have to implement! Also a variety of interests on the user side are present, from research institutions like Fermilab to commercial users like Adobe. A most valuable addition to the mix are acceademic institutions like INRIA itself, and Texas A&M University has a thriving department led by Bjarne himself. These departments are often the source of the most creative new features as ideas that become familiar in computer science research filter down in practical ways for modern languages. The most obvious example this time around has been Concepts (more about these in a future post) but important features such as lambda functions and variadic templates also came out of this direction.
A meeting lasts six days, much of the opening morning given over to status reports and planning for the week. Likewise, the final afternoon is given over to reports on the week’s progress and formal motions to adopt new features for the standard. There is also a dry run on the Friday afternoon so that contentious issues can usually be taken off the agenda to build another meeting’s worth of consensus. This helps to run an efficient Saturday meeting - which can be handy when you have transport plans for leaving later that day. It also means that the Friday meeting is usually the more ‘interesting’ one!
The other aspect to running the meeting is that it is essentially two meetings in one, an ISO meeting for national standards bodies, and the ANSI (more spefically INCITS) meeting for the American delegation itself. This means that typically two votes are taken on each motion, one to determine the US vote, and a second to determine the ISO. There were 7 nations represented at the last meeting in Sophia-Antipolis, France, Canada, Germany, Holland, Switzerland, UK, USA. If your nation is not listed and you think they should have a say in the future of C++, now would a really important time to get them interested because…
… one of the key topics and early decisions made this meeting is to try to finalize our timetable. The new standard is going to be a big deal, there are at least new 50 language features planned, ranging from small features like default template parameters for function templates, to seriously far-reaching features like Concepts. In addition to incorporating the new language feature the library is almost doubling in size! Pulling all this together has been a huge ammount of work, but it is important to finally close out the submissions and ship the standard. We spent some time weighing up the risk and cost of large new features like Concepts versus the timetable, and came up with what we hope will be the right balance. We plan to ship a feature complete Candidate Document (CD) at the next meeting, which means we should have everything we plan to include in the next version of C++ written up in formal Standards language, and we plan to spend a little more time cleaning up the document to make the specification as tight and precise as we believe an international stadard should be. Essentially, C++0x should be complete next meeting, bar the bookkeeping and bug-fixing. The purpose of shipping a CD is that an official ballot is called for all participating ISO nations to approve the document and make comments, so this will be the first real test of whether we have got our feature-set right.
Next the timetable calls for the Final Candidate Document (FCD) to be produced in the next 12 months, so we can send that out for a ballot around September next year. That ballot should also produce comments. If we are approved we can pass a final version of the document, further ammended in response to comments and now dubbed the Final Draught International Standard (FDIS), along to the top level of ISO/IEC for the final vote to adopt the standard. Again, we anticipate 12 months and 3 meetings to resolve FCD comments before sending out the FDIS.
So now we have a timetable with a clear plan to release a standard in just over 2 years. Essentially, C++0x will be ‘complete’ this year, 2008, but the final standard is likely to be available around 2010, or early 2011. So 0x may be 08, or hexadecimal 0A, depending on your point of view!
Next time I’ll talk about some of the features that were discussed and approved during the meeting.
Posted by Alisdair Meredith in C++0x, Standards | No Comments »