Russian Qt Forum

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

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

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

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

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

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

Нередко да

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример, конечно, крайне упрощенный. В самом деле дело было так. Был класс, и он работал с файлом. И много там было всего еще. Конструктору передавалось имя. А файла могло и не быть. И тут бы самое лучшее - вернуть что-то, говорящее - нету твоего файла. NULL, например. Потому что без толку экземпляр городить. И даже память на переменные класса нету смысла выделять. Конечно, можно это дело закостылить. Переменную, говорящую о неудаче. Потом взять ее геттером, сказать экземпляру delete и спокойно работать дальше. Но эстетически это выглядит костылем. Как и try.
К тому же, этот класс пользуется в нескольких местах, раскиданных по кодам. Тоже выход не сложен. Обернуть функцией. (не методом!) Но осадочек все равно остается....:)

Да нельзя сказать, что уж очень я озабочен. Вы предложили поболтать, я и вспомнил эпизод. Какие там заботы?! Всегда можно вставить кусок на чистом С (слава Богу, пока это не запрещено) или вот костылик наваять. Поле для творчества немерянное!:)

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

Скорее всего ваш класс не Pimpl. Что мешает создать его в стеке, что ничего не стоИт в плане производительности.
Вариант 2:  функцию static создать (аля класс фактори), которая возвращает объект если файл есть (либо прочитанным файлом). Аля:

Применение:


Это конструкция примитивна, но действенна - мы избавляемся от ошибок инициализации в конструкторе класса и добавляем проверки при передачи в сам объект и не будет выделение памяти под файл.
Понятно, это RAI конструкция, возможна и pointer или unique_ptr. Там проще - nullptr - нету файла. Но кого это интересут, дабаги сообщения наше всё.

Но даже это не стоит той работы (кроме, конечно, удовлетворения своим кодом). Чтение файла в тысячи (минимум) раз медлениее, чем самое ваше медленное решение.

std::optional (https://en.cppreference.com/w/cpp/utility/optional) для этого случая подошло бы?

Проверять имеет смысл только когда выделяются какие-то большие буфера, если после пары гигов нет памяти на инт, то ничего не поделать, придется упасть с std::bad_alloc.
В этих случаях можно обойтись маллоком и проверить по-старинке.
В остальных 99% случаев просто забить.
На самом деле, в том же Линуксе маллок никогда не вернет nullptr и new не тровнет, там по умолчанию включен memory overcommitment. То есть программу убьют когда вы попытаетесь в эту память записать, а не на выделении.
Вывод - ловить нехватку памяти надо только там где это можно нормально обработать, в остальных случаях - забить.

В C API считается хорошим тоном проверять все указатели на null. Как достичь того же на плюсах? Просто сравнение this нехорошо, о чем шланг и говорит.

Хорошо, пусть так, но согласитесь - последующий совет выглядит совсем куцым по сравнению с уничтожающей критикой, да и очевиден без всякого чтения
:)
Таких мест много сотен, всякий раз рихтовать вызывающего трудоемко, да и короткая конструкция заменяется на более длинную. А если попробовать так

C++ (Qt)
template <class T>
bool IsNull( const T * a ) { return !a; }

Да, множ наследование все равно не проверит, ну и бог с ним, это редкость. Что еще плохого? Покритикуйте

А что это решает? :)

Вопрос к уровню рассуждений. На каком мы уровне?
Можно рассуждать о скорости: v = расстояние/на время. В квантовой теории формула преображается.

Большой проект с выделением огромного кол-ва памяти? Совершенно другой подход, который мы здесь не  обсуждаем. В конкретном случаем мы не Oracle DB пишем. Хотя, возможно, есть здесь люди, которым надо большие объемы. Там сразу идёт по дефолту "менеджер памяти" свой и в этих рассуждениях они не участвуют. Аля пул потоков или аля стек. Не знаю как правильно аналогию провести.

Ну кто здесь парится про стек, который занимает 2 метра. Любое падение в стеке- ошибка рекурсии.

Это я к чему, Авварон. Надо на одном уровне находится, хотите другой - либо его красиво поднимайте в новой теме, либо.... Ну, не знаю как.

Мужик, я нихрена не понял что ты мне сказал (https://www.youtube.com/watch?v=9nHHgVXcbFA)

Эхехех
Как то так:
1-й класс: 3-5 - задача не имеет решение.
4-й класс: 3-5 равное -2.

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

Та этож бред! Земля вращается вокруг солнца, оно не может встать.

Сомневаюсь, что вы будете выносить мозги своим родным, доказывая что это утверждении не верно.

НО!!!!!!!!!!! Видео мне пондравилось.

Azazello, понятнее-то не стало. Я тоже НХНП. :D

Ну хорошо.
Митинг/оперативка/собрание.
Руководитель: написать ауторанер для DVD. Типа инстал что-то, красивые обои.
И тут встаёт чел: Предлагаю использовать самые передовые технологии! Будем писать на С+17 с использование последних фитч!
Все остальные ( в мыслях): Ну дебил, митинг затягивает, дадим Коляну, он за сегодня напишет.

Вариант 2:
Митинг/оперативка/собрание.
Руководитель: мы сегодня будем разрабатывать новую БД, которая порвёт рынок!
И тут встаёт чел: Предлагаю использовать самые передовые технологии! Создадим свой менеджер памяти и файловой системой!
Все остальные ( в мыслях): Ну блин попали, о чём он?

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

Да блин, что тут объяснять: когда начинаем строить дом, нефиг цвет занавесок обсжудать.
Когда дом построили и выбираем занавески, нефиг фундамент обсуждать.

Я как-то пришел на собеседование студентом в контору где меня срезали на том что я не привык проверять аллокацию памяти. Эти чувачки писали if (ptr) после ptr = new QTreeWidgetItem. Nuff said.

Да в том же Си есть фунции с суффиксом s (secure), которые делают доп проверки "на взлом". Хош вызывай небезопасную, хош безопасную. Это я к чему  - если вы уже точно знаете, что ваши данные валидны, зачем каждый раз вызывать s.

Если брать аналогию с C++, то тут даже проще. Половину ресурсов вы можете создать в конструкторе (нужном инициализваторе) и больше внутри класса не парится на проверку. Либо (для примера) pimp, где приватный класс точно знает, что все данные у него валидны - проверка во внешнем классе. (опять же, это как пример).

Так что я думаю тут плюсы выигрывают в плане проверок и краткости кода.
Да в конце концов можно использовать отложенную инициализацию.
И проверка if превращается в getPointer, где поинтер возвращает обертку над данными, которая всегда валидна для использования, даже если данных нет.

Или глобально в классе, isValid...
Какие то у вас не транзитивные классы. Ну очень. Я не знаю, что это означает, но звучит круто.

Классический вызов функции Си:


Даже определение std::unique_ptr(e,someOperationFree) очень упрощает этот сишный код

Очень смутно, но когда-то видел форму new которая возвращает null вместо выброса исключения. Что-то типа

C++ (Qt)
a = new (std::nothrow) int[N];

Но могу путать

А где же "благодать" что Вы говорили в стартовом посте? :) "С" не любят потому что он резко ограничивает возможности говнокодинга, все должно быть сделано аккуратно и скрупулезно. Зато на плюсах... Хирак - вот и контейнер, а то и пяток-десяток. Нужны они или как - та кто там будет думать если все так дешево и доступно. А уж std - рай говнокодера, "фишку" выучить и тыкать повсеместно (закрепляя заученное).

А что это упрощает? Ну облегчает удаление, а фиксация ошибки (printf в примере) и передача упр-я (return в примере) как были - так и остались. Понятно что хочется и это списать на "устаревший С" и ни хрена не проверять, ведь так (намного) легче

Чо???? Да C разрешает все, что угодно. Поэтому и говнокодинга на нем в разы больше, чем на плюсах.

На плюсах можно использовать штуки типа gsl::not_null, тогда можно не проверять всё подряд на null.

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

Ну ладно, берем открывам любой исходник С++ и рядом С. Смотрим.

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

Тут я думаю Igors имел в виду другое.
Попытаюсь сказать за него, но могу ошибаться, он поправит:

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

Хех. Но на практике это не так :) Видно когда бородатые дядьки на нем начинали кодить, инета особенно не было, жене не интересно вот и колбасили как хотели, а культура прижилась.

Все верно, "простыня" и "плевать" (из Вашего предыдущего поста) не покатят, быстро захлебнетесь в собственном коде. Не стали бы Вы копипастить отработку ошибки 57 раз, придумали бы как обобщить. Др словами ограниченность (пусть даже "убогость") средств дисциплинирует. А вот на плюсах, увы, этого не происходит. Зачем что-то придумывать?  Лучше чего то скоммуниздить (gsl::not_null), или, конечно, exception (который может и к месту, но может и нет).

Старый юмор (http://www.prog.org.ru/topic_12917_0.html)

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

Воспринимайте мой первоначальный пост следующим образом:
Как хорошо когда жена уехала, наконец то можно носки разбрасывать где хочу.

gsl::not_null поддерживается основными статическими анализаторами (clang и мелкософтным). Удачи сделать свой велосипед=)

А вы пользуетесь этим gsl::not_null? Какие ощущения? И как у него с поддержкой умных указателей (в частности unique_ptr)?

К сожалению, не пользуюсь=( Только недавно перешли на с++17 моими стараниями (был с++11), а gsl хочет с++14 минимум. В ближайших планах есть.
gsl:span юзал, вот это вещь, да.
С умными указателями вроде всё неплохо, почему нет?