А что uint так и не сделают стандартом в С и С++ ?

Язабан.

https://en.cppreference.com/w/cpp/types/integer

Бить надо за использование таких типов где попало! Как увижу внутри структур «int», «long» и т.п., аж материться хочется!!! Ну придумали же int32_t, uint64_t и так далее. Зачем пользоваться типами, у которых длина от архитектуры зависит?

учи стандарт

Да, до сих пор нет, я знаю. Таки когда?

Сами учите. Нет в стандарте uint. unsigned int ест, uint нет.

man c++11

Зачем? То что есть и так норм. А если пришло время переопределять по вообще пофиг ибо тупедефается вообще всё под проект.

Надоедает

Ну можешь чисто для себя сделать один awesome.h где описать все удобные тебе тупедефы макросы и прочее и включат его везде где надо. Я одно время так и делал. Но потом забил. Есть uintXXX_t intXXX_t для всего чего надо =)

то есть тебе нужно именно uint, а не uint32_t?

Тогда ты просто поехавший.

есть тип unsigned, но uint всё ещё не завезли, во всяком случае, если верить cppreference

есть тип unsigned, но uint всё ещё не завезли

А в чём разница? Желательно «на пальцах».

В первом слове 9 букв, во втором - 4.

Не используй unsigned типы нигде кроме разбора бинарных данных. Я зуб даю, тебе один бит погоды не сделает. В бинарных данных желательно явно указывать размер типа.

Не используй unsigned типы нигде

А если НАДО, чтобы переменная была >0 при любых обстоятельствах? Понятно, что есть size_t, но unsigned звучит по смыслу ближе.

а векторные типы для simd где?

8 букв вместо 4-х, к тому же с цифрами и подчёркиваниями - проще unsigned написать

не завезли

Об этом уже много споров спорено, в итоге решили, что НЕ НАДО (и не надо БЫЛО, что ещё важнее). С типизацией в С/С++ unsigned типы несут больше вреда, чем пользы. size_t туда же.

проще unsigned написать

Стоять, бояться! Вот это уже ересь. Это разные типы, не надо приравнивать их меж собой.

для simd

С каких это пор SIMD в каждом процессоре? Зачем это нужно в стандарте языка?

а векторные типы для simd где?

Hint: в библиотеках интринсиков.

НЕ НАДО

Всё-равно не убедил. Там, где мне лучше иметь явную ошибку, чем незаметную, я буду пользовать unsigned.

8 букв вместо 4-х, к тому же с цифрами и подчёркиваниями - проще unsigned написать

Тебе шашечки, или ехать? Цифры это отличная вещь, поскольку явно виден размер типа, который на некоторых платформах может быть отличным от широко используемого, типа int == 16.

Сделай себе typedef uint32_t uint32 и пользуйся на здоровье.

Не используй unsigned типы нигде кроме разбора бинарных данных.

И битовый сдвиг влево никогда не использовать?

С типизацией в С/С++ unsigned типы несут больше вреда, чем пользы. size_t туда же.

Например?

Там, где мне лучше иметь явную ошибку, чем незаметную, я буду пользовать unsigned.

Проблема в том, что, если ты сделал тип unsigned, то это НИКАК не убережет тебя от залезания в оридцательную область. В смысле что не будет никакого исключения, никакой ошибки, ничего.

unsigned хорош только для повышения читабельности кода, ну и если тебе и правда так нужен лишний бит (что случается достаточно редко).

Сравнение и арифметика между знаковыми и беззнаковыми и неявное преобразование типов в целом. Или эпичный костыль std::string::npos.

НИКАК не убережет тебя от залезания в оридцательную область

Ещё как убережёт. При int ты небольшое отрицательное число наверняка не заметишь, а при unsigned ты получишь нечто запредельное, что точно не смогёшь пропустить мимо.

Бинарные сдвиги нужны как правило где-то рядом с бинарными данными. Ещё можно умножать на 2, да.

Ещё можно умножать на 2, да.

А ещё чаше делить на 2. И не надо рассказывать, что деление - это гораздо лучше сдвига вправо.

Конечно деление лучше, так как показывает семантику

Компиляторы работают с умножением/делением оптимально.

Вот смотри: https://godbolt.org/z/XNpfeG

неявное преобразование типов в целом

О, да. Я на многое готов чтобы выключить эту штуку. Я даже готов ставить нестандартные плагины к компилятору. Но пока решения нет :(

При int ты небольшое отрицательное число наверняка не заметишь

Не заметишь чем? Глазом? Мне нужен автоматически контроль ошибок.

Конечно деление лучше

Стоп! Разговор закончен. До свидания.

Мне нужен автоматически контроль ошибок.

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

то это НИКАК не убережет тебя от залезания в оридцательную область.

Как минимум, убережёт при переполнении. То есть нарваться на что-то вроде https://habr.com/ru/company/pvs-studio/blog/276657/ вероятность меньше.

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

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

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

Нужно поблагодарить ТС :)

+1

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

+1, было бы полезно, все десять ног уже прострелил в таких местах…

Язабан.

Удваиваю.

который плевался error’ами на любые неявные преобразования.

Только плевки желательно «смачные», а не краткое «error».

а с каких пор int64_t в каждом процессоре?

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

unsigned тебе в этом не поможет.

Как минимум, убережёт при переполнении. То есть нарваться на что-то вроде https://habr.com/ru/company/pvs-studio/blog/276657/ вероятность меньше.

Статья полезная, спасибо.

Но вот со словом «убережёт» я всё еще не согласен.

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

Но я всё равно ратую за явное указание знаковости, но в первую очередь для целей читаемости кода.

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

А зачем пользоваться типами с фиксированной длиной, кроме как для описания бинарных протоколов?

Могу предположить, что ошибки посыпятся отовсюду, начиная с заголовков стандартной библиотеки. А какие варианты в прикладном коде останутся? Все через шаблоны строчить или постоянно кастовать вручную? Ну хз, второй вариант так себе, если честно. Первый реализуем, особенно хорошо на концептах, но опять же в нынешних реалиях это приведёт к header-only коду с бесконечным временем компиляции.

По мне, неявная типизация — вкусная особенность плюсов, особенно в до-11-ую эпоху. Но надо очень аккуратно, конечно.

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

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

А если нужны такие «универсальные» функции - можно и шаблоны, а можно просто объявить несколько вариантов функций, которые отличаются только типами параметров, и который будут просто кастовать тип и вызывать основную «максимально совместимую» функцию. Да, добавит пару строчек кода, на зато намного улучшит варификацию кода на этапе компиляции. Мне этого очень нехватает, особенно если создавать алиасы типам с помощью typedef.

Как приятно осознавать, что спустя 25 лет после создания первой 64-битной ОС в С++ добавили явные платформозависимые и платформонезависимые типы данных. Хотите знать, почему в этом и еще целой куче других языков создатели не могли ввести такие типы? Потому что любой уважающий себя web-level enterprise architect senior software engineer не может осилить две цифры в конце типа. Но время прошло, коньюктура подтолкнула акул бизнеса покорить новые высоты неумолимого прогресса в бурно меняющейся индустрии, которая не устает преподносить нам сюрприз за сюрпризом, где каждый новый день не похож на другой, и лишь способность понимать нужды завтрашнего дня уже сегодня позволяет прозорливым и опытным первопроходцам начать таки писать размер целочисленного типа в имени этого типа. Я кончил.

А зачем пользоваться типами с фиксированной длиной, кроме как для описания бинарных протоколов?

Чтобы один и тот же кода не вызывал на какой-нибудь архитектуре переполнение.

char a[100000];
for (int i = 0; i < 100000; i++) a[i] = 0;

где-то может быть бесконечным циклом.