Драфт стандарта, п. 6.7.4:

The zero-initialization (8.5) of all block-scope variables with static storage duration (3.7.1) or thread storage
duration (3.7.2) is performed before any other initialization takes place. Constant initialization (3.6.2) of a
block-scope entity with static storage duration, if applicable, is performed before its block is first entered.
An implementation is permitted to perform early initialization of other block-scope variables with static or
thread storage duration under the same conditions that an implementation is permitted to statically initialize
a variable with static or thread storage duration in namespace scope (3.6.2). Otherwise such a variable is
initialized the first time control passes through its declaration; such a variable is considered initialized upon
the completion of its initialization. If the initialization exits by throwing an exception, the initialization
is not complete, so it will be tried again the next time control enters the declaration. If control enters
the declaration concurrently while the variable is being initialized, the concurrent execution shall wait for
completion of the initialization. If control re-enters the declaration recursively while the variable is being
initialized, the behavior is undefined.

Выделение моё. Исправлена очевидная ошибка предыдущего стандарта, одними граблями меньше. Следующий синглтон в новом стандарте потокобезопасен!

struct Singleton {
  static Singleton& instance() {
    static Singleton res; // всегда инициализируется корректно
    return res;
  }
}

Кстати, gcc 4.x++ уже это делает, в смысле потокобезопасную инициализацию локальных статических членов. И это может приводить к неожиданным дедлокам. Новый стандарт не регламентирует, как нужно обеспечивать синхронизацию, а просто предостерегает от рекурсии. Будьте внимательны!

Ура!

Здравствуйте, Kolobrodin, Вы писали:

K>

K>Ура!

А я вот не знаю, радоваться или нет. С одной стороны, это, конечно удобно — в большинстве случаев — избавляет от необходимости реализовывать закат солнца вручную. С другой — это встраивание в язык прикладного уровня. Нарушается принцип "не платить за то, что не используешь", С++ становится более высокоуровневым (менее низкоуровневым) и приближается к "языкам со встроенными памперсами", как тут когда-то метко выразились

Здравствуйте, rg45, Вы писали:

R> С++ становится более высокоуровневым (менее низкоуровневым) и приближается к "языкам со встроенными памперсами"

В gcc эта синхронизация отключается ключами, спасибо разработчикам, подумавшим об огромной массе программ, где не нужно этих заморочек.

С другой стороны, предыдущее поведение было явной засадой. От статической переменной, хоть и локальной, как-то не ожидаешь подвоха в конкурентном окружении.

Здравствуйте, rg45, Вы писали:

R>А я вот не знаю, радоваться или нет. С одной стороны, это, конечно удобно — в большинстве случаев — избавляет от необходимости реализовывать закат солнца вручную. С другой — это встраивание в язык прикладного уровня. Нарушается принцип "не платить за то, что не используешь", С++ становится более высокоуровневым (менее низкоуровневым) и приближается к "языкам со встроенными памперсами", как тут когда-то метко выразились

С другой стороны, на счет потокобезопасного new никто почему-то не возмущается.

Здравствуйте, andrey_nado, Вы писали:

_>С другой стороны, предыдущее поведение было явной засадой. От статической переменной, хоть и локальной, как-то не ожидаешь подвоха в конкурентном окружении.

Ну это до первой встречи с рукояткой граблей

Здравствуйте, rg45, Вы писали:

R>А я вот не знаю, радоваться или нет. С одной стороны, это, конечно удобно — в большинстве случаев — избавляет от необходимости реализовывать закат солнца вручную. С другой — это встраивание в язык прикладного уровня. Нарушается принцип "не платить за то, что не используешь", С++ становится более высокоуровневым (менее низкоуровневым) и приближается к "языкам со встроенными памперсами", как тут когда-то метко выразились

Настоящего плюсовика уже ничего не обрадует, что ни предлагай.
Пытливый ум обязательно да увидит потенциальные возможности получить крэш-дамп или
дедлок из невинной конструкции в три строки.

Думаю, что хуже не будет, потому что статических объектов все равно обычно мало и они
инициализируются однократно. То есть, на такие микроскопические потери внимания обращать не стоит.

Здравствуйте, Тот кто сидит в пруду, Вы писали:

ТКС>С другой стороны, на счет потокобезопасного new никто почему-то не возмущается.

Не хочу показаться занудой, но разве потокобезопасная имплементация new/delete в
стандарте (ISO/IEC 1998,2003) упоминается ?

Здравствуйте, andrey_nado, Вы писали:

_>Драфт стандарта, п. 6.7.4:

_>The zero-initialization (8.5) of all block-scope variables with static storage duration (3.7.1) or thread storage
_>duration (3.7.2) is performed before any other initialization takes place. Constant initialization (3.6.2) of a
_>block-scope entity with static storage duration, if applicable, is performed before its block is first entered.
_>An implementation is permitted to perform early initialization of other block-scope variables with static or
_>thread storage duration under the same conditions that an implementation is permitted to statically initialize
_>a variable with static or thread storage duration in namespace scope (3.6.2). Otherwise such a variable is
_>initialized the first time control passes through its declaration; such a variable is considered initialized upon
_>the completion of its initialization. If the initialization exits by throwing an exception, the initialization
_>is not complete, so it will be tried again the next time control enters the declaration. If control enters
_>the declaration concurrently while the variable is being initialized, the concurrent execution shall wait for
_>completion of the initialization. If control re-enters the declaration recursively while the variable is being
_>initialized, the behavior is undefined.

Ыыы... Откуда concurrent execution? Так в C++ же потоков(которые thread) нет! Прямо как секса в СССР.

Здравствуйте, cpp-coder, Вы писали:

CC>Ыыы... Откуда concurrent execution? Так в C++ же потоков(которые thread) нет! Прямо как секса в СССР.
<thread>

Здравствуйте, cpp-coder, Вы писали:

CC>Ыыы... Откуда concurrent execution? Так в C++ же потоков(которые thread) нет! Прямо как секса в СССР.

Уже есть

Здравствуйте, баг, Вы писали:

баг>Здравствуйте, cpp-coder, Вы писали:

CC>>Ыыы... Откуда concurrent execution? Так в C++ же потоков(которые thread) нет! Прямо как секса в СССР.
баг><thread>
Мда... Почитаю матчасть как-нибудь. Жаль, что на нашем проекте не предвидится использование C++0x в обозримом будущем

Здравствуйте, okman, Вы писали:

O>Не хочу показаться занудой, но разве потокобезопасная имплементация new/delete в
O>стандарте (ISO/IEC 1998,2003) упоминается ?
ох, ну нет ведь там потоков (threads)
конечно, не упоминается

Здравствуйте, rg45, Вы писали:

R>Здравствуйте, Kolobrodin, Вы писали:

K>>

K>>Ура!

R>А я вот не знаю, радоваться или нет. С одной стороны, это, конечно удобно — в большинстве случаев — избавляет от необходимости реализовывать закат солнца вручную. С другой — это встраивание в язык прикладного уровня.

Оверхед тут почти никакой.
Проверили флаг, если в состоянии "уже" — ничего не делаем, используем переменную, нужен только один барьер для синхронизации.
Это для объектов с инициализацией, которая что-то делает. Для объектов вроде static int i = 0; оверхеда вообще нет, мы получаем полезную гарантию бесплатно.

Зато выгоды очевидны.

Во-первых не всем известно, что статики в текущем стандарте небезопасны. Точнее даже не так. Стандарт "не знающий" про потоки такое не описывает. Но есть некоторые ожидания, например ожидают от STL, что модификация разных контейнеров одновреенно в разных потоках безопасна, а одновременное чтение безопасно даже для одного контейнера. Так вот, покотобезопасность статиков может быть таким же логичным ожиданием. Я бы назвал поведение MSVC, при котором несколько флагов инициализации статиков пакуются в одну переменную, и эта переменная проверяется модифицируется неатомарно и устанавливается до фактической инициализации — преждевременной оптимизацией.

Во-вторых, всё сделать правильно может быть нетривиально. В конечном итоге, нужна глобальная переменная со статической инициализацией, потому что порядок динамической инициализации неопределён. В Windows до Vista нет объектов синхронизации, обходящихся статической синхронизацией. Т.е. по-любому нужны атомарные операции.

В третьих, если проблема со static'ом известна, и есть boost::call_once, использование такого решения вносит синтаксический оверхед. Надо объявить once_flag, именно глобальной переменной (или статическим членом класа), надо вынести инициализацию так, чтобы она была параметром boost::call_once.

Здравствуйте, breee breee, Вы писали:

BB>Здравствуйте, cpp-coder, Вы писали:

CC>>Ыыы... Откуда concurrent execution? Так в C++ же потоков(которые thread) нет! Прямо как секса в СССР.

BB>Уже есть

Нету
Есть только в проекте.
Зачали — не значит, что родили.
Не понял какого хрена тут чуваку минусов понаставили.