Здравствуйте, 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>Да какое же это чудовище? Мне оно кажется и симпатичнее и выразительнее. Хотя о вкусах не спорят. И по — моему в таком коде разобраться таки — проще.


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

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

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

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

D>Речь не об управлении временем жизни объектов, а о том, как сделать код прозрачным.
Очень хорошо. Почему твой вариант "более прозрачный"? Что виднее?

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

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

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

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

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

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

С уважением.

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

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


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

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

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

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

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

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

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

К>Здравствуйте, 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>не потокобезопасен.
К>Так что если программа многопоточная, нужно выкручиваться.

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

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

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

Согласен.

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

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

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

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

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

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

Или тебе хочется, чтобы всё было Очень Явно и с кучей обвесок?
Типа, пока не написал рядом с переменной [ThisIsSingleton], [ThisIsAdaptor] или std::binary_function<bool,int,int>, она синглетоном, адаптером или компаратором не станет?

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>>не потокобезопасен.
К>>Так что если программа многопоточная, нужно выкручиваться.

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

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

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

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

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

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

К>Или тебе хочется, чтобы всё было Очень Явно и с кучей обвесок?
К>Типа, пока не написал рядом с переменной [ThisIsSingleton], [ThisIsAdaptor] или std::binary_function<bool,int,int>, она синглетоном, адаптером или компаратором не станет?

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

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

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

Понятно, ответа значит нет. Бывает...

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

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

I>А Calculate зачем virtual?

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

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

Кое-что подзабыл. Исправляюсь.

К>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;
К>};

Кстати, философский вопрос — взводить флажок до или после (или вместо)
Можно просекать рекурсию, устанавливая флажок в позицию "занято" перед вычислением и в "готово" после.

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

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

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

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

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

Даже спорить не хочу, насколько это примерно не то же самое.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

здесь. Спасибо т. Bell и Кодту.