caxapa.ru :: Про само*** опустим. А вот умножение матриц через оператор * , при условии что матрица инкапсулирована в объект (символ) дает снижение сложности. Управление сложностью помогает сделать систему более понятной. Накладные расходы могут возрастать.

RxTx (23.05.2024 22:49, просмотров: 58) ответил mr-x на Ещё остался открытым вопрос благо ли это. Как по мне, то как минимум сомнительное. Умножение матриц через "*" даёт что? Делает код короче? Хочется ругаться матом, поэтому промолчу. Самосохраняющиеся переменные зачем? Чтобы через некоторое время выпустить это дело из внимания и облажаться? 24-х битные целые - это прикольно. Однако даже с базовыми целочисленными не всё / не всем до конца понятно, есть нюансы, тут ещё новый тип на нашу голову.

Про само*** опустим. А вот умножение матриц через оператор * , при условии что матрица инкапсулирована в объект (символ) дает снижение сложности. Управление сложностью помогает сделать систему более понятной. Накладные расходы могут возрастать.

Спасибо, князь. Вы настоящий дворянин. И программист.

Ответить

- Что такое "***" не понятно. А в A*B спич не про инкапсуляцию, а про перегрузку операторов. - mr-x(24.05.2024 10:19)
  - Слово "самосохранение" было длинное: я хотел написать "самосохранение опустим". Важна именно инкапсуляция в объекте "матрица" необходимых операторов/методов/полей. Это делает конечный код менее сложным и более понятным. - RxTx(30.05.2024 05:04)
    - Менее/более относительно чего? Плохого кода на бейсике? В Сях я работал с библиотекой с точно такими же паблик и приват методами и членами. И точно так же из-за вИденья афтора не мог реализовать весь потенциал либы без вытягивания символов из её внутренностей. Потому что сцуко красивые лаконичные абстракции снаружи. И пришлось трахнуть эту либу для извлечения скрытых элементов данных. - =AlexD=(30.05.2024 09:20)
      - AlexG: > С абстракциями в C++ можно оторваться по полной. Например, для начала сделать: <...> ...матрицы, математические операции с которыми в коде записываются в стиле A*B RxTx(123 знак., 30.05.2024 15:20)
        
        Я не умножаю матрицы каждый день. Гораздо чаще мне приходится следить за тем, что-бы списки не сожрали всю память. И С++ мне тут ну вообще никак не поможет, скорее спрячет проблему, запутает и заставит приделать к библиотеке костыли. В своё время я наигрался с С++ всласть. Шаблоны с инлайн методами позволяют экономить каждый байт сохраняя неплохую модульность проекта. Но в целом писать val->metod() или metod(val) - разница не велика. - =AlexD=(30.05.2024 16:33)
        
        А VAL::Method(); ? - VladislavS.(30.05.2024 17:29)
        
        VAL_Method() Синтаксический сахар в С++ есть, но не совсем там где хотелось бы и довольно кривовато. На С++ я большую часть времени думаю как ему объяснить чего хочу. Временами просто подбешивает. - =AlexD=(30.05.2024 17:47)
        
        Ещё VAL_Method легко переименовать в VAL_Method2 сразу во всех исходниках. А Method внутри VAL запаришься выколупывать по всем исходникам, чтобы при этом не затронуть другой Method внутри VAL2 и других классах/неймспейсах. - Ale3000(31.05.2024 07:33)
        
        +100! Конечно сейчас никто уже не пишет код в редакторе Нортон Командера (я - пишу), но возможность найти простым текстовым поиском - полезна. - Cкpипaч(31.05.2024 07:45)
        
        А в каких редакторах работает переименование членов класса по всему исходнику? Пробовал eclipse и VS Code - не нашёл там такого. Это есть в Embarcadero, но не работает: глючит и портит исходник. - Ale3000(31.05.2024 10:14)
        
        Рефакторинг в Clion работает с огромными проектами. Также Visual Studio (не Code). Также Vim и плагины. - RxTx(31.05.2024 20:41)
        
        Имеется в виду гарантированно работает, как промышленный результат. На который можно полагаться. И результат которого гарантированно откатывается целиком самой средой. Рефакторинг в Clion работает не на текстовом уровне, он работает на уровне семантики кода. - RxTx(01.06.2024 11:00)
        
        Кхе-кхе :) Ссылка(->) PyCharm неплохо справляется. А на Си я избегаю повторяемых имен. Все что нелокальное - имеет длинное, интуитивно понятное имя. Cкpипaч(1 знак., 31.05.2024 15:44, ссылка)
        
        SlickEdit вроде нормально рефакторит, но на очень больших проектах не проверял. Делаю проще - меняю имя и смотрю где компиляция упала. Но бывают проблемы с условной компиляцией и закомментированными огрызками. - =AlexD=(31.05.2024 10:38)
        
        Бывает, что компилируется нормально. Например, вместо переименованного метода подсовывает метод из родительского класса. Или в дочернем классе переименовал метод, а в родительском классе этот же метод, но виртуальный, не переименовал. В результате совершенно другая часть программы начинает по-другому работать. Трудно такие ошибки искать. - Ale3000(31.05.2024 10:53 - 13:10)
        
        О, ну эту жопу лучше вообще не трогать. Это выстрел даже не в ногу а сразу в яйца. - =AlexD=(31.05.2024 13:06)
- Возражаю. Знание что "оператор *" имеет нестандартное поведение увеличивает сложность! Cкpипaч(36 знак., 24.05.2024 09:31)
  - Чойта вдруг - RxTx(30.05.2024 06:09)
    - Потому что это не очевидно из текста самой строки. Нужно в голове держать дополнительную информацию. Даже: c = a.hyperspace_mul_by(b); намного лучше. - Cкpипaч(30.05.2024 16:19)
      - Когда человек видит оператор для пользовательских типов, он и так понимает что в первый раз необходимо посмотреть документацию или код. Некоторый малый рост сложности по сравнению с линейным дубовым написанием существует, это объективно и нельзя отрицать. Но как только требуется что-то посложнее Mtx4_Mul(&result, &mtx1, &mtx2); - а это будет именно так. т.е. серия сложений-перемножений итд лучше если запись будет как можно проще, операторы инкапсулированы в/с RxTx(664 знак., 30.05.2024 17:32)

Микроконтроллеры