Реализация интерфейса[РЕШЕНО]

[Igors]

struct SomeNumber : BaseNumber {
  virtual const SomeNumber& operator + (const BaseNumber& other) const
 }

Какой Вы умный   А на что же ссылается возвращаемое SomeNumber ?

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

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

[Tonal]

Ссылок в сигнатуре, конечно, быть не должно.
Что, однако, никак не влияет на остальные рассуждения. 

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

И опять согласен.
Причём сам же, в первом своём сообщении это учёл и написал:

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

Хотя вариант сохранить сигнатуру таки есть
Если к коду, приведённому в первом посте добавить оболочку:

Код:

struct AllNumber {
  const AllNumber operator + (const AllNumber& other) const {
    return AllNumber(val.get()->add(other.val.get()));
  }
  private:
    std::auto_ptr<Number> val;
};

И пользоваться только AllNumber.

[Igors]

Хотя вариант сохранить сигнатуру таки есть
...

Код:

struct AllNumber {
  const AllNumber operator + (const AllNumber& other) const {
    return AllNumber(val.get()->add(other.val.get()));
  }
  private:
    std::auto_ptr<Number> val;
};

И пользоваться только AllNumber.

Ну "пользоваться только" - это несолидно. А почему не так

Код

C++ (Qt)
struct CFractNumber : public CBaseNumber {
  CFractNumber & operator + (const CBaseNumber & other) const 
  {
    assert(dynamoc_cast <const CFactNumber *> &other) != 0);
    CFractNumber & result = mBuf[mBufCount];
    result = *this;
    mBufCount = (mBufCount + 1) % BUF_SIZE;
    return result += other;
  }
 
  private:
    static int mBufCount = 0;
    static CFractNumber mBuf[BUF_SIZE];
 
    enum {
      BUF_SIZE = 256,
    };
};
 

[m_ax]

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

[Даниил]

Самое правильное решение

Само по себе существование такого решения в мире программирования на C++ абсурдно. Есть субъективные мнения и не более. И даже это мнение субъективно.©

[m_ax]

Само по себе существование такого решения в мире программирования на C++ абсурдно. Есть субъективные мнения и не более. И даже это мнение субъективно.©

Почитайте про шаблонное метапрограммирование, в частности про шаблоны выражений в соседней ветки: http://www.prog.org.ru/topic_21540_0.html
Как альтернатива вашему подходу, которую люди не просто так с потолка взяли и которая не на пустом месте стала очень популярным и мощным решением.

[Даниил]

Само по себе существование такого решения в мире программирования на C++ абсурдно. Есть субъективные мнения и не более. И даже это мнение субъективно.©

Почитайте про шаблонное метапрограммирование, в частности про шаблоны выражений в соседней ветки: http://www.prog.org.ru/topic_21540_0.html
Как альтернатива вашему подходу, которую люди не просто так с потолка взяли и которая не на пустом месте стала очень популярным и мощным решением.

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

[m_ax]

Само по себе существование такого решения в мире программирования на C++ абсурдно. Есть субъективные мнения и не более. И даже это мнение субъективно.©

Почитайте про шаблонное метапрограммирование, в частности про шаблоны выражений в соседней ветки: http://www.prog.org.ru/topic_21540_0.html
Как альтернатива вашему подходу, которую люди не просто так с потолка взяли и которая не на пустом месте стала очень популярным и мощным решением.

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

Я не говорю о единственно верном варианте. Я говорю, что вариант в методичке - это пример как проектировать не нужно. Это костыль, от которого можно (да, да, есть решения более изящные и гибкие) избавиться, но вам, видимо,    приятнее ходить на костылях, чем свободно передвигаться без них)
У меня ощущение, что вы всячески пытаетесь оправдать то, что с костылями ходить приятнее.. Но вы ведь даже не пробовали избавится от них.
О чём здесь ещё можно говорить?

[Igors]

m_ax, ну Вы явно перегибаете палку. Хотим реализовать конструкцию

Код

C++ (Qt)
c = a + b;
 

Используя полиморфный механизм. Почему это плохо, кАстыльно (от слова "cast") ?   Во всей Вашей уничтожающей критике я не увидел ни одного мало-мальски весомого аргумента, а Ваши альтернативные предложения звучат странно. Ввести id типа - никак не в духе полиморфизма. Вынести операторы friend - и что, как это поможет с обобщенной алгеброй? 

Возможно template здесь более подходящий подход - согласен. Ну так "в огороде бузина, а в Киеве дядька". Чем виртуалы-то плохи? Я так вижу что только одним - что-то не получилось, не удалось сделать "по известным образцам", скопировать известное решение. И все - моментально срабатывает рефлекс "костыль! велосипед! посмотри на..". Грустно 

[m_ax]

Мне тож гручтно 

Путь кто нить приведёт пример нормального поведения (и полиморфного в том числе) для данной постановки задачи. Основываясь на тех рекомендациях, что приведены в методичке.

Потом я приведу свой вариант и сравним)

[m_ax]

И да, кстатии,

Хотим реализовать конструкцию

c = a + b;
 
Используя полиморфный механизм. Почему это плохо...

Я в курсе что мы это хотим реализовать. Именно с возможностью полиморфизма.
А плохо то, что вы пытаетесь писать костыль у которого больше минусов, чем плюсов, вместо того, что бы немного изменить архитектуру и тогда можно будет строить подобные конструкции, как используя полиморфизм:

Код

C++ (Qt)
AbstractNumber *n1 = new RealNumber(3.14);
AbstractNumber *n2 = new RealNumber(2.71);
 
*n1 = *n2 + *n1;
 

так и  использовать конструкции вида:

Код

C++ (Qt)
RealNumber n1(3.14);
RealNumber n2(2.71);
 
n1 = n2 + n1; 
 

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

Так что грустно, от того, что вы оправдываете  изначально кривую архитектуру.
А почему в методичке был поставлен так вопрос - это уже другая история (возможно печальная))
 

[Даниил]

Так что грустно, от того, что вы оправдываете  изначально кривую архитектуру.

А с чего вы собственно взяли, что архитектура кривая?

[m_ax]

Так что грустно, от того, что вы оправдываете  изначально кривую архитектуру.

А с чего вы собственно взяли, что архитектура кривая?

Вы что, издеваетесь надо мной? Перечитайте этот топик несколько раз)

[Даниил]

Реализацию я переписал, числа у меня значения при арифметических операциях не меняют. Мне проще написания обращения через указатели, чем через 3 класса, т.к. обращения к арифметическим операциям у меня идут в отдельном классе и упоминаются лишь единажды в проекте. Фактически ваш вариант займет физически больше кода. Есть еще у вас варианты в пользу использования вашего метода, а не кастования типов?

[m_ax]

Реализацию я переписал, числа у меня значения при арифметических операциях не меняют. Мне проще написания обращения через указатели, чем через 3 класса, т.к. обращения к арифметическим операциям у меня идут в отдельном классе и упоминаются лишь единажды в проекте. Фактически ваш вариант займет физически больше кода. Есть еще у вас варианты в пользу использования вашего метода, а не кастования типов?

Любопытно взглянуть) Не выложите исходники?