Здравствуйте, bc_kaya, Вы писали:

_>Хотел бы поинтересоваться у знающих людей, за что весь мир недолюбливает плюсы. Конкретно у меня данный язык вызывает симпатию (возможно потому, что это мой самый первый более менее освоенный язык программирования);
_>Поделитесь впечатлением и опытом программирования с использованием языка С++?
_>Холивары просьба не разводить, иначе уйдём не в ту степь обсуждения

1. Основная маса проблем C++ происходят из синтаксического наследия, а именно, синтаксиса объявлений, доставшегося из C, а там — по инерции из предшественников.
Когда пишешь "int i" вместо "var i: int" это удобно. Но немасштабируемо. Уже конструкции типа "int (*f)(void)" вызывают проблемы понимания и необходимость тренировки выворачивать парсер в мозгу. Усложнение этого хотя бы до уровня "функция, возвращающая указатель на функцию" доводит до того, что нормально пишется только с промежуточным typedef.
Когда из этого возникает most vexing parse, а затыкается мерами типа {} в инициализации (C++11); когда ты не знаешь заранее смысл синтаксической конструкции, написанной тобой (или такое с похожим результатом) и он может меняться от непредсказуемых заранее факторов...
Обратный сишному порядок объявлений (назовём его "паскалевским") многословнее, но принципиально полезнее для сложных конструкций.

2. Калечные эффекты с undefined behavior в местах, совершенно неожиданных для многих и особенно тех, кто не прошёл неплановые курсы "здесь водятся драконы". Арифметика

Автор: Кодт
Дата: 18.06.14

. Алиасинг. Другие оптимизации. Ещё несколько похожих эффектов.

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

3. Таки да, шаблоны, а именно — попытка их уложить в те же синтаксически ущербные рамки и "не вводить лишних сущностей", приводящая к фокусам типа std::enable_if.

4. Необходимость одновременно мыслить на нескольких разных уровнях — от высот рекурсивных шаблонов до укладки битов в памяти.

Всё сказанное выше — результат исторического развития методом "каждый раз шаг, полностью логичный из предыдущего состояния, но в новом направлении".

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

Здравствуйте, bc_kaya, Вы писали:

_>Хотел бы поинтересоваться у знающих людей, за что весь мир недолюбливает плюсы. Конкретно у меня данный язык вызывает симпатию (возможно потому, что это мой самый первый более менее освоенный язык программирования);
_>Поделитесь впечатлением и опытом программирования с использованием языка С++?
_>Холивары просьба не разводить, иначе уйдём не в ту степь обсуждения

1. Основная маса проблем C++ происходят из синтаксического наследия, а именно, синтаксиса объявлений, доставшегося из C, а там — по инерции из предшественников.
Когда пишешь "int i" вместо "var i: int" это удобно. Но немасштабируемо. Уже конструкции типа "int (*f)(void)" вызывают проблемы понимания и необходимость тренировки выворачивать парсер в мозгу. Усложнение этого хотя бы до уровня "функция, возвращающая указатель на функцию" доводит до того, что нормально пишется только с промежуточным typedef.
Когда из этого возникает most vexing parse, а затыкается мерами типа {} в инициализации (C++11); когда ты не знаешь заранее смысл синтаксической конструкции, написанной тобой (или такое с похожим результатом) и он может меняться от непредсказуемых заранее факторов...
Обратный сишному порядок объявлений (назовём его "паскалевским") многословнее, но принципиально полезнее для сложных конструкций.

2. Калечные эффекты с undefined behavior в местах, совершенно неожиданных для многих и особенно тех, кто не прошёл неплановые курсы "здесь водятся драконы". Арифметика

Автор: Кодт
Дата: 18.06.14

. Алиасинг. Другие оптимизации. Ещё несколько похожих эффектов.

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

3. Таки да, шаблоны, а именно — попытка их уложить в те же синтаксически ущербные рамки и "не вводить лишних сущностей", приводящая к фокусам типа std::enable_if.

4. Необходимость одновременно мыслить на нескольких разных уровнях — от высот рекурсивных шаблонов до укладки битов в памяти.

Всё сказанное выше — результат исторического развития методом "каждый раз шаг, полностью логичный из предыдущего состояния, но в новом направлении".

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