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

В чем проблема С++?

В С++ нет проблем. С++ - это всего лишь инструмент, не лучше и не хуже С.
Все проблемы лежат ЗА гранью С++.

Но они очевидны.

1. Проблема мышления на уровне абстракций.
Переходя на уровень абстракций, мозг теряет способность мыслить низкими категориями.
Это закономерно, ибо эти уровни являются взаимоисключающими by design.

2. Проблема проектирования архитектуры.
В С сделать плохое решение гораздо сложнее. Это факт.
Есть чистые данные, организованные в некие структуры, есть процедуры, ими оперирующие.
Можно выбрать неоптимальные наборы данных, можно написать неоптимальные алгоритмы.
НО. Проводить оптимизацию и рефакторинг такого кода несложно.

В С++ проблема любого большого проекта - проблема дизайна.
Есть на примете какой-нибудь проект с хорошим дизайном?

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

На досуге можно попробовать оценить иерархию классов в маленьком проекте 1cpp.
Можно еще нарисовать иерархию классов MFC

Я в свое время подбрасывал оба проекта doxygen'у - было очень познавательно.
И все равно нихрена не понятно.

4. Ну, чисто языковые проблемы C++ (типа перегрузки операторов || &&) я вообще оставлю в стороне.
На эту тему существует множество книг (типа С++ gotchas и т.д.).

5. Время подготовки специалиста.
Для программирования на С нужно прочитать одну книжку К&R (Керниган/Ритчи).
Ладно, так и быть, еще одну книжку по среде исполнения.
Ну да, еще немножко математики и профильного образования, чтобы хоть как-то писать какие-то алгоритмы.

Сколько книг нужно по C++, чтобы ХОТЯ БЫ перестать лепить полную лажу?
Я так и думал, что вы скажете, что одной хорошей хватит.
Хрен бы там.

В общем, смысл в следующем: для подготовки программиста на C требуется человек (не каждый) и время.
Для подготовки программиста С++ требуется человек (уже совсем не каждый) и гораздо большее время.

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

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

Вот, собственно, и все проблемы С++.

Ну и совсем уж, чтобы добить тему...

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

К примеру, у Страуструпа есть книжка Design and Evolution of C++, где он повествует о том, как С++ создавался.
И в какие он был зажат тиски, между комитетом (позже) и ортодоксальными последователями С (сразу).
Эффективность всегда была ключевым моментом для Страуструпа.

Торвальдс высказывается по поводу STL - ее сложности, стабильности и т.п.
Но когда мы, наконец, делаем попытку вникнуть в то, кто же такой по жизни Степанов, мы начинаем понимать,
что для него самое главное - это эффективность, алгоритмизация, чистая математика, наконец.

Степанов на самом деле (по убеждениям) очень близок к Торвальдсу, не знаю, понимает ли это сам Торвальдс или нет
Многие его работы, кстати, опубликованы на его сайте http://www.stepanovpapers.com

Но проблема у STL тоже есть и абсолютно такая же, как и у самого С++ - истинная сложность и мнимая простота.
В руках плохого танцора простые неграмотные ошибки в дизайне приводят к сложным неявным труднодиагностирумым проблемам.
И очень немногие могут эффективно мыслить в идеологии STL (а Степанов не предлагает реализацию, он предлагает идеологию).

P.S.
Да, по поводу Торвальдса.

Интересно, а что он вообще думает по поводу своего линукса?
У линукса ведь абсолютно те же проблемы, что и у C++.
Проблемы недостатка сознания (у потребителей).
Разве нет?
Разве не тем объясняется успех windows, что она по уровню сложности установки и использования ориентирована на среднестатистического дебила?

Так отож.

kms писал(а) 29. Декабря 2007 :: 23:35:

И что? Это проблема? Это средство борьбы со сложностью.

kms писал(а) 29. Декабря 2007 :: 23:35:

Чушь. Несложно только для простейшего небольшого кода. С большим количеством кода проблемы голого Си встают в полный рост. Отсутствие инкапсуляции, когда каждый имеет доступ к всему. Невозможность из-за этого сделать рефакторинг не поломав кучу кода. Сложность управления ресурсами. И так далее.

kms писал(а) 29. Декабря 2007 :: 23:35:

Ага в Си таких проблем нет. Дизайн сложной системы от языка зависит слабо. Зато Си не дает достаточно приличных средств для воплощения этого дизайна.

kms писал(а) 29. Декабря 2007 :: 23:35:


Вот для таких вещей С++ гораздо лучше С. Потому что, например, благодаря элементарной инкапсуляции можно спокойно делать рефакторинг не затрагивая потребителей.

kms писал(а) 29. Декабря 2007 :: 23:35:

Только причем тут С++? В любой сложной системе есть ряд непростых модулей со сложными зависимостями. Вот только при помощи С "со сложностью бороться сложнее".

kms писал(а) 29. Декабря 2007 :: 23:35:

Эти "проблемы" существуют только для идиотов.

kms писал(а) 29. Декабря 2007 :: 23:35:

Только когда начнутся сложные проекты одной книжки вдруг станет недостаточно.

kms писал(а) 29. Декабря 2007 :: 23:35:

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

kms писал(а) 29. Декабря 2007 :: 23:35:

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

kms писал(а) 29. Декабря 2007 :: 23:35:

Система, в которой за архитектуру отвечает кодер, а не архитектор - тухлая по определению. А вообще, кодер - это такой зверь, про которого все говорят, но никто не видел.

kms писал(а) 29. Декабря 2007 :: 23:35:

Неубедительно.

Цитата:

Вот тебе ссылки, любитель авторитетов ты наш без собственных мозгов:
http://rsdn.ru/Forum/Message.aspx?mid=2764724
http://rsdn.ru/Forum/Message.aspx?mid=2647838

Цитата:

Видишь ли в чем дело... Если ты завел ветку на форуме, значит, ты ждешь неких "мнений" насчет заинтересовавшего тебя предмета. Однако эти "мнения" совершенно не обязательно будут такими, какие тебя устроят. Заводя ветку на форуме, всегда надо быть готовым, что возможна неприятная для тебя реакция. Что и произошло в данном случае. Если тебя подобные вещи не устраивают, то тебе лучше завести собственный форум, где ты будешь тряпочкой подтирать неугодные тебе "мнения". Естественно, тогда тебе надо быть готовым к тому, что твой форум и на х никому не будет нужен. Но это уже частности.

Uzhast писал(а) 30. Декабря 2007 :: 15:58:

Сижу, зачитываюсь. Спасибо, порадовал

Михаил, я не согласен, практически со всеми твоими комментариями, и практически полностью согласен с Олегом.

Цитата:

Тут я также согласен с Олегом, что порог освоения экскаватора и мотоплуга выше, чем у лопаты. Но зато лопатой можно и поле вскопать, и котлован вырыть. Какая из трех вещей будет полезнее?

На самом деле, как ты правильно заметил, дело в разных уровнях проблем. И если решения проблем, с которыми работает С, уже имеются инструменты, такие как компилятор, отладчик и т.п. То для решения проблем, с которыми работает С++, инструменты только разрабатываются.

Это UML и другие инструменты анализа/проектирования. Но не только. Это и метологические инструменты, такие как TDD. Ну если не TDD, то уж тесты сейчас практически всеми пишутся. Имеются в виду, конечно, серьезные проекты. (Мои знакомые, которые пишут для MySQL, говорят, что если ты написал код, то он должен быть покрыт тестами. То есть не должно быть строчки кода, через которую не проши тесты.) Также сюда можно отнести инструменты рефакторинга. (И хрен ты проведешь серьезный рефакторинг С-кода для серьезного проекта при наличии отсутствия тестов).

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

И нихрена С не дает подходов для создания инструментов проектирования.

И относительно "дома с пристройками". Возможный уровень пристроек определяет такая величина (личный уровень разработчика)*(личный уровень знакомства с проектом)*(уровень инструментов поддержания целостности проекта). И если с первыми двумя все понятно, то про третий можно сказать, что он играет не меньшую роль. Таким инструментом может быть документация. Но гораздо большую пользу дают тесты. Они позволяют не только строить пристройки без разрушения основного здания, но и менять дизайн всего здания при достаточно низкой величине (личный уровень)*(уровень знакомства с проектом).

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

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

И последнее. Относительно алгоритмов/оптимальности программ. Каково сейчас соотношение стоимости часа условного программиста к мегабайту памяти? А к МегаФЛОПСу? А какое оно будет чере 5 лет? А через 10? Так во что эффективнее вкладываться?