августовская почта комитета (скроллируйте в самый низ страницы):
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/
Что интересно:
Текущее состояниее стандартизации:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2336.html (про язык)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2363.html (про библиотеку)
текущий драфт стардарта:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2369.pdf
предложение при остановке программы запускать еще одну функцию до уничтожения статических объектов, если хочется что-то с ними сделать (скажем, записать что-нть в файл):
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2383.html
сейчас это в общем случае сделать нельзя:
For an object with static storage duration constructed after a function is registered with atexit, then following the call to exit, the registered function is not called until the execution of the object’s destructor has completed.
т.е. всеми любимый синглтон Майерса идет лесом.
Предложение по ограничению using:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2386.pdf
Если сейчас заюзать std в каком-нть пространстве имен, а потом заюзать само это пространство, то std автоматически придет в комплекте. Иногда это нужно, иногда — нет.
Далее идут покушения на святое.
Предложение убить POD:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2342.htm
Вернее, разделить его его свойства на части — что считать binary compatible, что — trivial, и т.д.
Если примут — многие конструкции, которые не попадали под все требования ПОДов, попадут под определенные новые требования и с ними станет работать намного проще (например, появится возможность их двигать через memcpy.
Предложение убить (в смысле, тоже разобрать на части) точки следования:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2239.html
Это предложение не новое, но активно обсуждается, как и все, что связано с параллельностью:
Dynamic Initialization and Destruction with Concurrency:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2382.html
Concurrency memory model compiler consequences:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2338.html
Concurrency memory model (revised again):
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2334.htm
Memory Fences:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2362.html
C++ Atomic Types and Operations:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2381.html
Предложение поуправлять дефолтной генерацией разных вещей, которые генерятся/не генерятся сейчас сами:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm
Предложение разрешить задать инициализаторы по умолчанию для членов класса:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2354.htm
Атрибуты:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2379.pdf
Наследование конструкторов (включая конструкторы по умолчанию!):
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2376.html
Продолжается обсуждение auto:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2337.pdf
Надеюсь, они его успеют прояснить достаточно, чтоб нам не иметь потом с ним больших проблем
Несколько предложений касательно C++ Data-Dependency Ordering (на низком уровне):
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2359.html
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2360.html
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2361.html
