Не в том дело, что что-то лучше или производительней.
Но какая благодать использовать чистый С.

Это после подключении либы С к своему проекту.
Какие классы, какие архитектуры. Та вообще - пишем как хотим. Оууууу.
Нет никаких ограничений. Что в голову пришло, то и фигачишь простынёй. Плохо?  memory leak тесты подправят.
Всё таки можно позавидовать. Основа - атомы, т.е. обычная функция.
C++ основа - класс. Но в отличие от С: функция может жить отдельно, класс - архитектура.

Да, да. Здесь нет никакого открытия, все об этом знают. Но когда сидишь в своей "коробке" долгое время, а потом с этим  очередной раз сталкиваешься, очередное очевидное открытие.

Не, понятно, щас Igor вылетит о том, что у них точно также: классы не обязательно архитектура. Оно то так, если у вас классов внутри много, а вы тяготее к функциям.

Я не сетую за чистый С, наверное я на С++так повернулся, что уже не могу по другому.

Нередко да

Не было такого в мыслях

Мне достался "в наследство" большой проект написанный в незапамятные времена на Паскале и потом кое-как переведенный на C "без всяких классов". Время от времени я рефакторюсь, обычно это сводится к замене расхристаных ф-ций на класс, часто он получается с многими десятками методов, а иногда и не одну сотню. Откуда возникает эта необходимость

- слишком много параметров (переваливает за десятку)
- трудно найти нужную ф-цию (хотя она есть)

С др стороны масса "процедурального" кода продолжает работать в первозданном виде, и никакой необходимости его менять я не вижу. Обычно старый хедер файл - объявление структуры без методов, и тут же набор ф-ций для работы с ней. Т.е. класс как бы "незримо присутствует". Но механически делать это "обычным" классом не всегда так уж хорошо, выгодно.

Да, кстати. Вот допотопный (псевдо)код
Бяка - кака. Давайте сделаем нормальный метод

C++ (Qt)
void SomeClass::SomeMethod( ... ) 
{
  if (this) {
  ...
  }
}

и тут компилятор выдает гневный варнинг что, мол, так не должно быть в "well-designed C++ code", а в С++ 17 вообще будет хана. Но проверка очень полезна (желательна, необходима) и выносить ее наружу не хочется

Ну и что делать?

Ну хоть так
где ф-ция (или метод) FindObject возвращает указатель на объект или null если нет с таким именем. А GetID может быть напр таким

C++ (Qt)
int SomeClass::GetID( void ) const
{
 return this ? m_id : 0;
}

Это очень глупое решение. Проверяй указатель на nullptr в месте вызова.

Ну, вот такой простой пример (и не очень надуманный)

Эу. я не увидел здесь нигде c++ в современном понятии. В любом случае, какой бы тип не был (вы сейчас привели базовый int), всегда есть возможность тип обернуть в класс, чтобы использовать RAI. На крайняк unique_ptr, shared_ptr.

Ваш пример настолько многочитаем, что все таки его лучше конкретизировать.
Меня уже коробит
try {
  a = new int[N];
}

никто в здравом уме не обрабатывает для x86 архитектуры ошибки нехватки памяти.

Ваши рассуждения содержат софизм.
Это очень распростанненная ошибка, думая, что выделяя "разумное" кол-во памяти и обрабатывая ошибку вы перекрываете 90% своих запросов.
Это не так. После выделения 300 метров, следующее выделение инта может быть фатальным. Какой смысл оставлять 10% (это пример) не обработаных исключений?

Но это теоретические выкладки, на практике все совершенно по другому. И тут нужна более развернутая дискуссия.

Но оставим это. Ваша же программа базируется на других библиотеках, пусть к примеру на Qt.
И там нету никаких проверок. А с Qt и Pimpl это вообще треш, вы же их не перекроете по количеству даже на 5%.

Обрабатывая все ошибки выделения памяти на плюсах (достаточно кстати дорогой операции, это на камнях без ОС она ничего не стоит) вы его по производительности превратите в bash. И, чтобы, усилить свои слова, задам встречный вопрос - почему же никто кроме вас не озабочен этой проблемой?