-
- Ещё остался открытым вопрос благо ли это. Как по мне, то как
минимум сомнительное. Умножение матриц через "*" даёт что? Делает
код короче? Хочется ругаться матом, поэтому промолчу.
Самосохраняющиеся переменные зачем? Чтобы через некоторое время
выпустить это дело из внимания и облажаться? 24-х битные целые -
это прикольно. Однако даже с базовыми целочисленными не всё / не
всем до конца понятно, есть нюансы, тут ещё новый тип на нашу
голову. - mr-x(23.05.2024 22:11)
- Про само*** опустим. А вот умножение матриц через оператор * , при
условии что матрица инкапсулирована в объект (символ) дает снижение
сложности. Управление сложностью помогает сделать систему более
понятной. Накладные расходы могут возрастать. - RxTx(23.05.2024 22:49)
- Что такое "***" не понятно. А в 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)
- Кхе-кхе :) Ссылка(->) 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)
- Бывает, что компилируется нормально. Например, вместо
переименованного метода подсовывает метод из родительского класса.
Или в дочернем классе переименовал метод, а в родительском классе
этот же метод, но виртуальный, не переименовал. В результате
совершенно другая часть программы начинает по-другому работать.
Трудно такие ошибки искать. - Ale3000(31.05.2024 10:53 - 13:10)
- А в каких редакторах работает переименование членов класса по всему
исходнику? Пробовал eclipse и VS Code - не нашёл там такого. Это
есть в Embarcadero, но не работает: глючит и портит исходник. - Ale3000(31.05.2024 10:14)
- +100! Конечно сейчас никто уже не пишет код в редакторе Нортон
Командера (я - пишу), но возможность найти простым текстовым
поиском - полезна. - Cкpипaч(31.05.2024 07:45)
- Ещё VAL_Method легко переименовать в VAL_Method2 сразу во всех
исходниках. А Method внутри VAL запаришься выколупывать по всем
исходникам, чтобы при этом не затронуть другой Method внутри VAL2 и
других классах/неймспейсах. - Ale3000(31.05.2024 07:33)
- VAL_Method() Синтаксический сахар в С++ есть, но не совсем там где
хотелось бы и довольно кривовато. На С++ я большую часть времени
думаю как ему объяснить чего хочу. Временами просто подбешивает. - =AlexD=(30.05.2024 17:47)
- А VAL::Method(); ? - VladislavS.(30.05.2024 17:29)
- Я не умножаю матрицы каждый день. Гораздо чаще мне приходится
следить за тем, что-бы списки не сожрали всю память. И С++ мне тут
ну вообще никак не поможет, скорее спрячет проблему, запутает и
заставит приделать к библиотеке костыли. В своё время я наигрался с
С++ всласть. Шаблоны с инлайн методами позволяют экономить каждый
байт сохраняя неплохую модульность проекта. Но в целом писать
val->metod() или metod(val) - разница не велика. - =AlexD=(30.05.2024 16:33)
- AlexG: > С абстракциями в C++ можно оторваться по полной.
Например, для начала сделать: <...> ...матрицы,
математические операции с которыми в коде записываются в стиле
A*B RxTx(123 знак., 30.05.2024 15:20)
- Менее/более относительно чего? Плохого кода на бейсике? В Сях я
работал с библиотекой с точно такими же паблик и приват методами и
членами. И точно так же из-за вИденья афтора не мог реализовать
весь потенциал либы без вытягивания символов из её внутренностей.
Потому что сцуко красивые лаконичные абстракции снаружи. И пришлось
трахнуть эту либу для извлечения скрытых элементов данных. - =AlexD=(30.05.2024 09:20)
- Слово "самосохранение" было длинное: я хотел написать
"самосохранение опустим". Важна именно инкапсуляция в объекте
"матрица" необходимых операторов/методов/полей. Это делает конечный
код менее сложным и более понятным. - RxTx(30.05.2024 05:04)
- Возражаю. Знание что "оператор *" имеет нестандартное поведение увеличивает сложность! 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)
- Потому что это не очевидно из текста самой строки. Нужно в голове
держать дополнительную информацию. Даже: c =
a.hyperspace_mul_by(b); намного лучше. - Cкpипaч(30.05.2024 16:19)
- Чойта вдруг - RxTx(30.05.2024 06:09)
- Что такое "***" не понятно. А в A*B спич не про инкапсуляцию, а про
перегрузку операторов. - mr-x(24.05.2024 10:19)
- Про само*** опустим. А вот умножение матриц через оператор * , при
условии что матрица инкапсулирована в объект (символ) дает снижение
сложности. Управление сложностью помогает сделать систему более
понятной. Накладные расходы могут возрастать. - RxTx(23.05.2024 22:49)
- Бесплатных пряников не бывает. За все блага придется платить, каждая прослойка содержит кирпич, которым вас ударит по голове. Не удивляйтесь когда это произойдет. - Cкpипaч(23.05.2024 21:36)
- Ещё остался открытым вопрос благо ли это. Как по мне, то как
минимум сомнительное. Умножение матриц через "*" даёт что? Делает
код короче? Хочется ругаться матом, поэтому промолчу.
Самосохраняющиеся переменные зачем? Чтобы через некоторое время
выпустить это дело из внимания и облажаться? 24-х битные целые -
это прикольно. Однако даже с базовыми целочисленными не всё / не
всем до конца понятно, есть нюансы, тут ещё новый тип на нашу
голову. - mr-x(23.05.2024 22:11)