Опрос: Три-пять лучших фич C++

И поговорим )) Сам то поди на работе?

Как вернуть ошибку из конструктора без использования исключений?

X::X(int *status)
{
    if (/* problem 1 */) {
        *status = -1;

        return;
    }

    if (/* problem 2 */) {
        *status = -2;

        return;
    }
}

Гыы ))

Как вернуть ошибку из конструктора без использования исключений?

В Haiku для этого после конструктора надо вызвать status_t InitCheck() который вернёт код ошибки.

Пробовал ли ты писать на Си++ без исключений?

А без стандартной библиотеки?

Да. Даже ОС писать пробовал.

Т.е. ты сначала заявил, что в сишке нет массивов, и только потом решил поинтересоваться, про что же ты заявил?

Как массив передается в функцию?

Чел… Почитай учебник.

Как передать массив по значению?

Сам иди читай, школотрон.

на каждый чих

если это «чих», то обойдусь и препроцессором.

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

для получения желаемого результата

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

попроще и получше, без каких-либо серьезных потерь в производительности

это кто у нас тут нашелся простой и быстрый? )

И… утечка памяти и объект в недоинициализированном состоянии, который нужно очень аккуратно деинициализировать. В приведённом тобой примере нет намёков на то, что ресурсы, выделенные в «problem 1» будут корректно освобождены, если «problem 1» решится успешно, а «problem 2» — нет. Так что да, «гыы» очень хорошо описывает такой подход.

ага, прокрастинирую

Объект сам разберётся как ему себя деинициализировать. Деструктор будет вызываться.

нет намёков на то, что ресурсы, выделенные в «problem 1» будут корректно освобождены

там нет намеков и на то, что они там будут выделены )

для этого после конструктора надо вызвать status_t InitCheck() который вернёт код ошибки

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

Да. Даже ОС писать пробовал.

Молодец, возьми с полки пирожок. Я очень рад за тебя, правда. Я не очень рад, что ты пытаешься втирать в лицо свои взаимоотношения с Haiku всем подряд, особенно тем, кто про неё у тебя не спрашивал. Но это твоё дело.

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

почему для Си++ классов нужны исключения

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

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

исключения не нужны классами без конструкторов

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

Объект сам разберётся как ему себя деинициализировать

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

Я не очень рад, что ты пытаешься втирать в лицо свои взаимоотношения с Haiku всем подряд

Это было не про Haiku, а про «Мини ОС», написанную с нуля на C++ (Clang) для RISC-V. Си там вообще не поддерживается системой сборки на Makefile.

«то есть арифметические действия нужны, потому что дизайн ЯП без них кривой до состояния неюзабельности?»

«говоря проще арифметические действия это костыль, который создатели ЯП убедительно просят считать органичной частью их детища. ок)»

я исправил за тебя

Можно ещё фабриками пользоваться и не вызывать конструкторы напрямую.

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

Будет выглядеть как обычный C++ код без исключений... и без половины стандартной либы. То есть, инициализируем struct-class либо отдельным методом, возвращающим статус, либо вообще свободной функцией. А деструкторы используются только как некрасивая многословная форма «defer» и «attribute cleanup». Поскольку нет исключений, то нет и проблемы исключений в деструкторах.

есть некоторое количество ЯП в которых вообще нет механизма исключений, и это никоим образом не мешает на них программировать.

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

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

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

Добро пожаловать в CPython.

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

Другое дело, что «нетрудно наколхозить» обычно побеждает, даже если колхоз выглядит как колхоз и так же и ощущается. И более того на этот колхоз тратится время, просто чтобы преодолеть отсутствие функциональности нужно для задачи. Не это ли дописывание инструментария в процессе разработки? Использовать сейчас С без легаси нужды, или ситуации когда под целевую платформу нет ничего кроме С, ну хз, зачем?

Zero cost abstractions - абстракция не стоит дороже чем эквивалентный по функциональности код, написаный вручную без абстракции. Если стоит - это скорее баг или пробел в оптимизации, чем by design.

Мономорфизация, умные указатели

есть варианты и получше, тот же зиг неплох, д неплох, прости господи даже раст наверное.

этим йуным росточкам еще только предстоит отвоевать свое место под солнцем. заговорил и пошел - это еще не вся жизнь )

чтобы преодолеть отсутствие функциональности

обычно высказывают претензии к отсутствию сахара, а не «функциональности».

Использовать сейчас С без легаси нужды, или ситуации когда под целевую платформу нет ничего кроме С, ну хз, зачем?

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

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

не от достатка функциональности в языке, а он ее отсутствия

отсутствие фунциональности применительно к С - например? о чем речь?

Бегут, роняя.

Ну да, не спешат, ну и что? Когда-то (я бы ставил на «в течении года») добавят же. То есть, может разработчики и не считают, что шаблоны жизненно необходимы, но это и не похоже на «не нужно», раз всё-таки делают.

У меня такое ощущение, что про Си++ ты знаешь только название, а все твои оценочные суждения строятся по принципу «выдумал что-то, заявил, и если не набежали опровергать, то это считается правдой».

RAII
исключения
пространства имён
перегрузка функций

Уедешь на необитаемый остров без шаблонов?

Они как правило типовые и вместе с кодом не сказать чтобы очень трудно решаемые. И сообщение об ошибке компиляции всегда лучше ошибки в райнтаме, особенно, когда эта ошибка появляется время от времени

Дуглас Крокфорд с тобой не согласится, потому что херак-херак-и-в-прод пишется значительно быстрее при проверках в рантайме, чем при выносе мозга компилятором. Единственная реальная проблема, которую ты правильно указал «ошибка проявляется время от времени», но я боюсь, что C/C++ — это совсем не те языки, где решена проблема воспроизводимости.

ООП методология прекрасна. Реализация в C++ прекрасна. Разумеется если умеешь этим пользоваться и получать от этого удовольствие

Кто-то получает удовольствие от анального секса или регулярных семейных ссор. А я считаю, что ООП в крестах — это пародия на ООП, просто в последние 20-30 лет всплыли на поверхность школьники, которые кроме крестоового ООП ничего не знают, и которые перевернули теорию верх-ногами, так что теперь ООП в C++ стал для них эталоном, а всё остальное — модификации и подражания. Хотя на самом деле это пародии на пародии, и в том JS исходного ООП намного больше, чем в крестах.

и потому те же Go и Rust отказались от классов

Да это просто другой бренд. Другая реклама, другой продукт, адепты которого будут нести любую херню, чтобы обесценить уже имеющийся

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

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

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

Хорошо что уточнил, потому что да, в Си можно написать тоже со стоимостью в рантайме. Но смысл моего послания былл в том, что в крестах шаблоны чаще всего задействованы там, где шаблоны на самом деле не нужны. Именно поэтому программы на Go по большей части хорошо себя чувствуют без обобщений. Можно спорить о том, что аналогичную задачу можно решить совсем без шаблонов, на другом варианте метапрограммирования, и тоже с нулевой стоимостью в рантайме.

Нафига эти фантазии нужны? Если нельзя плюсы, бери без плюсов. Если можно плюсы - бери плюсы

Опрос, так сказать, с заковыкой. Настоящий вопрос «что бы вы убрали из C++», но я его завернул в необычную форму. Конечно же нет причин не использовать кресты, но есть большие причины для того, чтобы выкинут добрую половину фич крестов.

D и Go пошли по другому пути. Да что там, даже в GCC есть атрибут cleanup типа.

Это можно забыть написать и требуется постоянно писать заново в каждом случае

Если сделать typedef, то не забудешь. По сути получается очень, очень близко к деструкторам. Только без классов, поскольку классы — лишняя сущность, которая ничего не делает в алгоритме.

Лямбды, constexpr/consteval, атрибуты, модули, корутины. Если появится defer, то и его тоже

Очень хороший ответ, близкий к моему. Я только одного не понимаю: для чего корутины? Вот какие есть хорошие задачи, которые они умеют выполнять?

Меня немного повеселила эта статья https://habr.com/ru/post/243593/

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

Вначале может показаться неудобством, но с первых строк на …(ВСТАВИТЬ НУЖНОЕ)…, понимаешь, насколько это было удобное решение

Это спорное решение, но это мелочь. В Go есть проблемы, как то сомнительный упор на интерфейсы для реализации полифорфизма, но если говорить про private-public, то я бы вообще убрал private из языка, потому что от него только проблемы.

Вообще, откуда берется этот private: когда-то были внутренние структуры, реализация их алгоритмов, и функции-интерфейсы с параметрами-интерфейсами. Потом в какой-то момент умники нашли «решение» для организации архитектуры подобного приложения: давайте все-привсе функции и структуры данных запихнем в одну единственную сущность. Это и есть класс. Поскольку выяснилось, что в этом классе смешались в кучу конелюди, то теперь приходится решать проблемы, созданные таким «решением». Самый тупой вариант — закомментировать члены класса, мол «ты сюда не ходи. ты туда ходи», private-public — а это не более чем машиночитаемые комментарии, при нарушении которых компилятор бьет по пальцам.

Но вот чудо: нет классов — нет проблем.

А кому от этого легче станет, кроме разрабов компиляторов? В плюсах же в основном всё в компайлтайм решается, и если фичу не использовать, кушать она не просит.

Уедешь на необитаемый остров без шаблонов?

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

а у меня такое ощущение (тм), что ты решил решил переключиться на обсуждение меня )

Ну посмотри на Go, например.

Кстати, в Go стандартную библиотеку можно отключить?

отсутствие немспейсов, отсутсвие перегрузки функций, обобщенное программирование

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

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

машина едет, даже если не блестит.

Вот какие есть хорошие задачи, которые они умеют выполнять?

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

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

Если у тебя есть на уме более вежливая формулировка, озвучь. Если она действительно хороша, постараюсь в будущем использовать её или её вариации, чтобы поменьше обижать собеседников.

Если сделать typedef, то не забудешь.

Как тайпдеф тут помогает? Вот пример кода на Go:

func foo() error {
    file, err := os.Create("...")
    if err != nil {
        return err
    }
    defer file.Close()
    ...
}

Что и как тут тайпдефить?

Си я предлагаю поскорее закопать чтобы не мучился. Нет ни одного оправданного случая его использования кроме работы с очень устаревшим железом/ПО

Работа с оборудование, упаковка байтов (для сети), разделяемая память, БД, ну и тупо GPGPU/шейдеры.

Всё это прекрасно делается на C++.

Я вот прямо сейчас пишу драйвер видеокарты Radeon/AMD на C++.

Работа с оборудование, упаковка байтов (для сети), разделяемая память, БД, ну и тупо GPGPU/шейдеры.

Это С++ везде. nvcc это С++17 компилятор, какой С?

Всё правильно, С нужен только для устаревшего железо/ПО.

Если нравится С, то можно использовать С. Но нужен он только для устаревшего железо/ПО где нет С++.

Я же говорю: тут вопрос про идеальный С++, а не про Си

А ты красава, прочитал меж строк.

убивца С/С++ тоже должен быть такой парочкой. Т.е. должно быть два языка: простой и его отрицание для более высокоуровневого использования, фичи в которых будут перетекать из одного в другого.(перетекать в смысле стандартов)

Эту парочку можно было спокойно убить (и почти убили) единственным языком, который может шатать байты и при этом не составлен из UB сверху донизу, а самые платформозависимые низкоуровневые фичи просто пишутся инлайновым асмом, как и в Си.

Другое дело, что я даже не пытаюсь заткнуть этот пробел в индустрии, поскольку это всё дела уже минувшего века, в 21-ом веке основная проблема — это трудоемкость написания кода мартыхами, а не скорость выполнения инструкций. Процессор может выполнить миллиарды инструкций в секунду, а сколько инструкций в секунду ты можешь для него написать? То-то. Разве что массивы напишешь и в цикле пустишь. Максимум, что пока что получается — это двухмерный массивы и их свёртку через GPGPU.

Почему двухмерные? Потому что инструкции обработки двухмерных массивов в видюхах уже есть, а трехмерных — нету.