Работа с классами

[rrrFer]

Это ещё один огромный минус нашим преподам в универах научили блин...

Они, видимо, таких книг не читают и опыта у них нет. Я имею ввиду, таких преподов, которые дают подобные задания.

И тебе задание не нравится?
Если ты внимательно-внимательно читал то правило Мейерса, то заметил, что он грит примерно так "в нашем случае интерфейса будет достаточно, поэтому дружба не нужна". Но ведь может быть много вариантов, когда интерфейса не хватит. - допустим тебе также требуется неявно приводить типы, но в классе есть данные, которые ты не хочешь предоставлять всем подряд (геттер делать по каким-то причинам опасно), но вот этой функции те защищенные данные нужны.

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

Плохо - это дружба между классами - это факт.

А задание среднестатистическое, нормально ) Студент тоже среднестатистический - хреновый.

[8Observer8]

Сообщение от Stilet

Я пока тоже не понял в чем же ошибка преподавателей. Где вы там нашли быдлокодерство в задании?

В задании так сказано:

Реализовать методы класса: ввод дроби; сложение двух дробей; вычитание двух дробей; умножение двух дробей.

К примеру, оператор умножения дробей не может быть членом класса, так как мы не сможем умножить число на дробь. Этот оператор нужно сделать отдельной функцией.

Вот пример плохого кода, когда оператор является членом класса:

class Rational {
public:

    Rational(int numerator = 0, int denominator = 1)
    : m_numerator(numerator), m_denominator(denominator) {
    }

    void setNumerator(int n);
    void setDenominator(int d);
    int getNumerator() const;
    int getDenominator() const;
    
    const Rational operator*(const Rational& rhs);

private:
    int m_numerator;
    int m_denominator;
};

const Rational Rational::operator *(const Rational& rhs) {
    Rational result;
    result.setNumerator(m_numerator * rhs.getNumerator());
    result.setDenominator(m_denominator * rhs.getDenominator());
    return result;
}

#include <ostream>

std::ostream& operator <<(std::ostream& stream, const Rational& r) {
    stream << r.getNumerator() << "/" << r.getDenominator();
}

int Rational::getNumerator() const {
    return m_numerator;
}

int Rational::getDenominator() const {
    return m_denominator;
}

void Rational::setNumerator(int n) {
    m_numerator = n;
}

void Rational::setDenominator(int d) {
    m_denominator = d;
}

#include <iostream>

int main(int argc, char** argv) {
    // Умножаем две дроби
    Rational a(2, 5);
    Rational b(2, 3);
    Rational c;
    c = a * b; // нормально
    std::cout << "a = " << a << std::endl;
    std::cout << "b = " << b << std::endl;
    std::cout << "result = " << c << std::endl;
    
    // Умножаем дробь на число
    Rational d(1,5);
    c = d * 3; // нормально
    std::cout << c << std::endl;

    // Умножаем число на дробь
    c = 3 * d; // ОШИБКА
    return 0;
}

Это подробно описано в "Правило 24: Объявляйте функции, не являющиеся членами, когда преобразование типов должно быть применимо ко всем параметрам"

по этой ссылке: http://lib.rus.ec/b/269732/read

[8Observer8]

Сообщение от rrrFer

И тебе задание не нравится?
Если ты внимательно-внимательно читал то правило Мейерса, то заметил, что он грит примерно так "в нашем случае интерфейса будет достаточно, поэтому дружба не нужна". Но ведь может быть много вариантов, когда интерфейса не хватит. - допустим тебе также требуется неявно приводить типы, но в классе есть данные, которые ты не хочешь предоставлять всем подряд (геттер делать по каким-то причинам опасно), но вот этой функции те защищенные данные нужны.

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

Плохо - это дружба между классами - это факт.

А задание среднестатистическое, нормально ) Студент тоже среднестатистический - хреновый.

Цитата из http://lib.rus.ec/b/269732/read

lass Rational {
    ... // не содержит operator*
};

const Rational operator*(const Rational& lhs, // теперь свободная функция
        const Rational& rhs) {
    return Rational(lhs.numerator() * rhs.numerator(),
            lhs.denominator() * rhs.denominator());
}
Rational oneFourth(1, 4);
Rational result;
result = oneFourth * 2; // правильно
result = 2 * oneFourth; // ура, работает!

Это можно было бы назвать счастливым концом, если бы не одно «но». Должен ли operator* быть другом класса Rational?
В данном случае ответом будет «нет», потому что operator* может быть реализован полностью в терминах открытого интерфейса Rational. Приведенный выше код показывает, как это можно сделать. И мы приходим к важному выводу: противоположностью функции-члена является свободная функция, а функция – друг класса. Многие программисты на C++ полагают, что раз функция имеет отношение к классу и не должна быть его членом (например, из-за необходимости преобразовывать типы всех аргументов), то она должна быть другом. Этот пример показывает, что такое предположение неправильно. Если вы можете избежать назначения функции другом класса, то должны так и поступить, потому что, как и в реальной жизни, друзья часто доставляют больше хлопот, чем хотелось бы. Конечно, иногда отношения дружественности оправданы, но факт остается фактом: если функция не должна быть членом, это не означает автоматически, что она должна быть другом.
Сказанное выше правда, и ничего, кроме правды, но это не вся правда. Когда вы переходите от «Объектно-ориентированного C++» к «C++ с шаблонами» (см. правило 1) и превращаете Rational из класса в шаблон класса, то вступают в силу новые факторы, новые способы их учета, и появляются неожиданные проектные решения. Все это является темой правила 46.

[rrrFer]

К примеру, оператор умножения дробей не может быть членом класса, так как мы не сможем умножить число на дробь

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

Немного не в тему.
Неявное приведение типов, на которое упирает тут Мейерс - тоже плохо.

Чисто гипотетически, ты напишешь 2 функции
f(complex &, complex &);
f(rational &, rational &);

вызовешь f(1,1).
Если и comlex и rational могут неявно привестись - какая функция будет вызвана? - если верить Страуструпу - "вызывается наиболее подходящая".

Вобщем поэтому писать
complex a(1), b = 2 + a;
уже нехорошо.

вот я о том же.

[rrrFer]

Написал я выше про опасности всякие и даже покритиковал советы Мейерса, а вот пример, только что придумал (чуть подправил пример с cplusplus):

#include <iostream>     // std::cout
#include <numeric>      // std::accumulate

int main () {
  float numbers[] = {10.1,20.3,30.7};

  std::cout << std::accumulate(numbers,numbers+3, 1);
            << '\n';
            << std::accumulate(numbers,numbers+3, 1.f);
}

Ну вот примерно такие беды подстерегают тебя из за implicit. Если ты словишь такую ошибку - искать ее будет пи*дец как долго, я проверял.
(ну вобщем поэтому весь шум вокруг выноса функции из класса у Мейерса спорный очень). Если ты хочешь сложить число и комплектное число - так и пиши
b = complex(2) + a; // начало смотри в 14 посте

Вобщем, у Мейерса годные хорошие советы, но народная мудрость не зря грит "доверяй, но проверяй"

[8Observer8]

Сообщение от rrrFer

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

Мейерс тоже писал класс для умножения "двух дробей". А потом он вдруг сказал: "Хм..., а ведь пользователь может умножить число на дробь, ведь это вполне естественно".

Нужно сразу правильно учиться делать, чтобы на работе потом по голове не настучали. Разработчику нужно учиться предугадывать действия пользователя. Этому и учит Мейерс на данном примере. Причём пример то один в один!

[Вадим Мошев]

Сообщение от rrrFer

МБ расскажешь подробнее в чем ошибка? - я наверное быдлокодер, но ничего предрассудительного в задаче не вижу ))

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

[rrrFer]

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

Тебе именно кажется. В задаче нет слова "экран" вобще ниразу, есть слова "ввод" и "вывод". Если классы "не должны содержать операторов ввода/вывода.", нахрена эти операторы вобще в языке есть? - явно не просто так их в каждый стандарт проталкивают.

Главное, меня интересует "почему нельзя?", "почему не должны?" - пусть даже речь об экране идет.

[Utkin]

Главное, меня интересует "почему нельзя?", "почему не должны?" - пусть даже речь об экране идет.

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

[8Observer8]

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

"дробь" = "целое число" * "дробь"

Да, в задании об этом не говорится. Студент, со одной стороны, не обязан делать того, что в задании не требуется. Но всё же ведь свойственна?

Противоречие. С одной стороны, операция умножения свойственна дробям. Значит оператор умножения должен быть членом класса. С другой стороны, язык не позволит определить оператор умножения внутри класса, который принимает два аргумента . Точнее, если оператор внутри класса, то он принимает правый параметр через аргумент, а левый через this. И тогда умножение числа на дробь будет невозможна:

class Rational {
public:

    Rational(int numerator = 0, int denominator = 1)
    : m_numerator(numerator), m_denominator(denominator) {
    }

    void setNumerator(int n);
    void setDenominator(int d);
    int getNumerator() const;
    int getDenominator() const;
    
    const Rational operator*(const Rational& rhs);

private:
    int m_numerator;
    int m_denominator;
};

const Rational Rational::operator *(const Rational& rhs) {
    Rational result;
    result.setNumerator(m_numerator * rhs.getNumerator());
    result.setDenominator(m_denominator * rhs.getDenominator());
    return result;
}

#include <ostream>

std::ostream& operator <<(std::ostream& stream, const Rational& r) {
    stream << r.getNumerator() << "/" << r.getDenominator();
}

int Rational::getNumerator() const {
    return m_numerator;
}

int Rational::getDenominator() const {
    return m_denominator;
}

void Rational::setNumerator(int n) {
    m_numerator = n;
}

void Rational::setDenominator(int d) {
    m_denominator = d;
}

#include <iostream>

int main(int argc, char** argv) {
    // Умножаем две дроби
    Rational a(2, 5);
    Rational b(2, 3);
    Rational c;
    c = a * b; // нормально
    std::cout << "a = " << a << std::endl;
    std::cout << "b = " << b << std::endl;
    std::cout << "result = " << c << std::endl;
    
    // Умножаем дробь на число
    Rational d(1,5);
    c = d * 3; // нормально
    std::cout << c << std::endl;

    // Умножаем число на дробь
    c = 3 * d; // ОШИБКА
    return 0;
}

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