тут:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/#mailing2007-10
Из главного: приняли многопоточность (убрав из нее вопросы уничтожения работающего потока, за что получили порцию аплодисментов от группы по стандартизации С:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2455.pdf), решили отложить сборку мусора (не успевают к 2009), после следующего заседания будет финальный драфт:
A clear statement of intent was made to complete work on the new standard in 2008, in order to achieve publication in 2009. To meet this timetable the plan is to vote out a feature complete Working Draught in two meetings time at Sophia-Antipolis in June. An FCD will be issued from the following meeting, allowing at least a minimal time for review and 'integration testing' of the new features.
In order to reach this goal, the threading library presented at Kona has been adopted, although a further round of work in an Editorial Committee will follow before a Review Committee signs off the draught wording for the project editor. While this proposal is feature and semantically complete, a little wordsmithing remains before it is ready for the Working Draught. It is expected to be incorporated in the Working Draught of the pre-Bellevue mailing.
A second proposed compromise to meet the timetable is the scaling back of the garbage collection feature. It is planned to remove known problems that inhibit garbage collected implementations, without actively designing a new feature. A couple of library APIs will be added to indicate code where pointers may be masked, or it is known that masked pointers do not exist. Both could be implemented as no-operations on a non-collecting implementation. It is expected that work on garbage collection will continue, and should be adopted in some form ahead of a complete revision of the next standard. Possible means include a new Technical Report, or a Normative Addendum to the (planned) 2009 Standard.
текущее состояние стандартизации языка:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2432.html
текущее состояние стандартизации библиотеки:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2433.html
текущий драфт Стандарта:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf
что изменилось по сравнению с предыдущей версией, можно прочитать здесь:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2462.html
Теперь по пунктам.
Итак, победитель:
Multi-threading Library for Standard C++
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2447.htm
стандартизация уничтожения потока оставлена на будущее.
Сопутствующие статьи:
C++ Atomic Types and Operations
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html
Concurrency memory model (final revision)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2429.html
Allow atomics use in signal handlers
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2459.html
Dynamic Initialization and Destruction with Concurrency
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2444.html
Abandoning a Process
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2440.htm
Стандартизированная нотификация об ошибках (больше никакой мешанины из errno/GetLastError — будет один класс system_error, который, кстати, уже используется в библиотеке поддержки многопоточности):
Diagnostics Issues
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2422.htm
Случайные числа:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf
Class member initializers
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2426.htm
Это чтоб писать struct A { int i=5; }; без необходимости упоминать эту пятерку в каждом конструкторе.
Explicit bool for Smart Pointers
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2435.htm
Предлагают избавиться от трюка с unspecified-bool-type, поскольку уже предложены (см. следущий пункт)
Standard Library Applications for Explicit Conversion Operators
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2434.htm
давно пора. А то явные конструкторы есть, а явных операторов приведения типа нет.
STL singly linked lists
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2448.html
естественно, итерация будет только в одну сторону.
Сюрприз 1: класс будет называть не так, как вы подумали, а std::forward_list! (как обычно, из-за того, что во многих библиотеках slist уже есть, та же история, что и с hash_map, который стал std::unordered_map)
Сюрприз 2: какова, вы думаете, сложность std::forward_list::size()? Читайте статью
The Scoped Allocator Model
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2446.html
Это продолжение Omnibus Allocator Fix-up Proposals, которое я постил в предыдущий раз.
Как обычно, начинается прелестными словами "When allocators are allowed to have state"
Между тем, в текущем драфте все про аллокаторы по-старому
C++ Dynamic Library Support
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2425.html
к сожалению, это не для этого стандарта, но почитать уже есть что.
Как обычно, остался непроясненным вопрос взаимодействия разных компиляторов
Остальные статьи в основном представляют собой переработанные версии или wording (т.е. конкретные изменения в тексте Стандарта) уже существующих предложений.
Ну и на закуску:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2452.html — как у них происходят заседания
