LINUX.ORG.RU

Стандартен ли long в Си?

 , ,


0

2

Собственно вопрос. Описаны ли стандартом размеры всяких

long
long long
int
double
// И так далее

?
Если описаны, то чему равны их размеры? Или это компиляторозависимая платформоспецифичная особенность и лучше использовать к примеру uint64_t?

★★★
Ответ на: комментарий от nionio35

это делается для другого. я уже описал зачем.

не вижу где написано.

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

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

Байт может быть и не 8 бит, байтом он не перестанет вроде. Поменяется битность байта поменяются лимиты типов, всё остальное мною описанное останется верным. Ну вроде как…

Для float вне зависимости от размера байта в битах он будет 32 бита и 64 для double соотвецтвенно. Как будет это реализовано через 6битные байты отдельно или через ещё как хз, но адресация float_ptr++ по сути должна смещаться на 32 бита согласно размеру фиксированному флоата даже если байт будет двухбитным или 128 битным.

P.S. QEMU умеет эмулировать некую хню с не 8 битными байтами или вообще как вот такой случай экзотический потыкать палочкой на обычном x86 хосте? Было бы интересно. Даже пособирать под такое «железо» и посмотреть как код падает =)

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 2)
Ответ на: комментарий от safocl

Некропостинг такой некропостовый

Werenter ★★★
() автор топика
Ответ на: комментарий от LINUX-ORG-RU

6ти битный [байт?] например не байт разве?

А Вы таки правы. Википедия с Вами согласна, по крайней мере. И оказывается 8-ми битный байт зовётся «октетом».

ПыСы. С не 8-ми битными байтами сталкиваться не приходилось, несмотря на то что в прошлом приходилось иметь дело с «зоопарком» серверного железа (сейчас, слава богу, только x86 остался).

bugfixer ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Для float вне зависимости от размера байта в битах он будет 32 бита и 64 для double соотвецтвенно.

На архитектурах следующих IEEE756 (емнип), что в общем случае не так.

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

Яб под сетунь покомпилял привет миры, там вот именно что байта нет, там трайт и не из восьми битов, а из шести тритов. Вотета я понимаю экзотика =)

Хотя по сути, если код на сишке написан по всем канонам бородатых дедов то сишный код соберётся влёт и работать будет как обычно, просто будет потеря потерь в плане ёмкости памяти. Ну в теории, особо не думая, кажется что так :D

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от nionio35

бывает нужно и не при отладке. всяко бывает.

Не знаю какую именно проблему Вы решаете, но реальная Ж в другом: по историческим причинам на 32-ух битах int64_t алиасится в long long, а на 64-ех - в long. И это вызывает реальные проблемы так как long и int / long long это разные типы, несмотря на то что sizeof() is the same etc. И в обозримом будущем это пофикшено не будет, потому как означает слом ABI.

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

На архитектурах следующих IEEE756

А вот тут да. Только если заявлено. Просто float может быть каким угодно. На GPU например есть half float это 16 битный тип. Не всегда нужна точность, а от GPU до специфичного CPU рукой подать, FPU/ALU и там и там.

Но даже это экзотика обычному программисту можно вообще не парится, вот когда время придёт и надо, вот тогда и =)

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)
Ответ на: комментарий от soomrack
#define true false;  // fuck a duck with a Cristmass tree

Это еще не fuck a duck. Если хочется повеселиться, можно что-нибудь такое вкорячить.

#define true (srand ((unsigned int) time (NULL)),(((rand() % 99 + 1) < 95) ? (!false):false))

Веселой отладки )

btw, а чего это у меня рекурсивный макрос не получился? Пришлось писать !false вместо true, хотя по идее должно же было скомпилироваться с однократной подстановкой слова true

praseodim ★★★★★
()
Последнее исправление: praseodim (всего исправлений: 3)
Ответ на: комментарий от LINUX-ORG-RU

Хотя по сути, если код на сишке написан по всем канонам бородатых дедов

Лично я называю такой подход «академическим программированием». Имхо - ресурсы на ветер. Решать прикладную задачу нужно «здесь и сейчас», с тем железом и toolchain что доступно сейчас. А не тратить время на гипотетические случаи, которые Вы даже оттестировать нормально не сможете. Я уверен - довольно много народу со мной не согласятся (включая многоуважаемого, без тени сарказма, @eao197)…

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

А не тратить время на гипотетические случаи, которые Вы даже оттестировать нормально не сможете. Я уверен - довольно много народу со мной не согласятся (включая многоуважаемого, без тени сарказма, eao197)…

Не, ну некоторых вещей все же следует избегать, в частности, не подразумевать, что sizeof(void) == sizeof(int) даже на 32-битных x86

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

Смотря для какого кода, благо всегда есть выбор, и нет среди него неправильного. Если говорить про оптимизации то вообще проблем нет, если что переписываем. А если надо ультра мега гига монолитно эпично железно рабочий код который на водяном компьютере инопланетян должен собираться без ошибок и работать так же значит так тоже было надо =) А если нужно оптимизировать, пральна, переписываем =) Полномасштабная оптимизация часто возможна только чезез полную смену кишков лишь API наружу не трогать (и то не всегда получается) Ну да ладно.

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от praseodim

не подразумевать, что sizeof(void) == sizeof(int) даже на 32-битных x86

Не мы первые на этом «минном поле» )) intptr_t «деды» неспроста придумали ;)

bugfixer ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Я помню видел какой-то DSP, TI C64x или Motorola StarCore 56K, не помню уже, так там байт был 12 бит или около того.

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

С не 8-ми битными байтами сталкиваться не приходилось, несмотря на то что в прошлом приходилось иметь дело с «зоопарком» серверного железа (сейчас, слава богу, только x86 остался).

На DSP обычно бывают всякие приколы вроде байт равен 12, 16, 24 и т.д. битам.

Компилятор под Texas Instruments C55x DSP имеет такую карту:

type               size (bits)
  ------------------------------
  char               16
  short              16
  int                16
  long               32
  long long          40
  float              32
  double             32
  pointer (data)     16 or 23
  pointer (function) 24
EXL ★★★★★
()
Ответ на: комментарий от ox55ff

sizeof говорит сколько в типе вмещается char’ов. Он не про байты вообще.

Он про байты. Но ты имел ввиду, что он не про биты.

ISO/IEC 9899:2011 (E)

страница 4

3.6 
1 byte addressable unit of data storage large enough to hold any member of the basic character set of the execution environment 

2 NOTE 1 
It is possible to express the address of each individual byte of an object uniquely. 

3 NOTE 2 
A byte is composed of a contiguous sequence of bits, the number of which is implementation- defined. The least significant bit is called the low-order bit; the most significant bit is called the high-order bit.



страница 90

The sizeof operator yields the size (in bytes) of its operand, which may be expression or the parenthesized name of a type. The size is determined from the type of the operand. The result is integer. If the type of the operand is a variable length array typoe, the operand is evaluated; otherwise, the operand is not evaluated and the result is an integer constant.

When sizeof is applied to an operand that has type char, unsigned char, or signed char, (or a qualified version thereof) the result is 1. When applied to an operand that has array type, the result is the total number of bytes in the array.103) When applied to an operand that has structure or union type, the result is the total number of bytes in such an object, including internal and trailing padding.

The value of the result of both operators is implementation-defined, and its type (an unsigned integer type) is size_t, defined in <stddef.h> (and other headers).
soomrack ★★★★★
()
Последнее исправление: soomrack (всего исправлений: 2)
Ответ на: комментарий от soomrack

Note: C55x Byte is 16 Bits

By ISO C definition, the size of operator yields the number of bytes required to store an object. ISO further stipulates that when sizeof is applied to char, the result is 1. Since the C55x char is 16 bits (to make it separately addressable), a byte is also 16 bits. This yields results you may not expect; for example, sizeof (int) == 1 (not 2). C55x bytes and words are equivalent (16 bits).

Спека по TI C55x кстати как раз цитирует стандарт.

https://www.ti.com/lit/ug/spru281f/spru281f.pdf

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

Не помню откуда я нахватался про количество char’ов. Сейчас посмотрел, везде пишут что единица измерения sizeof это байт. Только в справке microsoft по c++ есть Yields the size of its operand with respect to the size of type char. Значит я не прав.

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

Ну логично, что цитирует, а как иначе то?

В целом, если грубо говорить, то byte – это наименьший возможный блок памяти, которым оперирует программа. Если программа будет работать с одним битом, то она все равно будет это делать работая со всем блоком (байтом), в котором лежит этот бит.

char должен помещаться в байт, но фактически он может занимать меньше байта, скажем байт это 8 бит, а char это 7 бит.

sizeof меряет все в блоках памяти минимального размера, т.е. байтах, округляя в большую сторону, т.е. sizeof(char) всегда будет 1.

Соответственно, байт может иметь любой размер в битах – это зависит от реализации, может иметь 7 бит, может 107. Меньше 7 бит он иметь не сможет, т.к. есть требование в стандарте, что он должен вмещать 96 символов.

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

Не помню откуда я нахватался про количество char’ов.

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

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

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

тогда это не компилятор языка программирования с++...

Да практически любая программа, заметно посложнее helloworld, выйдет зависимой от платформы.

полнейший бред.

Явно или неявно, но вылезет что-то платформенное.

снова бредятина.

или IFDEF-ами обкладывают и/или разные файлы используют при сборке

так это же учесть библиотек как раз — при чем тут код целевой программы?

и размер типов

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

порядок байт

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

не везде есть пользовательский аппаратный стек

вообще не понял что ты имеешь ввиду.

safocl ★★
()
Ответ на: комментарий от LINUX-ORG-RU

char(1)<=short(1 или 2)<=int(2 или 4)<=long(4 или 8)

откуда такие ограничения на максимум? в стандарте с++ указано по другому... коммитет по стандартизации взял тебя на заметку...

INT_MIN/INT_MAX

что вас вечно ведет к странным использованиям с++? — есть же нормальные limits

typenameXX_t

есть куда более лучшие типы — int_least{N}_t и int_fast{N}_t

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

в стандарте с++ вообще не про 1 указывается — прочтите же basic.fundamental — там табличку красивую сделали... ну все же для юзеров.. коммитет по стандартизации такие усилия прилагает, что бы ну хоть нормальный код писали люди и понимали что к чему...

safocl ★★
()
Ответ на: комментарий от LINUX-ORG-RU

Для float вне зависимости от размера байта в битах он будет 32 бита и 64 для double соотвецтвенно.

можно выписку из стандарта с++ сделать на это? я очень хочу увидеть, где там про такое указано...

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

есть куда более лучшие типы — int_least{N}_t и int_fast{N}_t

И как часто Вы вот это вот видели в проде? Задумка хорошА, но не «взлетело»…

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

прочтите же basic.fundamental

Таблицу вижу. Про красивость не соглашусь. Но при чём она здесь?

в стандарте с++ вообще не про 1 указывается

Есть про единичку.

7.6.2.5 Sizeof

The result of sizeof applied to any of the narrow character types is 1.
ox55ff ★★★★★
()
Ответ на: комментарий от soomrack

скажем байт это 8 бит, а char это 7 бит.

нет — так не может — табличка поможет понять почему...

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

в смсле не взлетело? используй — кто тебе мешает? ну и кстати можешь заценить какой нибудь код проги... думаю там тоже возможно будут такие типы очень вероятно)))

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

Но при чём она здесь?

при том, что мы про размер типов же... а там ничего не связанного с байтами указано...

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

The sizeof operator yields the number of bytes occupied by a non-potentially-overlapping object of the type of its operand.

«occupied by a non-potentially-overlapping» - тут думаю самое важное...

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

что то тут с дисциплинкой чтения стандарта с++

Складывается устойчивое впечатление что «чукча только читатель».

Создайте что нибудь рабочее, и возвращайтесь.

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

ну дак даже просто читатель получается правее в некоторых аспектах чем «сторожилы» кодирования?

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

7.6.2.5 Sizeof

в других версиях стандарта может быть другое число главы — лучше в таких случаях использовать ее алиасы справа — к примеру тут будет [expr.sizeof]

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

Есть про единичку.

кстати и на long может показать 1 — если байт будет 32 бита... От аппаратуры тут не зависит (вроде бы), поскольку байт чисто абстрактивная модель хранения данных в программировании.

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

ну дак даже просто читатель получается правее в некоторых аспектах чем «сторожилы» кодирования?

Код покажите, будет что обсудить.

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

можно выписку из стандарта с++ сделать на это?

https://eel.is/c++draft/basic.fundamental#12

the object and value representations and accuracy of operations of floating-point types are implementation-defined

но есть ещё С++23 опциональные типы: https://eel.is/c++draft/basic.extended.fp

Вот там задан размер…

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

the object and value representations and accuracy of operations of floating-point types are implementation-defined

а где тут про именно 32 и 64 бита для флоата и дабла соответственно?

п.с. а сайтик возьму на вооружение — спс

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

да ну не — тема вообще не про демонстрацию проектов жеж…

Мне не нужны «проекты», мне не нужны «идеи». Мне нужен пример кода. Желательно со всеми typedefs за которые вы так топили… Или мы только языком чесать умеем?

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

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

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

при чем тут конкретно мои поделки?

Хочу увидеть историю успеха и живого человека использующего «int_least{N}_t и int_fast{N}_t». Ну пожалуйста, хоть разочек!

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