Программирование для математиков: класс Polynomial

[VTsalyuk]

Уважаемые учащиеся-математики! Вашему вниманию предлагается более или менее полное
описание опыта разработки содержательного класса объектов математического характера. Содержится в архиве
Polynomial.zip. Начинать чтение надо с файла Polynomial.pdf.

Всего лишь 5% этого архива представляют собой программный код. Остальное --
PDF файлы с проектной документацией, документацией пользователя, комментариями к коду и т.д.

Проект носит учебный характер и поэтому реализовывался минимально необходимыми средствами. (Можно заподозрить, что только эти средства и знакомы автору Так оно и есть! Я знаю только то, что мне было необходимо узнать.)

Важно отметить, что это ни в коей мере не учебник и никак его не заменяет. Это описание попытки разработать полновесный класс, в отличие от учебных примеров, которые приводятся в учебниках (объект x класса X:-)).

Есть два способа использования этого:

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

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

Цитата из рецензии Pphantom:

Цитата:

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

В общем, если хочется, то можно опубликовать ссылку в разделе "Программирование" (но шишки будут, это можно сказать наверняка).

Следующий учебный проект, который я хочу опубликовать на этом форуме -- разработка оконного класса, предназначенного для показа/редактирования/ввода значения переменной типа double. Это опять преимущественно для математиков! Но сначала хотелось бы получить конструктивную критику здесь. Мешок для шишек подготовил.

[rockclimber]

Цитата из PDF файла:

Цитата:

А зачем изучать С++? Конечно, ради объектно-ориентированного программирования. Но ООП, с моей точки зрения, это не проектирование интерфейса пользователя вышиванием по канве, а разработка, и затем использование, классов объектов.

Фраза построена таким образом, как будто вы где-то встретили утверждение "ООП - это проектирование интерфейса пользователя вышиванием по канве", и теперь его опровергаете. Просто интересно, где можно было найти такой бред и как можно было воспринимать его всерьез.

-- 29.08.2018, 21:21 --

Кхм. После такого

Цитата:

Иногда случается, что попытка вычисления достаточно сложных выражений с многочленами вызывает ошибки на стадии компиляции. Диагностика этих ошибок иногда, хм, непонятная. Например инструкции
double A[3] = {1, 1, 2};
double B[2] = {-1, 1};
Polynomial Z(0.0);
Z += Polynomial(2, A) * Polynomial(1, B);
вызывают ошибку
Error! E189: overloaded function cannot be selected for arguments used in call
По видимому, проблема в том, что компилятор не справляется с сохранением и дальнейшим использованием промежуточных результатов вычисления.

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

[tolstopuz]

Не буду подробно останавливаться на том, что в C++ не принято использовать malloc, на ужасном хранении остатка от деления (вместо этого можно было бы спокойно вернуть pair из операции деления), на том, что конструктор по умолчанию создает объект с нарушенным инвариантом, приводящий к ошибкам при почти любых действиях с ним. Но не могу пройти мимо двухстраничной борьбы в Examples.pdf с забытым const в operator*, в результате которой сделаны выводы космического масштаба и космической же глупости. Бедные студенты, которым предстоит это читать...

-- Ср авг 29, 2018 20:25:28 --

rockclimber в сообщении #1335364 писал(а):

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

Не уверен, что это помогло бы в данном случае. Правильная работа с модификатором const - непростое дело. Стоило бы для начала почитать какую-нибудь книжку про это, а потом уже начинать писать тексты самому.

[rockclimber]

tolstopuz
Извините, я совершенно не знаю С++. В тех языках, которые знаю, при получении подобной ошибки как правило совершенно несложно догадаться, как это исправить.

-- 29.08.2018, 21:38 --

tolstopuz в сообщении #1335370 писал(а):

Не уверен, что это помогло бы в данном случае.

Догадаться, что дело не в компиляторе, который не справляется с хранением промежуточных вычислений, - можно. (Компилятор хранит промежуточные вычисления? Чудная штука ваш С++)

[Xaositect]

Что сразу бросается в глаза:

• Нет единого стиля оформления кода: в большинстве мест отступ в два пробела, но в паре мест используется один пробел, в большинстве мест закрывающая фигурная скобка идет на отдельной строке, но иногда впихнута в последнюю, в половине файлов используется очень странный стиль, где функции начинаются с отступом в один пробел.
• Проект слишком маленький, чтобы делать его некроссплатформенным. У меня с первого раза не скомпилировалось (conio.h и нессответствие регистра в названии файла Polynomial.hpp в архиве)
• В паре мест стоит точка с запятой после тела функции - будет синтаксическая ошибка на старых компиляторах.
• Операторы присваивания (=,+=,-=,*=) должны возвращать не void, а Polynomial& (ссылку на полученный после присваивания объект).
• Вместо конструктора из FILE* и метода Display нужны операторы для работы с потоками ввода-вывода.
• Дизайн деления с остатком ужасен (как минимум, нет потокобезопасности)
• Не используются даже базовые средства C++. std::vector здесь будет очень кстати, или хотя бы уж new вместо malloc.
• В C++ заголовки называются не stdio.h, а cstdio.
• Почему это вообще не шаблонный класс?

[warlock66613]

- using namespace в заголовочном файле
- невиртуальный деструктор в не-final классе

[Munin]

Xaositect в сообщении #1335381 писал(а):

Операторы присваивания (=,+=,-=,*=) должны возвращать не void, а Polynomial& (ссылку на полученный после присваивания объект).

Всё-таки const Polynomial &.

[Xaositect]

Munin в сообщении #1335390 писал(а):

Всё-таки const Polynomial &.

Нет.

[mihaild]

Munin в сообщении #1335390 писал(а):

Всё-таки const Polynomial &.

Возвращать Polynomial&. Принимать - const Polynomial&.

[EtCetera]

Munin в сообщении #1335390 писал(а):

Xaositect в сообщении #1335381 писал(а):

Операторы присваивания (=,+=,-=,*=) должны возвращать не void, а Polynomial& (ссылку на полученный после присваивания объект).

Всё-таки const Polynomial &.

C++ Core Guidelines в разделе "C.60: Make copy assignment non-virtual, take the parameter by const&, and return by non-const&" писал(а):

An assignment operator should return T& to enable chaining, not alternatives like const T& which interfere with composability and putting objects in containers.

Лично от себя замечу в противовес процитированному, что этот самый chaining вещь не настолько нужная, насколько потенциально ошибкоёмкая (в особенности при возврате неконстантной ссылки), поэтому возврат void в принципе кажется более разумным (хоть это и противоречит сложившейся практике).

[Pphantom]

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

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

Во-вторых, даже учебные задачи стоит подбирать так, чтобы осваиваемый инструмент был адекватен задаче. А писать что-либо подобное на C++ противоестественно. Консерваторы и те, кому необходима скорость, будут использовать Fortran или C; любители быстрой реализации воспользуются Python; пуристы возьмут какой-либо функциональный язык; те, кому нужно разовое решение, просто используют какой-нибудь матпакет. В общем-то математикам (которым номинально адресован пример) именно C++ (да и, по большому счету, ООП в целом) в принципе не нужен, так что даже при идеальном коде основная цель не вполне разумна.

[tolstopuz]

EtCetera в сообщении #1335396 писал(а):

поэтому возврат void в принципе кажется более разумным (хоть это и противоречит сложившейся практике).

К сожалению, стандарт запрещает класть объекты с const T& operator=(const T&) в контейнеры типа vector, потому что они не CopyAssignable. Фактически is_copy_assignable не проверяет тип возврата operator=, но мало ли что изменится в следующей версии стандарта.

[mihaild]

tolstopuz в сообщении #1335404 писал(а):

К сожалению, стандарт запрещает класть объекты с const T& operator=(const T&) в контейнеры типа vector, потому что они не CopyAssignable

vector для просто создания требует только Erasable. И скажем unique_ptr не CopyAssignable, но класть их в контейнер вполне можно.

[EtCetera]

tolstopuz
Да, вот это требование CopyAssignable, чтобы возвращаемое значение было неконстантной ссылкой, мне и кажется нездоровым (и продиктовано оно, по-видимому, прежде всего историческими причинами, дабы не ломать горы уже возведённого).

[Munin]

Xaositect
mihaild
tolstopuz
Спасибо. Значит, я устарел.