c vs c++

[Azazello]

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

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

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

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

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

[Пантер]

Выдыхай чувак. И больше не кури эту гадость.

[Igors]

Но какая благодать использовать чистый С.

Нередко да

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

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

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

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

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

[Azazello]

Выдыхай чувак. И больше не кури эту гадость.

Так этож классно, чувак. Во всех придуманных смыслах.
И не такая она уж и гадость была.
Мы же по спирали ходим, и новые вещи открываем для себя, которые уже давно "открыли" для себя.
Но некоторые ходят по кругу.

[Igors]

Да, кстати. Вот допотопный (псевдо)код

Код:

void SomeFunc( SomeStruct * a, ...) 
{
  if (a != NULL) {
  ...
  }
}

Бяка - кака. Давайте сделаем нормальный метод

Код

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

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

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

[Пантер]

Это ненормальное переписывание кода. Как тут this может быть nullptr? Приведи пример.

[Igors]

Как тут this может быть nullptr? Приведи пример.

Ну хоть так

Код:

if (FindObject(name)->GetID() == theID) return true; 

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

Код

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

[Old]

Разыменование nullptr это UB.
Компилятор может нагенерить что угодно, и поведение этого кода будет сильно отличаться от ожидаемого вами. Почитайте недавнюю тему от Гурмана и не пишите таких глупостей.

[Пантер]

Как тут this может быть nullptr? Приведи пример.

Ну хоть так

Код:

if (FindObject(name)->GetID() == theID) return true; 

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

Код

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

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

[Azazello]

Бяка - кака. Давайте сделаем нормальный метод

Код

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

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

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

Не, ну тут я вообще ничего не осилил, даже Ваш пример. В упор не понимаю эту конструкцию.
Видно есть ещё магия в плюсах, которую невозможно осилить.

[Day]

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

Код:

int *a;
a = malloc(N*sizeof(int));  // C
if (a==NULL) ...
                        // C++
a = new int[N];  // Может выброситься исключение. Только так можно поймать...
                        // Приходится оборачивать
try {
  a = new int[N];
} catch {
   ...
}
         // Но меня коробит...

[Авварон]

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

this не может быть nullptr и компилятор волен убрать всю ветку кода с else. gcc вообще убирает всё нафиг и вставляет трап.
причина - множественное наследование.
Если класс С наследует А и В, то вызывая метод В от nullptr, this для В становится равен nullptr+sizeof(A). И "изнутри" В вы хрен это поймаете (вы же не знаете наследует В кто-то или нет).
Это плохой и негодный код. Делайте статичным сишным методом. То есть оставляйте как было.
Вот опять очередная попытка обмануть компилятор и его разработчиков.
Я в вышеназванной теме кидал статью зачем нужно UB в си/си++ и как компилятор оптимизирует исходя, но вы же не читали

[Azazello]

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

Код:

int *a;
a = malloc(N*sizeof(int));  // C
if (a==NULL) ...
                        // C++
a = new int[N];  // Может выброситься исключение. Только так можно поймать...
                        // Приходится оборачивать
try {
  a = new int[N];
} catch {
   ...
}
         // Но меня коробит...

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

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

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

[Пантер]

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

Код:

int *a;
a = malloc(N*sizeof(int));  // C
if (a==NULL) ...
                        // C++
a = new int[N];  // Может выброситься исключение. Только так можно поймать...
                        // Приходится оборачивать
try {
  a = new int[N];
} catch {
   ...
}
         // Но меня коробит...

Если ты отхватил эксепшен выделения разумного количества памяти, значит тебе и ловить ничего не надо, ибо дальше программа врядли будет коректно работать. Конечно, я не говорю про вариант, когда ты сам рулишь памятью.

[Azazello]

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

Код:

int *a;
a = malloc(N*sizeof(int));  // C
if (a==NULL) ...
                        // C++
a = new int[N];  // Может выброситься исключение. Только так можно поймать...
                        // Приходится оборачивать
try {
  a = new int[N];
} catch {
   ...
}
         // Но меня коробит...

Если ты отхватил эксепшен выделения разумного количества памяти, значит тебе и ловить ничего не надо, ибо дальше программа врядли будет коректно работать. Конечно, я не говорю про вариант, когда ты сам рулишь памятью.

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

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

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

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