http://www.linux.org.ru/forum/development/9500118

Сложновато форматирование оформить, так что извините

Вот этот список:

Вырвиглазный синтаксис и контекстно-зависимая грамматика


медленная компиляция
частые «internal error» в компиляторах
код плохо читается и его сложно поддерживать
разбор кода различными инструментами, вроде IDE, и его генерация — сильно затруднены
ручное управление памятью


неудобства при работе с динамической памятью
утечки памяти
висячие ссылки
сегфолты
стандартные средства, как то malloc/new, работают медленно
фрагментация кучи
велосипедные аллокаторы на каждом шагу
которые далеко не факт что эффективнее malloc/new
велосипедные счетчики ссылок на каждом шагу, опять же
медленная работа
перерасход по памяти
отладка затруднена
написание GC, по факту, невозможно, отчасти из-за (5), (7) и (8)
Никакого ABI
Нестандартизированный и непредсказумый 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)

По причинам 3, 4, 5, 9 и 10 C++ совершенно неприменим для системного и низкоуровневого программирования. А по причинами 1, 2, 5, 6, 7, 8, и, опять же, 9 и 10 — и для прикладного.

У C++ нет области применения.

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

I>http://www.linux.org.ru/forum/development/9500118

Вроде, баян из жэжэшечки, или нет?

I>исключения в конструкторах гарантированно влекут утечку памяти

Хотелось бы тут подробнее с примерами.

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

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

I>>http://www.linux.org.ru/forum/development/9500118

Q>Вроде, баян из жэжэшечки, или нет?

Не проверял.

I>>исключения в конструкторах гарантированно влекут утечку памяти

Q>Хотелось бы тут подробнее с примерами.

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

c::c(){
  field1 = new something();
  field2 = something_that_can_throw_exception();
}

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

I>>исключения в конструкторах гарантированно влекут утечку памяти

Q>Хотелось бы тут подробнее с примерами.

Не корми тролля. Тем более такого унылого.

You will always get what you always got
  If you always do  what you always did

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

I>Вероятно имеется ввиду вот такой код
I>

I>c::c(){
I>  field1 = new something();
I>  field2 = something_that_can_throw_exception();
I>}
I>

Для таких случаев есть списки инициализации, правильный подход к RAII по Саттеру/Мейерсу и к исключениям по Абрахамсу.

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

I>>Вероятно имеется ввиду вот такой код
I>>

I>>c::c(){
I>>  field1 = new something();
I>>  field2 = something_that_can_throw_exception();
I>>}
I>>

Q>Для таких случаев есть списки инициализации, правильный подход к RAII по Саттеру/Мейерсу и к исключениям по Абрахамсу.

Спасибо, К.О. В статье говорится не про возможность обхода, а про наличие проблемы.

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

I>>>Вероятно имеется ввиду вот такой код

Если такой, то почему именно конструктор, а не произвольный метод?

I>Спасибо, К.О. В статье говорится не про возможность обхода, а про наличие проблемы.

Говорится про гарантированную утечку.

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

I>>>>Вероятно имеется ввиду вот такой код
Q>Если такой, то почему именно конструктор, а не произвольный метод?

Спроси автора статьи.

I>>Спасибо, К.О. В статье говорится не про возможность обхода, а про наличие проблемы.

Q>Говорится про гарантированную утечку.

Спроси автора статьи.

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

I>http://www.linux.org.ru/forum/development/9500118

Так, это всё уже сто раз обсуждалось на РСДН. Ты хочешь за раз поднять все топики? Флуд какой-то

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

I>...По причинам 3, 4, 5, 9 и 10 C++ совершенно неприменим для системного и низкоуровневого программирования. А по причинами 1, 2, 5, 6, 7, 8, и, опять же, 9 и 10 — и для прикладного.

I>У C++ нет области применения.

Согласен со всеми претензиями кроме выводов. Реально С++ имеет одну узкую но все же реальную нишу. С++ — это средство обертывания низкоуровневого (обычно высоко-эффективного) кода в обертки облегчающие применение этого низкоуровневого кода. Эдакий фасад над С.

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

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

M>Так, это всё уже сто раз обсуждалось на РСДН. Ты хочешь за раз поднять все топики? Флуд какой-то

Думаю, что от 101-го хуже не станет. Все лучше чем в политике ошиваться.

Я бы перефразировал вопрос так — почему при наличии такого количества недостатков для С++ еще не сделали замену?

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

VD>Я бы перефразировал вопрос так — почему при наличии такого количества недостатков для С++ еще не сделали замену?

А на чем еще библиотеки писать, которые могут быть одновременно использованы из JVM, .NET, CPython и т.д.?
Встраивать чужую VM ради библиотеки занятие не из приятных.

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

VD>Согласен со всеми претензиями кроме выводов. Реально С++ имеет одну узкую но все же реальную нишу. С++ — это средство обертывания низкоуровневого (обычно высоко-эффективного) кода в обертки облегчающие применение этого низкоуровневого кода. Эдакий фасад над С.

Так этот самый низкоуровневый высокопроизводительный код вполне можно и уместно писать на C++. А роль фасада может играть что угодно, Питон или любой другой удобный высокоуровневый язык.

VD>Но по вышеперечисленным причинам ему давно нужно было бы придумать замену. К сожалению ни один язык пока таковой не стал. Причем не по технически причинам, а скорее по морально-социальным.

Нужно, конечно. Но причины очень даже технические. C++ — язык с нулевым оверхедом. Других таких нет.

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

I>У C++ нет области применения.

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

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

VD>>Но по вышеперечисленным причинам ему давно нужно было бы придумать замену. К сожалению ни один язык пока таковой не стал. Причем не по технически причинам, а скорее по морально-социальным.

RO>Нужно, конечно. Но причины очень даже технические. C++ — язык с нулевым оверхедом. Других таких нет.

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

И вот такой момент — как ни открою нативное приложение, почемуто количество потоков зашкаливает. Мне не жалко, но когда счет идет на сотни это не смешно. А если приложение еще иморозится и морозит систему так и вовсе бедствие.

Вот задача, есть файл навроде файла проекта, который содержит кучу линков на файлы и разные ресурсы. Нужно проерить наличие всех таких файлов и ресурсов.
Нативная аппликация создает сотню потоков, на каждый файл, для асинхронных операций. Это очень модно в сиплюсе — создавать потоки под асинхронные операции. Потоки заняты ожиданием, процессор не едят но едят адресное пространство и память. Итог — 100мб памяти распылилось, ап уверенно фрагментируется.
В языке с оверхедом все тоже самое можно сделать штатными средствами без создания сотен потоков при том же перформансе причем без фрагментирования и создания сотен потоков

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

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

I>>У C++ нет области применения.

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

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

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

I>Нативная аппликация создает сотню потоков, на каждый файл, для асинхронных операций. Это очень модно в сиплюсе — создавать потоки под асинхронные операции. Потоки заняты ожиданием, процессор не едят но едят адресное пространство и память. Итог — 100мб памяти распылилось, ап уверенно фрагментируется.

Это отнюдь не проблема языка как такового, а проблема конкретного (криволапого) архитектора.

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

N>А на чем еще библиотеки писать, которые могут быть одновременно использованы из JVM, .NET, CPython и т.д.?
N>Встраивать чужую VM ради библиотеки занятие не из приятных.

Вариантов много: C, D, Delphi, OCaml. А лучше писать версии под каждую платформу. JVM и .NET переносимые решения. Создавать для них флатформно-зависимые библиотеки не лучшее решение.

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

I>>Нативная аппликация создает сотню потоков, на каждый файл, для асинхронных операций. Это очень модно в сиплюсе — создавать потоки под асинхронные операции. Потоки заняты ожиданием, процессор не едят но едят адресное пространство и память. Итог — 100мб памяти распылилось, ап уверенно фрагментируется.

V_S>Это отнюдь не проблема языка как такового, а проблема конкретного (криволапого) архитектора.

У языка вообще проблем нет, ни у одного. Проблемы есть у людей которые с этим языком работают.

В С++ нет ничего для этой самой асинхронщины, как то так.

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

RO>>C++ — язык с нулевым оверхедом. Других таких нет.

I>Я бы не сказал что это большой плюс.
I>Почти везде модные техники програмироваия навроде смартпоинтеров и тд добавляют оверхеда. Собственно нет разницы, откуда взялся оверхед, из либы или самого языка.

А вот ничего подобного. Я уже наткнулся на то, что Java дала мне огромное количество оверхеда, избавиться от которого не представлялось возможным, а речь шла о мобилке, где ресурсы очень ограничены: http://www.rsdn.ru/forum/life/5244441.1

Автор: Roman Odaisky
Дата: 28.07.13