Когда человек видит оператор для пользовательских типов, он и так
понимает что в первый раз необходимо посмотреть документацию или
код. Некоторый малый рост сложности по сравнению с линейным дубовым
написанием существует, это объективно и нельзя отрицать. Но как
только требуется что-то посложнее Mtx4_Mul(&result, &mtx1,
&mtx2); - а это будет именно так. т.е. серия
сложений-перемножений итд лучше если запись будет как можно проще,
операторы инкапсулированы в/с объектами, и объекты будут сами управлять памятью. Я понимаю, что поскольку я вынужден это тебе объяснять, вероятно ты не сталкивался с этими проблемами. А это реально проблемы. Писать в 3D движке или коде игрушки перемножение нескольких матриц, векторов или кватернионов в виде V1 * (B * C) * D при том что умножение матриц/векторов некоммутативно дело десятков секунд. Предполагается что operator* отлажен и всё работает из коробки. А вот написать композицию из функций принимающих взаимные результаты (сразу вспоминается OpenGL 1.x) - это нетривиально, и еще будет предстоять пошаговая отладка. Короче, инкапсуляция и объектный подход рулит, это однозначно.
RxTx (30.05.2024 17:32, просмотров: 140) ответил Cкpипaч на Потому что это не очевидно из текста самой строки. Нужно в голове
держать дополнительную информацию. Даже: c =
a.hyperspace_mul_by(b); намного лучше.