- 1
- 2
- 3
- 4
- 5
- 6
typedef long long dlong;
typedef long double ldouble;
typedef unsigned long ulong;
typedef unsigned short ushort;
typedef unsigned char uchar;
typedef unsigned long long udlong;-
C++ / Говнокод #22884
−18
Говно или нет?
Запостил:
Arman,
01 Мая 2017
Follow us!
чо уж там.
ненужно
> long double
ненужно
> unsigned long
ненужно
> unsigned short
ненужно
> unsigned char
uint8_t
> unsigned long long
ненужно
Из всех нефиксированных интов нужны только int и unsigned int.
Хотя unsigned int тоже под сомнением, имхо.
Впрочем, на некоторых архиьектурах даже невыровненный mov это ошибка
https://msdn.microsoft.com/en-us/library/system.overflowexception(v=vs.110).aspx
А как же никому не нужная кроссплатформа по части железа?
Я вот знаю что инт это лучший размер для числа в цпу, и похуй 16 он бит или 64 и мне заебись
ему пофиг вообще там 16 или 64. Какая разница?
Мне, блин, там возраст надо хранить
Сериализация? Соснули. Размеры везде разные, файлы непереносимые.
Счётчик чего-нибудь? У меня работает, а у соседа внезапно переполнился.
Задали байты шестнадцатиричным питухом? CHAR_BIT = 6.
Не завязался на размер - с вероятностью 1 найдётся платформа, где твоя валидная программа не заработает.
Подход с неопределёнными размерами int/long int работает только в браузерах, где не важно, отрисуется ли снежинка, или её координаты - (-1e9, NaN). Хотя, даже в браузерах уже пишут серьёзные приложения.
Программа на Си сопровождается молитвой программиста о том, чтобы её не скомпилировали там, где инты покороче.
А типы надо делать в формате ('u' | 's')? ('l' | 'g' | 'e') DIGIT+
Т.е. например sl32 - знаковое целое не более 32 бит, ug16 - беззнаковое целое не менее 16 бит, e128 - знаковое целое ровно 128 бит.
Или даже диапазоны задавать. Например, UINT(16, sizeof(void*) * CHAR_BIT). Тогда и у компилятора будет выбор, и у программиста гарантии.
Не меньше восьми же
Разумеется. Но сериализация нужна не всегда.
>>Счётчик чего-нибудь? У меня работает, а у соседа внезапно переполнился.
MAX_INT?
не-а, не слышал.
Кстати, разная разрядность тоже отстой. У меня malloc работает, а у соседа он вернул null.
>>Не завязался на размер - с вероятностью 1 найдётся платформа, где твоя валидная программа не заработает.
Чушь.
> не-а, не слышал.
Ну хорошо,
> Чушь.
Чушь. См. выше пример с миллионом.
Вручную считал, по одному? )
С сишными типами чисел только абстрактные библиотеки для вычисления факториалов можно писать, где не важно, что в реальности работает максимум факториал пяти. Настоящие числа потребуют нижнюю планку.
лол) насколько бОльшие?
http://govnokod.ru/22884#comment385412
22884 / 255 > 89.7
385412 / 255 > 1511.4
Даже на ГК - в сотни-тысячи раз большие.
Ну, багор. Подточить тебя пора.
Не нужны char/short/long/int потому, что по сути гарантируют только -128..127 или 0..255.
int8_t и uint_16t нужны, когда числа входят в их гарантированный диапазон.
Довольно много понятий из реального мира (как минимум, размеры файлов; количества людей в мегаполисах) используют числа большие, чем гарантированные 255.
ты высосал из пальца какое-то увтерждение с рэндомным числом в середине и пытаешься мне его доказать.
"Я утверждаю что числа меньше 12348752 не нужны". Ты точно программист?
Число 385412 - контрпример для утверждения о достаточности типов с 0..255. Число 385412 встречается в реальной программе "Сервер сайта ГК" и не влезает в один октет. Подобных целых чисел, встречающихся в реальной жизни и находящих своё представление в программах - куча.
> пытаешься мне его доказать
Уже доказал. Доказательством служит сам факт наличия этого числа в выхлопе реальной программы "сервер ГК".
а вот доказательство ненужности типа char: https://en.wikipedia.org/wiki/Trillion
трудно говорить с гуманитарием
> а вот доказательство ненужности типа char: https://en.wikipedia.org/wiki/Trillion
Где? Где хотя бы доказательства, что триллион используется в программе как целое значение?
Я показывал значение такой целочисленной переменной, для которой как минимум используется арифметическая операция (x+1).
P. S. Даже с такой простой задачей как продемонстрировать использование целого числа в программе тупой багор не справился.
С трудом узнал в этом сердитом подростке объект своего почитания.
Кому, и с какой целью Вы одолжили Вашу учётку?
Овладел твоим анусом, проверь.
Мои горячность молодости и наивность иногда делают из меня живую мишень в чёрством мире самодовольных интернет-троллей.
Даже немного завидую себе, что меня некогда отождествили с доктором.
Кто-то сказал, что при капитализме происходит эксплуатация человека человеком, а при коммунизме — совсем наоборот.
@а при коммунизме — совсем наоборот
Это заметная точка зрения.
Пациент высказывает бредовые утверждения, желая подловить меня и показать, какой он мозговитый, но в итоге выглядит как клоун, который придирается к словам не понимая сути сказанного, с которой он быть может даже согласен.
похоже что js это диагноз
Последний раз. Тезисы для болезных:
1. int/long/char не нужны, т.к. гарантируют только 8 бит под число, чего в реальном коде явно не хватает.
2. Есть случаи, когда используются малые числа, которые влезают в 8 бит, тогда можно использовать int8_t и uint8_t.
>>int/long/char не нужны, т.к. гарантируют только 8 бит под число
точнее говоря они не гарантируют что туда влезет мое число в 128 бит.
А еще они не гарантируют что сложение двух интов не займет 44 года. В стандарте про это ни слова.
Если мне нужна гарантия размера -- я беру _t, если не нужна -- зачем мне _t?
>>чего в реальном коде явно не хватает.
в твоем не хватает, а в моем хватает.
У меня может быть буфер размером MAX_INT и мне с ним ок.
поле с возрастом, да что угодно
ну давай, скажи что на говнокоде говна больше чем на 8 бит и это твое
доказательство, лол.
Размер типа может иметь значение, а может не иметь, в зависимости от задачи.
Багров надо давить интеллектом либо не кормить.
Что "что угодно"?
Количество детей у человека, количество детей в классе, сортов мороженного в киоске - может и влезут.
Но размер файла, количество единиц продукта, выпущенного заводом, количество людей в городе, посетителей в больнице - не хватит.
> ну давай, скажи что на говнокоде говна больше чем на 8 бит и это твое доказательство, лол.
Да, это моё доказательство. Пользователей > 20K, постов > 300K, символов в комментарии - от 1 до 2К. На остальных сайтах так же. У народа по 300 друзей в соцсетях, у хабра 60К просмотров статей, картинки заливают 300кБ - 5МБ. В реальной жизни и не пахнет одним октетом.
Предсказываю, что сейчас среднестатистической программе требуется 24 бита для представления целого числа.
ахахахаа, я тут даже не знаю что сказать. Если ты не троллишь , а реально так думаешь то говорить не о чем. А если троллишь от тем более
> картинки заливают 300кБ - 5МБ
Как раз в три байта размеры и входят.
Обмен шила на мыло багор?
Ну программисту приятнее написать кроссплатформенный код.
А так обман какой-то получается. Вроде язык не зависит от платформы, а по факту чтобы что-то серьёзное написать, надо тонкости знать или ВМ пилить.
Ты точно ёбнулся.
У 99% архиваторов ядро писано на асме.
Архиваторы - это классический пример непоратабельного софта. Ооочень часто для каждой архитектуры пишется своя реализация. (Потому что иначе ими никто пользоватся не будет.) Да, выхлоп/вхлоп идентичны - но и только.
Ты завязываешься на минимальный нужный диапазон значений. Берешь тип в который это помещается, и округляешь до инта. Если не влазит в инт - заводишь специальный тайпдеф для этого типа. Если не влазит в нативные типы - надо извращатся.
> Сериализация? Соснули.
И как только все программы файло сохраняют?... Чувствую что тут не реальность, а кто-то другой сосёт.
Плюс, ты забываешь про очевидный вариант сериализации: ASCII.
> Задали байты шестнадцатиричным питухом? CHAR_BIT = 6.
Ц реалистически не поддерживает ничего где байт не 8 бит. -> ABI поддерживает только 8 бит -> даже если платформа 9 бит/этц, будут симулировать 8 бит.
В каком то смысле, байты уже давно симулируются, потому что многие платформы (количественно: подавляющее большинство) нативно не поддерживают арифметику/этц на не-регистрах: они в принципе не могут два байта сложить. поэтому расширяют байты до вордов, складывают ворды, нормализуют результат до байта. округление типов локальных переменных до ворда - это одна из типичных оптимизаций компиляторов.
Идиотизм. 16 бит музейный комп 30-40 летней давности -> диапазон значений (-32768, 32767) -> разрешение дисплеев еще пару десятилетий надо что бы это переполнить. (С другой стороны, нубам и идиотам, наверное нужно только пара минут.)
> Программа на Си сопровождается молитвой программиста о том, чтобы её не скомпилировали там, где инты покороче.
Похоже, ты просто портабельного софта не видел.
Многие программы и библиотеки компилятся и работают на ура - без молитв.
С другой стороны, прагматически, сейчас существуют только 32 и 64 бит компы. 16 бит микроконтроллеры тихо сидят в своих нишах (и компов на них никто не делает) потому что там тематика другая и портабельность там тоже другая.
А в случае 32 вс. 64 бит все просто: int как минимум 32 бит. Если тебе идиоту даже диапазона [-2,147,483,648 , 2,147,483,647] что бы какую-то ебучую снежинку нарисовать не хватает, то тебе серьёзно надо задуматся о смене професии.
Стандарт считает иначе. Если нужны как минимум 32 бита, надо юзать long.
short/int/long/long long в прикладном софте не нужны. Если ты хочешь сказать, что тебе нужно минимум 32 бита, так и скажи: int_fast32_t. Так всем понятно, что происходит, ни у кого нет никаких иллюзий.
Какой стандарт? И какое приложение этого стандарта (платформа? компилер?) так делают?
Стандарт языка C, разумеется. Мы же о переносимом софте говорим, так ведь? К примеру, из C99
5.2.4.2.1 Sizesof integer types<limits.h>
...
— minimum value for an object of type int
INT_MIN -32767 //−(2^15−1)
— maximum value for an object of type int
INT_MAX +32767 //2^15−1
Посикс это дело не уточняет, SUSv1 тоже. Только в SUSv2 расширили
{INT_MAX}
Maximum value for an object of type int.
Minimum Acceptable Value: 2 147 483 647
{INT_MIN}
Minimum value for an object of type int.
Maximum Acceptable Value: -2 147 483 647
-- http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html
Это всего лишь минимумы. Стандарт диктует что реализация стандарта (компилер, платформа) не может делать меньше.
И какая платформа - кроме какого MS-DOS - это делает?
Я веду к чему: поэтому то ты никогда не видишь (и не увидишь) лэйбла "портабельно на все С платформы!", а видишь (например) "поддерживаем прыщи, бсд и солярку, 32/64 бита."
Стандарт это всего лишь основа. Ты портируешь не на стандарт - ты портируешь на платформу.
единственный недостаток — унылый printf, который напрямую эти типы не поддерживает, и приходится пользоваться макросами для форматирования типов. Но у size_t та же проблема.
просто кастишь переменные в стандартные типы.
> Но у size_t та же проблема.
"%zu" уже есть как минимум десятилетие. на бсд появился раньше, но до линухов тоже дошел. в posixv7 есть. в портабельном коде конвертил в (long) - ни разу проблем не было.
я честно говоря не знаю о каких сложностях ты говоришь. я в телекомах так 10 лет писал - и все работало, и работало на 3-5 *них платформах.
я догадываюсь что твое видение реальности омрачено опытом работы под винды. я тоже когда то таким был: все было сложно, мрачно и обложено граблями. был шанс - ушел с виндов. ни разу не жалею. граблей и говна намного меньше. проблемы поменялись - но уже одно отсутствие вечных неизменных тупостей некрософота это громадное облегчение. пару лет тоже подобные сомнения меня мучали - а потом привык на int/long/etc полагатся, и о чудо, оно работает. "полагатся" - вот это именно то сентимента на виндах остро не хватает.
лол, я ни одной программы чисто под винду не написал.
Моё видение реальности омрачено опытом решения олимпиадных задач, когда ты ковыряешься в байтах, а среду выполнения своих программ не контролируешь. А потом выясняется, что там в long 4 байта было, и тебя вообще UB в программе, потому что ты знаковые переполнил.
Может звучать смешно, но это быстро приучает к анализу размерностей, очень помогает на код-ревью.
> Может звучать смешно
Это не смешно. Это даже как то печально. Ну да в каждой нише есть своя специфика. От проблем никуда не деться: за ихнее решения деньги то и платят.
Вопрос только: вытекает ли из "помогает на код-ревью" в улучшает что то в конечном продукте. Или ты один из тех "заноз" которые докалупываются до проблем в каком `int a = sizeof(long);`.
Ну тут легко показать, что проблемы маловероятны. А вот функция вроде
template <class T> T sum(const vector<T>& items);
вообще говоря, вполне может вызывать подозрения. В этом плане std::accumulate грамотно сделан.
да, неожиданно интересный и тривиальных подход.
- то-то ты такой ебанутый!
рома рома роман, РОМАН
> С другой стороны, прагматически, сейчас существуют только 32 и 64 бит компы.
Выходит, практика и массовость молятся за программиста.
- Какого размера у тебя числа?
- Вот тут короче инта сделал, а вот тут - длиннее.
- Сколько в битах, блядь, спрашиваю?!
- Зачем ругаешься, насяльника, вот тут короче инта, а тут - длиннее.
fixed
Железка А может long double (он же на FPU, который на x87, завязан?) в 64 бита, железка B — 80, железка C — 128. Пара-тройка sizeof и прочая — и можно иметь возможность использовать аппаратный тип на полную.
Ну так если под винды программируешь, чего тогда некрософтовскими тайпдефами/дефайнами не пользуешься? чем DWORD не угодил??
На *нихах int/long работают в качестве портабельных типов превосходно.
Потому что портабельность редко ломается на размерности типов - она чаще ломается на кривых кастах основаных на неявных предположениях о размерности типов, которые унаследованы от кривых системных интерфейсов. Сравни POSIX vs WinAPI на досуге. POSIX основан на int/long/size_t + дюжина специальных типов. WinAPI основан на большой куче говна дефайнов и тайпдефов для каждой мелкой чмошной байды. Первое с мелкими поправками работает уже десятилетиями. Второе ломается с каждым значительным релизом винды, потому что редко кто догадывается где какой тип нужно правильно использовать, потому что уже WinAPI само местами криво: вывод одной функции не подходит как ввод другой.
POSIX тихо оставляет это имплементации. Поэтому все имплементации ебутся с когда-то 32битным time_t/clock_t, 32битным off_t (и дублированными системными вызовами, принимающими off64_t) и многим другим.
они никогда не были частью стандарта - они присутствую как ОС расширения для облегчения миграции/доступ к 64бит данным из 32бит софта.
> time_t/clock_t, off_t
и есть еще парачка. но то что ты назвал это как раз и есть центр 32/64 совместимости. (самое смешное что даже есть 16 бит позиксы системы - не щупал но читал.)
самое ненавистный тайпдеф/дефайн в позиксе на самом деле это socklen_t - попытка помирить SysV (size_t) c BSD (int; как если бы размер сокета когда может 4ГБ превосходить). на куче систем он: есть/нет/есть но в левом хидере/есть но кривой/есть но кривой, и не дефайн, почему нельзя проверить его наличие или отсутствие. но даже это весьма изолированая проблема без каких либо побочных эффектов.
под 16 bit protected mode (это двойка без paging) была xenix в теории)
Скорее они присутствуют из-за того, что стандарт не регламентировал размер, кто-то поставил его 32битным, его не хватило, а поменять ABI -- это убиться.
И такой стандарт скорее вреден: "ну, time_t это число, может целое, может дробное. функция time() возвращает time_t". Нулевая польза для разработчика, если мы даже не можем быть уверены, time() != time() через день, и что в данный момент time() не вовзращает ERANGE всегда.
С проблемами с socklen_t не сталкивался, но я ни под что экзотическое не пишу.
не бредь.
Из POSIX:
> clock_t shall be an integer or real-floating type. time_t shall be an integer type.
и само собой разумеется что time_t signed потому что иначе бы в 2038 не переполнилось бы.
А в предыдущем ещё не было: http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/types.h.html