LINUX.ORG.RU

Модели данных

 


0

1

Сижу вот, занимаюсь байто**ством. Вот некоторые модели данных.

 	ILP32 	LP64 	LLP64 	ILP64
char 	8 	8 	8 	8
short 	16 	16 	16 	16
int 	32 	32 	32 	64
long 	32 	64 	32 	64
long long 	64 	64 	64 	64
size_t 	32 	64 	64 	64
pointer 	32 	64 	64 	64

Один чел мне говорит «Проверяй, если инт 8 байт, то юзай шорт». Однако, педивикии говорят что ляликс юзает LP64, а оффтоп LLP64, не понимаю где чел встретил ILP64 (или какую-то другую?).

Растолкуйте от чего отталкиваться? Какие модели данных надо учесть хотябы для самых распространенных случаев?

В самом идеале, конечно, свою прилагу я предполагаю запускать на линукс/фря/оффтоп 32/64. Вопрос вообще возник от того, что читаю бинарку из файла, и там может быть BE, а может быть LE byte order, плюс еще размер самих типов, и надо как-то это все перелопачивать под то, на чем я запущен в конкретный момент.

В данном случае вопрос касается только размера инта, но полюбому я зацеплюсь в каком-нибудь месте рогами во что-то еще. Хотя это уже будет другой вопрос.

ляликс

К логопеду, быдло!

Pavval ★★★★★
()
Ответ на: комментарий от i-rinat

А это жи только для православного? Оффтоп их подругому декларирует вроде? Это я еще не зырил. Ну, даже если подругому, можно будет впилить микрокостылик, переобозвать в «родные» типы.

deep-purple ★★★★★
() автор топика
Ответ на: комментарий от i-rinat

Хм.. Ну ладно, буду юзать их. А если-что не проканает на какой-то архитектуре, то буду решать по месту костыликами.

Спасибо!

deep-purple ★★★★★
() автор топика

Пользоваться stdint.h. Принять что sizeof(int) == 4 для всех популярных платформ. В основном проблемы возникают при printf() 64-битных типов, когда приходится пользоваться уродскими PRIx64 или делать свой typedef long long int myInt64.

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

Dendy ★★★★★
()
Ответ на: комментарий от Dendy

В основном проблемы возникают при printf() 64-битных типов, когда приходится пользоваться уродскими PRIx64 или делать свой typedef long long int myInt64.

сделай свою printf(), в чём проблема-то?

emulek
()

Растолкуйте от чего отталкиваться?

а ты не можешь писать свой код так, что-бы он работал с _любым_ int'ом?

emulek
()
Ответ на: комментарий от deep-purple

Я не сохранял этих файлов

и не сохраняй ТАКИЕ файлы.

мне их прочитать надо

про stdint.h уже сказали.

emulek
()
Ответ на: комментарий от emulek

сделай свою printf(), в чём проблема-то?

О том и речь, что свои стандарты придумывать приходится. Да и не так просто написать свой printf(), когда в популярны компиляторах заточены атрибуты функций именно под этот стиль форматирования. Следующее предложение будет свой компилятор написать? Пока личным стандартном призывается сведение использования printf() к минимуму.

а ты не можешь писать свой код так, что-бы он работал с _любым_ int'ом?

К примеру, записал ты int в файл. Вопрос сколько байт записалось? И сериализаторы тут не помогут, у каждой программы сериализатор будет видеть свой размер int и читать/писать по-разному. Тут нужно или принять, что он всегда 4 байта или вообще никогда им не пользоваться, потому что стандарт не определяет для него смысловой контекст. И будьте уверены, что читатель кода не поймёт этого тоже никогда. Именно по этой же причине не допускается использование long в коде. Вместо него или свой typedef с конкретным смыслом или size_t или intptr_t или ещё что-нибудь.

Dendy ★★★★★
()
Ответ на: комментарий от Dendy

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

ЯННП

Вот вы используете свой любимый тип? Ну и напишите обёртку для этого типа, vprintf(3) вам в помощь.

Пока личным стандартном призывается сведение использования printf() к минимуму.

дык оно вроде и не годно ни для чего, окромя отладки и helloworld'ов.

Вопрос сколько байт записалось?

sizeof(int), очевидно жеж! Если тебе присралось ТОЧНО 4 байта, дык int32_t тебе в помощь.

Тут нужно или принять, что он всегда 4 байта

не нужно. Это не баг, а фича, int по задумке растёт вместе с компьютерами. Раньше int везде был 16 бит, сейчас везде 32 бита, но уже пора сделать 64 бита в 64х битных платформах, ибо как заповедовали K&R, int это _типичный_ размер целых чисел для данного CPU.

стандарт не определяет для него смысловой контекст

так задумано:

1. вася компиллит приложение на встроенном компьютере, в котором 8К памяти, и 16и битный тип регистров. Ему больше 16и не нужно. Вот у него 16и битный int

2. петя компиллит для старого iPentium4, 32х битного, у него 32х битный int

3. коля компиллит для нормального CPU, в котором 64х битные регистры, int по идее должен быть 64х битный

ИЧСХ, они все компиллят один и тот же код. Если-бы int был 32х битный у всех, то:

у васи код был-бы раздут, т.к. _любая_ арифметика выполнялась-бы частями, по 16 бит, и потом ещё по 16 бит. Причём васе это нафиг не надо, и даже вредно, т.к. у него всего жалкие 8К

у коли тоже возникли-бы проблемы, например с постоянными кастами в int32 из других типов (ptrdiff_t и size_t у него 64х битные)

emulek
()
Ответ на: комментарий от emulek

так задумано:

Если верить Википедии это было задумано 40 лет назад, сейчас это только оправдание для обратной совместимости с огромным количеством исходного кода. В современном кроссплатформенном коде типы данных выбираются в контексте конкретной задачи, к примеру, проитерироваться по файловой системе или сложить монетки в кошельке. Обьяснять выбор int ростом компьютера для совместимости между микроконтроллером и 64-битной десктопной ОС это ни в какие ворота не лезет, даже два числа перемножить уже упрётся в ограничения размера и псевдосовместимость превратится в реальные ошибки. Все эти модели данных не от хорошей жизни придуманы. Оставлю ссылку на оригинальную статью: http://www.unix.org/version2/whatsnew/lp64_wp.html

Dendy ★★★★★
()
Ответ на: комментарий от Dendy

Если верить Википедии это было задумано 40 лет назад

и согласись: задумано хорошо, т.к. на сишке до сих пор код пишут. А всякие паскали с DWORD давно вымерли.

В современном кроссплатформенном коде типы данных выбираются в контексте конкретной задачи

ага. Подход называется «640К хватит всем!».

emulek
()
Ответ на: комментарий от emulek

Забыл ответить.

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

ЯННП

Имелся в виду __attribute__ ((format (printf, ...))).

Dendy ★★★★★
()
Ответ на: комментарий от qulinxao

смотри как этот(различия в размерах и порядке) решали(и имхо качественно решили) в сырцах plan9.

а почему plan9 никто не юзает?

emulek
()
Ответ на: комментарий от Dendy

Имелся в виду __attribute__ ((format (printf, ...))).

всё равно не понял.

emulek
()
Ответ на: комментарий от emulek

ага. Подход называется «640К хватит всем!».

Это сарказм? На C/C++ тип под задачу выбирается в 99% случаях, на высокоуровневых Java/Python/JS в 100% случаях, потому как размеры типов специфицированы языком. Расход ресурсов контролируется другими механизмами, такими как объём кеша в памяти, дополнительным набором инструкций, многопоточностью и так далее. А размер целочисленных типов — исключительно контекстом их задачи.

Dendy ★★★★★
()
Ответ на: комментарий от Dendy

Это сарказм? На C/C++ тип под задачу выбирается в 99% случаях

ты когда-нибудь слышал про повторное использование функций/классов? Ну и как ты предлагаешь «выбирать тип под задачу», если задача неизвестно? Каждый раз писать очередной qsort? Или использовать callback? Или может шаблоны и C++ only?

emulek
()

бинарку из файла, и там может быть BE, а может быть LE byte order

Какое-то редкостное головожопие. Уж о формате-то файлов, едином между платформами, можно было договориться?

alegz ★★★★
()

размера инта

А писать int32_t, uint64_t и т.д. тебе влом?

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от alegz

Уж о формате-то файлов, едином между платформами

Одна платформа записала в файл long, который у неё вот сейчас во время записи был 32 бита be, а вторая платформа читает завтра это файл в long который у неё 64 бита le. О каком единстве может быть речь?

deep-purple ★★★★★
() автор топика
Ответ на: комментарий от emulek

Каждый раз писать очередной qsort?

То-есть должен остаться один qsort, который сортирует только int, и, следуя вашей логике, он будет «расти вместе с компьютерами».

Dendy ★★★★★
()
Ответ на: комментарий от alegz

Какое-то редкостное головожопие. Уж о формате-то файлов, едином между платформами, можно было договориться?

не получилось.

emulek
()
Ответ на: комментарий от Dendy

То-есть должен остаться один qsort

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

emulek
()
Ответ на: комментарий от emulek

С другой стороны, писать говно, которое жёстко приколочено к текущему размеру int, тоже не нужно.

Вы только что назвали 99% программ на C/C++ говном, потому что они приколочены к размеру int. А в пределах одной платформы (к примеру, ядро Линукс) — 100%, потому что там приняты модели данных, перечисленные автором этой темы. Ну и заодно все программы на Java и других высокоуровневых языках, в которых, о ужас, размеры целочисленных типов заданы жёстко.

Dendy ★★★★★
()
Ответ на: комментарий от Dendy

linux диктует модель данных, так что неудивительно, что он знает о размере int.

Java вообще не в тему была упомянута. Другой язык, другие стандарты.

SystemD-hater
()
Ответ на: комментарий от emulek

ты серьёзно? .

а нет необходимости.

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

это(выше абзац) - обычные явление всеобуча ,

а конкретно с plаn9VsUnixes произошло следующее:

unix оказалался достаточно хорош что-бы стать лингво-франко-ОСью() и вытеснить вполне неплохие(наряду с ужасными) нишевые оси.

plan9 «чище»(однородней и продуманей) чем unix'ы но не достаточно лучше что бы каждый почуствовал необходимость смены.

да и лицензия на plan9 по факту в90ые была хуже чем на unix в 70ые

qulinxao ★★☆
()
Ответ на: комментарий от SystemD-hater

А что принять за число бит в байте? Уж не 8 ли?

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

Dendy ★★★★★
()
Ответ на: комментарий от Dendy

Вы только что назвали 99% программ на C/C++ говном, потому что они приколочены к размеру int.

пруф?

А в пределах одной платформы (к примеру, ядро Линукс) — 100%, потому что там приняты модели данных, перечисленные автором этой темы

зачем же там всякие size_t юзают, которые тоже везде разные?

Ну и заодно все программы на Java и других высокоуровневых языках, в которых, о ужас, размеры целочисленных типов заданы жёстко.

да кому нужен будет этот говнокод через 5 лет?

emulek
()
Ответ на: комментарий от deep-purple

Одна платформа записала в файл long, который у неё вот сейчас во время записи был 32 бита be, а вторая платформа читает завтра это файл в long который у неё 64 бита le.

Либо надо записывать не в платформозависимом формате, а в том, который определен заранее обговорённым протоколом, либо, если уж протокола нет — признать формат одной из платформ стандартом де-факто, и читать тот формат, который записан, а не «long который у неё 64 бита le».

(«Самый лучший отдых – растолковывать общеизвестные истины.» ©)

О каком единстве может быть речь?

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

alegz ★★★★
()
Ответ на: комментарий от qulinxao

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

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

plan9 «чище»(однородней и продуманей) чем unix'ы но не достаточно лучше что бы каждый почуствовал необходимость смены.

на самом деле, GNU/Linux намного лучше, чем ты думаешь. Это если с т.з. практики, а не с т.з. голой теории.

Что касается теории, то BrainFuck намного более логичный ЯП нежели сишка. Там даже UB нет. И что?

emulek
()
Ответ на: комментарий от Dendy

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

ну не все же байтами обмазываются?

emulek
()
Ответ на: комментарий от alegz

Либо надо записывать не в платформозависимом формате, а в том, который определен заранее обговорённым протоколом, либо, если уж протокола нет — признать формат одной из платформ стандартом де-факто, и читать тот формат, который записан, а не «long который у неё 64 бита le».

самое простое: писать в текстовом виде лог.

emulek
()
Ответ на: комментарий от SystemD-hater

Java вообще не в тему была упомянута. Другой язык, другие стандарты.

Так про стандарты и речь. Или для вас стандарт это нечно неприкосновенное по определению? Стандарт определяет некие общие правила, упрощающие модель в пределах конкретной задачи, некую точку отсчёта для упрощения понимания между участниками. Конкретно в стандартах C/C++ дикий разброс и шатание, спецификация огромна, порог вхождения тоже, многие вещи необходимые в прикладных задачах неопределены. Сколько секунд в минуте? 60? Ответ — сколько угодно, потому что вы пишите на C/C++.

И язык Java и модели данных C/C++ это примеры сужения стандартов для решения прикладных задач. Если вы попали в 1%, которому нужна большая свобода портирования — выберите соответствующий язык под свою задачу. Конкретно в С/C++ принимаются сужающие стандарты, вроде модели данных и стиля кодирования.

Dendy ★★★★★
()
Последнее исправление: Dendy (всего исправлений: 1)
Ответ на: комментарий от Dendy

Конкретно в С/C++ принимаются сужающие стандарты, вроде модели данных и стиля кодирования.

ты что курил? Какие «стили» и «модели данных» в стандартах сишки?!

emulek
()
Ответ на: комментарий от qulinxao

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

emulek
()
Ответ на: комментарий от emulek

Какие «стили» и «модели данных» в стандартах сишки?!

В реальных проектах. Потому что стандарт слишком широк.

Dendy ★★★★★
()
Ответ на: комментарий от Dendy

Какие «стили» и «модели данных» в стандартах сишки?!

В реальных проектах. Потому что стандарт слишком широк.

дык это хорошо: если нужен знаковый тип из 32х битов, пиши int32_t, если просто «целое число», то пиши int.

emulek
()
Ответ на: комментарий от anonymous

в POSIX char всегда байт, в байте 8 бит

ага. А потом мы удивляемся, «почему у нас юникод не работает?». Да потому, что 99.99% программистов считают «символ» == «байт» == «8 бит».

emulek
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.