Что за тип данных uint32_t?

Это без знаковый int, который занимает 32 бита. А вот t, что значит?

0

Сообщение от Renji Да, да, сегодня в универсальном sha512 потребности нет.

Что еще в кучу смешаем? Строки и файлы уже смешали, осталось добавить длинные целые, структуры, устройства, потоки и прочее.

Сообщение от Renji Так вам теперь все же стало понятно

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

Сообщение от Renji Программирование без IDE, это тоже самое что забивание гвоздей ботинком

Угу, а еще то же самое, что поедание вторника и форматирование красного ультразвука. Кончайте с заведомо неверными аналогиями.
Впрочем, ваш ответ вполне понятен: "программировать на С++ без костылей нельзя".

Сообщение от Renji Имеем массив объектов, которые нельзя перемещать простым memcpy.

Что же это за объекты такие, что перемещать не просто накладно, а нельзя вообще?

Сообщение от Renji Как это надо было делать: ну, раз нельзя memcpy, попытаемся расширить массив, никуда его не перемещая.

Так оно вроде так и происходит. Сначала пытаемся расширить выделенную память, и только если невозможно - перемещаем.
Это только в С++ какие-то проблемы с реаллокацией объектов, в Си-то с этим нормально.

Сообщение от Renji Читаем исходное утверждение - "Вообще-то, mtx_lock уже восемь лет как часть стандартных библиотек Си.".

А потом читаем стандарт и убеждаемся, что это утверждение неверно.

0

Сообщение от COKPOWEHEU Что еще в кучу смешаем? Строки и файлы уже смешали, осталось добавить длинные целые, структуры, устройства, потоки и прочее.

Еще неплохо взять пример с Питона и разрешить читать-писать картинки через стрим (BytesIO), завернутый на образ файла в памяти. Наш ответ tmpfs, ага.
Так подсчет хеша от текста и файла разносим по разным функциям? При том что за вычетом операций чтения, эти функции будут совпадать до последней буковки. Или потребности в хеш-функциях сегодня нет?

Сообщение от COKPOWEHEU Угу, а еще то же самое, что поедание вторника и форматирование красного ультразвука. Кончайте с заведомо неверными аналогиями.

Вы либо пользуетесь инструментами разработанными для решения проблем, либо страдаете от проблем. Вот собственно и вся аналогия.

Сообщение от COKPOWEHEU Что же это за объекты такие, что перемещать не просто накладно, а нельзя вообще?

Банальное Small String Optimization. Короткие строки сохраняются во вшитый в стринг буфер, не дергая динамическую память. При перемещении такого стринга с места на место, линки на буффер придется обновить. Совершенно верно, в Си с этим нормально. Нет оптимизации - нет проблемы с ее реализацией.

Сообщение от COKPOWEHEU А потом читаем стандарт и убеждаемся, что это утверждение неверно.

Убеждаемся что в программах помеченных макросом "Многопоточность? Не, не слышали" мьютексы можно не поддерживать. Что и логично - нафига они в однопоточных приложениях то? Но в стандарте мьютексы таки описаны.

0

Сообщение от Renji Еще неплохо взять пример с Питона

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

Сообщение от Renji Наш ответ tmpfs, ага.

Ах да, еще же можно к языку примешать операционную систему.

Сообщение от Renji Вы либо пользуетесь инструментами разработанными для решения проблем, либо страдаете от проблем.

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

Сообщение от Renji Банальное Small String Optimization. Короткие строки сохраняются во вшитый в стринг буфер, не дергая динамическую память.

Что еще за вшитый в стринг буфер? Строка это просто массив char'ов, без всякиз объектов. Или у вас опять навязчивое желание натянуть С++ на Си?

Сообщение от Renji Но в стандарте мьютексы таки описаны.

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

0

От

Сообщение от Andy_Coldfield А вот t, что значит?

До

Сообщение от COKPOWEHEU Что еще за вшитый в стринг буфер?

Всего 83 сообщения.

0

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

Ну да, ну да. Зачем нам этот костыль с "за секунду нажал F2 и у тебя открылся нужный хедер, на нужном месте". В хорошо спроектированном языке мы всего минуты за три ручками откроем нужный хедер в nano и ручками же пролистаем до нужного места. Деды так делали, отцы так делали и мы будем делать.

Сообщение от COKPOWEHEU Что еще за вшитый в стринг буфер? Строка это просто массив char'ов, без всякиз объектов. Или у вас опять навязчивое желание натянуть С++ на Си?

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

Сообщение от COKPOWEHEU В стандарте описаны рекомендуемые названия. Но пока они не стали обязательными, стандартными их считать нельзя.

Можно до тех пор пока рекомендованные названия компилируются в 99% мест, а не рекомендованные в 99% мест компилятор не кушает.

0

Сообщение от Renji В хорошо спроектированном языке мы всего минуты за три ручками откроем нужный хедер

То есть вы еще и язык от IDE не отличаете. Совсем прекрасно.
Даже не буду намекать, что ни к изначальной теме, ни к локальной (про длину стандартных имен) этот выкрик не имеет ни малейшего отношения.

Сообщение от Renji Строки произвольной длины, это массив в динамической памяти.

В Си нет строк произвольной длины. Вы опять тянете весь мусор, который знаете, туда, где ему не место?

Сообщение от Renji Можно до тех пор пока рекомендованные названия компилируются в 99% мест

Даже тогда нельзя. Рекомендация это всего лишь рекомендация, а не гарантия.

0

Сообщение от COKPOWEHEU То есть вы еще и язык от IDE не отличаете. Совсем прекрасно.

То есть, вспоминаем разговор про перегрузки.
Я: Сделано через неудобную конструкцию.
Вы: Неа, оно удобно, чтобы искать объявление перегруженной функции.
Я: Это делается в IDE одной кнопкой за секунду, без всяких Generic.
Вы: Не хочу в IDE за секунду, хочу в nano ручками файл листать.

Ну а про имена еще раз. Все эти короткие read удобны ровно до тех пор, пока read у вас один. Но чтоб он был один, он должен читать из какого-то универсального объекта. А универсальный объект представляющий и файл, и память, и черта лысого вы не хотите. А значит у вас появляется выводок из fread, dread, cread, которые так и просят чтоб их кто-то перепутал.

Сообщение от COKPOWEHEU В Си нет строк произвольной длины.

Таким образом, в Си нет и работы с файлами содержащими в себе строки произвольной длины. Прощай парсинг XML и JSON.

Сообщение от COKPOWEHEU Даже тогда нельзя. Рекомендация это всего лишь рекомендация, а не гарантия.

Окей, так и записываем - VLA в Си тоже нет. Ибо с макросом __STDC_NO_VLA__ поддержку VLA можно послать куда подальше.

0

Сообщение от Renji Не хочу в IDE за секунду, хочу в nano ручками файл листать.

Если языком невозможно пользоваться без IDE - с ним что-то не так и он годится только для узкоспециальных задач.

Сообщение от Renji А значит у вас появляется выводок из fread, dread, cread, которые так и просят чтоб их кто-то перепутал.

Что у вас за задача, если понадобились низкоуровневые аналоги системного вызова read? Или речь идет опять о неумении разделять код по уровням?

Сообщение от Renji Таким образом, в Си нет и работы с файлами содержащими в себе строки произвольной длины. Прощай парсинг XML и JSON.

А Си-шники-то не знают что у них какие-то проблемы с парсингом файлов.

Сообщение от Renji Окей, так и записываем - VLA в Си тоже нет. Ибо с макросом __STDC_NO_VLA__ поддержку VLA можно послать куда подальше.

Оно и правильно: небезопасная штука. Невозможно определить успешность выделения массива. Обычный *alloc ненамного длиннее, зато позволяет обрабатывать ошибки.

0

Сообщение от COKPOWEHEU Если языком невозможно пользоваться без IDE - с ним что-то не так и он годится только для узкоспециальных задач.

Возможно. Вместо F2, ройтесь в хедерах через ctrl+F, ктож не дает. Но через IDE быстрее хоть на Си пиши, хоть на плюсах. Так что кому реально важно быстро найти нужную перегрузку функции, тот сидит в IDE. А кому нужно не чтоб быстро, а чтоб как в восьмидесятые, ну так ему и Generic не нужен.

Сообщение от COKPOWEHEU Что у вас за задача, если понадобились низкоуровневые аналоги системного вызова read?

Библиотека для подсчета хеша sha512. Должна кушать и восьмисимвольные пароли, и дампы диска. Второе требует механизмов чтения файла по кускам. И что, реализовывать sha512 два раза, один раз под fread, другой раз под прямое чтение входных данных из памяти?
Ну а семейство read появляется, если все же идти путем "для каждого источника по отдельной функции".

Сообщение от COKPOWEHEU А Си-шники-то не знают что у них какие-то проблемы с парсингом файлов.

Равно как и не знают что у них нет строк произвольной длины.

Сообщение от COKPOWEHEU Оно и правильно: небезопасная штука. Невозможно определить успешность выделения массива. Обычный *alloc ненамного длиннее, зато позволяет обрабатывать ошибки.

Как будто для обычных массивов успешность выделения определить можно и функция без VLA не может выбить stack overflow.
VLA выделяет память за константное время, malloc за хрен знает какое, alloca в стандарте нет даже в форме рекомендации. Так и записываем, скорость работы программы для Си не критична.

0

Сообщение от Renji Так что кому реально важно быстро найти нужную перегрузку функции

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

Сообщение от Renji Должна кушать и восьмисимвольные пароли, и дампы диска.

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

Сообщение от Renji Равно как и не знают что у них нет строк произвольной длины.

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

Сообщение от Renji Как будто для обычных массивов успешность выделения определить можно и функция без VLA не может выбить stack overflow.

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

Сообщение от Renji Так и записываем, скорость работы программы для Си не критична.

Ну да, на Си не пишут критичный ко времени и объему код. Ни драйвера, ни ядра ОС, ни прошивки для контроллеров. Все пользуются исключительно Питоном!

0

Сообщение от COKPOWEHEU А кому не важно заниматься мазохизмом, просто не перегружает функции на каждый чих, а структурирует программы.

Кому не важно заниматься мазохизмом, тот просто пользуется перегруженной функцией, не интересуясь где там она перегружена. А если кому надо просто список перегрузок посмотреть, это опять же покажет IDE.

Сообщение от COKPOWEHEU Не знаю, как производится вычисление sha256, но для CRC16 стандартный способ - передавать данные порциями.

И конечно же эта передача будет делаться через отдельную функцию. А потом все это разрастается в зоопарк из msha512 для прямого чтения из памяти, ssha512 для хеша от строк, fsha512 для чтения файла заданного FILE* и fnsha512 для чтения данных из файла заданного текстовым именем "file.txt".
Финальным акордом кто-то случайно путает ssha512 с fnsha512 и долго удивляется почему это хеш берется не от файла, а от его имени.

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

Ну и как будем возвращать результат парсинга JSON-строки, если ее размер по стандарту ничем не ограничен, а строк произвольной длины у нас нету?

Сообщение от COKPOWEHEU Для обычных массивов это гораздо более предсказуемо.

VLA обшивается проверкой if(vlaSize>256)return errorCode и предсказуемо падает реже. Потому что хапает не более 256 элементов. Обычный массив всегда хапает по 256 элементов и предсказуемо падает чаще.
А malloc под Линуксом вообще по умолчанию работает через overcommit "выдадим программе сто терабайт, а потом пристрелим при попытке воспользоваться памятью". Удачи вам в предсказании поведения подобного кода.

Сообщение от COKPOWEHEU Ну да, на Си не пишут критичный ко времени и объему код. Ни драйвера, ни ядра ОС, ни прошивки для контроллеров. Все пользуются исключительно Питоном!

Пишут не пытаясь заменить VLA на malloc.

0

Сообщение от Renji Кому не важно заниматься мазохизмом, тот просто пользуется перегруженной функцией

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

Сообщение от Renji А потом все это разрастается в зоопарк

У вас - не удивлюсь. У нормальных людей, повторяю, таких проблем не возникает. Потому что они думают над архитектурой программ и не пытаются складывать числа, строки, файлы и прочие объекты, которые видят.

Сообщение от Renji Ну и как будем возвращать результат парсинга JSON-строки, если ее размер по стандарту ничем не ограничен, а строк произвольной длины у нас нету?

Понятия не имею, мне эта проблема не интересна. Посмотрите в исходниках соответствующих библиотек, если так уж надо.

Сообщение от Renji Удачи вам в предсказании поведения подобного кода.

Очевидная утечка памяти, это уже не анализировать, а исправлять надо.
Если весь ваш код похож на это, я не удивлен что Си вам не дается. Сидите на своих Питонах и дальше.
.
А вообще, прежде чем продолжать обсуждение, сформулируйте наконец, что же именно вы пытаетесь доказать.
Если то, что С++ лучший язык - так это неправда и не нуждается в доказательствах.
Если то, что С++ лучше хотя бы Си, то это тоже неправда, иначе Си бы вымер.
Если то, что в Си куча атавизмов и неудачных решений, то это и так ни для кого не секрет.
Впрочем, все это оффтопик.

0

Сообщение от COKPOWEHEU тот НЕ пользуется перегруженной функцией, потому что нужна она крайне редко.

Потому что вынужден вместо этого заводить cbrt_long и cbrt_float... извините, cbrtl и cbrtf. И рассказывать всем плюсовикам о том что зелен, дескать, виноград перегрузок, тотчас оскомину набьешь.

Сообщение от COKPOWEHEU Понятия не имею, мне эта проблема не интересна. Посмотрите в исходниках соответствующих библиотек, если так уж надо.

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

Сообщение от COKPOWEHEU Если то, что С++ лучше хотя бы Си, то это тоже неправда, иначе Си бы вымер.

Си по факту подмножество современного C++, не более. Плюс-минус мелкие шероховатости уровня "вот в Си у меня каст FILE*->int* компилируется, хотя и с варнингом. А в C++ вместо варнинга ошибка!". Ну ладно, подмножество C++ с расширениями от gcc. Подмножество не может быть лучше целого.
А то что не вымер, ну так легаси код. И Линукс Торвальд кричащий что-то про тупых плюсовиков, когда ему предлагают перепилить ядро на плюсах.

0

Renji, что Вас удивляет в коротких именах?
Язык C разрабатывался для UNIX.
Сокращения всего и вся в Unix в порядке вещей.
Потому часто даже опции в программах не читаемые.
Получается что-то вроде prg -xcvhgds file.txt.
Говорят, это устраивает коренных юниксоводов.
Для нелюдей изобрели опции с длинными именами.
Я вообще удивлен, что atoi называется не просто ati или a.

0

Сообщение от Croessmah Renji, что Вас удивляет в коротких именах? Язык C разрабатывался для UNIX.

А UNIX вышел лет пятьдесят тому назад. О том и речь, что короткие имена существуют исключительно по историческим причинам. В новом коде к истории не привязанном, от них спокойно отказываются. А исходные uint32_t и uint_fast32_t это какой-то монстр Франкенштейна. Типа, вот вам длинное имя fast, вот вам подчеркивание между частями имен, но хоть type, хоть type то дайте сократить, ироды!

0

Сообщение от Renji хоть type то дайте сократить, ироды!

ИМХО, с _type будет еще страшнее. _t самое то.
Так что здесь на вкус и цвет.
К слову, также сокращен unsigned integer до uint.
почему-то это Вас никак не расстраивает.
Суффикс _t и префикс T - весьма распространены, так что их использование вполне нормально.

0

Сообщение от Croessmah К слову, также сокращен unsigned integer до uint. почему-то это Вас никак не расстраивает.

Сокращение integer->int общепринятое, причем далеко за пределами C/C++. А uint следует либо в стандарт наконец ввести (именно как отдельное имя), либо на unsigned заменить.

0

Сообщение от Renji Потому что вынужден вместо этого заводить

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

Сообщение от Renji Посмотрел. В первой же попавшейся библиотеке и SSO, и длинные_и_понятные_имена, и строки произвольной длины. Никаких мифических архитектур, позволяющих лепить короткие имена не наблюдается.

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

Сообщение от Renji Си по факту подмножество современного C++, не более.

И ассемблер - подмножество С++, ведь есть asm(). Ну и что?

Сообщение от Renji Подмножество не может быть лучше целого.

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

Сообщение от Renji А то что не вымер, ну так легаси код.

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

Сообщение от Renji И Линукс Торвальд кричащий что-то про тупых плюсовиков, когда ему предлагают перепилить ядро на плюсах.

Зачем на С++, есть же куда более современные языки. Что там сейчас в тренде, Раст, кажется? Давайте уж на нем переписывайте, чего мелочиться с "тяжким наследием Си"

Сообщение от Croessmah Для нелюдей изобрели опции с длинными именами.

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

Сообщение от Renji В новом коде к истории не привязанном, от них спокойно отказываются.

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

Сообщение от Renji А uint следует либо в стандарт наконец ввести (именно как отдельное имя), либо на unsigned заменить.

Зачем вносить uint в стандарт?
unsigned int == unsigned и без того в стандарте с самого начала, как и long int == long, как и прочий неявный int.
.
Главный вопрос вы, похоже, не заметили:

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

0

Сообщение от COKPOWEHEU Могу еще раз повторить: когда перегрузка нужна - да, заводится куча функций и заворачивается в макрос. Но в подавляющем большинстве случаев она просто не нужна.

Так и записываем, зоопарк из printf/sprintf/fprintf в подавляющем большинстве случаев не нужен. Кстати, ни в какой макрос он не заворачивается.

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

У меня все ходы записаны.
"К сожалению, в ЯВУ это необходимость, но вот Си или Ассемблер оперируют куда более простыми объектами и в гораздо меньшем количестве. Там длинные имена просто не нужны. "
Вот о том и спорим, действительно ли Си такой замечательный язык, что ни длинных имен там не нужно, ни SSO не нужно. Или все как у всех, а за короткие имена держатся только по причине ретроградства.

Сообщение от COKPOWEHEU И ассемблер - подмножество С++, ведь есть asm(). Ну и что?

Хуже. Ассемблер это подмножество G++. Синтаксис ассемблера у Интеллов и синтаксис ассемблера у GNU Assembler несовместимы даже на уровне банального mov (Intel Syntax vs AT&T Syntax). И да, как самостоятельный язык Ассемблер сдох. Ибо нужен по большей части только в качестве асм-вставок.

Си пока что очень нужен чтобы пересобирать Линукс из исходников. Потому что на предложения переписать сишный код на чем то другом, Торвальдс выкатывает возражения стиля "ты урод, C++ уродство, STL-уродский глюкодром, кто скажет что не глюкодром, тот урод". И к сожалению, я тут никакой экспрессии от себя не добавлял. Как такие Торвальдсы свалят наконец на пенсию, так Си и окончательно растворится в C++.

Сообщение от COKPOWEHEU Зачем вносить uint в стандарт?

Затем, что если uint32_t такое замечательное сокращение, что его надо протащить в стандарт, то и uint будет не менее замечательным сокращением. А когда uint32_t тащим, uint не тащим, это больше похоже на "да, у нас тут длинное_имя, но вот из принципа хоть одно сокращение, а воткну".

0

Сообщение от Renji Так и записываем, зоопарк из printf/sprintf/fprintf в подавляющем большинстве случаев не нужен. Кстати, ни в какой макрос он не заворачивается.

Вам - несомненно не нужен. Сидите на своем С++ и радуйтесь. Тем же, кто пишет на Си, нужен. И, заметьте, они в нем не путаются и не видят нужды заворачивать разные функции в макрос.

Сообщение от Renji "К сожалению, в ЯВУ это необходимость, но вот Си или Ассемблер оперируют куда более простыми объектами и в гораздо меньшем количестве. Там длинные имена просто не нужны. "

И где противоречие? В стандартной библиотеке обычно не нужны (разве что какая-то редко используемая экзотика). В юзерском коде - это его, юзера, дело, как ему удобнее. Еще раз: уровни абстракции. Не приписывайте мне всякой чуши, я не такой фанатик как вы и не пытаюсь навязать откровенно вредные парадигмы всем вокруг.

Сообщение от Renji Хуже. Ассемблер это подмножество G++.

У-у-у, как все запущено... Что вы понимаете под G++, кстати, не гнутый ли компилятор часом? Если так, ваше высказывание еще большая чушь, чем выглядит на первый взгляд.

Сообщение от Renji Синтаксис ассемблера у Интеллов и синтаксис ассемблера у GNU Assembler несовместимы

Это здесь каким боком?! Ну вот какое отношение различие диалектов в семействе ассемблеров (они все разные, если что) имеет к длине имен в Си или типу данных uint32_t?!

Сообщение от Renji И да, как самостоятельный язык Ассемблер сдох.

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

Сообщение от Renji Си пока что очень нужен чтобы пересобирать Линукс из исходников.

Разработчикам gtk тоже Торвальдс мешает? И над программистами контроллеров он стоит с талмудом K&R готовый покарать отступников? И даже те, кто хочет просто программировать на простом языке, без изучения вообще всех изобретенных человечеством парадигм, осмеливаются открыть IDE c C++ лишь в подвале под одеялом, ибо Торвальдс не дремлет.
Тяжко жить в вашем мире...

Сообщение от Renji Затем, что если uint32_t такое замечательное сокращение, что его надо протащить в стандарт

С этого начали. Логичнее было бы назвать этот тип покороче, но разработчики опасались за совместимость со всякими изобретателями u32. Оттуда же получилось невероятно кривое название _Bool.

Сообщение от Renji и uint будет не менее замечательным сокращением

Обычно не нужно на практике. Учитывая, что размер int не стандартизован, нет особого смысла в типе данных с вдвое большим диапазоном. Но если кому-то вдруг действительно понадобится, может сделать typedef или просто unsigned.
.

Сообщение от COKPOWEHEU сформулируйте наконец, что же именно вы пытаетесь доказать

0