Является ли управление памятью главной проблемой C/C++?

Имхо - нет.
Выделение и освобождение памяти (как и прочих ресурсов!), имхо, совсем не трудная задача и её легко проводить даже в C.
Это дело просто дисциплины. Тупой как валенок дисциплины.
Например в Delphi я никогда не испытывал особых проблем от того, что в каждом деструкторе надо вызвать вручную деструкторы объектов которыми текущий владеет.
Цепочки владения и передача владения - всё это тривиально, если придерживаться тупой как валенок дисциплины. Это ни разу не творческая задача - это кодерство чистой воды.
Да, писанина и _возможность_ ошибиться спросонья по запарке. Такая же возможность как описаться в границе for.
Но в конце концов есть всякие детекторы утечек, можно даже без внешних тулзов воткнуть счётчики в деструкторы и в принципе вопрос решаемый. Есть хотя бы за что зацепиться в случае чего. Видишь в диспетчере задач, что память растёт - значит надо искать проблему. Тупо.

Что же на самом деле является проблемой C/C++? На мой взгляд это выход за пределы массива. Это грёбанный heap/stack corruption.
Вот это - бич и бич осязаемый от которого очень трудно избавиться - потому что он непредсказуем, трудно определяется где происходит, вылазит боком как пуля со смещённым центром тяжести и оно реально происходит. Где то забыл умножить на sizeof( short ) и fread запорол тебе heap и т.п. и т.д. И можно до посинения искать ошибку потом в отображении модели которой там нет.

Вот это - реально проблема.
А менеджмент памяти - нет.

Поэтому чем всякие Java выигрывают для меня по сравнению с C/C++? Только тем, что невозможно накосячить с heap corrupt и тебе в любом случае будет выкинуто исключение null pointer или index out of bounds и ты точно увидишь где проблема и в чём она сразу же по месту её возникновения. Только этим.
А сборщик мусора - не более чем приятный бонус.

=A=L=X=
> и fread запорол тебе heap и т.п. и т.д. И можно до посинения искать ошибку
> потом в отображении модели которой там нет.

иноверец? тебе же говорят шо нету разницы по скорости разработки между явой и сипипи

innuendo
> иноверец? тебе же говорят шо нету разницы по скорости разработки между явой и
> сипипи

Если под C++ понимать Qt, то в принципе да.

=A=L=X=
> C/C++
Нет такого языка.
Есть Древнее говно для прострела ноги (Си) и есть более-менее современный и безопасный (но не без недостатков) язык C++.

> Выделение и освобождение памяти совсем не трудная задача
> Это дело просто дисциплины
Кожаные ублюдки плохо справляются с соблюдением дисциплины. Поэтому лучше автоматизировать необходимые действия.
У меня на проектах, например, ручных вызовов delete вообще нету, а в большинстве своём даже вручную написанных деструкторов нету.

> Это грёбанный heap/stack corruption.
> он непредсказуем, трудно определяется где происходит
Отчасти это лечится написанием тестов и прогоном их под всякими детекторами (valgrind, например).

> де то забыл умножить на sizeof( short ) и fread запорол тебе heap
Если ты забыл умножить, то ты это быстро заметишь - увидишь, что данные прочитались не полностью.

> будет выкинуто исключение null pointer или index out of bounds и ты точно
> увидишь где проблема и в чём она сразу же по месту её возникновения
Можешь обложиться санитайзерами на C++ и получить тот же результат. И по скорости оно будет на уровне той же Жабы.

Вопрос из серии "являются ли буквы главной проблемой алфавита?"
В плюсах полно проблем вроде ub, unsigned index и пр. А вот простая реализация управления памятью наоборот входит в основные преимущества языка.

Panzerschrek[CN]
> Можешь обложиться санитайзерами на C++
Около года назад случайно наткнулся на скрытое повреждение стека, неотлавливаемое санитайзерами, так что не панацея.

Ну вот obj-c как-то живет без деструхтиров и смарт пойнтеров и ему нормально.

nes
> и ему нормально
...было несколько лет назад, пока ябл не запилили свифт. С обж-с нынче даже начинают крупный софт снимать потихоньку.

Кстати, почему это без смарт-поинтеров? Там ведь наоборот все указатели по-умолчанию автоматические.

=A=L=X=
> Например в Delphi я никогда не испытывал особых проблем от того, что в каждом
> деструкторе надо вызвать вручную деструкторы объектов которыми текущий владеет.

Этих проблем не было даже в Turbo Pascal 7.0, таки да, дело в дисциплине, - написал GetMem, сразу же написал FreeMem и логику между ними. Та же фигня что с обычными скобочками, написал левую, сразу поставь правую и всё.

Panzerschrek[CN]
> Отчасти это лечится написанием тестов и прогоном их под всякими детекторами
> (valgrind, например).

Тесты надо писать на функционал, - написание тестов на отстрел ноги, - плохая новость (неумение пользоваться компилятором...  или, в случае динамического УГ, - необходимость писать отсутствующие части компилятора со статической типизацией)

Panzerschrek[CN]

А, да, хотел написать, да забыл, что в С++ проблема за счёт автодеструкторов и умных указателей еще и сильно ослаблена.

В Дельфи еще внутри функции чтобы не было утечек есть примитивный тоже паттерн:

obj1 := nil; // локальные переменные заполнены мусором
obj2 := nil; // поэтому надо принудительно занулить
obj3 := nil;
try
  obj1 := SomeObject.Create( ... );
  ... // и так далее
finally
  obj3.Free; // безопасно вызывать для nil
  obj2.Free;
  obj1.Free;
end;

pahaa
>С обж-с нынче даже начинают крупный софт снимать потихоньку.
И как там у свифта дела с кроссплатформенностью?

>Кстати, почему это без смарт-поинтеров? Там ведь наоборот все указатели по-умолчанию автоматические.
Я его уже плохо помню, но, вроде без ауторелиз пула будет утечка памяти, не?

=A=L=X=
> Если под C++ понимать Qt, то в принципе да.

не понял, шот ты имел ввиду?

pahaa
> Около года назад случайно наткнулся на скрытое повреждение стека,
> неотлавливаемое санитайзерами, так что не панацея.

обманываешь, мне вот крутые дяди сказали что всё ловится на раз два :)

pahaa
> случайно наткнулся на скрытое повреждение стека
Расскажи мне, как ты умудрился такое сделать, а я тебе поясню, что ты делал не так.

nes
> obj-c как-то живет без деструхтиров и смарт пойнтеров и ему нормально
Он мёртв, вместо него Swift в котором это всё есть.

0iStalker
> Тесты надо писать на функционал, - написание тестов на отстрел ноги, - плохая
> новость
Хороший набор тестов на функционал позволяет проверить почти все пути выполнения и все экстремальные случаи.

=A=L=X=
> в С++ проблема за счёт автодеструкторов и умных указателей еще и сильно
> ослаблена
Более того, ослаблена и проблема порчи стека.
Там где Си-шный говноед выделяет буфер на стеке, ошибается в sizeof или не проверяет входные данные и получает порчу стека (со всеми вытекающими последствиями), плюсовик тупо заиспользует std::vector, и сделает ему resize.

Panzerschrek[CN]
>Он мёртв, вместо него Swift в котором это всё есть.
Да ты шо, и как свифть дружит с крестами?