@ИсмаилПркопенко

Когда-то я уже начинал изучать C++, даже писал не большие программки на C++. Потом забросил и не кодил на C++ лет 8. Почти все забыл. Но тут возникла одна идея, которую нужно реализовать в виде программы и я решил тут «вспомнить молодость» и начать, что называется, «с нуля». Взял в руки книжку В.В. Подбельского «язык C++» 2005 года выпуска (знаю, что есть Страуструп, Липман и др. книжки посвежее и по «забористей» - но говорю же: «с самого нуля» решил начать, а в предисловии к книжке как раз написано было, что она для тех, кто изучает C++ “с нуля”) и стал читать. Попутно заглядывая в гугл.
И начитался про иерархии классов и наследование (в т.ч. перекрестное), про спецификаторы доступа (private, protected и public), про конструкторы (по умолчанию, копирования, преобразования), про перегрузку (как обычных функций, так и операторов и конструкторов), про дружественные функции и классы, про шаблоны функций и классов, про виртуальные функции и чисто абстрактные классы, про механизм «продвижения типов». И ошалел. А ведь есть ещё конструкции с ключевыми словами explicit,try catch,typeid, typename, reinterpret_cast, const_cast, static_cast, dynamic_cast, virtual, mutable, с которыми я пока не разбирался.
Учитывая все сказанное я хочу спросить:
1) Если вам нужно разобраться в логике работы чужой, незнакомой вам, программы достаточно большого объема и выловить баги в ней, а в программе используются достаточно сложные иерархии классов (вплоть до 4-го левела и больше) с перекрестным наследованием, и в классах иерархии используются многократные перегрузки (причем как просто функций, так и функций операторов и конструкторов всех видов), дружественные функции, виртуальные функции, шаблоны, то ведь, пожалуй запутаться можно (« что и когда вызывается») и голову можно сломать пока разберешься? В чужой программе на чистом СИ разбираться и искать багги легче?
У меня, например, даже простейшие программки, приведенные в книге, вызывали головную боль, пока разберешься «что это такое, куда и зачем». Получалось понять работу программ только раза с 10-го. С пониманием же программ на СИ такого не было. СИ я освоил буквально за 1 день. Вот я и подумал: а все эти навароты в С++ и что программа так трудно понимается, чем оправданы?
2) А если сам пишешь программу, то поставленную задачу можно решить на C++ реально проще и быстрей, чем на СИ? Если да, то в каких задачах проявляется преимущество C++? И за счет чего облегчается и ускоряется написание программы?
3) В каких-нибудь задачах (и в каких конкретно) вам приходилось в классе использовать сразу почти все ОО-средства С++ «по полной программе»? Т.е. перекрестное многоуровневое наследование с многократными перегрузками всего и вся с виртуальными функциями и абстрактными классами, с дружественными функциями и классами,с шаблонами, исключения, RTTI и т.п.. Или у вас такой необходимости никогда не возникало? Или вы не использовали «сразу все» просто, чтобы самому же не запутаться в своем коде?

Миниатюры

 

0

zer0mail

А чего в него вцепились и 11 страниц тянете резину? Берите Си плюс любые из оставшихся способов и - вперед.

0

@Avazart

Не стоит забывать что есть такие вещи как перспектива, а поддержка каноничности дает ясность.
Но и ежу понятно что не должно быть фанатизма.

0

@hoggy

не нужно пытаться решать проблемы будущего,
которое может и не наступить.

и не нужно плодить сущности без необходимости.
это только усложняет архитектуру.

каноничность ради каноничности не нужна.

0

@ИсмаилПркопенко

ОО парадигме уже почти 70(!!!) лет.
Да да. Первые упоминания о ней датируются 1949-м годом.
Не пора бы уже чего-нибудь поновей использовать?

0

@hoggy

например?

0

@ИсмаилПркопенко

Не помню у кого это прочитал. ЕМНИП у Макконэла.
"Не решайте задач, которых нет"©

0

@hoggy

Макконелл вроде бы действительно,
что то подобное писал)

1

@Avazart

Добавлено через 2 минуты
Как быть все же наступит? Никто не говорит о воображаемых задачах.
Cуть в том что бы решать задачу чуть-чуть шире чем это требует ситуация сейчас, на то она и перспектива.
Я про каноничность за ради ясности.

0

@hoggy

когда наступит, тогда и будем думать.

это - зряшная трата времени(денег) компании.

нужно решать конкретные поставленные задачи,
и ничем более.

ясность наступает, когда кода мало, он лаконичен,
и выполняет реальную полезную работу.

ооп ради ооп - не нужен.
а 100500 классов, которые которые не делают никакой полезной работы,
никакой ясности не добавляют.

у меня был случай:
для решения одной задачки я организовал 3 класса.
причем про один из них пользователи ничего не знают.
то есть для работы нужно знать только про паблик двух маленьких классов.

мой коллега глянул и сказал:

- код простой, и его мало. однако решение не вполне канонично.
- покажи каноничный вариант

и вот он мне нарисовал uml-архитектурку.
где образовалось больше двух десятков разных классов.
большая часть которых нафиг не нужна для работы.

и я спросил его:
- вот что проще: два маленьких классах, или два десятка?
- зато тут все по канонам ооп
- задача ооп - упращать жизнь, а не усложнять.


"ясность" - это миф. человеку со стороны все равно придется вникать
в чужую кодовую базу.

и вот здесь, чем меньше кода - тем проще,
и быстрее будет протекать этот процесс.

фундаментальное для ооп правило:
"не плодить сущности без необходимости"

2

@Avazart

Думать с перспективой развития, это скорее экономия.

Ну с таким же успехом можно было упаковать все в один монолит.

Ну дело ведь не в количестве строк.

Но и так понятно
что это явный перебор, нет смысла держать столько объектом в голове, и это действительно усложнение.
Вопрос только в том что он понимал под "канонами ооп".

Есть базовые приемы которые знают большая часть программистов благодаря чему разбор кода идет быстрее и городить что-то левое нет смысла.
Кроме того человек не должен быть "со стороны".

0

@hoggy

нет, это - убытки.

вы не должны думать ни о чем,
кроме решения самой задачи в поставленных рамках.

попытка учесть будущие (но ещё не существующие) требования - напрасная трата времени,
и усложнение проекта без оснований.

нельзя.
проблема монолита: что бы понять целое, нужно понять частное.
но что бы понять частное, нужно уже понимать целое.

что бы этого не происходило,
код дробят на отдельные независимые фрагменты,
каждый из которых решает свою маленькую задачу.

и в количестве строк так же.

дело в количестве информации, которое нужно держать в голове,
что бы работать с проектом.

"в лучших традициях банды четырёх"

0

@ИсмаилПркопенко

Давайте без хамства и "переходов на личности"
"Одинаково трудно разбираться в одной большой функции как в нескольких десятках маленьких"

Добавлено через 9 минут
Все эти каноны, изобретаемые бездельниками-теоретиками, "от лукавого".
Это все равно что как если бы человек, никогда не державший в руке лопаты, взялся бы писать книгу "шаблоны копания траншей лопатой"

Добавлено через 2 минуты
В программировании как в инженерии: самые лучшие инженеры книжки не пишут, ибо им некогда.
А пишут те, у кого куча свободного времени, потому что инженерной работой они не загружены (или вообще ей не занимаются) и посему слабо представляют себе её специфику и занимаются ТЕОРЕТИЗИРОВАНИЕМ

0

@Voivoid

А как назвать того, кто на форуме уже на протяжении недели пишет кучу бесполезных вопросов и даже не может скомпилировать пример из-за отстутсвия хидера?

3

@ИсмаилПркопенко

Voivoid
Давайте не будем сводить эту тему к киданию какашками?
ОК?
Мы же с Вами взрослые люди.
И никому читать взаимные оскорбления будет не интересно.
Иначе я буду вынужден обратиться к модераторам.
Поэтому давайте все же про "науку".
То бишь про недостатки С++ и ООП подхода.

Добавлено через 1 минуту
А Вы можете скомпилировать код без хидеров?
Научите как

Добавлено через 18 минут
"На вкус и цвет товарищей нет"©
Для Вас они, может, и бесполезные, а для меня- самые важные и животрепещущие

0

@JIawliet

ООП эффективна, полезна и удобна! Именно по этому она была создана, что произвело большой прорыв в программировании. Или вы думаете, что все бестолковые и просто не видят очевидных недочетов в ООП, и только вы понимаете, что ООП - бред? Вынужден вас разочаровать... пройдитесь по вакансиям на должность программиста практически везде требуют знание ООП, и что-то я как-то не наблюдаю требования: процедурное программирование.

Добавлено через 2 минуты
ИсмаилПркопенко, у вас в теме написано: "Развейте мои сомнения".. Какие могут быть сомнения??? Откройте глаза, оглянитесь вокруг! 2016 на дворе!

0

@ИсмаилПркопенко

Вот вот. А мы до сих пор юзаем ООП, первые упоминания о котором относятся к 1949-му году.
Т.е. уже почти 70 лет "дедушке"
Как думаете: не пора ли использовать парадигму посвежей?

Добавлено через 1 минуту
Пройдитесь по магазинам - больше всего народ покупает самые дешевые продукты.
Но это не значит что они самые полезные и качественные

Добавлено через 1 минуту
И кстати, кто не в курсе, ООП парадигма появилась РАНЬШЕ процедурной.
Но гуглить сейчас это не буду - кому интересно сами нагуглите

0

@Voivoid

Не пора ли закончить с ТЕОРЕТИЗИРОВАНИЕМ и начать уже писать код ( ну или еще чем полезным заняться ) ?

Очевидно, что убрать ненужные зависимости

1

@JIawliet

ага, процедурное программирование оплачивается выше, чем ООП... оно ведь качественное и полезное...

ваши предложения? + обоснуйте преимущества вашего подхода

а вообще если вы так уверены что вам не нужно С++ и ООП, не учите... от темы попахивает холиваром / троллингом, 11 страниц не о чем.

1

@ИсмаилПркопенко

Звучит глупо.
Это все равно что сказать: "просто взять и переписать все несколько миллионов строчек кода с нуля, так, чтобы стандартная библиотека вообще не использовалась"

Добавлено через 2 минуты
Господа! Если Вы считаете что у ООП и его С++-й реализации нет недостатков и что тут даже обсуждать нечего - то не надо хамить. Просто покиньте эту тему раз она Вам не интересна.
А хамскими топиками засорять тему я не позволю

Добавлено через 3 минуты
То как ООП бывает красиво выглядет на искусственных, надуманных задачах я и без вас по книжкам знаю.

А меня интересует то, что в ++-й реализации ООП просто омерзительно и безобразно сделано, что Вас выбешивает и каждый раз раздражает в С++. Вот что меня в ПЕРВУЮ очередь интересует.

Т.е. ограничения и недостатки С++

0

@zss

Закрываю тему.
Похоже, все, кто хотел, высказались!

2