-
- Просто хаос в голове. Tyмблep(1531 знак., 22.07.2024 16:43)
- Вы полюбому напишете эти процэдуры с параметрами, в том или ином
виде. mse homjak(703 знак., 22.07.2024 18:27)
- А вы хотели, чтобы процедуры сами собой взошли, без труда ? Типа
крекс-фекс-пекс - и готово ? Tyмблep(343 знак., 22.07.2024 20:10)
- Ну? Я-жэ и говорю:"жмёшь кнопку, мешок на спине, жмёшь другую, спина в мыле". mse homjak(138 знак., 22.07.2024 20:55)
- Бывает. У меня именно так. Без всех этих огромных (но бесполезных)
надстроек. Cкpипaч(323 знак., 22.07.2024 20:19)
- Что бывает ? Tyмблep(194 знак., 22.07.2024 20:22)
- Бывает - "типа крекс-фекс-пекс - и готово". Cкpипaч(152 знак., 22.07.2024 20:32)
- Если речь идет о написании нового кода, а не подгонки старого, то
ООП, в целом, выигрывает на любом уровне сложности. Точнее, она
ничем не хуже по затратам по сравнению с обычным программирования,
но более надежна и модернизируема. Вы можете писать в стиле ООП, не "включая" ООП, а при необходимости легко перейти -
"включить". Вам не надо переписывать код. Единственное ограничение
сегодня, это возможности компилятора. - Anvar(23.07.2024 06:37)
- ООП, с моей колокольни, это лишние абстракции и лишний текст, в
сравнении с модульным программированием. Избыточность +
спагетти-код, в его обьектной реинкарнации. Оно не может
выигрывать. Cкpипaч(269 знак., 23.07.2024 08:12)
- Модуль работы с периферией на ООП несущественно сложнее обычного
модуля. Его небольшое усложнение с лихвой окупается надежностью
кода из за абстракции данных и методов для пользователя - он ничего
не может сломать. А все эти наследования, полиморфизм это уже
дополнительные плюшки, которые не обязательны - Anvar(23.07.2024 09:08)
- Ключевое "для пользователя". Т.е. для человека, который получил это
в готовом виде, написанное, отлажэнное и документированное. mse homjak(146 знак., 23.07.2024 10:56)
- Можно подумать на неООП этого делать не надо - Anvar(23.07.2024 11:09)
- Именно, что надо. У чом выигрыш-то? Если нет перспективы хотя-бы двухкратного использования, имеем дурную работу. Да и дажэ для двух-трёх раз заморачиваться, такое себе. Это всё прекрасно, когда тебе дали на блюдечке с каёмочкой и ты его юзаешь налево-направо, как в каком Винтеле. Там ООП безальтернативен и писать мегапроги можэт туловище, не знающее чем триггер отличается от триппера. mse homjak(179 знак., 23.07.2024 12:17)
- Можно подумать на неООП этого делать не надо - Anvar(23.07.2024 11:09)
- Темплейты, иерархия классов, полиморфизм? Нет, я сам умею писать на Паскале для компилятора С++ (и будет несложно), но в чистом эксперименте - радикально сложнее. - Cкpипaч(23.07.2024 10:43)
- Ключевое "для пользователя". Т.е. для человека, который получил это
в готовом виде, написанное, отлажэнное и документированное. mse homjak(146 знак., 23.07.2024 10:56)
- Модуль работы с периферией на ООП несущественно сложнее обычного
модуля. Его небольшое усложнение с лихвой окупается надежностью
кода из за абстракции данных и методов для пользователя - он ничего
не может сломать. А все эти наследования, полиморфизм это уже
дополнительные плюшки, которые не обязательны - Anvar(23.07.2024 09:08)
- ООП, с моей колокольни, это лишние абстракции и лишний текст, в
сравнении с модульным программированием. Избыточность +
спагетти-код, в его обьектной реинкарнации. Оно не может
выигрывать. Cкpипaч(269 знак., 23.07.2024 08:12)
- Если речь идет о написании нового кода, а не подгонки старого, то
ООП, в целом, выигрывает на любом уровне сложности. Точнее, она
ничем не хуже по затратам по сравнению с обычным программирования,
но более надежна и модернизируема. Вы можете писать в стиле ООП, не "включая" ООП, а при необходимости легко перейти -
"включить". Вам не надо переписывать код. Единственное ограничение
сегодня, это возможности компилятора. - Anvar(23.07.2024 06:37)
- Бывает - "типа крекс-фекс-пекс - и готово". Cкpипaч(152 знак., 22.07.2024 20:32)
- Что бывает ? Tyмблep(194 знак., 22.07.2024 20:22)
- А вы хотели, чтобы процедуры сами собой взошли, без труда ? Типа
крекс-фекс-пекс - и готово ? Tyмблep(343 знак., 22.07.2024 20:10)
- СТМовский Куб обходится как-то без этого мракобесия. И его
применение не вызывает особых затруднений. Есть претензия к
качеству кода, но этодругое. - =AlexD=(22.07.2024 16:55)
- Кстати, интересный вопрос, почему в КУБ-е не использовали эти
возможности С++? - AlexBi(22.07.2024 18:53)
- А смысл? Делать две разные либы - одна на Си, другая на С++? Не, ну сделать свои обёртки они конечно могут, но видимо не видят смысла в лишней работе. - =AlexD=(23.07.2024 09:27)
- Вероятно, я знаю эту тайну. Tyмблep(732 знак., 22.07.2024 20:47)
- Опытные программисты знают что если пишешь не для себя, а для
использования другими, то лучше не применять всю мощь плюсов без
особой необходимости. Иначе потом замучают вопросами "как это
использовать?" и воплями "ничего не понятно" и "ничего не
работает". А сделать библиотеку которую смогут использовать не
заглядывая внутрь - это ещё более сложная задача, особенно когда
процессор в 200 раз медленнее и памяти в миллион раз меньше. - ЫЫyкпy(23.07.2024 08:46)
- Основная проблема объектных библиотек (вне зависимости от языка) в том, что авторы не могут предусмотреть все варианты использования. А чаще всего возникает необходимость использовать какую-то часть библиотеки отдельно, вне иерархии. Например не на поток данных, а на файл или структуру в памяти. Процедурные библиотеки в этом плане проще, там только с хедерами могут накосячить, напихав в них всё что ни попадя. Но с этим можно бороться. С иерархией классов уже ничего не сделать =AlexD=(1 знак., 23.07.2024 09:24)
- С++ с современными возможностями, метапрограммированием выглядит не таким простым как С - AlexBi(22.07.2024 23:39)
- Опытные программисты знают что если пишешь не для себя, а для
использования другими, то лучше не применять всю мощь плюсов без
особой необходимости. Иначе потом замучают вопросами "как это
использовать?" и воплями "ничего не понятно" и "ничего не
работает". А сделать библиотеку которую смогут использовать не
заглядывая внутрь - это ещё более сложная задача, особенно когда
процессор в 200 раз медленнее и памяти в миллион раз меньше. - ЫЫyкпy(23.07.2024 08:46)
- А что это даст? (ну кроме самого по себе "использования") - Cкpипaч(22.07.2024 20:18)
- Программа станет более понятной, меньше по объему, написанному руками (код КУБа не учитываем), лучше контроль ошибок несовместимости настроек (заполняя разные структуры легко ошибиться), результирующий код меньше/быстрее (оптимизатор еще не так крут, на сколько мне известно) - AlexBi(22.07.2024 23:36)
- Кстати, интересный вопрос, почему в КУБ-е не использовали эти
возможности С++? - AlexBi(22.07.2024 18:53)
- Вы полюбому напишете эти процэдуры с параметрами, в том или ином
виде. mse homjak(703 знак., 22.07.2024 18:27)
- Просто хаос в голове. Tyмблep(1531 знак., 22.07.2024 16:43)