P>Тебе сложно один раз прочитать макрос и понять для чего он ? Ну так и будешь всю жизнь флажки копипастить.

мало придумать идею. Нужно придумать 10 идей и выбросить 9.

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

E>>>>4) А в многпоточном окружении это не работает просто фатально
P>>>А мне и не надо в многопоточном.
E>>>>5) Ну и тупо поле с флагом проще, понятнее, эффективнее и надёжнее.
P>>>Мне удобней вставить одно слово в функцию, чем заводить флажки и методы для них
V>>А мне нифига не удобней читать чужой г-код из-за того что кому-то стало неудобно заводить флажки и методы для них. Первое правило программиста — ты пишешь код не для себя! Ты его нарушил — поведение твоих коллег по отношение к тебе — UB! Намёк понятен?
P>Тебе сложно один раз прочитать макрос и понять для чего он ?
Нет, но причём здесь это? Твой макрос нифига не эквивалентен тому же самому флажку, но мало того что убожество, так ещё и баги вносит.

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

C>>"У каждой проблемы есть простое, красивое и неправильное решение" (с) Генри Менкен
P>Язык должен позволять создавать новые абстракции, называть их и пользоваться ими. Я просто попытался создать нужную
P>мне абстракцию на С++.
В данном случае, проблема не имеет правильного красивого решения (язык С++ ограничен в своей выразительной мощности). Но это не повод использовать неправильное.

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

C>Не поможет с реентарабельным кодом.

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

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

V>Стопудовая логика, код не понял — поставлю мютекс.

Это называется "привет, привет, гайзенбаг-дедлок!!!"

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

P>Тебе сложно один раз прочитать макрос и понять для чего он ? Ну так и будешь всю жизнь флажки копипастить.
Копипастить будешь не всю жизнь, а пока на С++ программировать не научишься...

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

P>>Тебе сложно один раз прочитать макрос и понять для чего он ? Ну так и будешь всю жизнь флажки копипастить.
C>"У каждой проблемы есть простое, красивое и неправильное решение" (с) Генри Менкен

В данном случае, тем не менее, оно НЕпростое и НЕкрасивое. Хотя с "НЕправильным" коллега таки попал

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

P>Язык должен позволять создавать новые абстракции, называть их и пользоваться ими. Я просто попытался создать нужную
P>мне абстракцию на С++.

Скорее на С...

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

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

Контролировать рекурсивность, первый вызов функции...

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

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

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

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

    virtual ~FrozenInit() {}

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

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

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

При этом, обрати внимание, что если объекты не передаются между нитями, то оно сразу MT-ready, надёжно работает, НЕ ТРАТИТ времени на вызов, если он не нужен, ну и на поиски в массивах тоже. Ну и вообще работоспособно, корректно и читабельно.
С++ довольно мощный язык, и свои мысли можно выражать на нём ПРЯМО.

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

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

E>>3) Это не работает в обычном случае
P>Почему же нет. Можешь проверить.
Я привёл тебе пример простого случая, когда оно не работает. Цайберакс привёл другой пример на ту же тему.
Но вот тебе случай повеселее, добавь к своему примеру

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

} ups_ups;

E>>4) А в многпоточном окружении это не работает просто фатально
P>А мне и не надо в многопоточном.
Беда тут в том, что и читабельность и другие кондиции кода нужны, если код живёт промышленной жизнью, развивается, поддерживается и всё такое. При такой жизни код часто меняет программиста. Ну и вообще часто есть плод коллективных усилий. А при таких делах, легко может внезапно понадобиться MT, и просто забесплатно отказываться от него -- глупо...

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

E>>Для просветления советую помедитировать над кодом:

E>>void ups()
E>>{
E>>    Temp t;
E>>    t.f();
E>>}

E>>int main(int argc, char* argv[])
E>>{
E>>    for( int i = 0; i < 10; i++ ) {
E>>        ups();
E>>    }
E>>    return 0;
E>>}
E>>

P>И что здесь не так?

Ну ты подумай, попробуй исполнить и всё такое...

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

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

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

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

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

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

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

Формально ты, конечно прав, но на самом деле, это не переменная никакая, а литерал так просто оформлен...

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

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

P>>>>Я,к примеру, реализую семантику "заморозки" метода после первого вызова с помощью static.
E>>>А зачем это вообще надо? Кроме того, ТС написал, что ему не надо хранить контекст между вызовами.
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>С++ довольно мощный язык, и свои мысли можно выражать на нём ПРЯМО.
Вот-вот. И где же ты тут выразил свою мысль прямо ? Допустим, ты пишешь модификатор доступа const в объявлении метода. Одно слово.
И всем сразу понятно, что ты хотел этим сказать. Теперь представь, что нет в плюсах const. Не замучаешься с флажками ?
С++ — ограниченный язык, потому что нельзя сотворить такое:

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

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


E>>>3) Это не работает в обычном случае
P>>Почему же нет. Можешь проверить.
E>Я привёл тебе пример простого случая, когда оно не работает. Цайберакс привёл другой пример на ту же тему.
E>Но вот тебе случай повеселее, добавь к своему примеру

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

E>} ups_ups;

E>>>4) А в многпоточном окружении это не работает просто фатально
P>>А мне и не надо в многопоточном.
E>Беда тут в том, что и читабельность и другие кондиции кода нужны, если код живёт промышленной жизнью, развивается, поддерживается и всё такое. При такой жизни код часто меняет программиста. Ну и вообще часто есть плод коллективных усилий. А при таких делах, легко может внезапно понадобиться MT, и просто забесплатно отказываться от него -- глупо...

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

E>>>Для просветления советую помедитировать над кодом:

E>>>void ups()
E>>>{
E>>>    Temp t;
E>>>    t.f();
E>>>}

E>>>int main(int argc, char* argv[])
E>>>{
E>>>    for( int i = 0; i < 10; i++ ) {
E>>>        ups();
E>>>    }
E>>>    return 0;
E>>>}
E>>>

P>>И что здесь не так?

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

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

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

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

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

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

J>статик зло и нет ему оправдания
J>(не рассматривая случаи (как например ваш) когда он only read но это скорее исключение)

Почему это, не рассматривая? И даже если не рассматривая, так ты эту оговорку-то сразу делай, а не заявляй огульно про все "статик внутри функции".

И кстати, read-only не всегда снимает проблему.

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

E>Формально ты, конечно прав, но на самом деле, это не переменная никакая, а литерал так просто оформлен...

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

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

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

В смысле, вместо того, чтобы узнать, когда использование статических локальных переменных безопасно, и когда нет, проще наложить на себя обет не использовать их вообще?

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

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

ps если вам хочется потролить то вы мимо

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

J>потому что любой практик а не теоретик понимает что read only не попадало под рассмотрение так как юзается в одном проценте из ста так вам понятней ?

Я read-only переменные использую чаще чем не read-only.

J>это вообще не в тему

Это все же где-то в тему, поскольку немаловероятно, что кое-кто думает, что использование read-only static local переменных никогда не ведет к проблемам, к которым ведет использование не read-only static local переменных. А это не так.

J>это вообще полный финиш значит из за 1 процента read only статик перменных вы согласны признать статик не всегда злом и полагаете что это просто от недопонимания

Отнюдь не 1 процент.