Матрица. Перегрузка операторов

[_Bers]

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

Инвариант класса даёт гарантию пребывать в корректном состоянии, пока он доступен для использования, но что делать, если по каким-то причинам он перешёл или перейдёт в некорректное состояние после следующего действия?

Не понял вопроса.

[netrino]

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

Не понял вопроса.

Что делать объекту класса, если в результате каких-либо действий он перешёл/может перейти в некорректное состояние? Как-то умножение на несовместимую матрицу. Это один из тех примеров, где вполне оправданно использование исключений, так как класс не в состоянии ничего предпринять для устранения проблемы.

[Пепел Феникса]

Иначе что? Система обрушится, или как?

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

Аргумент пришёл не_валидный? Ну и как это может повредить целостности класса?

класс не может выполнить то что от него хотят.
это по вашему не ошибка?

исключения так же приручают обрабатывать ошибки всегда, а не плевать на них(некорректный ввод, тоже ошибка)

А если это реально ошибка программиста, ну поймает её ловушка исключений, и чего? Каким таким образом прикажете ловушкам исключений исправлять ошибки самого программиста?

можно умереть по красивее, а не просто сгинуть.

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

то есть один блок try catch на три инструкции подрят это сильно уродливее трех if(к ним же)?

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

как минимум нормальная программа всегда должна реагировать на ошибки.

Он не знает, какие из его сигналов принципиально важны для вызывающей стороны, а какие нет.

зато он знает, что если он бросает сигнал значит он не может работать.
а если вызывающей стороне пофиг, на то отработал ли он или нет, то нафиг тогда вообще вызывать было?

еще актуален вопрос настраиваемого поведения по исключениям.

PS: я сейчас по работе пишу программу(центральная, см далее) для управления копировальным автоматом(ксерокс), обрабатываю сигналы от купюроприемника, от клавиатуры, от монетоприемника, и управляю дисплеем(из всего этого тока клава чуть менее обычная, лишь 5 клавиш).
автомат должен быть полностью независим, и обработка ошибок это святое.
и у меня стоит по if на каждый read,open,select.
поверьте код не сильно шикарный от этого становиться.

[_Bers]

Сообщение от Пепел Феникса

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

ой ли? А может так задумано было. Откуда вы знаете, как именно устроена вызывающая сторона, и чего она в итоге ожидает?

Сообщение от Пепел Феникса

класс не может выполнить то что от него хотят.
это по вашему не ошибка?

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

Либо вызывающая сторона допускает вероятность подобной ситуации.
И считает данную ситуацию частью своей штатной работы.
В этом случае не_валидный аргумент никак не может угрожать ни работоспособности класса (который просто не пропустит такой аргумент), ни работоспособности вызывающей стороны (которая сознательно предусматривает подобный исход). Если вызывающей стороне обязательно нужен отчет класса о проделанной работы - пожалуйста. Для этого кодов ошибок хватит за глаза.

Сообщение от Пепел Феникса

можно умереть по красивее, а не просто сгинуть.

Для безопасного кода не очень хороший подход. Для безопасности лучше совсем не умирать.

Сообщение от Пепел Феникса

то есть один блок try catch на три инструкции подрят это сильно уродливее трех if(к ним же)?

Да.

Сообщение от Пепел Феникса

зато он знает, что если он бросает сигнал значит он не может работать.
а если вызывающей стороне пофиг, на то отработал ли он или нет, то нафиг тогда вообще вызывать было?

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

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

Теперь Вася и Миша конструируют большую систему, а Феникс конструирует отдельный класс по работе с этим файлом.

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

Вася с Мишей заколеблются писать кучу ловушек для всех своих элементов, хотя им это исключение вообще три раза не упало. Им было бы достаточно, что бы класс просто тупо-молча возвращал этот многострадальный хэндл.

Если бы такой класс делал я, то я бы не додумывал за вызывающую сторону, а возвращал бы хэндл, и делал пометку для GetLastError()

Потому что я знаю: ответственность класса - делать свою работу, и при этом не допустить крэша по его вине.

Если сигналы класса вызывающей стороной были проигнорированы, значит либо вызывающая сторона косячная (нарушение её инварианта), либо это нормальный рабочий

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

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

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

[Пепел Феникса]

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

ну может вы так и напишите.
тут просто проситься синглетон(или класс со статическим полем файла)

Если сигналы класса вызывающей стороной были проигнорированы, значит либо вызывающая сторона косячная (нарушение её инварианта), либо это нормальный рабочий

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

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

подведу итог:
писать вам и дело ваше, я лично применяю опыт полученный с других ЯП.

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

[_Bers]

Сообщение от Пепел Феникса

ну может вы так и напишите.
тут просто проситься синглетон(или класс со статическим полем файла)
а кто мешает делать так же с исключениями?

Я к тому речь веду, что класс решает - будет он работать, или не будет.
А вот ошибка это или нет - решать вызывающей стороне, а не классу.

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

Сообщение от Пепел Феникса

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

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

[Пепел Феникса]

Я к тому речь веду, что класс решает - будет он работать, или не будет.
А вот ошибка это или нет - решать вызывающей стороне, а не классу.

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

тут еще есть решение как относиться к исключениям, для меня обработка ошибок это святое.

[ElectroMent]

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

matrix& matrix :: operator *= (const matrix& x1) 
{
	if( СhM(x1) ) //СhM - проверка на возможность умножения двух матриц
	{
		*this=this*x1;
	} 
	
	else throw "ERROR"; 
	return *this;
}

Написал следующее, каким еще способом можно перегрузить оператор *= и почему первый наиболее эффективный?

Общий случай:
1. operator *= работает c мин. накладными затратами, чем его братья - бинарный и унарный operator * (у последних будет по крайне мере 2 выделения памяти. (вызовы конструкторов и одного деструктора !если надо))

Чтобы минимизировать затраты:
а) operator *= - выполняет непосредственное умножение и присвоение
б) operator * ( унарный и бинарный ) реализуют через operator *=

Потому как ты реализовал крайне не рекомендуется. (Припаял еще вызов operator = )

*this=this*x1;

Вот один из возможных вариантов.

matrix& matrix :: operator *= (const matrix& x1) 
{
   //умножение матриц c сохранением результата в this
   ...
   return *this;
}

const matrix matrix :: operator * (const matrix& x1) 
{
   matrix res( *this );
   res *= x1;
   return res;
}

const matrix matrix :: operator * (const matrix& x1, const matrix& x2 ) 
{
   matrix res( x1 );
   res *= x2;
   return res;
}

Касательно исключений и блоков try / catch - желательно минимизировать их.
Не стремись к универсальности, делай матрицы определенного типа, чтоб не было исключительных ситуаций (не той размерности) и тогда не потребуются исключения.

Касательно матриц и их умножения - страйся вообще их не умножать - почитай "отложенные вычисления" у Страуструпа.