2 Yossarian

ГВ> Однако, если те, кто "пишет правильно" добивается хороших результатов,
ГВ> то логично ведь предположить, что те, кто их не добился - пишут неправильно

Но те, кто "пишет правильно" на Delphi, Java, OCAML, FORTRANe, тоже добиваются
хороших результатов. Следовательно, если соотношение "плохих"/"хороших"
программистов не в пользу С++, можно сделать вывод, что этот язык
не поощряет хорошие практики программирования.
Я бы не настаивал на безусловной справедливости этого вывода, но обратное
совершенно точно неверно.

:) Ага, те, кто добивается хороших результатов на Java, Delphi (...) - пишут правильно на этих языках (наверное ;) ). Но ведь это никак не влияет на их (и не только их!) умение писать на C++. Весьма спорным представляется также ссылка на "...хорошие практики программирования". Что это такое? И почему факт достижния хорошего результата с использованием Delphi связывается с использованием хороших практик программирования? Рискну предположить, что этим термином обозначается некоторое структурирование кода, архитектура и т.п. Но как раз таки порог, при котором становится критичным применение "хороших практик" (и следовательно, соответвующая мозговая активность ;) ) при использовании здоровущих интегрированных сред типа Delphi отодвигается , т.е., условно говоря, можно написать хорошую программу совсем не применяя этих самых практик. А что? Затолкали в OnClickSuperButton() гору кода, чем нарушили целую гору принципов структурирования и привет: всё работает! Вместо LSP-compliant решения влепили анализ типа входного объекта (Java) и опять всё работает! Где же здесь поощрение хорошей практики? :))

Так что, ИМХО, твоё утверждение не только спорно, но ещё и безосновательно. :(

c127

Давайте говорить о сопостовимых вещах: если сравнивать, то не Delphi с C++, а паскаль с C++. Паскаль искуственно навязывает хороший стиль программирования, он для этого и был придуман - обучать людей программировать, и последнее есть медицинский факт.

OK, согласен, логичнее сопоставить C++ и Object Pascal. Но вот с тем, что Паскаль навязывает хороший стиль программирования я не совсем согласен. Да, по сравнению, например с С, он требует более жёсткой типизации, да, на его примере обучают структурированию реализации идей и в сущности, неплохо обучают.

Однако остаётся вопрос о средствах структурирования и об их применимости на практике. И здесь, ИМХО, ответ отнюдь не в пользу Pascal/Object Pascal. Как минимум, таких мощных средств как множественное наследование реализаций и шаблоны этот язык лишён (поравьте меня, если я ошибаюсь). Также, как лишена его и Java. Отсюда раньше или позже в реальных условиях возникает проблема эффективности процесса разработки. Я не буду утверждать, что эта проблема всегда принимает критический характер, но всё таки. Дальше, как логичное следствие, возникают нарушения хороших практик, которые сами по себе входят в "нормальную" практику. То же самое приведение типа "сверху вниз" и т.п. С другой стороны, конечно, можно и на Object Pascal не допустить подобных нарушений, например, повсеместно используя интерфейсы (или методы с модификатором abstract, сам когда-то занимался этим ещё на Turbo Pascal 5.5-7.0), но плата за это - потеря эффективности исполнения и увеличение длительности разработки. Т.е., O.Pascal/Java на самом деле при практическом использовании нередко провоцируют нарушения принципов "правильного" проектирования, поскольку опять таки нередко ставят программиста в условия, где сочетание:

а) сильной согласованности исходных текстов при их глубокой структурированности;
б) эффективности исполнения;
в) скорости разработки

становится практически недостижимым, тогда как C++ эти задачи блестяще (оговорюсь: на фоне остальных) решает. Но! Решает только при адекватном подходе к разработке, который, ИМХО, является логичным продолжением подхода, каковому обучают на примере Pascal.

Т.е. умение программировать на паскале влияет на умение программировать на C/C++.

Естественно, согласен, но только когда умение сие развивается до того, что начинает логично применять концепции C++. Развитие же в "обратном направлении", т.е., сознательный переход с C++ на O.Pascal, ИМХО, является свидетельством определённого рода деградации.

PS. За ссылку, конечно, спасибо, только я её уж лет десять как прочёл.
PPS. Вот, тоже рекомендую: Б. Лисков, Дж. Гатэг, Использование абстракций и спецификаций при разработке программ, М. Мир - 1989, 424 c. ISBN 5-03-000489-0

2 c127

Да он и не предназначен для этого: паскаль по определению проверяет типы и потому медленный (проверки можно выключить, но это уже будет не паскаль),

Ээээ..., по-моему, ты ошибаешься. Паскаль проверяет типы только во время компиляции, хотя в нём и есть приведение чего хошь к чему хошь. ИМХО, через промежуточное преобразование к pointer.

эти begin end задолбешься везде ставить.
:) ну, я думаю, по этому поводу спорить не будем. :)


Потому в качестве языка для прикладной системы (дельфи) он выбран ИМХО неудачно, я бы лично предпочел C++. Но если вдуматься эти различия - только константа, ничего существенного.

Delphi стала логичным развитием вполне себе успешного Turbo Pascal, а С++ тогда ещё не развился до нынешнего состояния.

Но собственно, речь не об этом.

Множественное наследование. Я никогда не сталкивался с необходимостью использования и не очень представляю, какие существенные преимущества оно дает. Существенные это те, которые перевешивают проблемы, порожденные введением в язык множественного наследования. Объясните если есть возможность.

Хммм... если обобщённо, то МН здорово экономит силы на реализации подмешиваемых интерфейсов. Иначе приходится писать гору дополнительного кода для связи методов, унаследованных от подмешанных интерфейсов с какими-то объектами, реализующими методы интерфейсов. Посмотри ATL - она в немалой степени построена на МН.

Иными словами, существенное преимущество МН перед одиночным наследованием в экономии сил, затрачиваемых на реализацию. Соответственно, проще отладка, тестирование и т.п.

Кстати, здесь присоединюсь к vdimas, поскольку необходимости использования МН на самом деле нет. Его всегда можно эмулировать одиночным наследованием реализации и множественным наследованием интерфейсов. Просто его использование позволяет обойтись без этой эмуляции. :) Из недостатков можно отметить то, что использование МН требует более вдумчивого проектирования.

Наболевший вопрос. У кого-нибудь есть каие-нибудь данные по сравнению C++ и C на аналогичных проектах в смысле размеров исходников, затраченного труда? То, что я знаю почему-то явно не в пользу C++. Но я специальных исследований не проводил.

Поищи в сети, где-то есть. На RSDN (www.rsdn.ru) в форуме, кажется "философия программироваия" проскакивало что-то из этой серии.

От себя рискну предположить, что скорее всего ты и будешь обнаруживать сравнения совсем не в пользу C++ по целому ряду причин. Смотри, если кто-то пишет на C++, то аналогичную программу он скорее всего не будет писать на чистом C, т.е., ему объективную оценку просто не из чего получать. Обратный случай: некий C-шный продукт переписывается "по-объектному". Следовательно, скорее всего, в нём блокируются какие-то трюки C (вроде использования void*), добавляются новые уровни абстракции и т.п., т.е., это уже не тот же самый продукт . Ну и кроме того, когда осваивают C++, на первых порах разработчики клепают горы ошибок в проектировании. Результат получается не ахти... Вот тебе и отрицательное сравнение. Третий вариант - когда в последнем случае среди C-шников попадается хороший C++-ник. Вот здесь есть основания для получения сравнения "в пользу" C++. Ну вот. И как ты думаешь, каких случаев (и следовательно - фактов оценок ) больше? ;)

2 c127

Нет, например в случае объявления:
type t=1..333;
var y: t;
тип должен проверяться в случае каждого присваивания вида y:=что_то;. Есть и более сложные случаи т.е. тормозит сильно. У классического паскаля очень строго с типами, целая наука.

Да, верно, я и забыл о паскалевской строгости с enumeration.

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

ИМХО, стОит, поскольку множественное наследование реализаций позволяет в ряде случаев сэкономить ручной труд и вобщем-то, является логичным развитием концепции наследования.

Но ведь задача решается та же. В конечном счете ведь нас интересует решение задачи.

Да, именно так. Но после решения задачи всегда остаётся период сопровождения, который нельзя игнорировать при начальной разработке программы.

Кстати, вспомнилось, если не читал, то советую посмотреть книжку Алана Голуба "Правила програмирования на C & C++". Хоть сама по себе она содержит довольно много устаревших и просто спорных вещей, но там есть интересное в контексте нашей беседы высказывание по поводу "гибридных" проектов - когда в рамках одного проекта сочетаются подходы C и C++. Дословно не помню, но суть сводилась к следующему: хоть менеджеры и утверждают, что "раз такие проекты эксплуатируются, то этот подход работает", но его сопровождение превращается в один непрерывный кошмар. Я, в принципе, двумя руками поддерживаю подобную оценку. Беда в том, что немалая часть проектов на C++ выполнена как раз по "гибридной" схеме. Можно даже правило определённое вывести: если активно используется MFC, то это - гибридный проект. Почему? Потому что MFC в целом представляет собой всё что угодно, только не объектную C++-библиотеку. Ну не объектная она и всё тут. Для того, чтобы ей пользоваться "объектно" и получить пряники, обещаемые ОО-подходом нужно сделать ещё гору врапперов, надстроек и т.п.

Готов принять поток критики, но я до сих пор уверен, что факт наличия работающего продукта ещё не означает, что этот продукт работает хорошо, уж тем более, это не является критерием того, что подходы, использованные в реализации проекта можно смело переносить на другие продукты. Никода не доводилось ужасаться по поводу своего кода, помещённого в выпущенный продукт? Мне - приходилось. :) Так что, факт "сданности" продукта сам по себе ничего не означает. Он может служить подтверждением работоспособности тех или иных методик, но для того, чтобы сравнивать методики сами по себе, нужно как очень детальное сравнение двух или более готовых продуктов, и, что не менее важно - сравнение характеристик цикла разработки и сопровождения. А их и считать-то толком не всегда умеют...

А ведь этого [С++ не вытесняет C] не происходит, до сих пор многие крупные проекты пишутся на сях. Только консерватизмом такую ситуацию объяснить по-моему нельзя. Например паскаль в промышленности практически умер и кое-как держится только из-за дельфи.

Ты не учитываешь фактора определённой стереотипичности мышления, присущей программстам. Кроме сугубо рациональных аспектов использования тех или иных языклв есть ещё и... Бытовала такая шутка: "Для чего предназначены языки программирования? Pascal - для студентов, APL - для марсиан, Lisp - для учёных, Smalltalk - для домохозяек, C - для программистов ". Там было перечислено много языков, остальных не помню, но суть, надеюсь, ясна. Потом опять же - "настоящие программисты пишут на Fortran"... :)

Потом, фактор того, что масса ПО уже написана на C (те же операционные системы).

Есть ещё и фактор, который можно сформулировать так: "я всегда писал на C и у меня всё получалось". Воздействие такого соображения очень трудно преодолеть. Приходится "тыкать носом" в очевидные проколы, которых удалось бы избежать, не будь там преобразования к void* и т.п.

Наконец, есть ещё фактор наличия инструментальных средств. Например, компиляторы C++ только сейчас начали подтягиваться к реализации стандарта ANSI. Соответственно, перенос разработок с платформы на платформу был затруднителен. С другой стороны, реализации C отличались по большому счёту только набором библиотек. Да и станарт C был принят, если не ошибаюсь, аж в 90 году.

И наконец, ИМХО, один из самых серъёзных, если не самый серьёзный фактор. "Правильная", т.е., "объектная" разработка на C++ требует бОльших вложений на начальной фазе развития проекта, чем разработка на C, особенно это заметно при переходе с C на C++ (проверял на себе). Различия проявляются позже - когда начинается эволюция/сопровождение. Это, кстати, неоднократно отмечалось апологетами ОО-подхода, цитат сейчас привести, к сожалению, не могу, но по-моему, такие высказывания есть у Буча, Шлеера, Голуба... В середине 90-х на эту тему только и жужжали.

2 c127

...При этом я пока принимаю за аксиому полезность ООП.

:) Ты путаешь наблюдение следствий и идентификацию причин. Т.е., в принципе, мне перечисленные пункты понравились, но, ИМХО, в качестве определения причины они "бьют мимо цели". Вот почему:

1) ООП в при кодировании в C++ счень сложен, по крайней мере для среднего разработчика, человек быстро скатывается к более простому сишному стилю.

Проблема не в этом. Проблема в том, что разработчики часто поставлены в условия, когда им необходимо писать так, чтобы это было понятно даже... ммм... скажем так, не очень опытному коллеге. При этом упор делается не на то, что этому самому неопытному коллеге было бы очень полезно поковыряться в сложной программе, сделанной хорошим C++-ником, а на исключение фактора непредсказуемости времени, которое новичок потратит на саморазвите в этом случае. Т.е., не "низы поднимаем", а "опускаем" тех, кто более развит. И квалификация при этом всё чаще связывается не с умением мыслить, а с запоминанием API, технологий и прочим бредом.

А само по себе кодирование ООП-ной программы на C++ ничуть не сложнее, чем, например, на том же Java.

2) Сишный стиль настолько прост и удобен, что от него нельзя отказаться.

Неверная оценка. Сишный (процедурный) стиль прост и удобен для определённой категории разработчиков, безотносительно их "хорошести" или "плохости". Кроме того, сишный стиль всегда будет присутствовать на компьютерах с фон-неймановской архитектурой.

3) Имеются серьезные скрытые проблемы, отличные от п.1, в практическом использовании C++ в кодировании ОО приложений, которые вынуждают программистов использовать более простой C-стиль, выдерживают только самые стойкие.

Ну всё, обливаю себя бальзамом. Я стойкий. :) По моим наблюдениям, ни в коем случае не претендующим на полноту, самым большим откровением для "сишников" становится гораздо более мелкая объектная структуризация программы, чем это кажется им на первый взгляд. Ну, например, мне неоднократно задавали вопросы типа: "для чего эти смарт-пойнтеры-то нужны? Программу лучше тестировать надо!". Понимаешь, достаточно трудно используя, например, стандартные UML-диаграммы показать реализацию, например, массива указателей. Для сишника со стажем это просто массив указателей, для C++-ника же - инстанцирование шаблона vector<>.

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

Основное, что я хочу сказать, наверное, можно выразить кратко: причины эффективного применения C++ ищи в конкретных людях , причины провалов - в командах и менеджменте. Почему? Потому что эффективное использование C++ одним разработчиком в ряде случаев (я не хочу сказать - всегда) сводит на нет необходимость команды, менеджеров, промежуточной документации и прочих ритуальных плясок, тогда как неэффективность обусловлена коммуникационными барьерами между людьми. Вот уж действительно - пляски так пляски. Другая сторона медали, ИМХО, в том, что процедурный стиль ближе "паковщикам" по терминологии А.Картера, кои составляют бОльшую часть людей. Отсюда и бОльшая популярность языков вроде C, а вернее - процедурного подхода.

Отвлечённое наблюдение, возможно не совсем точное. C++ как и куча языков-сверстников развивался с прицелом, в частности, на повышение эффективности индивидуала , и перекладывание работы по верификации программы на компилятор. Сильная типизация - как раз игрища из этой области, поскольку понятие "тип" определяется как набор допустимых операций.
А современные нам языки, такие как Java и C# направлены на поддержку команд, менеджмента... На что угодно, только не на то, чтобы дать программисту в руки инструмент воплощения видения картины мира. Чувствуешь "изменение" вектора? Вместо развития, как повышения уровня абстракции и систематизации получается деградация.

В полезности шаблонов я не сомневаюсь. Идея мне очень нравится, но вот похоже Степанов недоволен ее реализацией в C++. Я не очень понимаю почему, но ему виднее. Насколько я понимаю, к OOP-у шаблоны не имют отношения. Хотя я не большой знаток основ ООП и готов выслушать другие мнения.

Как минимум, он недоволен отсутсвием consraints в шаблонах, насколько я помню. Ещё у него в интервью (где-то в сети есть) были замечательные слова (не дословно): "мне говорят, что надо идти туда, где большие деньги, но по-моему это дурно пахнет".