От: | Ikemefula | http://blogs.rsdn.org/ikemefula | |
Дата: | 04.09.13 10:25 | ||
Оценка: | 65 (5) +5 -4 |
Вот этот список:
Вырвиглазный синтаксис и контекстно-зависимая грамматика
По причинам 3, 4, 5, 9 и 10 C++ совершенно неприменим для системного и низкоуровневого программирования. А по причинами 1, 2, 5, 6, 7, 8, и, опять же, 9 и 10 — и для прикладного.
медленная компиляция
ручное управление памятью
частые «internal error» в компиляторах
код плохо читается и его сложно поддерживать
разбор кода различными инструментами, вроде IDE, и его генерация — сильно затруднены
неудобства при работе с динамической памятью
Никакого ABI
утечки памяти
висячие ссылки
сегфолты
стандартные средства, как то malloc/new, работают медленно
фрагментация кучи
велосипедные аллокаторы на каждом шагу
которые далеко не факт что эффективнее malloc/new
велосипедные счетчики ссылок на каждом шагу, опять же
медленная работа
перерасход по памяти
отладка затруднена
написание GC, по факту, невозможно, отчасти из-за (5), (7) и (8)
Нестандартизированный и непредсказумый name mangling
Дублирование функционала Си
сами фичи из Си никуда не деваются при этом
Стандартная библиотека убога
отчасти из-за того, что по функционалу превосходят аналоги из C++
запутывает новичков
malloc — new/new[], free — delete/delete[]
препроцессор — шаблоны
указатели — ссылки
ссылка не может быть NULL, что способствует появлению висячих ссылок и сегфолтов
структуры — классы
stdio — iostream
Отсутствует даже такой функционал, как вменяемая работа со строками и многомерные массивы
Слабая типизация
Юникод?
способствует ошибкам
объектая система убога
затрудняет отладку
const не дает абсолютно никаких гарантий
при этом система типов невероятно переусложенена
в основном из-за пунктов (2), (5) и (9)
медленная компиляция
частые внутренние ошибки в компиляторах
практически никакой интроспекции
шаблоны
отладка затруднена
передача объектов по значению
понятие идентичности объекта теряет смысл
добавляет сложностей в управлении памятью
добавляет сложностей при отладке
используется часто, по причине (2)
перерасход по памяти
медленная работа
множественное наследование неудобно в использовании
проблема ромба по дефолту не разрешается никак
исключения в конструкторах гарантированно влекут утечку памяти
исключения в деструкторах тоже, и просто утечку — еще в лучшем случае
коды ошибок деструкторы и конструкторы возвращать не могут
ошибки в них не обработать никак
поэтому ими стараются не пользоваться
раздувание кода
деструктор можно вызывать до выхода из блока кода, или до delete
гарантированная утечка ресурсов/сегфлот
это не предотвратить никак, деструктор обязан быть public
одиночная диспетчеризация
виртуальные методы в конструкторах не работают
реализована убого
pure virtual function call
сложности в случае с множественным наследованием
деструкторы обязаны быть виртуальными
по дефолту — не виртуальные
никаких интерфейсов, только классы
порядок инициализации статических членов классов не определен
private, public и protected не дают никаких гарантий сокрытия данных
к инкапсуляции же не относятся совершенно никак
отсутствие «свойств»
вынуждает городить getter'ы и setter'ы
раздувание кода
размывание интерфейса класса
неявно генерирумые конструкторы, деструкторы и операторы присваивания
«friend» нарушают инкапсуляцию
очень сильно замедляют компиляцию
исключения
раздувание кода
обфускация кода
результат раскрытия плохо предсказуем
сложности в отладке
километровые и плохо читаемые сообщения об ошибках при компиляции
нарушают инкапсуляцию
обязаны содержать реализацию в заголовочных файлах
позволяют генерировать некорректный код
отсутствие finally/unwind-protect
заставляет городить классы ради одних деструкторов
раздувание кода
медленная компиляция
медленная работа
конфликтуют с другими возможностями языка
конструкторы/деструкторы
ручное управление памятью
работают медленно
малофункциональны (ср. CL condition system)
У C++ нет области применения.