Здравствуйте, Аноним, Вы писали:

А>Подскажите в каком случае выгодно добавлять static к временной локальной переменной в функции?
А>Чтобы она не создавалась каждый раз на стеке(хранить состояние между вызовами не нужно)

Не совсем ответ на этот вопрос, но вот что написал Matthew Wilson в книге Imperfect C++:

11.3 Function-Local Static Objects

. . .

Imperfection: Function-local static instances of classes with nontrivial constructors are not thread-safe.

Другой проблемный случай рассмотрен в стандарте:

6.7 Declaration statement [stmt.dcl]

. . .

4 . . . If control re-enters the declaration (recursively) while the object is being initialized, the behavior
is undefined. [Example:

int foo(int i)
{
    static int s = foo(2*i); // recursive call – undefined
    return i+1;
}

—end example]

Здравствуйте, Аноним, Вы писали:

А>Подскажите в каком случае выгодно добавлять static к временной локальной переменной в функции?

1. Когда нужно хранить состояние. Например, при кэшировании результатов вычислений.
2. Для объявления read-only констант внутри функции. В случае со static не тратится время на инициализацию констант каждый раз при входе в функцию.
3. В специфичных условиях, когда нужно экономить стек. Например, в микроконтроллерах, если большая глубина вложенности вызовов.

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


А>>привет
А>>Подскажите в каком случае выгодно добавлять static к временной локальной переменной в функции?
А>>Чтобы она не создавалась каждый раз на стеке(хранить состояние между вызовами не нужно)
J>статик внутри функции это всегда непереносимая функция какашка годная только для одного проекта и специфического контекста несовместимая с многопоточностью вообщем это плохо этого надо избегать при любой возможности хорошие мобильные и реентабельные функции не должны обращатся к глобальнывм данным к этому надо стремится в идеале

Про знаки препинания слышал?

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

I>"Формально" это и есть единственное, что считается. Мы же про программирование, а не про жизнь и про любовь.
Главная беда, что это не особо полезно. "формально" тут значит "ничего не даёт по сути", ну почти ничего...

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

I>Я read-only переменные использую чаще чем не read-only.
Йо! И они часто static?..
Можно узнать, зачем?

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

P>>>Допустим, есть виртуальный метод инициализации. Он должен быть вызван для объекта один раз.
P>>>Я знаю, что это ужасно выглядит для макрофобов. Скажи как мне по другому объявить такую семантику.

E>>Ну, например, NVI интерфейс инициализации в базе...
E>>

class FrozenInit {
E>>public:
E>>    bool Init()
E>>    {
E>>        if( isInited ) {
E>>            return false;
E>>        }
E>>        //  Тут можно добвать поддержку многопоточности, если надо.
E>>        isInited = true;
E>>        DoFrozenInit();
E>>        return true;
E>>    }
E>>protected:
E>>    FrozenInit() : isInited( false ) {}
E>>    FrozenInit( const FrozenInit& ) : isInited( false ) {} // или какая там у тебя семантика?
E>>    void operator = ( const FrozenInit& ) {}

E>>    virtual ~FrozenInit() {}

E>>    virtual void DoFrozenInit() = 0;
E>>private:
E>>    bool isInited;
E>>};

E>>//  Пример использования:
E>>class Test : public FrozenInit {
E>>    void DoFrozenInit();
E>>public:
E>>    //  тут интерфейс класса... если надо, можешь явно упомянуть Init()
E>>};
E>>

E>>Если ты придумаешь, зачем иметь несколько "отмороженных" методов, то легко написать CRTP шаблон, который будет хранит много флажков в битиках одного слова...

E>>При этом, обрати внимание, что если объекты не передаются между нитями, то оно сразу MT-ready, надёжно работает, НЕ ТРАТИТ времени на вызов, если он не нужен, ну и на поиски в массивах тоже. Ну и вообще работоспособно, корректно и читабельно.
E>>С++ довольно мощный язык, и свои мысли можно выражать на нём ПРЯМО.
P>Вот-вот. И где же ты тут выразил свою мысль прямо ? Допустим, ты пишешь модификатор доступа const в объявлении метода. Одно слово.
P>И всем сразу понятно, что ты хотел этим сказать. Теперь представь, что нет в плюсах const. Не замучаешься с флажками ?
Вообще не будет флажков. Будет два интерфейса к классу. Для r\o доступа и для полного.

P>С++ — ограниченный язык, потому что нельзя сотворить такое:

P>

P>class SomeClass {
P>public:
P>void someFunction() const, frozen, logable, busy {
P>//logable пишет что-то в лог о входе/выходе в функцию
P>//busy показывает "песочные часы"
P>}
P>};
P>

Это будет какой-то другой язык.
Ты, кстати, так тоже не смог.
Но в С++ такого рода свойства принято выражать наследованием.
Типа class SomeClass : public FrozenInit {
virtual void DoFrozenInit() { ... }
};

E>>Хочешь -- устрой тут голосовалку
E>>Но, я обращу твоё внимание, что ты показал этот код с багой, которую САМ И НЕ ЗАМЕТИЛ...
Так голосовалку ты устроил, или и так признал, что твой вариант нечитабельный?

E>>>>2) Это UB
P>Думаю, возможно. Будет время, подумаю над этим.
Тут есть такая беда, что надо как-то умирающие объекты вымарывать из списка. При этом даже умершие без вызова деструктора...

E>>Но вот тебе случай повеселее, добавь к своему примеру

static class SuperTemp : public Temp {
E>>public:
E>>    SuperTemp() { f(); }
E>>    ~SuperTemp() { f(); }

E>>} ups_ups;

Так ты проверил, что получается с таким кодом-то?

E>>>>5) Ну и тупо поле с флагом проще, понятнее, эффективнее и надёжнее.
P>>>Мне удобней вставить одно слово в функцию, чем заводить флажки и методы для них
E>>А вариант с базой тебе как?
P>Не нравится. Многословно.
Что многословно? Идея "запускать один раз на один объект" там выражена прямо. Код простой, клиентский код минимальный...

P>>>И что здесь не так?
E>>Ну ты подумай, попробуй исполнить и всё такое...
P>Объект Temp создается на стеке по одному и тому же адресу...Понятно.
P>У меня в реальной программе немного другое макроопределение. Оно на Qt и выдерживает этот тест.
P>Пока не буду его приводить.
Что-то, как-то верится с трудом...

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

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

P>>>>Допустим, есть виртуальный метод инициализации. Он должен быть вызван для объекта один раз.
P>>>>Я знаю, что это ужасно выглядит для макрофобов. Скажи как мне по другому объявить такую семантику.

E>>>Ну, например, NVI интерфейс инициализации в базе...
E>>>

class FrozenInit {
E>>>public:
E>>>    bool Init()
E>>>    {
E>>>        if( isInited ) {
E>>>            return false;
E>>>        }
E>>>        //  Тут можно добвать поддержку многопоточности, если надо.
E>>>        isInited = true;
E>>>        DoFrozenInit();
E>>>        return true;
E>>>    }
E>>>protected:
E>>>    FrozenInit() : isInited( false ) {}
E>>>    FrozenInit( const FrozenInit& ) : isInited( false ) {} // или какая там у тебя семантика?
E>>>    void operator = ( const FrozenInit& ) {}

E>>>    virtual ~FrozenInit() {}

E>>>    virtual void DoFrozenInit() = 0;
E>>>private:
E>>>    bool isInited;
E>>>};

E>>>//  Пример использования:
E>>>class Test : public FrozenInit {
E>>>    void DoFrozenInit();
E>>>public:
E>>>    //  тут интерфейс класса... если надо, можешь явно упомянуть Init()
E>>>};
E>>>

E>>>Если ты придумаешь, зачем иметь несколько "отмороженных" методов, то легко написать CRTP шаблон, который будет хранит много флажков в битиках одного слова...

E>>>При этом, обрати внимание, что если объекты не передаются между нитями, то оно сразу MT-ready, надёжно работает, НЕ ТРАТИТ времени на вызов, если он не нужен, ну и на поиски в массивах тоже. Ну и вообще работоспособно, корректно и читабельно.
E>>>С++ довольно мощный язык, и свои мысли можно выражать на нём ПРЯМО.
P>>Вот-вот. И где же ты тут выразил свою мысль прямо ? Допустим, ты пишешь модификатор доступа const в объявлении метода. Одно слово.
P>>И всем сразу понятно, что ты хотел этим сказать. Теперь представь, что нет в плюсах const. Не замучаешься с флажками ?
E>Вообще не будет флажков. Будет два интерфейса к классу. Для r\o доступа и для полного.
Это как ?

P>>С++ — ограниченный язык, потому что нельзя сотворить такое:

P>>

P>>class SomeClass {
P>>public:
P>>void someFunction() const, frozen, logable, busy {
P>>//logable пишет что-то в лог о входе/выходе в функцию
P>>//busy показывает "песочные часы"
P>>}
P>>};
P>>

E> Это будет какой-то другой язык.
E>Ты, кстати, так тоже не смог.
E>Но в С++ такого рода свойства принято выражать наследованием.
E>Типа class SomeClass : public FrozenInit {
E> virtual void DoFrozenInit() { ... }
E>};
Если мне произвольный метод произвольного класса нужно "заморозить", как тут наследование поможет?

E>>>Хочешь -- устрой тут голосовалку
E>>>Но, я обращу твоё внимание, что ты показал этот код с багой, которую САМ И НЕ ЗАМЕТИЛ...
E>Так голосовалку ты устроил, или и так признал, что твой вариант нечитабельный?
То что бажный, признаю. Но нечитабельный скорее твой вариант.
E>>>>>2) Это UB
P>>Думаю, возможно. Будет время, подумаю над этим.
E>Тут есть такая беда, что надо как-то умирающие объекты вымарывать из списка. При этом даже умершие без вызова деструктора...

E>>>Но вот тебе случай повеселее, добавь к своему примеру

static class SuperTemp : public Temp {
E>>>public:
E>>>    SuperTemp() { f(); }
E>>>    ~SuperTemp() { f(); }

E>>>} ups_ups;

E>Так ты проверил, что получается с таким кодом-то?
Ладно, верю)

E>>>>>5) Ну и тупо поле с флагом проще, понятнее, эффективнее и надёжнее.
P>>>>Мне удобней вставить одно слово в функцию, чем заводить флажки и методы для них
E>>>А вариант с базой тебе как?
P>>Не нравится. Многословно.
E>Что многословно? Идея "запускать один раз на один объект" там выражена прямо. Код простой, клиентский код минимальный...
Это же каждый раз надо такое писать. Я хочу идею "заморозки" зафиксировать одним словом. В определении или лучше в объявлении.

P>>>>И что здесь не так?
E>>>Ну ты подумай, попробуй исполнить и всё такое...
P>>Объект Temp создается на стеке по одному и тому же адресу...Понятно.
P>>У меня в реальной программе немного другое макроопределение. Оно на Qt и выдерживает этот тест.
P>>Пока не буду его приводить.
E>Что-то, как-то верится с трудом...

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

E>Йо! И они часто static?..
E>Можно узнать, зачем?

Можно. Статические переменные как и переменные вообще у меня чаще read-only чем не read-only. Или ты юродствуешь просто?

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

E>>Йо! И они часто static?..
E>>Можно узнать, зачем?

I>Можно. Статические переменные как и переменные вообще у меня чаще read-only чем не read-only. Или ты юродствуешь просто?

Это не ответ на вопрос "зачем".
Вопрос же конкретный стоит, про static in function, которые сами по себе редко нужны.
Зачем константы, объявленные в функции делать статическими? Пример какой-нибудь кода, можешь привести?

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

E>>>>Если ты придумаешь, зачем иметь несколько "отмороженных" методов, то легко написать CRTP шаблон, который будет хранит много флажков в битиках одного слова...

E>>Вообще не будет флажков. Будет два интерфейса к классу. Для r\o доступа и для полного.
P>Это как ?

Ну посмотри на std::list<int>::iterator и std::list<int>::const_iterator, например.
На самом деле, новации -- это хорошо, но чтобы новации были хорошими, лучше сначала изучить язык, и уже накопленный опыт.

E>>Но в С++ такого рода свойства принято выражать наследованием.
E>>Типа class SomeClass : public FrozenInit {
E>> virtual void DoFrozenInit() { ... }
E>>};
P>Если мне произвольный метод произвольного класса нужно "заморозить", как тут наследование поможет?

Ты вот оставил очень большой рверквотинг, которого тут очень не любят, но так и не прочитал его внимательно при этом. Я же писал тебе, что через CRTP-шаблон удобно будет сделать. Только мне не понятна сама по себе идея "заморозить" произвольный метод произвольного класса. Зачем это вообще надо-то?
Я не случайно спрашиваю "зачем надо", потому, что для всех сколько-нибудь реально востребованных сценариев в С++ уже давно что-то предложено. Либо есть одно хорошее, либо есть есть много с ограничениями всякими. Но какие-то варианты, кроме "индусского копи-паста" есть всегда. Поэтому поясни юзкейс, а я или кто-то ещё из тутошних завсегдатаев попробуем предложить вариант решения.

P> То что бажный, признаю. Но нечитабельный скорее твой вариант.
Ну так устрой голосовалку. "Нечетабельный" -- это очень просто. Это если берёшь 100 прогеров средней квалификации, которые не в теме задачи, но знают язык и стандартный инструментарий и смотрим процент прогеров, который разберётся за минуту на кило кода, например, или среднее время и т. д.
В общем суть в том, что нечетабельный код сильно сопротивляется усилиям посторонних вникнуть. Обычно это сильно мешает поддержке.
Так что, если ты считаешь, что твои макросы с точкой с запятой в качестве параметра читабельны, то устрой таки голосовалку.
Хорошим признаком читабельности было бы такое решение, что прочитав клиентский код не возникло бы желания лезть в определение макроса...

P>Ладно, верю)
В общем, как ни жаль, но подход плох по многим направлениям. Хранить флаг в объекте метода намного прямее, чем в статическом ассациативном контейнере...

P>Это же каждый раз надо такое писать. Я хочу идею "заморозки" зафиксировать одним словом. В определении или лучше в объявлении.

А зачем базу писать много раз? Её можно переиспользовать.
Ну, в конце концов, если ты так любишь макросы, то пока не разлюбил, можешь написать макрос, определяющий такую базу, например. Но надёжнее сделать не макрос, а шаблон, наверное.
Но, перед тем, как делать, хорошо бы понять цель. Так как не совсем понятно, что надо сделать. Например, если у метода есть возвращаемое значение, то что он должен вернуть, когда он уже заморозился?..

P>>>У меня в реальной программе немного другое макроопределение. Оно на Qt и выдерживает этот тест.
P>>>Пока не буду его приводить.
E>>Что-то, как-то верится с трудом...

Так как у тебя решается проблема создания разных объектов по одинаковым адресам-то?..

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

E>Зачем константы, объявленные в функции делать статическими? Пример какой-нибудь кода, можешь привести?

Так я же привел уже. Ну вот еще:

    static struct {
        char chr;
        char const* ref;
    } const char_ref[] = {
        { '<', "lt" },
        { '>', "gt" },
        { '&', "amp" },
        { '\'', "apos" },
        { '"', "quot" },
    };

Даже если и без слова static компилятор сможет соптимизировать инициализацию (сможет ли?), static еще и читающему программу говорит, что значение char_ref является общим для всех вызовов функции, в которой char_ref объявлена. (Слова const недостаточно, поскольку в списке инициализации могли быть использованы параметры или глобальные переменные.)

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

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

E>>Зачем константы, объявленные в функции делать статическими? Пример какой-нибудь кода, можешь привести?

I>Так я же привел уже. Ну вот еще:

I>

I>    static struct {
I>        char chr;
I>        char const* ref;
I>    } const char_ref[] = {
I>        { '<', "lt" },
I>        { '>', "gt" },
I>        { '&', "amp" },
I>        { '\'', "apos" },
I>        { '"', "quot" },
I>    };
I>

Зачем тебе отложенная инициализация этой таблички? и мьютекс впридачу. Место все равно выделяется там же где и глобальные. Я бы на ревью зарубил.

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

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

I>>"Формально" это и есть единственное, что считается. Мы же про программирование, а не про жизнь и про любовь.
E>Главная беда, что это не особо полезно. "формально" тут значит "ничего не даёт по сути", ну почти ничего...
вот как раз почти иногда и нужно.

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

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

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

J>>>я говорю про проблемы при попытке выполнить кукок кода несколько десятков функций
J>>>вызывающих друг друга сразу в нескольких потоках если там есть статики то
J>>>поимееш геморой...

I>>В общем случае это неверно, потому я и привел пример статической локальной переменной, не создающей проблем независимо от того, сколько там десятков или сотен вызывающих друг друга функций и тысяч потоков.
J>статик зло и нет ему оправдания
J>(не рассматривая случаи (как например ваш) когда он only read но это скорее исключение)
J>а не only read статики даже в заранее предполагаемой однопоточной
J>среде это связывание по рукам и ногам от распараллеливания
а если код не будет параллелиться? т.е. вообще не будет.
J>такого кода в будущем а ой как может понадобится хотя раньше и не думал
wtf ?
J>а чужому программисту распараллелить твой код со статиками полнейший геморой
беда-беда

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

SD>Зачем тебе отложенная инициализация этой таблички? и мьютекс впридачу.

Мне они не нужны, в данном случае компилятор вправе применить статическую инициализацию.

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

I>Мне они не нужны, в данном случае компилятор вправе применить статическую инициализацию.
Ну, это тот же пример, что и первый. Ты создаёшь некую предопределённую константную структуру в памяти, фактически литерал, но в коде функции пердставляешь её, как static in function константу, а не как-то ещё, попроще.
Ну вычурно записал простую вещь. Но смысл так извращаться от меня ускользает. А другие какие-нибудь примеры есть?
Или это всегда наследники COMMON DATA из FORTRAN?

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

E>Ну, это тот же пример, что и первый. Ты создаёшь некую предопределённую константную структуру в памяти, фактически литерал, но в коде функции пердставляешь её, как static in function константу, а не как-то ещё, попроще.
E>Ну вычурно записал простую вещь. Но смысл так извращаться от меня ускользает.

Где вычурность-то, в добавлении static? Смысл очевидно в сужении области видимости. Константы (как и функции, и типы) вовсе не обязательно объявлять как можно локальнее, иногда константу лучше сделать глобальной, даже если используется она в одном единственном месте, но иногда — нет. Для этого последнего случая можно воспользоваться static внутри функции или даже блока.

E>А другие какие-нибудь примеры есть? Или это всегда наследники COMMON DATA из FORTRAN?

Я других не знаю. Тем не менее заявления вроде "статик внутри функции это всегда непереносимая функция какашка" как бы относятся и к приведенным мной примерам, и скорые на расправу рубщики рубят ведь "на ревью", и локальные по сути константы болтаются потом в глобальной области видимости или еще где.

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

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

E>>>>>Если ты придумаешь, зачем иметь несколько "отмороженных" методов, то легко написать CRTP шаблон, который будет хранит много флажков в битиках одного слова...

E>>>Вообще не будет флажков. Будет два интерфейса к классу. Для r\o доступа и для полного.
P>>Это как ?

E>Ну посмотри на std::list<int>::iterator и std::list<int>::const_iterator, например.
E>На самом деле, новации -- это хорошо, но чтобы новации были хорошими, лучше сначала изучить язык, и уже накопленный опыт.
Но мне же нужен один метод, который должен быть константным. А что должен делать неконстантный его брат-близнец и зачем он нужен?


E>>>Но в С++ такого рода свойства принято выражать наследованием.
E>>>Типа class SomeClass : public FrozenInit {
E>>> virtual void DoFrozenInit() { ... }
E>>>};
P>>Если мне произвольный метод произвольного класса нужно "заморозить", как тут наследование поможет?

E>Ты вот оставил очень большой рверквотинг, которого тут очень не любят, но так и не прочитал его внимательно при этом. Я же писал тебе, что через CRTP-шаблон удобно будет сделать. Только мне не понятна сама по себе идея "заморозить" произвольный метод произвольного класса. Зачем это вообще надо-то?
E>Я не случайно спрашиваю "зачем надо", потому, что для всех сколько-нибудь реально востребованных сценариев в С++ уже давно что-то предложено. Либо есть одно хорошее, либо есть есть много с ограничениями всякими. Но какие-то варианты, кроме "индусского копи-паста" есть всегда. Поэтому поясни юзкейс, а я или кто-то ещё из тутошних завсегдатаев попробуем предложить вариант решения.

class Condom {
public:
enum {Xxl, Tiny}
bool use() enable_only_calls(1);
};
//...
Condom* xxl= CondomsCollection.get(Condom::Xxl);
if (xxl) {
xxl->use();
trash->utilize(xxl);
//bla-bla-bla
} else {
xxl= trash->get(Condom::Xxl);//
if (xxl) {
xxl->use(); //compile time (or run-time) error 'attempt to call frozen use() method'
}
}

Или, например:

class User {
public:
bool login() enable_only_calls(3);
};
//...
try {
while (!user->login())
user->getPassword();
}
catch(Exception &e) {
//only 3 attempts for login !!!
}

//Сравни с этим
for (int i=0; i<user.maxCountOfLoginAttempts(); ++i)
if (!user->login())
user->getPassword();
if (!user.logined())
return;

Ну и на кой мне тут сдалась переменная-индекс цикла ? Она меня вообще не интересует, но я вынужден её таки использовать.
Ещё метод maxCountOfLoginAttempts() дополнительно нужно заводить.

В Ruby ,например, можно "заморозить" весь объект
freeze (Ruby)

E>А зачем базу писать много раз? Её можно переиспользовать.
E>Ну, в конце концов, если ты так любишь макросы, то пока не разлюбил, можешь написать макрос, определяющий такую базу, например. Но надёжнее сделать не макрос, а шаблон, наверное.
E>Но, перед тем, как делать, хорошо бы понять цель. Так как не совсем понятно, что надо сделать. Например, если у метода есть возвращаемое значение, то что он должен вернуть, когда он уже заморозился?..
Default value

E>Так как у тебя решается проблема создания разных объектов по одинаковым адресам-то?..
Пока сам не разобрался. Разберусь — устрою голосовалку)

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

I>Я других не знаю. Тем не менее заявления вроде "статик внутри функции это всегда непереносимая функция какашка" как бы относятся и к приведенным мной примерам, и скорые на расправу рубщики рубят ведь "на ревью", и локальные по сути константы болтаются потом в глобальной области видимости или еще где.



нда какой же вы интересный человек вцепились в этот 1 процент юз кейса в качестве
статических констант
и не видите 99 процентов говна со статиками у меня очень редко статическая пермеменная в коде
я фактически сразу думаю о многопоточности и почти их не использую
а вот намного чаще пытался распараллелить свой и чужой код со статиками и приходилось
переделывать потому что писался он в расчете на однопоточное исполнение а мне нужно было его
параллельно запускать и сейчас часто вижу код со статиками инвалидный в многопоточной среде
а этот код выкладывают как примеры нате мол пользуйтесь а вы говорите статик хорошо
это костыли за очень редким исключением
даже ваш пример

static struct {
        char chr;
        char const *ref;
    } const char_ref[] = {
        { '<', "lt" },
        { '>', "gt" },
        { '&', "amp" },
        { '\'', "apos" },
        { '"', "quot" },
    };

чуть изменить и этот кусок и уже юзает флажок инвалидный в многопотоке
и что еще хуже C генерирует другой код там можно инитить только
константами и литералами и инититятся они до входа в main все статики а C++
флажки втыкает когда ему вздумается это уже огромный мотив чтоб не пользоватся
этим даже для инита const static переменных вот этот код будучи скомпилен
для C и для C++ на одном компиляторе cl.exe 15.0 генрирует разный код для C
генерируется потокобезопасный а для C++ инвалидный

static struct {
        char chr;
        char const ref[32];
    } const char_ref[] = {
        { '<', "lt" },
        { '>', "gt" },
        { '&', "amp" },
        { '\'', "apos" },
        { '"', "quot" },
    };

каким вы правилои руководствуетесь в этих двух примерах почему один инициализируется
в compile time а второй в run time ? фактически по стандарту C++ они оба инвалидны
там грится что при первом проходе локальный статик инится что фатально
в многопотоке а то что он примитивы в компайл там заинитил (первый пример) так это только
фича компилятора фактически же если не оптимизирует то два раза будет инициализироватся
этот костыль одноврмененно двумя потоками что тут хорошего если даже нет уверенности
когда он данные будет инитить и сколько раз и несовместим с C на базовом уровне
таком как инициализация массива литералами это же полный ахтунг

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

SD>>Зачем тебе отложенная инициализация этой таблички? и мьютекс впридачу.

I>Мне они не нужны, в данном случае компилятор вправе применить статическую инициализацию.
Жаль, конечно, что компилятору только дозволено сделать так, но его никто не обязывает:

4 The zero-initialization (8.5) of all local objects with static storage duration (3.7.1) is performed before any
other initialization takes place. A local object of POD type (3.9) with static storage duration initialized with
constant-expressions is initialized before its block is first entered. An implementation is permitted to perform
early initialization of other local objects with static storage duration under the same conditions that an
implementation is permitted to statically initialize an object with static storage duration in namespace scope
(3.6.2). Otherwise such an object is initialized the first time control passes through its declaration; such an
object is considered initialized upon the completion of its initialization.
[...]

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

Автор:
Дата: 04.11.04

(см. ответ Mr. None

Автор: Mr. None
Дата: 05.11.04

).