стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 05.09.07 12:24
Оценка: -1
Здравствуйте, Кодт, Вы писали:

E>>Например на мокрософтовском компиляторе такой вот код:

К>
 int plus( int arg )
E>>{
E>>    static const int seed = calc_seed();
E>>    return seed + arg;
E>>}
К>

E>>долгое время приводил к GP (АКА AV)

К>Ну, здесь-то явно баг компилятора. Зачем было класть в секцию констант объект, который инициализируется в рантайме?


Ну, вообще код типа этого — объявление статической переменной внутри функции, это потенциальный источник ошибок в мало — мальски обьемной программе. Это, наверное, не мое
дело, но думаю, что так писать код вообще не стоит.

11.09.07 20:06: Ветка выделена из темы Вопрос знатокам стандарта C++
Автор:
Дата: 04.09.07
— Павел Кузнецов
11.09.07 20:06: Ветка выделена из темы Вопрос знатокам стандарта C++ — Павел Кузнецов
Re: стиль: объявление статической переменной внутри функции
От: Erop Россия  
Дата: 05.09.07 12:27
Оценка:
Здравствуйте, dandy, Вы писали:

D>Ну, вообще код типа этого — объявление статической переменной внутри функции, это потенциальный источник ошибок в мало — мальски обьемной программе. Это, наверное, не мое

D>дело, но думаю, что так писать код вообще не стоит.

Чего?
Тебе кажется, что так писать не стоит?
double foo( double x )
{
    static const sin_pi_6 = sin( pi / 6 );
    return use_it( sin_pi_6, x );
}


А почему?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re: стиль: объявление статической переменной внутри функции
От: igna Россия  
Дата: 05.09.07 12:36
Оценка:
Здравствуйте, dandy, Вы писали:

D>Ну, вообще код типа этого — объявление статической переменной внутри функции, это потенциальный источник ошибок в мало — мальски обьемной программе. Это, наверное, не мое дело, но думаю, что так писать код вообще не стоит.


Приведи пример, пожалуйста, где стоит объявлять статическую переменную?
Re[2]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 05.09.07 13:03
Оценка:
Здравствуйте, Erop, Вы писали:

E>Чего?

E>Тебе кажется, что так писать не стоит?
double foo( double x )
E>{
E>    static const sin_pi_6 = sin( pi / 6 );
E>    return use_it( sin_pi_6, x );
E>}


E>А почему?


Потому что код получается нечитаемый. Если эта переменная употребляется только в одной функции, то модификатор static вообще не нужен (и просто вреден). Если у вас есть желание объявить и тут же проинициализировать глобальную переменную, то лучше всего сделать это там, где ее проще всего найти, то есть после директив препроцессора. Если нужно несколько похожих значений, то лучше было бы что — то вроде.

class CSinus
{
public:
static const double
_pi_6,
_pi_4,
_pi_3;
};

const double CSinus::_pi_3 = sin( pi / 3 );
const double CSinus::_pi_4 = sin( pi / 4 );
const double CSinus::_pi_6 = sin( pi / 6 );

Но тут может быть много вариаций. И у компилятора такой код протестов не вызовет.
Re[2]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 05.09.07 13:12
Оценка:
Здравствуйте, igna, Вы писали:

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


D>>Ну, вообще код типа этого — объявление статической переменной внутри функции, это потенциальный источник ошибок в мало — мальски обьемной программе. Это, наверное, не мое дело, но думаю, что так писать код вообще не стоит.


I>Приведи пример, пожалуйста, где стоит объявлять статическую переменную?


Увы, такого не попадалось.
Re[3]: стиль: объявление статической переменной внутри функции
От: Erop Россия  
Дата: 05.09.07 13:32
Оценка:
Здравствуйте, dandy, Вы писали:

D>const double CSinus::_pi_3 = sin( pi / 3 );

D>const double CSinus::_pi_4 = sin( pi / 4 );
D>const double CSinus::_pi_6 = sin( pi / 6 );

D>Но тут может быть много вариаций. И у компилятора такой код протестов не вызовет.


Тут будут всякие косяки с порядком инициализации. А ещё константа может иметь смысл только в рамках функции...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[3]: стиль: объявление статической переменной внутри функции
От: Erop Россия  
Дата: 05.09.07 13:33
Оценка:
Здравствуйте, dandy, Вы писали:

D>>>Ну, вообще код типа этого — объявление статической переменной внутри функции, это потенциальный источник ошибок в мало — мальски обьемной программе. Это, наверное, не мое дело, но думаю, что так писать код вообще не стоит.

I>>Приведи пример, пожалуйста, где стоит объявлять статическую переменную?
D> Увы, такого не попадалось.

тут что-то не так...
Автор: dandy
Дата: 05.09.07
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[4]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 05.09.07 13:41
Оценка:
Здравствуйте, Erop, Вы писали:


E>Тут будут всякие косяки с порядком инициализации.


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

E>А ещё константа может иметь смысл только в рамках функции...


Ну если навсегда только одна эта константа и только в одной этой функции... Но как — то странно это.
Re[5]: стиль: объявление статической переменной внутри функции
От: Erop Россия  
Дата: 05.09.07 13:51
Оценка:
Здравствуйте, dandy, Вы писали:

E>>А ещё константа может иметь смысл только в рамках функции...

D>Ну если навсегда только одна эта константа и только в одной этой функции... Но как — то странно это.
А что, ты никогда сложные вычислительные функции не писал?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[5]: стиль: объявление статической переменной внутри функции
От: Erop Россия  
Дата: 05.09.07 13:52
Оценка:
Здравствуйте, dandy, Вы писали:

E>>Тут будут всякие косяки с порядком инициализации.

D>Код инициализации в этом случае выполняется при запуске программы. Можно поподробнее про косяки?
Ну представь себе, что sin не всегда посчитать можно, а только после инициализации какого-нибудь статическогообъекта...
Функции-то разные бывают. Бывают и сложные...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 05.09.07 14:06
Оценка:
Здравствуйте, Erop, Вы писали:

E>Ну представь себе, что sin не всегда посчитать можно, а только после инициализации какого-нибудь статическогообъекта...

E>Функции-то разные бывают. Бывают и сложные...

Если так, то понятнее было бы сделать эту переменную глобальной нестатической а инициализировать ее сразу после инициализации этого "какого-нибудь статического объекта..." если хотите сэкономить каплю времени. Если несколько тактов процессора некритично, то почему бы не сделать эту переменную локальной?
Re[7]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 05.09.07 14:15
Оценка: :)
Здравствуйте, dandy, Вы писали:

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


E>>Ну представь себе, что sin не всегда посчитать можно, а только после инициализации какого-нибудь статическогообъекта...

E>>Функции-то разные бывают. Бывают и сложные...

D>Если так, то понятнее было бы сделать эту переменную глобальной нестатической а инициализировать ее сразу после инициализации этого "какого-нибудь статического объекта..." если хотите сэкономить каплю времени. Если несколько тактов процессора некритично, то почему бы не сделать эту переменную локальной?


Одно нехорошо — для первого случая опять же придется писать оберточный класс.
Re[7]: стиль: объявление статической переменной внутри функции
От: Erop Россия  
Дата: 05.09.07 14:15
Оценка:
Здравствуйте, dandy, Вы писали:

D>Если так, то понятнее было бы сделать эту переменную глобальной нестатической а инициализировать ее сразу после инициализации этого "какого-нибудь статического объекта..." если хотите сэкономить каплю времени. Если несколько тактов процессора некритично, то почему бы не сделать эту переменную локальной?


А если не несколько тактов?
И что делать с тем, что этот коэффициент не имеет смысла вне функции?

И главное, в чём смысл этой бескомпромиссной борьбы со статическими в функциях числами?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[8]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 05.09.07 14:36
Оценка:
Здравствуйте, Erop, Вы писали:

E>А если не несколько тактов?

А сколько времени нужно процессору, чтобы выделить память под
automatic const double
? Возможно мне что — то непонятно?

E>И что делать с тем, что этот коэффициент не имеет смысла вне функции?


В класс их завернуть... И функцию, и коэффициенты.

E>И главное, в чём смысл этой бескомпромиссной борьбы со статическими в функциях числами?


Не видел кода этой программы, но, насколько мог вас понять, что — то в этом роде приходилось дебажить. Занятие не для слабонервных.
Re[3]: стиль: объявление статической переменной внутри функции
От: igna Россия  
Дата: 05.09.07 14:42
Оценка: +1
Здравствуйте, dandy, Вы писали:

I>>Приведи пример, пожалуйста, где стоит объявлять статическую переменную?


D> Увы, такого не попадалось.


За сколько лет программирования на C++?
Re[9]: стиль: объявление статической переменной внутри функции
От: Erop Россия  
Дата: 05.09.07 14:46
Оценка:
Здравствуйте, dandy, Вы писали:

D>А сколько времени нужно процессору, чтобы выделить память под
automatic const double
D>
? Возможно мне что — то непонятно?


Время занимает конечно не выдлеение памяти под число, а его вычисление...

E>>И что делать с тем, что этот коэффициент не имеет смысла вне функции?

D>В класс их завернуть... И функцию, и коэффициенты.

Ну в класс завернуть идея хорошая. Но дальше-то что делать? Опять начнутся проблемы с порядком инициализации?

E>>И главное, в чём смысл этой бескомпромиссной борьбы со статическими в функциях числами?


D>Не видел кода этой программы, но, насколько мог вас понять, что — то в этом роде приходилось дебажить. Занятие не для слабонервных.


Ну что-то считаем. Константы, которые вычисляются долго и нами кэшируем при помощи статических в функциях переменных. В чём вред такого подхода --
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[10]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 05.09.07 15:01
Оценка:
Здравствуйте, Erop, Вы писали:

E>Время занимает конечно не выдлеение памяти под число, а его вычисление...

E>Ну в класс завернуть идея хорошая. Но дальше-то что делать? Опять начнутся проблемы с порядком инициализации?

Написать такой класс (классы), чтобы не было проблем с порядком инициализации — это сложнее, но не настолько... Вы считаете что это невозможно?

E>Ну что-то считаем. Константы, которые вычисляются долго и нами кэшируем при помощи статических в функциях переменных. В чём вред такого подхода --


Вред от такого подхода обычно начинается сразу после ухода с проекта 1 — го разработчика.
Re[11]: стиль: объявление статической переменной внутри функции
От: Erop Россия  
Дата: 05.09.07 15:17
Оценка:
Здравствуйте, dandy, Вы писали:

D>Написать такой класс (классы), чтобы не было проблем с порядком инициализации — это сложнее, но не настолько... Вы считаете что это невозможно?

Я считаю, что это не нужно.
Я не люблю синглетоны, но в данном случае, ИМХО, имеет место случай так называемого перебдения

E>>Ну что-то считаем. Константы, которые вычисляются долго и нами кэшируем при помощи статических в функциях переменных. В чём вред такого подхода --


D>Вред от такого подхода обычно начинается сразу после ухода с проекта 1 — го разработчика.

И состоит он в том, что?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[4]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 05.09.07 15:22
Оценка:
Здравствуйте, igna, Вы писали:

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


I>>>Приведи пример, пожалуйста, где стоит объявлять статическую переменную?


D>> Увы, такого не попадалось.


Это имеет смысл делать в тестовых программах. Несколько сотен строк кода, не более.

I>За сколько лет программирования на C++?


Вопрос личный. По этому поводу: как — то работал в одной конторе с программистом, у которого стаж работы был более 20 — ти лет(только C/C++). Он хронически (на протяжении 6 — ти лет) не мог отладить свою программу — она вылетала у юзеров постоянно. Так что стаж работы — это характеристика та еще... В другой конторе, прога писалась на протяжении 6 — ти лет, написана она была так, что на ее отладку ушло около 3 — х месяцев (чистого времени) — при том что кода там было с гулькин хвост. Причем самый плохой код был написан разработчиком, который, знал С++ лучше всех (из тех кто над этим проектом работал)
Делайте выводы
Re[5]: стиль: объявление статической переменной внутри функции
От: Erop Россия  
Дата: 05.09.07 15:24
Оценка:
Здравствуйте, dandy, Вы писали:

D>...В другой конторе, прога писалась на протяжении 6 — ти лет, написана она была так, что на ее отладку ушло около 3 — х месяцев (чистого времени) — при том что кода там было с гулькин хвост.


НУ в целом "6 лет писали 3 месяца отлаживали" соотношение неплохое. Но от чего 6 лет писали "с гулькин хвост кода" не понятно
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[5]: стиль: объявление статической переменной внутри функции
От: igna Россия  
Дата: 05.09.07 15:41
Оценка:
Здравствуйте, dandy, Вы писали:

D>Вопрос личный.


И что? Я же не спрашиваю, где ты работаешь, да сколько тебе платят, да с кем ты спишь. В первом же сообщении ты написал довольно странное преобразование ссылки в константную ссылку через указатель, а рассуждаешь как большой; вот я и спросил. А ты как рыба об лед.
Re[12]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 05.09.07 15:50
Оценка:
Здравствуйте, Erop, Вы писали:

E>Я считаю, что это не нужно.

E>Я не люблю синглетоны, но в данном случае, ИМХО, имеет место случай так называемого перебдения
D>>Вред от такого подхода обычно начинается сразу после ухода с проекта 1 — го разработчика.
E>И состоит он в том, что?..

Вы там написали (и еще напишете) глобальных функций, следующий разработчик продолжит эту тенденцию, так как ему либо переписывать ваш код заново — либо продолжать в том же духе. Представьте, что из этого проекта получится лет через 5. Не представляете? Получатся функции длиной несколько тысяч строк с очень сложной внутренней логикой. А теперь представьте, что вы пришли на новую работу, что проект такой, как описан выше, что в проекте ошибка на ошибке, а вам нужно их устранить, и добавить еще кое — какую функциональность. Делайте выводы.
Re[13]: стиль: объявление статической переменной внутри функции
От: Erop Россия  
Дата: 05.09.07 15:53
Оценка:
Здравствуйте, dandy, Вы писали:

E>>И состоит он в том, что?..


D>Вы там написали (и еще напишете) глобальных функций, следующий разработчик продолжит эту тенденцию, так как ему либо переписывать ваш код заново — либо продолжать в том же духе. Представьте, что из этого проекта получится лет через 5. Не представляете? Получатся функции длиной несколько тысяч строк с очень сложной внутренней логикой. А теперь представьте, что вы пришли на новую работу, что проект такой, как описан выше, что в проекте ошибка на ошибке, а вам нужно их устранить, и добавить еще кое — какую функциональность. Делайте выводы.


Э-э-э, а какая связь между статическими константами, определёнными в функциях и всеми описанными ужасами?
Предположим, что рассматриваемая функция -- это метод. И что? В методе уже можно заводить статическую константу?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[3]: стиль: объявление статической переменной внутри функции
От: Sergey Россия  
Дата: 05.09.07 15:55
Оценка: +1
> Потому что код получается нечитаемый.

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

> Если эта переменная употребляется только в одной функции, то модификатор static вообще не нужен (и просто вреден).


И в чем же его вред?
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[6]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 05.09.07 16:01
Оценка:
Здравствуйте, Erop, Вы писали:

E>НУ в целом "6 лет писали 3 месяца отлаживали" соотношение неплохое. Но от чего 6 лет писали "с гулькин хвост кода" не понятно


Основная проблема была с отсутствием толковой документации по API программы, к ней писался плагин. Да и сам плагин был не из простых.
Re[7]: стиль: объявление статической переменной внутри функции
От: Erop Россия  
Дата: 05.09.07 16:08
Оценка:
Здравствуйте, dandy, Вы писали:

D>Основная проблема была с отсутствием толковой документации по API программы, к ней писался плагин. Да и сам плагин был не из простых.


6 лет люди с API разбирались? А купить доку не пробовали? Или хачили чего? Что можно с выгодой хачить 6 лет?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[14]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 05.09.07 16:14
Оценка:
Здравствуйте, Erop, Вы писали:

E>Э-э-э, а какая связь между статическими константами, определёнными в функциях и всеми описанными ужасами?

E>Предположим, что рассматриваемая функция -- это метод. И что? В методе уже можно заводить статическую константу?

Если пишете класс — то не вижу смысла заводить в нем статическую константу (в классах для этого заводят protected & private части), статические константы объявляются (как правило) в глобальных функциях любителями этого стиля программирования. Ну и так далее. Что вы здесь видите смешного?
Re[15]: стиль: объявление статической переменной внутри функции
От: Erop Россия  
Дата: 05.09.07 16:25
Оценка: +1
Здравствуйте, dandy, Вы писали:

D>Если пишете класс — то не вижу смысла заводить в нем статическую константу (в классах для этого заводят protected & private части), статические константы объявляются (как правило) в глобальных функциях любителями этого стиля программирования. Ну и так далее. Что вы здесь видите смешного?


Короче не видишь, значит не видишь. А я вижу. Что тут поделаешь. Видимо у нас различный опыт. Я на всякий случай приведу пример, а ты потом можешь сам решать есть смысл нет и всё такое.

class CMyFormulaCalculator {
public:
   static double Process( double x, double y, double z )
   {
       const double A = 0.928745;
       const double B = 0.98455096;
       const double C = 0.023756;

       static const double ABC = formulaPart1( A, B, C );
       static const double BCA = formulaPart2( B, C, A );
       static const double CAB = formulaPart3( C, A, B );

       return ABC * formulaPart3( z, x, y ) + BCA * formulaPart1( x, y, z) + CAB * formulaPart2( y, z, x );
   }

private:
   // Эти три функции вычисляются очень долго.
   static double formulaPart1( double x, double y, double z );
   static double formulaPart2( double x, double y, double z );
   static double formulaPart3( double x, double y, double z );
};


ИМХО очквидно, что выделенные полужирным static ускорят эту программу в два раза.
Или в два раза -- это не смысл?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[8]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 05.09.07 16:34
Оценка:
Здравствуйте, Erop, Вы писали:

E>6 лет люди с API разбирались? А купить доку не пробовали? Или хачили чего? Что можно с выгодой хачить 6 лет?


Эта прога — издательская система, купить доку пробовали — за нее попросили несуразную цену,
хачить пришлось уже после того как раздобыли доку, так как эта дока существует в таком виде, что толку с нее до смешного мало. Да и прога сама по себе еще та — разрабатывалась под MAC OS, под винду портируется. Названия проги упоминать не буду — здесь уже писал о ней здесь год назад — никто ничего об этой проге не знает, так что смысла не вижу. А насчет выгоды — юзеры говорят, что разработанный плагин лучший из тех, что они где — либо видели. Разрабатывался для внутреннего пользования.
Re[16]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 05.09.07 17:28
Оценка:
Здравствуйте, Erop, Вы писали:
E>Короче не видишь, значит не видишь. А я вижу. Что тут поделаешь. Видимо у нас различный опыт.
Ну, каждому — свое

Я на всякий случай приведу пример, а ты потом можешь сам решать есть смысл нет и всё такое.

E>
E>class CMyFormulaCalculator {
E>public:
E>   static double Process( double x, double y, double z )
E>   {
E>       const double A = 0.928745;
E>       const double B = 0.98455096;
E>       const double C = 0.023756;

E>       static const double ABC = formulaPart1( A, B, C );
E>       static const double BCA = formulaPart2( B, C, A );
E>       static const double CAB = formulaPart3( C, A, B );

E>       return ABC * formulaPart3( z, x, y ) + BCA * formulaPart1( x, y, z) + CAB * formulaPart2( y, z, x );
E>   }

E>private:
E>   // Эти три функции вычисляются очень долго.
E>   static double formulaPart1( double x, double y, double z );
E>   static double formulaPart2( double x, double y, double z );
E>   static double formulaPart3( double x, double y, double z );
E>};


E>ИМХО очквидно, что выделенные полужирным static ускорят эту программу в два раза.

E>Или в два раза -- это не смысл?

Иногда ускорение выполнения и на 20% — уже есть смысл.
А насчет кода — сделал бы что — то вроде такого (в первом приближении, можно и лучше, но думать лениво ):
Тут для экономии уменьшено количество параметров
class CCalculateFormulaPart
{
protected:
    BOOL _bCalculated;
    double _fResult;
public:
    CCalculateFormulaPart() : _bCalculated(0) {}
    virtual double Calculate(double) = 0;
};

class CCalculateFormulaPart_1 : public CCalculateFormulaPart
{
    double Calculate(double f)
    {
        if(!_bCalculated)
        {
            _fResult = formulaPart1(f);
            _bCalculated = TRUE;
        }
        return _fResult;
    }
};


+ еще 2 таких класса для formulaPart3 и formulaPart2, их обьекты — включил бы статическими членами в CMyFormulaCalculator

Тогда (псевдокод) функцию Process нужно было бы записать так:

E>       const double A = 0.928745;
E>       const double B = 0.98455096;
E>       const double C = 0.023756;

E>       const double ABC = _formulaPart_1.Calculate(A);
E>       const double BCA = _formulaPart_2.Calculate(B);
E>       const double CAB = _formulaPart_3.Calculate(C);

E>       return ABC * formulaPart3( z, x, y ) + BCA * formulaPart1( x, y, z) + CAB * formulaPart2( y, z, x ); // тут можно дополнить классы CCalculateFormulaPart_I, чтобы вызывать эти функции из них - для полного счастья :)


Мне такой код кажется более наглядным и проще при модификации, нежели исходный
Re[6]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 05.09.07 17:32
Оценка:
Здравствуйте, igna, Вы писали:

I>И что? Я же не спрашиваю, где ты работаешь, да сколько тебе платят, да с кем ты спишь. В первом же сообщении ты написал довольно странное преобразование ссылки в константную ссылку через указатель, а рассуждаешь как большой; вот я и спросил. А ты как рыба об лед.


Ну только без обид, пожалуйста!
Re[4]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 05.09.07 18:02
Оценка: 1 (1)
Здравствуйте, Sergey, Вы писали:

>> Потому что код получается нечитаемый.


S>По-настоящему нечитаемый код получается как раз при интенсивном использовании глобальных переменных.


Да, если их не группировать в объекты.

>> Если эта переменная употребляется только в одной функции, то модификатор static вообще не нужен (и просто вреден).


S>И в чем же его вред?


Возникает искушение обратиться к такой переменной из другой функции. Если таких обращений и функций много, то попробуйте такой код отладить.
Re[17]: стиль: объявление статической переменной внутри функции
От: Erop Россия  
Дата: 05.09.07 19:01
Оценка: +4
Здравствуйте, dandy, Вы писали:

D>Иногда ускорение выполнения и на 20% — уже есть смысл.

Ну вот и хорошо. Смысл мы уже отыскали. Теперь поговорим о сестре таланта

D>Тут для экономии уменьшено количество параметров

D>
D>class CCalculateFormulaPart
D>{
D>protected:
D>    BOOL _bCalculated;
D>    double _fResult;
D>public:
D>    CCalculateFormulaPart() : _bCalculated(0) {}
D>    virtual double Calculate(double) = 0;
D>};

D>class CCalculateFormulaPart_1 : public CCalculateFormulaPart
D>{
D>    double Calculate(double f)
D>    {
D>        if(!_bCalculated)
D>        {
D>            _fResult = formulaPart1(f);
D>            _bCalculated = TRUE;
D>        }
D>        return _fResult;
D>    }
D>};
D>

D>+ еще 2 таких класса для formulaPart3 и formulaPart2, их обьекты — включил бы статическими членами в CMyFormulaCalculator

D>Тогда (псевдокод) функцию Process нужно было бы записать так:


D>
E>>       const double A = 0.928745;
E>>       const double B = 0.98455096;
E>>       const double C = 0.023756;

E>>       const double ABC = _formulaPart_1.Calculate(A);
E>>       const double BCA = _formulaPart_2.Calculate(B);
E>>       const double CAB = _formulaPart_3.Calculate(C);

E>>       return ABC * formulaPart3( z, x, y ) + BCA * formulaPart1( x, y, z) + CAB * formulaPart2( y, z, x ); // тут можно дополнить классы CCalculateFormulaPart_I, чтобы вызывать эти функции из них - для полного счастья :)
D>


D>Мне такой код кажется более наглядным и проще при модификации, нежели исходный

Это более наглядный код?
Сначала были просто формулы просто и прямо отображающие логику задачи.
А ты навертел 4 класса с наследованием и виртуальными функциями, синглетонами, линивыми вычислениями и прочей чешуёй. При этом ты ещё и параметры выкинул "для упрощения". Нехилое упрощение я тебе скажу.

Ты представляешь себе вычислительную прогу какую-нибудь серъёзную? Когда строк 100 000 вычислений. При этом непростых вычислений, сложно довольно организованных?

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

ИМХО код надо писать выразительно и так просто, как только возможно, без потери выразительности. А не запуьывать и усложнять из каких-то идеологических предрассудков.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[5]: стиль: объявление статической переменной внутри функции
От: Erop Россия  
Дата: 05.09.07 19:06
Оценка:
Здравствуйте, dandy, Вы писали:

S>>По-настоящему нечитаемый код получается как раз при интенсивном использовании глобальных переменных.

D>Да, если их не группировать в объекты.

О да, прекрасный объект "PI делённое на различные натуральные числа" конечно же грандиозно повышает читабельность программы. Как же
Вот в обсуждаемой формуле ты вместо констант предложил какие-то уродские полиморфные синглетоны использовать, например.
Интересно, как бы ты класс с константами ABC, BCA и CAB назвал бы?

>>> Если эта переменная употребляется только в одной функции, то модификатор static вообще не нужен (и просто вреден).

S>>И в чем же его вред?
D>Возникает искушение обратиться к такой переменной из другой функции. Если таких обращений и функций много, то попробуйте такой код отладить.
О мудрейший Гуру! Открой нам, сирым, как можно обратиться к static in function переменной, объевленной в одной функции из другой функции? Я, например, так не умею...
Зато я умею обращаться к безумным глобальным константам... Но предпочитаю этого не делать и безумных констант не иметь тоже
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[9]: стиль: объявление статической переменной внутри функции
От: Erop Россия  
Дата: 05.09.07 19:09
Оценка:
Здравствуйте, dandy, Вы писали:

D>А насчет выгоды — юзеры говорят, что разработанный плагин лучший из тех, что они где — либо видели. Разрабатывался для внутреннего пользования.


Ну, то есть разработка была успешной, не смотря на все твои мрачные замечания?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[5]: стиль: объявление статической переменной внутри функции
От: Sergey Россия  
Дата: 05.09.07 19:27
Оценка: +1
Здравствуйте, dandy, Вы писали:

S>>По-настоящему нечитаемый код получается как раз при интенсивном использовании глобальных переменных.


D>Да, если их не группировать в объекты.


Чего группировать в объекты? В одной функции у меня, допустим, конфиг как static объявлен, в другой — логфайл. Мне что их теперь, в один объект сувать?

>>> Если эта переменная употребляется только в одной функции, то модификатор static вообще не нужен (и просто вреден).


S>>И в чем же его вред?


D>Возникает искушение обратиться к такой переменной из другой функции. Если таких обращений и функций много, то попробуйте такой код отладить.


Такой код отлаживать не придется. Потому что он не скомпилируется.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[18]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 05.09.07 19:57
Оценка:
Здравствуйте, Erop, Вы писали:

E>Это более наглядный код?

E>Сначала были просто формулы просто и прямо отображающие логику задачи.
E>А ты навертел 4 класса с наследованием и виртуальными функциями, синглетонами, линивыми вычислениями и прочей чешуёй.

Эти 4 класса добавляют (если не считать базового) по 3 строки кода к вызову функции. Это усложняет? Базовый класс написан для того, чтобы уменьшить количество кода и упростить логику производных классов А синглетонов там нет, их там и не нужно.

E>При этом ты ещё и параметры выкинул "для упрощения". Нехилое упрощение я тебе скажу.


А если бы параметров было бы 30, а не три? Это всего лишь пример, а не рабочий код, и думаю, ни к чему его раздувать, смысл и без того понятен.


E>Ты представляешь себе вычислительную прогу какую-нибудь серъёзную? Когда строк 100 000 вычислений. При этом непростых вычислений, сложно довольно организованных?


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

E>На хрена эту и без того сложную программу представлять в запутанное чудовище из таких вот объектов? ((

E>Почему тебе кажется, что это будет проще поддерживать?
E>Да ты никогда в жизни не поймёшь что надо поменять в такой программе, когда что-то поменяется в математике

Да какое же это чудовище? Мне оно кажется и симпатичнее и выразительнее. Хотя о вкусах не спорят. И по — моему в таком коде разобраться таки — проще.

E>ИМХО код надо писать выразительно и так просто, как только возможно, без потери выразительности.


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

E> А не запуьывать и усложнять из каких-то идеологических предрассудков.

Согласен.
Re[6]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 05.09.07 20:03
Оценка:
Здравствуйте, Erop, Вы писали:

E>Вот в обсуждаемой формуле ты вместо констант предложил какие-то уродские полиморфные синглетоны использовать, например.


Вы считаете, что на это нужно отвечать?
Re[19]: стиль: объявление статической переменной внутри функции
От: Erop Россия  
Дата: 05.09.07 20:33
Оценка:
Здравствуйте, dandy, Вы писали:

D>Эти 4 класса добавляют (если не считать базового) по 3 строки кода к вызову функции. Это усложняет? Базовый класс написан для того, чтобы уменьшить количество кода и упростить логику производных классов А синглетонов там нет, их там и не нужно.

Это как назвать. Вот статические экземпляры тех самых классов -- самый, что ни на есть синглетон...

У них ещё и семантика мутная, вообще-то. Зачем нужно, чтобы метод Calculate считал только первый раз за время жизни объекта. А потом игнорировал сой аргумент?
Это такое упрощение или это зачем?
Вот напишу я такой код, скажем:
foo()
{
    CCalculateFormulaPart_1 calculator;
    double v1 = calculator.Calculate( a1 );
    double v2 = calculator.Calculate( a2 );
    assert( v1 == v2 ); // сюрприз! сюрприз! сюрприз!!!
}


D> ...смысл и без того понятен.

Смысл такой, что из очень простого кода, где для оптимизации некоторые константы вычислялись единожды за время жизни программы ты предлагаешь сделать какого-то мегакрокодила, в котором надо разбираться и разбираться. С наследованиями, виртуальными методами, неявными состояниями, игнорируемыми параметрами и т. д.
Давно это называется упрощением?: )

D>Не, вычислительные проги писал только в универе на вычах и только на фортране. Естественно, маленькие. Код типа этого как раз и пишется для сложных программ, для разбиения сложного функционала на относительно простые части.


ИМХО ты говоришь о о чём-то другом. Похоже о управлении временим жизни объектов. Да, это дело учше не запутывать. Но в вычпрограммах обычно очень простые схемы владения как раз... Зачем их "улучшать"?

E>>Да ты никогда в жизни не поймёшь что надо поменять в такой программе, когда что-то поменяется в математеке

D>Да какое же это чудовище? Мне оно кажется и симпатичнее и выразительнее. Хотя о вкусах не спорят. И по — моему в таком коде разобраться таки — проще.

Обрати вниание, что ты ответил вовсе и не на моё замечание, а на какое-то своё...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: стиль: объявление статической переменной внутри функции
От: Erop Россия  
Дата: 05.09.07 20:34
Оценка:
Здравствуйте, dandy, Вы писали:

E>>Вот в обсуждаемой формуле ты вместо констант предложил какие-то уродские полиморфные синглетоны использовать, например.


D>Вы считаете, что на это нужно отвечать?


Я прошу прощения за "уродские", но по существу считаю что твой вариант значительно хуже.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[20]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 06.09.07 10:50
Оценка:
Здравствуйте, Erop, Вы писали:

E>Это как назвать. Вот статические экземпляры тех самых классов -- самый, что ни на есть синглетон...


Нет. Прямо здесь на RSDN есть статья с вариантами реализациями синглтона. Там же есть определение синглтона. Думаю, вам стоит посмотреть.

E>У них ещё и семантика мутная, вообще-то. Зачем нужно, чтобы метод Calculate считал только первый раз за время жизни объекта. А потом игнорировал сой аргумент?

E>Это такое упрощение или это зачем?
E>Вот напишу я такой код, скажем:
foo()
E>{
E>    CCalculateFormulaPart_1 calculator;
E>    double v1 = calculator.Calculate( a1 );
E>    double v2 = calculator.Calculate( a2 );
E>    assert( v1 == v2 ); // сюрприз! сюрприз! сюрприз!!!
E>}


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

E>Давно это называется упрощением?: )

Это не вопрос.

E>ИМХО ты говоришь о о чём-то другом. Похоже о управлении временим жизни объектов. Да, это дело учше не запутывать. Но в вычпрограммах обычно очень простые схемы владения как раз... Зачем их "улучшать"?


Речь не об управлении временем жизни объектов, а о том, как сделать код прозрачным.


E>>>Да ты никогда в жизни не поймёшь что надо поменять в такой программе, когда что-то поменяется в математеке
D>>Да какое же это чудовище? Мне оно кажется и симпатичнее и выразительнее. Хотя о вкусах не спорят. И по — моему в таком коде разобраться таки — проще.

E>Обрати вниание, что ты ответил вовсе и не на моё замечание, а на какое-то своё...



Вобще исходный топик был такой:


E>На хрена эту и без того сложную программу представлять в запутанное чудовище из таких вот объектов? ((
E>Почему тебе кажется, что это будет проще поддерживать?
E>Да ты никогда в жизни не поймёшь что надо поменять в такой программе, когда что-то поменяется в математике

D>Да какое же это чудовище? Мне оно кажется и симпатичнее и выразительнее. Хотя о вкусах не спорят. И по — моему в таком коде разобраться таки — проще.



Обратите внимание: Вы удалили часть своей реплики, то есть вы пытались кого — то обмануть (или кому — то досадить). Вывод простой — это обсуждение пора закрыть
Re[21]: О чём таки спор...
От: Erop Россия  
Дата: 06.09.07 11:05
Оценка:
Здравствуйте, dandy, Вы писали:

E>>Это как назвать. Вот статические экземпляры тех самых классов -- самый, что ни на есть синглетон...

D>Нет. Прямо здесь на RSDN есть статья с вариантами реализациями синглтона. Там же есть определение синглтона. Думаю, вам стоит посмотреть.
Можно я ограничусь первоисточниками?

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

<развёрнутая версия вопроса поскипана>
D>Это не вопрос.
Скорее это не ответ

D>Речь не об управлении временем жизни объектов, а о том, как сделать код прозрачным.

Очень хорошо. Почему твой вариант "более прозрачный"? Что виднее?

D>

E>>>>Да ты никогда в жизни не поймёшь что надо поменять в такой программе, когда что-то поменяется в математеке
D>>>Да какое же это чудовище? Мне оно кажется и симпатичнее и выразительнее. Хотя о вкусах не спорят. И по — моему в таком коде разобраться таки — проще.

E>>Обрати вниание, что ты ответил вовсе и не на моё замечание, а на какое-то своё...

D>


D>Вобще исходный топик был такой:

<исходный топик>

D>Обратите внимание: Вы удалили часть своей реплики, то есть вы пытались кого — то обмануть (или кому — то досадить). Вывод простой — это обсуждение пора закрыть

А может ты всё-таки перед тем, как "закрывать обсуждение" ответишь на моё замечание про трудность поиска соответсвий между математическими выкладоками и твоим "прозрачным" кодом?

Вообще, ИМХО, твой вариант конечно выразителен, но выражает не исходный алгоритм рассчёта, а твоё немение или неумение (у всех своё мнение тут я полагаю) писать хитрые классы, с не очень понятными и совсем неописанными свойствами и состояниями...

Ну а главный вопрос "ЗАЧЕМ" пока что получил ответ, что так де прозрачнее, красивие, легче поддерживать и не получил, ИМХО, вообще никаких обоснований этих "тезисов".

С уважением.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[22]: О чём таки спор...
От: dandy  
Дата: 07.09.07 11:57
Оценка:
Здравствуйте, Erop, Вы писали:

D>>Обратите внимание: Вы удалили часть своей реплики, то есть вы пытались кого — то обмануть (или кому — то досадить). Вывод простой — это обсуждение пора закрыть

E>А может ты всё-таки перед тем, как "закрывать обсуждение" ответишь на моё замечание про трудность поиска соответсвий между математическими выкладоками и твоим "прозрачным" кодом?


Потому что поведение вроде того что вы продемонстрировали следует пресекать.
На остальные свои вопросы вы уже начинаете отвечать самостоятельно.
Re[17]: стиль: объявление статической переменной внутри функции
От: Кодт Россия  
Дата: 07.09.07 12:33
Оценка: +1
Здравствуйте, dandy, Вы писали:

D>Мне такой код кажется более наглядным и проще при модификации, нежели исходный


Ну ты и нагенерил!

Сперва CONTRA

Риторический вопрос: чем фактически отличается
void foo()
{
    static int const x = expr();
    ..... x .....
}

//-----------------

struct StaticX
{
    int value;
    bool done;
};
static StaticX sx = {0,false};

void foo()
{
    if(!sx.done) sx.value = expr();
    int const x = sx.value;
}

//-----------------

struct StaticX
{
    int value;
    bool done;
    int EvalOnce()
    {
        if(!done) value = expr();
        return value;
    }
};
static StaticX sx = {0,false};

void foo()
{
    int const x = sx.EvalOnce();
}

Ответ: исключительно громоздкостью. Слово static делает всё то же самое, но
— гораздо выразительнее
— компилятором (а сделать ошибку в компиляторе гораздо сложнее, чем сделать ошибку в велосипедном коде)

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




А теперь PRO

Синглетон Майерса, сиречь статическая переменная внутри функции, не потокобезопасен.
Так что если программа многопоточная, нужно выкручиваться.

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

Или прибегнуть к критическим секциям.
Или к честной мемоизации и потокобезопасным контейнерам.

Но во всех этих случаях получится код не такой громоздкий, как ты привёл, а ГОРАЗДО более громоздкий.
Одно счастье, что эта громоздкость, скорее всего, будет сосредоточена в библиотеке поддержки, а не размазана по программе.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Re[18]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 07.09.07 12:56
Оценка:
Здравствуйте, Кодт, Вы писали:

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


D>>Мне такой код кажется более наглядным и проще при модификации, нежели исходный


К>Ну ты и нагенерил!


К>Сперва CONTRA


К>Риторический вопрос: чем фактически отличается

К>
К>void foo()
К>{
К>    static int const x = expr();
К>    ..... x .....
К>}

К>//-----------------

К>struct StaticX
К>{
К>    int value;
К>    bool done;
К>};
К>static StaticX sx = {0,false};

К>void foo()
К>{
К>    if(!sx.done) sx.value = expr();
К>    int const x = sx.value;
К>}

К>//-----------------

К>struct StaticX
К>{
К>    int value;
К>    bool done;
К>    int EvalOnce()
К>    {
К>        if(!done) value = expr();
К>        return value;
К>    }
К>};
К>static StaticX sx = {0,false};

К>void foo()
К>{
К>    int const x = sx.EvalOnce();
К>}
К>

К>Ответ: исключительно громоздкостью. Слово static делает всё то же самое, но
К>- гораздо выразительнее
К>- компилятором (а сделать ошибку в компиляторе гораздо сложнее, чем сделать ошибку в велосипедном коде)

В первом случае логика неявная (по крайней мере не совсем явная). Многие предпочитают такого избегать.

К>Плюс, если ты будешь передавать в EvalOnce какие-то параметры, то во всех последующих случаях будешь делать это вхолостую. Так что выгоды от мемоизации уменьшатся.


Естественно.

К>


К>А теперь PRO


К>Синглетон Майерса, сиречь статическая переменная внутри функции,


Считаю, что называть объект паттерном, или паттерн объектом некорректно. (Котлеты — отдельно, мухи — отдельно , но это уже вопрос к Майерсу.)

K>не потокобезопасен.

К>Так что если программа многопоточная, нужно выкручиваться.

К>Способы выкручивания могут быть самыми разными. Начиная с того, чтобы выносить константы из рантайма (перекладывать на компилятор или на внешние средства) или предвычислять их на ранней стадии.


К>Или прибегнуть к критическим секциям.

К>Или к честной мемоизации и потокобезопасным контейнерам.

К>Но во всех этих случаях получится код не такой громоздкий, как ты привёл, а ГОРАЗДО более громоздкий.

К>Одно счастье, что эта громоздкость, скорее всего, будет сосредоточена в библиотеке поддержки, а не размазана по программе.

Согласен.
Re[19]: стиль: объявление статической переменной внутри функции
От: Кодт Россия  
Дата: 07.09.07 14:08
Оценка: 1 (1) :)
Здравствуйте, dandy, Вы писали:

D>В первом случае логика неявная (по крайней мере не совсем явная). Многие предпочитают такого избегать.


К>>Синглетон Майерса, сиречь статическая переменная внутри функции,


D>Считаю, что называть объект паттерном, или паттерн объектом некорректно. (Котлеты — отдельно, мухи — отдельно , но это уже вопрос к Майерсу.)


Есть паттерн Синглетон.
Есть идиома Синглетон Майерса, воплощающая этот паттерн одним из возможных способов.
Есть код, воплощающий эту идиому.
Наконец, есть конкретный объект, полученный в результате работы этого кода.
И этот объект и есть синглетон — воплощение паттерна.

Если хочешь, отделение мух от котлет состоит в том, чтобы одно слово писать с большой буквы (его святейшество Паттерн Синглетон), а другое — с маленькой.
Точно так же, как есть паттерн Адаптер и есть конкретные адаптеры.

Или тебе хочется, чтобы всё было Очень Явно и с кучей обвесок?
Типа, пока не написал рядом с переменной [ThisIsSingleton], [ThisIsAdaptor] или std::binary_function<bool,int,int>, она синглетоном, адаптером или компаратором не станет?
... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Re[19]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 07.09.07 14:14
Оценка: -1 :)
D>Здравствуйте, Кодт, Вы писали:

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


К>>Ну ты и нагенерил!


К>>Сперва CONTRA


К>>Риторический вопрос: чем фактически отличается

К>>
К>>void foo()
К>>{
К>>    static int const x = expr();
К>>    ..... x .....
К>>}

К>>//-----------------

К>>struct StaticX
К>>{
К>>    int value;
К>>    bool done;
К>>};
К>>static StaticX sx = {0,false};

К>>void foo()
К>>{
К>>    if(!sx.done) sx.value = expr();
К>>    int const x = sx.value;
К>>}

К>>//-----------------

К>>struct StaticX
К>>{
К>>    int value;
К>>    bool done;
К>>    int EvalOnce()
К>>    {
К>>        if(!done) value = expr();
К>>        return value;
К>>    }
К>>};
К>>static StaticX sx = {0,false};

К>>void foo()
К>>{
К>>    int const x = sx.EvalOnce();
К>>}
К>>

К>>Ответ: исключительно громоздкостью. Слово static делает всё то же самое, но
К>>- гораздо выразительнее
К>>- компилятором (а сделать ошибку в компиляторе гораздо сложнее, чем сделать ошибку в велосипедном коде)

D>В первом случае логика неявная (по крайней мере не совсем явная). Многие предпочитают такого избегать.


К>>Плюс, если ты будешь передавать в EvalOnce какие-то параметры, то во всех последующих случаях будешь делать это вхолостую. Так что выгоды от мемоизации уменьшатся.


К>>


К>>А теперь PRO


K>>не потокобезопасен.

К>>Так что если программа многопоточная, нужно выкручиваться.

К>>Способы выкручивания могут быть самыми разными. Начиная с того, чтобы выносить константы из рантайма (перекладывать на компилятор или на внешние средства) или предвычислять их на ранней стадии.


К>>Или прибегнуть к критическим секциям.

К>>Или к честной мемоизации и потокобезопасным контейнерам.

К>>Но во всех этих случаях получится код не такой громоздкий, как ты привёл, а ГОРАЗДО более громоздкий.

К>>Одно счастье, что эта громоздкость, скорее всего, будет сосредоточена в библиотеке поддержки, а не размазана по программе.

Самое главное — появляются возможности для развития логики программы. Для этого собственно такой код и "громоздится" (употребляя ваши же выражения). Причем, вынесение этой "громоздкости" в библиотеку поддержки вам кажется затеей глупой и ненужной. Судя по всему, с задачами, где такая "громоздкость" является лучшим вариантом, вы не сталкивались.
Re[20]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 07.09.07 14:21
Оценка:
К>Есть паттерн Синглетон.
К>Есть идиома Синглетон Майерса, воплощающая этот паттерн одним из возможных способов.
К>Есть код, воплощающий эту идиому.
К>Наконец, есть конкретный объект, полученный в результате работы этого кода.
К>И этот объект и есть синглетон — воплощение паттерна.

К>Если хочешь, отделение мух от котлет состоит в том, чтобы одно слово писать с большой буквы (его святейшество Паттерн Синглетон), а другое — с маленькой.

К>Точно так же, как есть паттерн Адаптер и есть конкретные адаптеры.

К>Или тебе хочется, чтобы всё было Очень Явно и с кучей обвесок?

К>Типа, пока не написал рядом с переменной [ThisIsSingleton], [ThisIsAdaptor] или std::binary_function<bool,int,int>, она синглетоном, адаптером или компаратором не станет?

Это примерно то же самое, что называть объект класса классом
Re[23]: О чём таки спор...
От: Erop Россия  
Дата: 07.09.07 14:45
Оценка:
Здравствуйте, dandy, Вы писали:

D>Потому что поведение вроде того что вы продемонстрировали следует пресекать.

D>На остальные свои вопросы вы уже начинаете отвечать самостоятельно.

Понятно, ответа значит нет. Бывает...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[17]: стиль: объявление статической переменной внутри функции
От: igna Россия  
Дата: 07.09.07 15:13
Оценка:
Здравствуйте, dandy, Вы писали:

D>class CCalculateFormulaPart
D>{
D>protected:
D>    BOOL _bCalculated;
D>    double _fResult;
D>public:
D>    CCalculateFormulaPart() : _bCalculated(0) {}
D>    virtual double Calculate(double) = 0;
D>};

D>class CCalculateFormulaPart_1 : public CCalculateFormulaPart
D>{
D>    double Calculate(double f)
D>    {
D>        if(!_bCalculated)
D>        {
D>            _fResult = formulaPart1(f);
D>            _bCalculated = TRUE;
D>        }
D>        return _fResult;
D>    }
D>};


А Calculate зачем virtual?
Re[18]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 07.09.07 15:22
Оценка:
Здравствуйте, igna, Вы писали:

I>А Calculate зачем virtual?


По правилам объявления чисто виртуальных функций. Ее в базовом классе можно и не объявлять, но тогда можно забыть ее реализовать в производном классе.
Re[18]: стиль: объявление статической переменной внутри функции
От: Кодт Россия  
Дата: 07.09.07 15:25
Оценка:
Здравствуйте, igna, Вы писали:

I>А Calculate зачем virtual?


А это результат велосипедного дизайна. Хотелось применить шаблонный метод, по-видимому
class CalculateFormula
{
    bool done;
    double value;
public:
    CalculateFormula() : done(false) {}
    double Calculate()
    {
        if(!done) value = DoCalculate();
        return value;
    }
protected:
    virtual double DoCalculate() = 0;
};
... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Re[19]: стиль: объявление статической переменной внутри функции
От: Кодт Россия  
Дата: 07.09.07 15:29
Оценка:
Кое-что подзабыл. Исправляюсь.
К>class CalculateFormula
К>{
К>    bool done;
К>    double value;
К>public:
К>    CalculateFormula() : done(false) {}
К>    double Calculate()
К>    {
К>        if(!done)
        {
            done = true;
К>             value = DoCalculate();
        }
К>        return value;
К>    }
К>protected:
К>    virtual double DoCalculate() = 0;
К>};

Кстати, философский вопрос — взводить флажок до или после (или вместо)
Можно просекать рекурсию, устанавливая флажок в позицию "занято" перед вычислением и в "готово" после.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Re[19]: стиль: объявление статической переменной внутри функции
От: igna Россия  
Дата: 07.09.07 15:30
Оценка:
Здравствуйте, dandy, Вы писали:

D>По правилам объявления чисто виртуальных функций. Ее в базовом классе можно и не объявлять, но тогда можно забыть ее реализовать в производном классе.


А для чего тут вообще разделение на два класса?
Re[21]: стиль: объявление статической переменной внутри функции
От: Кодт Россия  
Дата: 07.09.07 15:32
Оценка: +1
Здравствуйте, dandy, Вы писали:

D>Это примерно то же самое, что называть объект класса классом


Даже спорить не хочу, насколько это примерно не то же самое.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Re[20]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 07.09.07 15:40
Оценка:
Здравствуйте, igna, Вы писали:

I>А для чего тут вообще разделение на два класса?


Если нужны несколько похожих классов, которые включают одинаковые данные или функции, то все общее для этих классов проще вынести в базовый класс. По крайней мере Страуструп ( интересная фамилия) это рекомендует и многие с ним согласны. Хотя и не все.
Re[21]: стиль: объявление статической переменной внутри функции
От: igna Россия  
Дата: 07.09.07 15:43
Оценка: +1
Здравствуйте, dandy, Вы писали:

D> Если нужны несколько похожих классов, которые включают одинаковые данные или функции, то все общее для этих классов проще вынести в базовый класс. По крайней мере Страуструп ( интересная фамилия) это рекомендует и многие с ним согласны.


Офигеть. А ссылку можно?
Re[21]: стиль: объявление статической переменной внутри функции
От: igna Россия  
Дата: 07.09.07 15:47
Оценка: +1
Здравствуйте, dandy, Вы писали:

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


У тебя недоработка, проверку if(!_bCalculated) нужно вынести в базовый класс. Или еще куда.
Re[19]: стиль: объявление статической переменной внутри функции
От: igna Россия  
Дата: 07.09.07 15:54
Оценка:
Здравствуйте, Кодт, Вы писали:

К>А это результат велосипедного дизайна. Хотелось применить шаблонный метод, по-видимому


Может быть. Но я все же думаю, не было там такого в мыслях. Было просто... ну как сказать... наверное лучше никак.
Re[22]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 07.09.07 15:55
Оценка:
Здравствуйте, igna, Вы писали:

I>Офигеть. А ссылку можно?


здесь. Спасибо т. Bell и Кодту.
Re[23]: стиль: объявление статической переменной внутри функции
От: igna Россия  
Дата: 07.09.07 15:59
Оценка:
Здравствуйте, dandy, Вы писали:

D>здесь.


Это у меня есть. Номер страницы, пожалуйста.
Re[22]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 07.09.07 15:59
Оценка: :)
Здравствуйте, igna, Вы писали:

I>У тебя недоработка, проверку if(!_bCalculated) нужно вынести в базовый класс. Или еще куда.


Конечно же можно лучше, этот код — всего лишь пример и писался почти что на коленке
Re[19]: стиль: объявление статической переменной внутри функции
От: igna Россия  
Дата: 07.09.07 16:09
Оценка:
Здравствуйте, dandy, Вы писали:

D>По правилам объявления чисто виртуальных функций. Ее в базовом классе можно и не объявлять, но тогда можно забыть ее реализовать в производном классе.


То есть вот она какая причина, чисто виртуальные функции как средство от забывчивости. То есть полиморфное использование объекта класса CCalculateFormulaPart_1 как объекта класса CCalculateFormulaPart не планируется?
Re[24]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 07.09.07 16:10
Оценка:
Здравствуйте, igna, Вы писали:

I>Это у меня есть. Номер страницы, пожалуйста.


Стр. 16 по книге, пункт 1.8. подпункты [1] с) и [1] d). Хотя эти советы после написания сотни — другой классов и без того очевидны.
Re[20]: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 07.09.07 16:56
Оценка:
Здравствуйте, igna, Вы писали:

I>То есть вот она какая причина, чисто виртуальные функции как средство от забывчивости. То есть полиморфное использование объекта класса CCalculateFormulaPart_1 как объекта класса CCalculateFormulaPart не планируется?


Оно там просто осуществляется, тупо, и безо всякого планирования.
Извините, но у меня голова разболелась, так что придется отложить продолжение на будущее.
Re[21]: стиль: объявление статической переменной внутри функции
От: Erop Россия  
Дата: 07.09.07 18:02
Оценка:
Здравствуйте, dandy, Вы писали:

D>Извините, но у меня голова разболелась, так что придется отложить продолжение на будущее.

Жаль. Сучувствую. Береги себя...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[21]: Вот вам смешно, а я со стула упал :(
От: Erop Россия  
Дата: 07.09.07 18:09
Оценка:
Здравствуйте, dandy, Вы писали:

D> Если нужны несколько похожих классов, которые включают одинаковые данные или функции, то все общее для этих классов проще вынести в базовый класс. По крайней мере Страуструп ( интересная фамилия) это рекомендует и многие с ним согласны. Хотя и не все.


Ну то есть у классов
namespace shapes { 
    class rectangle {
        point first; // usualy left-bottom point
        point secont; // usualy up-top point
    };

    class triangle {
        point first; // usualy mostly left point
        point second; // usualy mostly top point
        point last; 
    };
} // namespace shapes
должны иметь общего пердка std::pair<point, point>?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[20]: А конкретнее?
От: Erop Россия  
Дата: 07.09.07 18:10
Оценка:
Здравствуйте, dandy, Вы писали:

D>Самое главное — появляются возможности для развития логики программы. Для этого собственно такой код и "громоздится" (употребляя ваши же выражения). Причем, вынесение этой "громоздкости" в библиотеку поддержки вам кажется затеей глупой и ненужной. Судя по всему, с задачами, где такая "громоздкость" является лучшим вариантом, вы не сталкивались.


Интересно бы было узнать примерное направление развития этой программы, которое облегяается таким подходом...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[22]: Вот вам смешно, а я со стула упал :(
От: igna Россия  
Дата: 07.09.07 19:17
Оценка: +1
Здравствуйте, Erop, Вы писали:

E>... должны иметь общего пердка std::pair<point, point>?


Ну на 16-ой странице Страуструпа действительно написано нечто, что можно и так понять. Но он наверное на 16-ой не остановится, так что можно надеяться.
Re[22]: стиль: объявление статической переменной внутри функции
От: igna Россия  
Дата: 07.09.07 19:38
Оценка: +1
Здравствуйте, Erop, Вы писали:

E>Жаль. Сучувствую. Береги себя...


Да. Присоединяюсь. Весело все же.
Re[23]: Вот вам смешно, а я со стула упал :(
От: Erop Россия  
Дата: 07.09.07 20:30
Оценка:
Здравствуйте, igna, Вы писали:

I>Ну на 16-ой странице Страуструпа действительно написано нечто, что можно и так понять. Но он наверное на 16-ой не остановится, так что можно надеяться.


Ну да, будем надеяться
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[2]: стиль: объявление статической переменной внутри функц
От: Sni4ok  
Дата: 11.09.07 16:11
Оценка:
Здравствуйте, igna, Вы писали:

I>Приведи пример, пожалуйста, где стоит объявлять статическую переменную?


все теже места, где разумно применять синглетоны или глобальные переменные,
а также использование статических констант.
Re[21]: У тебя всё хорошо?
От: Erop Россия  
Дата: 11.09.07 16:17
Оценка:
Здравствуйте, dandy, Вы писали:

D>Извините, но у меня голова разболелась, так что придется отложить продолжение на будущее.


Данди! Ты ещё жив? А то что-то как-о мы тебя заклевали до больной головы и привет. Это последний товой пост
Автор: dandy
Дата: 07.09.07
.
Я беспокоюсь
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re: стиль: объявление статической переменной внутри функции
От: Xentrax Россия http://www.lanovets.ru
Дата: 12.09.07 11:07
Оценка:
Здравствуйте, dandy, Вы писали:

D>Ну, вообще код типа этого — объявление статической переменной внутри функции, это потенциальный источник ошибок в мало — мальски обьемной программе. Это, наверное, не мое

D>дело, но думаю, что так писать код вообще не стоит.

Думаю не стоит вводить людей в заблуждение. Статические локальные переменные — отличное средство организации singleton и отложенной инициализации по запросу, у них множество преимуществ над глобальными переменными (в том числе и статическими членами классов).

Во-первых, исключаются проблемы с порядком инициализации (почти самый страшный мой ночной кошмар, сразу после vtable boost::shared_ptr<>, указывающей в адреса выгруженной из памяти DLL).
Во-вторых, исключаются проблемы с созданем потоков и явной подгрузкой DLL из DllMain (в конструкторах статическизх объектов).
В-третьих, они вычисляются только при необходимости, чем ускоряется запуск программы и снижается потребление памяти.
В-четвертых, всегда есть место куда поставить breakpoint.

Математические вычисления — плохой пример. Вот вам пример получше.

namespace ???_platform
{
    bool IsSuperDevice()
    {
#ifndef UNDER_CE
        return false;
#else
        static bool isSuperDevice = FileFuncs::IsFileExist(_T("\\Windows\\superdevice.dll"));
        return isSuperDevice;
#endif
    }
}


В нашем проекте больше 50МБ кода, я не припомню ни одной проблемы с локальными статическими переменными, зато с глобальными объектами — много. Как вам, например, ситуация, когда отладчик EVC просто не всегда останавливается на breakpoints в конструкторах глобальных переменных.
Re: стиль: объявление статической переменной внутри функции
От: eremeer  
Дата: 12.09.07 14:28
Оценка:
Здравствуйте, dandy, Вы писали:

D>Ну, вообще код типа этого — объявление статической переменной внутри функции, это потенциальный источник ошибок в мало — мальски обьемной программе. Это, наверное, не мое

D>дело, но думаю, что так писать код вообще не стоит.

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

Определение статической константной переменной в функции-члене.
Преимущества.

1 Определение в теле функции-члена
Имеет смысл в том случае, если переменная используется лишь в одной (данной) функции-члене.

1.1 Инкапсуляция, сокрытие деталей реализации, т.е. "потребителю" кода становится неизвестной возможно лишняя информация о типе, способе инициализации, о внутренней структуре класса.

1.2 Упрощение интерфейса класса, он становится менее перегруженным информацией, более сконцентированным на конечных задачах

1.3 Повышение понятности кода вследствие использования переменной в месте ее инициализации (в том же блоке кода):у читающего код отпадают вопросы "в каком файле объявлена эта переменная, чем проинициализирована" и прочие.

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

1.5 Пункты 1.3 и 1.4 ведут к повышению управляемости кода.

2 Статическая переменная в теле функции-члена
Имеет смысл в том случае, если инициализация требуется единожды (н-р реализация синглтона) и/или связана с ресурсоемкими операциями.

3 Константная статическая переменная в теле функции-члена
Необходима, если не предполагается дальнейшая модификация переменной.

4 Определение статической константной переменной в функции-не-члене
Справедливы все аргументы, кроме 1.2

Недостатки
Статический объект имеет время жизни равное времени жизни программы и создается даже в том случае, если функция, где он был объявлен, ни разу не вызывалась (в случае не шаблонных функций). Выход — отложенная инициализация.
Re[2]: стиль: объявление статической переменной внутри функц
От: Erop Россия  
Дата: 12.09.07 14:57
Оценка:
Здравствуйте, Xentrax, Вы писали:

X>Думаю не стоит вводить людей в заблуждение. Статические локальные переменные — отличное средство организации singleton и отложенной инициализации по запросу, у них множество преимуществ над глобальными переменными (в том числе и статическими членами классов).

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

X>Во-первых, исключаются проблемы с порядком инициализации (почти самый страшный мой ночной кошмар, сразу после vtable boost::shared_ptr<>, указывающей в адреса выгруженной из памяти DLL).

Да? А как разрушаются созданные в разных DLL синглетоны Маерса ты ещё во сне не рассмаотривал?

X>Во-вторых, исключаются проблемы с созданем потоков и явной подгрузкой DLL из DllMain (в конструкторах статическизх объектов).

Явная функция инициализации -- это почти что "серебрянная пуля"

X>В-третьих, они вычисляются только при необходимости, чем ускоряется запуск программы и снижается потребление памяти.

Ну это да, хотя если это таки надо, то преимущество левое, а если не надо, то можно иметь явно "незагруженное" состояние ну и грузить, когда надо, либо из функции инициализации.
А иначе ты вообще никогда не поймёшь почему твоё приложение отказалось грузиться у очередного клиента
X>В-четвертых, всегда есть место куда поставить breakpoint.
А один хрен нужна система логгирования в таких штуках, а то правда никогда не поймёшь почему у клиента твоё изделие не грузится. У него же и кривая ось может приключиться...

X>Математические вычисления — плохой пример. Вот вам пример получше.

Вот как раз в свете математических вычислений тема и обсуждалась
А в свете "просто синглетонов", то тут было обсуждение на эту тему большое где-то.
ИМХО явная функция специализации должна быть "решением по умолчанию". И только наличие каких-то нереально важных причин может приводить к отказу от такого решения...

Вот у тебя, например, гараздо надёжнее, ИМХО, при старте программы где-то как-то посмотреть есть ли супердевайс и зарегить это в каких-то опциях всего приложения. А только потом работать.
Либо гарантированно этого всего не делать слишком рано, а реальную проверку делать при первой реальной нужде.

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

X>В нашем проекте больше 50МБ кода, я не припомню ни одной проблемы с локальными статическими переменными, зато с глобальными объектами — много. Как вам, например, ситуация, когда отладчик EVC просто не всегда останавливается на breakpoints в конструкторах глобальных переменных.

Ну логгирование -- это то, что надо. Ну а с тем, что проектом своим успешно управляете я вас поздравляю. Это хорошо конечно
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[3]: стиль: объявление статической переменной внутри функц
От: MasterZiv СССР  
Дата: 12.09.07 17:16
Оценка:
dandy пишет:

> Потому что код получается нечитаемый. Если эта переменная употребляется

> только в одной функции, то модификатор static вообще не нужен (и просто
> вреден).

Posted via RSDN NNTP Server 2.1 beta
Re[2]: стиль: объявление статической переменной внутри функц
От: Sni4ok  
Дата: 13.09.07 02:17
Оценка:
Здравствуйте, Xentrax, Вы писали:

X>В нашем проекте больше 50МБ кода, я не припомню ни одной проблемы с локальными статическими переменными, зато с глобальными объектами — много.


одна из проблем- инициализация локальных статических переменных в зависимости от компилятора может не являться thread safe.
Re[3]: стиль: объявление статической переменной внутри функц
От: Erop Россия  
Дата: 13.09.07 06:03
Оценка:
Здравствуйте, Sni4ok, Вы писали:

S>одна из проблем- инициализация локальных статических переменных в зависимости от компилятора может не являться thread safe.


А что, есть компиляторы, где является? Это какие? Или это от настроек всё зависит?
Но в любом случае, если делать так, что всё инициализируется из функции инициализации (в том числе и запускаются всякие допю нити), то обычно легко сделать так, чтобы всё создавалось в однопоточном окружении....
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re: стиль: объявление статической переменной внутри функции
От: dandy  
Дата: 14.09.07 17:57
Оценка: :)
Здравствуйте, dandy, Вы писали:

[]

На самом деле вопрос был скорее в стиле написания кода. Мне кажется, что сложная функциональность в С — стиле разработки — реализация функциональности в виде глобальных и статических функций более сложна в отладке и разборе. В то время как код разработанный в стиле GoF даже при явном злоупотреблении количеством абстрактных уровней намного более понятен. Переписать заново (в крайнем случае), чтобы можно было отлаживать такой код намного проще, и логов там обычно нужно меньше.

ЗЫ Неделю назад этот сайт падал при вставке смайлика внутрь тега ccode. Хотя это и не мое дело.
Re[3]: стиль: объявление статической переменной внутри функц
От: Roman Odaisky Украина  
Дата: 17.09.07 05:52
Оценка: :)
Здравствуйте, Sni4ok, Вы писали:

I>>Приведи пример, пожалуйста, где стоит объявлять статическую переменную?

S>все теже места, где разумно применять синглетоны или глобальные переменные,

Т. е., нигде?

S>а также использование статических констант.
До последнего не верил в пирамиду Лебедева.
Re[2]: стиль: объявление статической переменной внутри функц
От: Roman Odaisky Украина  
Дата: 17.09.07 05:58
Оценка: :)
Здравствуйте, eremeer, Вы писали:

E> Разрешите порассуждать человеку, не обремененному обширным опытом программирования и не претендующуему на непогрешимость и исчерпывающую полноту суждений.


Я бы проще сказал — те же преимущества и недостатки, что и у «одиночек»: трудно расширить, проблемы с инициализацией (в т. ч. thread safety), меньше оверхеда.

E>Недостатки

E>Статический объект имеет время жизни равное времени жизни программы и создается даже в том случае, если функция, где он был объявлен, ни разу не вызывалась (в случае не шаблонных функций). Выход — отложенная инициализация.

#include <iostream>

int f()
{
    std::cout << "F" << std::endl;
    return 42;
}

int g()
{
    static int const x = f();
    return x;
}

int main()
{
    //g();
}

По меньшей мере 2 компилятора не вызывают здесь f().
До последнего не верил в пирамиду Лебедева.
Re[2]: стиль: объявление статической переменной внутри функц
От: alzt  
Дата: 18.09.07 08:48
Оценка:
Здравствуйте, dandy, Вы писали:

D>ЗЫ Неделю назад этот сайт падал при вставке смайлика внутрь тега ccode. Хотя это и не мое дело.


:-)


Если вы видите этот смайлик — то исправлено.
Re[3]: стиль: объявление статической переменной внутри функц
От: Аноним  
Дата: 18.09.07 15:32
Оценка: +1
RO>По меньшей мере 2 компилятора не вызывают здесь f().
И не должны вроде как
Re: стиль: объявление статической переменной внутри функции
От: nut888 Россия  
Дата: 19.09.07 06:07
Оценка:
На мой взгляд
это может быть оправдано при использовании рекурсии
Re[4]: стиль: объявление статической переменной внутри функц
От: Sni4ok  
Дата: 19.09.07 10:57
Оценка:
Здравствуйте, Erop, Вы писали:

S>>одна из проблем- инициализация локальных статических переменных в зависимости от компилятора может не являться thread safe.


E>А что, есть компиляторы, где является? Это какие? Или это от настроек всё зависит?


насколько мне известно(со слов других, сам не проверял), что на gcc под линукс — thread safe
Re[5]: стиль: объявление статической переменной внутри функц
От: Erop Россия  
Дата: 19.09.07 11:55
Оценка:
Здравствуйте, Sni4ok, Вы писали:

S>насколько мне известно(со слов других, сам не проверял), что на gcc под линукс — thread safe

А как это реализуется, и главное, ЗА ЧТО? Это же накладно однако...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.