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

D>здесь.

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

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

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

Конечно же можно лучше, этот код — всего лишь пример и писался почти что на коленке

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

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

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

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

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

Стр. 16 по книге, пункт 1.8. подпункты [1] с) и [1] d). Хотя эти советы после написания сотни — другой классов и без того очевидны.

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

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

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

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

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

Здравствуйте, 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>?

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

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

Интересно бы было узнать примерное направление развития этой программы, которое облегяается таким подходом...

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

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

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

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

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

Да. Присоединяюсь. Весело все же.

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

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

Ну да, будем надеяться

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

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

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

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

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

Данди! Ты ещё жив? А то что-то как-о мы тебя заклевали до больной головы и привет. Это последний товой пост

Автор: dandy
Дата: 07.09.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 в конструкторах глобальных переменных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

dandy пишет:

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

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

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

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

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

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

А что, есть компиляторы, где является? Это какие? Или это от настроек всё зависит?
Но в любом случае, если делать так, что всё инициализируется из функции инициализации (в том числе и запускаются всякие допю нити), то обычно легко сделать так, чтобы всё создавалось в однопоточном окружении....

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

[]

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

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