Комитет не может остановиться..

После принятия концептов SFINAE уходит в прошлое.

Не для всего, к сожалению. В частности pfr и reflect-cpp, определяющие типы через инициализацию агрегатов, делают это именно через sfinae (да и почти всё более-менее сложное метапрограммирование так делает).

Концепты великолепно закрывают область штатного использования шаблонов.

Но вот когда у тебя есть какой-нибудь sequence типов, и тебе их надо преобразовать и отфильтровать с использованием неизвестных тебе типов, в общем случае подходит только sfinae (хотя наверняка в каких-то отдельных ситуациях можно и концепты подтянуть).

А какой у тебя топ 5 самых лишних/вредных нововведений в плюсы?

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

будто что-то плохое

но не думают, нужно ли оно вообще в языке или нет

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

а то получится как с Zig: создатели с фига-то решили, что нормальные строки в языке не нужны, сношайтесь с массивами чаров

В Си никакого bool не было никогда.

Раньше не было, но в C99 появился. То есть уже 25 лет как.

Двойные двоеточия.

А в C23 bool стал полноценным типом, а не typedef.

https://gcc.godbolt.org/z/fe9P8h358

а то получится как с Zig: создатели с фига-то решили, что нормальные строки в языке не нужны, сношайтесь с массивами чаров

Я вас понимаю, но Зиг он как раз «Си с фичами», там полное управление памятью и относительно низкоуровнево, поэтому ситуация со строками логична.

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

Двойные двоеточия.

Т.е. методы структур/классов в плюсах - это самое вредное нововведение? Радикальненько, но не поспоришь.

Ну вы меня понимаете)

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

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

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

Но лично меня ещё больше, чем это бесит -> у указателей. Причём мне вообще не понятно зачем он понадобился? В чём проблема обращаться к методам/полям указателей через точку? Но это вообще наследие сишки.

А в C23 bool стал полноценным типом, а не typedef.

Разве это принципиально? В C23 всего лишь необязательно включать stdbool.h.

В чём проблема обращаться к методам/полям указателей через точку? Но это вообще наследие сишки.

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

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

А существует оно потому что точка это оператор выбора дочернего объекта, а стрелочка это ещё со следованием по ссылке

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

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

Сейчас уже, разумеется, менять что-либо поздно.

Стройная система костылей и подпорок.

Не пиши код как мудак, будет тебе нормальный синтаксис.

С99 это что угодно, но не Си. НедоСи++ какой-то.

А что со SFINAE не так? Отличный трюк.

Медленно, костыльно, не понятно.

С99 это что угодно, но не Си.

Уже 25 лет прошло, а у сишников до сих пор травма!

Нет никакой травмы. Я категорически отказываюсь признавать бредни сумасшедших ISOшников за стандарт Си. Пусть сами этим говном пользуются.

И что там не понятного? Переберать шаблоны до тех пор, пока не подойдет какой-нибудь. Очень простая идея.

Shared ptr хранит указатель на контрольный блок, в котором находятся счётчики. Никакой хэш таблицы там не нужно и отродясь не было.

Нет никакой травмы. Я категорически отказываюсь признавать бредни сумасшедших ISOшников за стандарт Си. Пусть сами этим говном пользуются.

Да-да-да, как и я пишу: душевная травма и отказ от реальности. В воображении пациента существует некий идеализированный язык под названием Си, который был создан Святыми Керниганом и Ритчи, у которого нет современных реализаций (gcc и clang следуют стандарту ISO) и который был богохульно запятнан и осквернён «злыми комитетчиками» (т.е. дьяволом этой мифологии).

Я категорически отказываюсь признавать бредни сумасшедших ISOшников за стандарт Си. Пусть сами этим говном пользуются.

Комменты // тоже не используешь?

Обязательно старый стиль объявления функций! С int по умолчанию!

main(argc, argv)
  int argc;
  char *argv[];
{
   ...
}

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

b = "swin";
a[b]

Писать

if b == "swin"
  a.swin

В Си не использую. Это комментарии C++. Их и редактор в Си коде не ставит.

Это C K&R. Сейчас только ANSI C компиляторы встречаются.

Пфф, тут целый тред был о переезде ядра с С89, и сишники долго выясняли пора уже или ещё подождать, на основании того где правильно счётчик цикла объявлять

Это C K&R. Сейчас только ANSI C компиляторы встречаются.

В C89 нет даже stdin.h. Как ты предлагаешь писать кросс-платформенный код без фиксированных типов?

Никак, это теоретик, познавший дзен хеллоуворда.

Зачем фиксировать размер типа?

Зачем фиксировать размер типа?

Затем чтобы структура вида

struct foobar {
    unsigned long int a;
    unsigned int b;
    unsigned long int c;
    unsigned int d;
} __packed;

будет разного размера на разных архитектурах.

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

Во-вторых unsigned long int следует упорядочить в начало, а unsigned int ниже, чтобы структура занимала меньше места.

В-третьих да, оно будет разного размера. И это хорошо, потому что эти переменные будут максимально быстры для конкретной платформы. Например int обязан быть не менее 2-х байт. (На современных десктопах обычно 4 байта). Допустим ты пишешь код с циклом for и создаешь счетчик int i. На 16-битной платформе скорее всего int будет скорее всего как раз 2 байта и работать быстро. На 32-битной платформе он будет 4 байта скорее всего и вмещать больше и работать так же быстро. А если ты напишешь «намертво» какой-нибудь int32_t, то на 16 битной платформе компилятор включит в бинарник свою библиотеку длинной арифметики и будет обрабатывать операции с числами (которые фактически никогда не вылезут за 2 байта) в несколько раз медленнее. Если хочешь быть уверен, что знаковое целочисленное число будет 4 байта или больше, используй long или unsigned long для беззнаковых.

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

не так страшен c++: std = N, как cmakeи и прочий сопутствующий шлак

В-третьих да, оно будет разного размера. И это хорошо, потому что эти переменные будут максимально быстры для конкретной платформы.

Это будет максимально НЕХОРОШО когда пакет с этой структурой придет на другую архитектуру.

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

А зачем тебе именно такой тип? Просто интересен контекст.

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

Их нет в C.

А зачем тебе именно такой тип? Просто интересен контекст.

Затем чтобы я мог передать число через сеть?

Их нет в C.

https://en.wikipedia.org/wiki/C_data_types#Main_types

Смотри колонку «Minimum size (bits)»

Затем чтобы я мог передать число через сеть?

Не обижайся, но тут меня прям на смех пробило. В общем, так делать нельзя. Читай про big-endian и little-endian. Ты обязан все передавать по сети как набор байт.

Смотри колонку «Minimum size (bits)»

Ты понимаешь чем «minimum» отличается от «fixed»?

Не обижайся, но тут меня прям на смех пробило. В общем, так делать нельзя. Читай про big-endian и little-endian. Ты обязан все передавать по сети как набор байт.

Ээ… ты обязан передавать в правильном формате. Размерность тебе сохранять все равно нужно. Ты уверен что ты на C писал?

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

Настолько хорошо сделан, что в стандартном C нет ничего для запаковки структур без паддинга, типа __attribute__((packed)) из GCC/шланга.

В K&R этого кстати тоже нет. Видимо, предлагается ручками через char[] пердолиться.

Настолько хорошо сделан, что в стандартном C нет ничего для запаковки структур без паддинга, типа attribute((packed)) из GCC/шланга.

Как мы выяснили, это все для сосунков. Настоящие мужики побайтово пишут в сокет.

Ээ… ты обязан передавать в правильном формате. <...> Ты уверен что ты на C писал?

Ты шутишь? Как оно будет работать, если одна машина big-endian, а вторая little-endian?

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

Тебе все равно придется считать/записать набор байт и конвретировать их в число с помощью функций. Опять-таки потому что бывают big-endian и little-endian машины. И (видимо речь про драйвер) для максимальной портируемости должен делать именно так.

Тебе все равно придется считать/записать набор байт и конвретировать их в число с помощью функций.

Зачем, если можно считать структурку?

Штош, ликбез для «сишников»:

struct foobar {
    uint16_t a;
    uint8_t b;
    uint8_t c;
} __packed;

int
main(void)
{
    int ret;
    struct foobar f = {0};

    fd = connect_to_peer();

    f.a = h16tobe(UINT16_MAX);
    f.b = 1;
    f.c = 2

    ret = write(fd, &f, sizeof(f));

[...]

    return 0;
}

Ничего. Он для внутреннего хранения данных в оперативке. Пишешь функцию, которая получает указатель на структуру и возвращает указатель на char (набор байтов). И наоборот для перевода бинарного формата во внутреннее представление.

Как офигительно. А теперь допиши, скомпилируй одно для big-endian, а второе на little-endian машине и убедись, что данные не будут переданы корректно.