E>Например? Только фичи языка, а не STL, etc.

CMyClass& как параметр вызовов.

Получается, что вызов f(obj) может модифицировать obj, и при этом нет никакой видимой подсказки.

Если бы не было такой фичи, то параметр f имел бы тип CMyClass* — и вызов пришлось бы писать в стиле f(&obj). Это лучше, потому как явная подсказка, что obj может быть изменен в результате вызова.

Namespaces и особенно оператор using.

Почему в ядре Windows функции имеют явные лексические префиксы? IoCreateDevice, KeSetEvent... прекрасный путь. Во-первых, ищется грепом по всему проекту. Что будет в Си++? Kernel::SetEvent? Сразу лишний визуальный шум в виде ::. Но это еще полбеды. А если использовался using? Тогда одна и та же сущность может быть поименована и как set, и как CMyTooSmartNamespace::set, попробуй проищи по всему проекту.

Уже нужен BSCMAKE вместо grep, и вдобавок код лишается локальной понятности. Позвано просто — set() и все. И чтобы понять, что за set(), надо листать код на начало файла, где стоит using.

Operaror overloading. Скрытая семантика. Читаешь a+b и не знаешь, а что тут значит +. Чтобы узнать — надо лезть в башку, и хорошо, если этого класса, а не одного из предков.

Но это еще цветочки. Тут хоть лексема + есть. А если operator T()? Вот тут даже никакой видимой подсказки нет, что зовется какая-то процедура сбоку. Прям хоть венгерскую нотацию используй

RTTI. Уродство. Если язык претендует на ОО, и считает полиморфизм важной фичей языка (а против полиморфизма я ничего сказать не могу, прекрасная идея) — то на кой черт поощрять не-полиморфные стили программирования? Сам же Страуструп писал в 90ом году, что УМЫШЛЕННО не стал делать RTTI как часть языка. И приводил очевидные аргументы. Во-первых, это поощрение не-полиморфного стиля программирования (который однозначный отстой, и кандидат на рефакторинг). Во-вторых, невозможно раз и навсегда придумать правильную раскладку class object. В-третьих, если надо, то несложно сляпать самому, и к чему язык загромождать?

Теперь он что, передумал? На кой черт эта фича в языке? Если уж очень сильно надо — что бывает редко — чем плох DECLARE_DYNAMIC из MFC? Однозначно лучше, чем что бы то ни было compiler-generated (а компилятор сгенерит то же самое, это очевидно). Например, тем, что можно откастомайзить под себя class object.

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

E>Ну вот я пишу под ACAD. И кое-что нельзя использовать. Например dynamic_cast

dynamic_cast само собой. Но это не единственный бред в Си++.

E>Так, а что такое "завистливые функиии"?

Метод одного класса, который часто и помногу работает с содержимым другого класса. Кандидат на перенос в тот другой класс.

E>Читайте Буча, первое издание. Там примеры были на Smalltalk. Про энтропию — опять же
>квалификация программистов.

Программисты (и часто даже очень толковые программисты) есть народ, очень склонный к сверхценным идеям и поиску "серебряных пуль" на все случаи жизни. Вбил он себе в башку, что ОО — это круто, и будет потом писать программу для чтения SMART данных с винчестера в ОО стиле, при этом делая идиотства типа открытия файла в конструкторе. И невдомек ему, что OO — это круто для inherently object oriented задач типа UI, а вовсе не панацея на все случаи жизни.

Почти каждая фича, каждый подход, каждый язык и каждая библиотека имеет своих маньяков. Даже такая шиза, как юниксные condvar.

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

Заумь написать мы все можем, дурное дело нехитрое. А ты (абстрактный "ты", не Exhumer) попробуй простой код написать. Существенно сложнее.

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

E>С C++ вообще в командной строке тяжело работать. Но в оболочке — не вызывает никаких >
>атруднений. Особенно если VC + VisualAssist. Удобство работы на порядок улучшается.

О! Уже даже MSVC мало, нужен еще какой-то VisualAssist. Энтропия инструмента такова, что требует дополнительных тулов для ее обуздания

И вот только не надо мне говорить, что project workspace в MSVC лучше, чем файл SOURCES или Makefile. Потому как это не так аргументы могу привести. Project workspace — это иллюзия юзабилити для начинающих.

E>Ну это типичное мнение linux-оидов. Частично как следствие инертности мышления.

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

Я работал на Си++ годы. С 93 по эдак 99. И что я могу сказать... если выкинуть оттуда половину бреда (административным путем), то хороший инструмент для своего круга задач. Для всего UI, например.

Вот только в системном программировании вряд ли он хорош. Потому как бы и не приживается он там. Инструмент старый. Давно зрелый. Уже в 93ем году был зрелый — тот же Борланд 3.1. А в системном программировании не прижился.