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

Лучшее что есть в крестах это написанный на них v8

Аналогично для сишки - питон

Все остальное в С-подобных ад и уныние

Понять и простить. Я упомянул очень простые штуки, в том числе на основе которых можно писать составные контейнеры, и уж при самом-самом крайнем случае писать что-то по-настоящему свое. Без строк в 2021 очень неприятно писать программы, знаешь ли.

Не. Я реально не знаю, как там в Go с этим. Если знаешь, просвяти. Можно ли там иметь свой тип контейнера со своим типом элементов или хотя бы стандартный контейнер с пользовательским типом элементов и засовывать его в стандартные алгоритмы?

Да, JS и Go, индустрия своё слово сказала.

По поводу JS еще куда ни шло (хотя это в основном фронт в вебе - а это еще далеко не вся индустрия). Но по поводу Go - хрен с два индустрия показала. А если бы гугл не пиарил его, то вообще бы он помер бы уже.

1. неймспейсы 2) умные указатели 3) throw

• 1. выше по треду
• 2. тут https://github.com/drodri/c-smart-pointers
• 3. try-cath-finally? что-то другое?

Ой, да конечно, ты все проекты перечислил.

Три не знаю, но перегрузки функций очень нехватает мне, а да еще const & в прототипе функции

Вброшу что ли. Вижлстудия кресты лучше поддерживает, чем си.

перегрузки функций очень нехватает мне

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int addi(int a, int b) {
    return a + b;
}

// achtung! beware of memory leak 
char *adds(char *a, char *b) {
    char *res = malloc(strlen(a) + strlen(b) + 1);
    strcpy(res, a);
    strcat(res, b);
    return res;
}

#define add(a, b) _Generic(a, int: addi, char*: adds)(a, b)

int main(void) {
    int a = 1, b = 2;
    printf("%d\n", add(a, b)); // 3

    char *c = "hello ", *d = "world";
    printf("%s\n", add(c, d)); // hello world

    return 0;
}

ну и в clang есть attribute((overloadable))

В сишке не хватает разве что использования строк и строковых констант в case, а так всё именно так как и должно быть.

Кроме того, никто же не зарпещает использовать c++ как просто c с классами. Версию постарше указать -std=c++98 и вперёд.

C удовольствием прочитал все твои костыли и workaround-ы для сишки в этом треде, мякота.

• Классы
• Умеренно наследование (или хотя бы возможности реализации интерфейсов)
• Немного шаблонов и вывод типов
• Стандартных контейнеров, особенно строк и векторов
• RAII
• namespace
• references
• move

Список не отсортирован по важности и вообще никак.

Вижлстудия кресты лучше поддерживает, чем си.

Можешь оставлять свои багрепорты тут: https://developercommunity.visualstudio.com/home

Visual Studio 2019/2022 заявляют о поддержке последнего актуального стандарта C17.

constexpr, модули, перегрузка операторов, шаблоны, RAII

Шаблоны, константные выражения, семантику перемещения и исключения (для этого правда нужен будет какой-то интерфейс для RAII, а это ещё половину всего C++ потянет).

шаблоны

Забавно, что создатели Go не разделили твою позицию.

До сих пор думаешь, что шаблоны в Go не добавят?

First appeared: November 10, 2009; 12 years ago

До сих пор думаешь, что шаблоны в Go не добавят?

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

А constexpr наколдуешь?

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

• пишется программа(ы), которая эти значения вычисляет. большая, маленькая, несколько маленьких - неважно.
• результаты вычислений заносятся этими программой(ами) в (обычно) .h файл
• компилируем основную программу

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

1. Пользовательская база
2. Популярность
3. Живучесть

У C всего этого тоже в достатке, но главное в том, чтобы отобрать это у крестов.

результаты вычислений заносятся этими программой(ами) в (обычно) .h файл

Вот единственное, чего не хватает сишечке в стандарте - вменяемая компоновка с бинарниками.

Но этого и в крестах нет, так что.

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

Так и «шаблоны» можно делать на С.

Хороший метод. Я тоже так делаю в С.

Да и в С++ этот метод тоже пока нужен кое-где.

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

Кто и как эту шустрость измерял?

Я сначала 10 лет сидел на KDE, теперь 10 лет сижу на гноме. Разницу я можно сказать жопой своей прочуял. Очевидно, прав я.

you’re welcome

Интересно. И вот только напрашивается вопрос. Ты 10 лет сидел на каких именно версиях кед и на каком железе? И далее ты еще 10 лет сидишь на каких версиях гнома и каком железе?

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

От себя скажу так. По мне текущие kde, cinnamon, mate на моем железе i7-7700/16Gb/SSD работают примерно одинаково быстро. Если взять мой десятилетний ноут i7-3520M/8Gb/HDD, то на нем указанные окружения работают относительно одинаково стабильно с периодическими подтормаживаниями.

Я бы выкинул из сишки массивы и оставил бы только указатели, массивы мешают видить всю гибкость и мощь работы с указателями

Так и «шаблоны» можно делать на С.

да, это проще и приятней чем на макросах колхозить.

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

Так в сишке нету массивов.

ну хорошо, тогда пусть удалят синтаксический сахар над указателями, который позволяет разыменовывать указатель каким-то неестественным образом pointer[i]

1. Деструкторы
2. Шаблоны
3. Функторы и Лямбды

3) да

в целом, вопрос же был за «изкоробки».

Лямбды.

в Си будет кучу раз продублировано

Либо будет решено на уровне макросов.
Слез, боли, ужаса и макросов.

погоди, это только начало велосипеда )

ну такой себе вброс, кажется у них это даже в документации написано.

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

Нра:

• Шаблоны
• RAII
• namespace

Не нра:

• скорость компиляции
• макросы и прочее легаси
• всякое UB

Если в Си добавить классы, то нужно ещё добавлять и исключения

Было бы интересно узнать, как необходимость исключений следует из добавления классв.

Говорят, что плохо отвечать вопросом на вопрос. Поэтому я отвечу тремя вопросами. Про три вопроса ничего плохого я не слышал.

1. Как вернуть ошибку из конструктора без использования исключений?
2. Пробовал ли ты писать на Си++ без исключений?
3. А без стандартной библиотеки?

Не ссорьтесь. Я сразу подчеркнул, что класс — это слишком абстрактная штука, чтобы о чем-то говорить. Ваша ветка обсуждения началась с того, что «defer заменяется классом с деструктором» — то есть, приплели классы «потому что». Внезапно Ринат приплел сюда еще и конструкторы, которым, очевидно, нужны исключения, потому что у конструкторов нет возвращаемого значения. Однако, исключения не нужны классами без конструкторов.

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

Пащитал голоса: https://pastebin.com/vNHgJxJ1

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

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

все приведенные тут примеры это голимый стандарт.

такие программы в хороший год будут переиспользованы еще пару раз

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

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

в целом, вопрос же был за «изкоробки».

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

попытки вывернуться за счет написания дополнительного тулчейна

тулчейн-то ты тут где узрел

бойлерплейт кода для того чтобы преодолеть невыразительность языка

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

Так в сишке нету массивов.

Пожалуйста, освободите компьютер санитара и вернитесь в палату.

Щас мы тебя в палату положим) a[2] == 2[a]

Если вы начнете на каждый чих писать под проекты ваше ПО которое будет генерировать определенным образом хедеры и вообще код в помощь к основной функциональности языка, как пример можно взять мок из qt и это уже даже не С. То о каком отсутствии необходимости написания дополнительного тулчейна вы говорите? Бойлерплейт вы уже показали, вам основательно возразили, что по функциональности он недотягивает до того, что реализовано как фича языков более позднего разлива. Как видите даже писать ничего не надо, я вполне способен объяснить словами, то что вы и так прекрасно поняли с первого раза, но будете продолжать защищать написание бойлерплейта, и встраивание костылей и доп оснастки для получения желаемого результата с использованием языка семидесятилетней давности даже там где в этом нет какой-то необходимости. Идеальных языков конечно нет, но зачем упираться когда есть вариант попроще и получше, без каких-либо серьезных потерь в производительности - непонятно.

И как из a[2] == 2[a] следует что «в сишке нету массивов»?

Не, ну а при чём тут я?

Наливай, чо уж...

Что такое массив?

Не, ну а при чём тут я?

а поговорить? )