IT в России и мире в реалиях мирового кризиса
1,360,489 8,118
 

  _IAJ_ ( Слушатель )
08 май 2023 11:53:09

Вы хотели практика об ООП? Ну....

новая дискуссия Дискуссия  135

Сижу вот, и ржу.
Не, ребята, вы конечно молодцы. Знакомы с теорией автоматического управления. В кирове, когда то, слышали про тряску станин станков (о чем мы с Махно и вовсе не слышали), а рэт (не подумайте плохого, я всегда читаю Вас с интересом) даже, сцуко, знает о указателях на функции.
Но
Но, ребята, если вы говорите об ООП, то по крайней мере надо знать, во что есть. Я вот не знаю. Но я не знаю, что вы имели ввиду. Я готов обсуждать C++ и его фенечки (иногда довольно дурные фенечки), Ради бога. Я мыслю на этом языке. Я самоучка, и это мне во многом мешает, я ремесленник.Но об ООП как концепции я говорить не готов. Оно разное.....
  • -0.06 / 3
  • АУ
ОТВЕТЫ (14)
 
 
  adolfus ( Слушатель )
08 май 2023 14:49:26

C++ не является ОО языком. Это универсальный язык программирования "с элементами ООП", причем реализованными не очень хорошо, если не сказать грубее. ООП-язык не предполагает использования стека для размещения переменных и объектов, а также отрицает рекурсию. А автоматические переменные – это переменные в стеке, а рекурсия – основа функционального программирования. 
Да и задач, которые хорошо или даже просто без натяжки ложатся на ОО парадигму не очень много. Вот, например, нынче пытаются заменить в автокаде и производных лисп питоном. Причина – программисты поголовно отравлены ОО парадигмой, не в состоянии думать в рамках функционального программирования и понимают лишь сущности с состоянием. Результат – стагнация проекта. 
ОО парадигма имеет одну очень поганую вещь – наследование. Эта мерзость совместно с такой хренью, как "use cases", препятствует устранению ошибок, совершенных на начальной стадии разработки, а также препятствует развитию проекта. Пример – вордпроцессоры. Объектно-ориентированный базис в основе staroffice/openoffice/libreoffice навечно заморозил ошибки, совершенные на стадии начального проектирования. Даже IBM, обладающая крутейшими программистами, слила в конце концов свой вариант опенофиса, так и не справившись с проблемами. Там проблема на проблеме, начиная от представления страниц, параграфов, таблиц и всего остального, включая конвейер отрисовки. Все это выстроено в виде иерархии классов и, как это всегда имеет место у ОО-проектов, генерирует эффект тришкиного кафтана, когда какую-то проблему таки решают, однако в результате появляется новая, как побочный результат. Та же картина и у мсворда.
  • +0.08 / 5
  • АУ
 
 
  _IAJ_ ( Слушатель )
08 май 2023 16:20:25

Гы....
Нынчея импортозамещаюсь, и переписваю под Qt все, что я десятелетиями писав под винлу. Удовольствия в этом мало. Мата много.
Не, сцуково, вот взять этот объектный прихват... А, ладно. Но, надо сказать, что всякая виртуальность существенно облегчает мне жизнь. Не, я могу и без. А исключения? Вот это не просто облегчает, а добавляет новое качество....
  • -0.04 / 2
  • АУ
 
 
 
  _IAJ_ ( Слушатель )
08 май 2023 16:29:37

Знаете, робяты, я в своих библиотеках достиг того, что могу в отладчике прервать исполнение в любой момент.
И данные самовосстановятся. А данные, они временами сложные, и некоторые в базе данных хранятся. Но, в рамках постановки задачи, оно получилось. Кончно же, само собой. Дерьмо иногда случается. Гы.....
  • -0.06 / 3
  • АУ
 
 
 
 
  _IAJ_ ( Слушатель )
08 май 2023 16:37:41

Не, я фанатею от стандартной библиотеки языка C Я писаю кипятком от логики именования функций. Я ее люблю.
Но, C++ добавляет...... Исключений, более строгую типизацию, да ваааще.
X
08 май 2023 19:08
Предупреждение от модератора Slav Rus:
Если что то есть желание сказать самому себе, то не обязательно это писать здесь.
  • -0.06 / 3
  • АУ
 
 
 
 
 
  Прокруст ( Слушатель )
08 май 2023 20:03:46

С++ по сути экспериментальный язык фич. Выводы делайте сами. Ах да, они там теперь еще не любят реальность, всякие там указатели и заменяют их абстракциями. Так что новые фичи не просто фичи, это абстрактные фичи.
А исключения ничего не дают, только отнимают. Закрывать глаза на существование ошибок исключениями и делать вид что их не существует - плохой код.
  • -0.03 / 1
  • АУ
 
 
 
 
 
 
  GrinF ( Слушатель )
09 май 2023 02:19:31

Ошибки и исклбчения - както лих вы объединили
  • +0.02 / 2
  • АУ
 
 
 
 
 
 
  adolfus ( Слушатель )
09 май 2023 17:20:17

Чем хорош С++, так это тем, что ничего не навязывает. Не хотите использовать "умные" указатели -- не используйте,  не хотите использовать исключения? – да, пожалуйста.
Что касается исключений, то в С++ это на самом деле действительно неоднозначная фича. Дело в том, что явная обработка чего бы там ни было всегда лучше, чем неявная. И прежде всего это касается обработки возвратов из функций. Возможно, код с явной обработкой выглядит громоздко, но никто не  мешает обернуть вызовы и писать программы в операторной парадигме – все сетевое написано именно так. А исключения провоцируют писать линейный код, который банально падает, если что-то пошло не так, в то время как 80% "плохих" возвратов элементарно "лечатся" – нужно только определить причину и написать код восстановления. Обработку исключений писать более сложно, чем просто проверять возвраты, да и блоки try-throw-catch сильно ломают как визуальную структуру алгоритма, так и его понимание. Неявного более чем достаточно в обработке сигналов, чтобы использовать технику обратного вызова еще и для обработки возвратов и прочих ситуаций.
Языки С и С++ – это языки, в основе которых лежат выражения, а не операторы, и чтобы использовать эти языки эффективно, нужно мыслить больше функционально, нежели в терминах состояний и методов их изменения. И вообще, количество плохо обнаруживаемых ошибок в программах нелинейно растет с количеством переменных, хранящих состояние и операторов присваивания. И никакая инкапсуляция сократить эти ошибки не способна, только функциональный подход к программированию.
Приходит молодой специалист на фабрику, ему в зубы дают автолисп и он практически с ходу через неделю пишет рабочие библиотеки для конструкторов. И никаких ошибок программирования.
  • +0.01 / 3
  • АУ
 
 
 
 
 
 
 
  Прокруст ( Слушатель )
09 май 2023 20:50:16

Угу, не навязывает, можно не пользоваться - но другие пользуются. Как говорится, жизнь слишком коротка, что научится читать С++ во всем его разнообразии.
Язык достиг монстрических размеров и умрет как только предложат лаконичную замену. Что-нибудь вроде Swift, но лаконичней и не от Эпл.
ЦитатаЧто касается исключений, то в С++ это на самом деле действительно неоднозначная фича. Дело в том, что явная обработка чего бы там ни было всегда лучше, чем неявная. И прежде всего это касается обработки возвратов из функций. Возможно, код с явной обработкой выглядит громоздко, но никто не  мешает обернуть вызовы и писать программы в операторной парадигме – все сетевое написано именно так. А исключения провоцируют писать линейный код, который банально падает, если что-то пошло не так, в то время как 80% "плохих" возвратов элементарно "лечатся" – нужно только определить причину и написать код восстановления. Обработку исключений писать более сложно, чем просто проверять возвраты, да и блоки try-throw-catch сильно ломают как визуальную структуру алгоритма, так и его понимание. Неявного более чем достаточно в обработке сигналов, чтобы использовать технику обратного вызова еще и для обработки возвратов и прочих ситуаций.

Да, неявная обработка и компилятор никак не помогает. Можно конечно запихать ее в один файл, при исключениях только в статических функциях можно надеяться на контроль (ну или хотя бы забубенить для таких функций префикс подражая венгерской нотации). То есть применение требует самодисциплины программиста. Так зачем эти исключения, если они требуют дополнительных усилий для применения?
Проще и очевидней возврат успеха в сочетании с оператором && и блоками кода ({}).
PS.
Главная же проблема что большинство использует исключения по принципу - здесь происходит какая-то хрень, а мы ее в try - и не будем с ней париться и все у нас хорошо. И это не лечится. Я не против экономии мыслетоплива, но эти поделия не для ремонта.
В общем исключения - полностью в парадигме бейсика - узнать об ошибке как можно позже. Ой вей!
  • +0.03 / 1
  • АУ
 
 
 
 
 
 
 
 
  GrinF ( Слушатель )
09 май 2023 21:39:44

Программист без самодисциплины называется в простонародье быдлокодер... Причем таковых сейчас преобладающая масса среди тех ктто сеьч именуют программистами... Я ужо уважаемый и не знаю какие усилия требует исключения - но мне так они кажутся вообще органичными при любом программировании где существует ввод вывод и прочия вероятностные процессы окружающей среды.. Да вспомнилось о самодисциплине и качеестве кода - выскахывание главного героя из сериала силиконовая долина - у нас у каждого сейчас телефон превосходит по возможностям те процессоры которые были при полетах на луну, так почему все так черекз жопу работает...Потому шо программисты сплошь и рядом без самодисциплины....Давеча смртрел одного перца о задачах на собеседованиях в гугол... уссался - он привел 4 алгоритма - первы простойф перебор - и с таким багажом люби приходят на 100 к учстраиваться в гугол...ипрочяя эпплы 
ЦитатаПроще и очевидней возврат успеха в сочетании с оператором && и блоками кода ({}).
PS.
Главная же проблема что большинство использует исключения по принципу - здесь происходит какая-то хрень, а мы ее в try - и не будем с ней париться и все у нас хорошо. И это не лечится. Я не против экономии мыслетоплива, но эти поделия не для ремонта.
В общем исключения - полностью в парадигме бейсика - узнать об ошибке как можно позже. Ой вей!
  • +0.05 / 3
  • АУ
 
 
 
 
 
 
 
 
  Егор А.Изотов ( Слушатель )
10 май 2023 07:53:50

Ну, тут я бы поспорил: использование обработки исключений подразумевает и обработку конкретного типа исключений. 
Вы, если не ошибаюсь, описываете ситуацию, когда какой-то кусок кода значительных размеров, "не глядя" на суть происходящего в нем, заключают в рамки (я использую синтаксическое подобие Delphi, который сам по себе способен уменьшить вероятность наступления ситуации "фигня случилась"):
"try
// критичный фрагмент 1
// критичный фрагмент 2
except // Здесь обрабатываем исключения
begin
// Фигня случилась вообще
end;
и, в худшем случае, даже не обрабатывают ситуацию исключения как таковую.
Но ведь правильно - так, и это описано во всех учебниках, практически для любого ЯВУ:
"try
// критичный фрагмент 1
except // Здесь обрабатываем исключения 1
begin
// Фигня случилась 1 - обрабатываем ее:
onErrorType1: 
onErrorType2: 
...
end;
... 

"try
// критичный фрагмент 2
except // Здесь обрабатываем исключения 2
begin
// Фигня случилась 2
// Фигня случилась 1 - обрабатываем ее:
onErrorType3: 
onErrorType4: 
...
end;

В общем виде, разумеется.
Ну и, как писали в давние времена, в байке про ЯВУ и выстрел в ногу:
"
C: один выстрел - и ни ноги, ни пистолета;
Pascal - просто не даст вам выстрелить себе в ногу.Улыбающийся
  • -0.03 / 1
  • АУ
 
 
 
 
 
 
 
 
 
  adolfus ( Слушатель )
10 май 2023 20:19:41

"Конкретного типа" исключений не бывает – есть конкретные ситуации, возникющие в конкретном семантическом контексте, требующие партикулярной обработки в рамках этого самого контекста. Соответственно, все такие ситуации всегда разные и никакого типа, не понижая вариативность ответа, им невозможно сопоставить. Многие системные вызовы возвращают конкретные ошибки и эти ошибки долны быть соответствующим образом обработаны именно на этом уровне семантики. Любые обобщающие обертки в виде абстрактных синтаксических конструкций резко понижают возможности восстановления. Но поскольку они неплохо понижают "порог вхождения" и поднимают конкуренцию в поле найма, их усиленно продвигают мерзавцы от IT – экономия на быдлокодерах куда как круче затрат на лоеров, отмазывающих этих жуликов в соответсвии с дисклаймерами. 
Стоит ли "снижения порога вхождения" некоторая синтаксическая конструкция, оборачивающая системный вызов или несколько, решать должен программист, но он это делать должен осознанно, понимая, что у него отбирают, и к чему это может привести. Ну, например, в ПО систем поддержки критических хирургических операций или в авионике пассажирских аэропланов.
Самый простой и распространенный в C++ случай такой ситуации – отказавший оператор new. Использовать исключения в этом случае можно только в целях демонстрации того, что исключения существуют как таковые. Потому что практически в каждом случае для обработки исключения, генерируемого new, требуется семантический контекст вызова new, который можно получить только если new будет nothrow и только тут же на месте его вызова. Именно поэтому в реальной работе никто не использует new, а используют malloc(), который "ближе к небесам". Слава богам, C++ пока еще в свой состав интергирует libс без изъятий. Как только он полнстью превартится в операторный говноязык, он умрет.
  • +0.05 / 6
  • АУ
 
 
 
 
 
 
 
 
 
 
  Егор А.Изотов ( Слушатель )
11 май 2023 08:12:04

Я таким мудрым словам не обучен, но, в целом, мысль Вашу понял.
Ну да, разумеется, говоря о необходимости обработать конкретно каждый код возврата, дабы определить, что конкретно случилось, и произвести восстановление (если таковое возможно), и иные необходимые действия - Вы совершенно правы, тут нужно обработать коды возврата каждого вызова и т.д., но, в некоторых ситуациях, в принципе, достаточно уже того, что "что-то случилось вообще" (например, явным образом определяемая ситуации деления на ноль. Или же, в случае, если пишется какая-то диагностическая утилита "для себя" - тут можно, на мой взгляд, в дебри не лезть, пытаясь максимально точно определить, что же именно произошло.
Скажу за себя: когда я писал драйвера для железа, я обрабатывал все возможные ситуации (майкрософтовские и IBM-овские "кирпичи" на столе всегда лежали стопкой) я старался (сейчас я немного далек от этого) обработать все возможные варианты событий (собственно, когда пишешь на асм-е, будь он для х86 или 8051, или С - это естественная логика действий. После, когда занялся сетями и их безопасностью - тоже старался так действовать. Ну а когда пишешь какой-то набор "быстрых-грязных" инструментов на Go - тут я особо сейчас не утруждаюсь детализациейУлыбающийся Хотя - когда-как. Сейчас вот пишу небольшой мелкий аналог Burp - тут приходится тщательно все обрабатывать.
Ну а насчет "быдлокодеров"..тут не знаю. По-моему, в абсолютном большинстве "букварей" обработка результатов, возвращаемых значений и т.д. - она прописана, и, если человек учится по учебнику, а не методом ненаучного тыка, то это уж он освоить должен, как мне кажется.
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
  Егор А.Изотов ( Слушатель )
11 май 2023 20:33:00

Нам на эту тему товарищ преподаватель еще в первой половине 90-х что-то такое рассказывал, мол, так правильно делать.
  • +0.00 / 0
  • АУ
 
 
 
 
 
  _IAJ_ ( Слушатель )
09 май 2023 08:56:51

Мил человек, иди пиши про северный морской путь. А в программирование не лезь. Тупым выглядишь. Не надо....
Сцуко.
  • -0.01 / 1
  • АУ
 
<< Сообщают о повторном ракетном ударе по Украине
Заявление начальника пресс-центра группировки «Запад» >>