В своём справочнике по С, Шилдт пишет, что стандартами C89 и C99 определены минимально допустимые диапазоны значений для базовых типов. Т.е. диапазоны могут быть и больше. Например, у меня 64-х разрядный процессор + 64-битная операционная система, в свете чего я предполагаю, что в моём случае минимально допустимый диапазон может существенно отличаться от указанного Шилдтом... 
  Как в C программно определить потенциально допустимые (учитывая только архитектуру компьютера) диапазоны значений для базовых типов на текущей локальной машине, а так же фактически допустимые диапазоны значений (учитывая архитектуру компьютера + разрядность ОС) ?

Это сообщение отредактировал(а) Compositum - 11.5.2011, 07:35

Вопрос снят, т.к. в гугле нашел ответ - sizeof().
Написал такой код:


Результат получился таким (размеры, как я понял - в байтах):

в моём случае long double существенно отличается от значения, указанного Шильдтом в справочнике - 16 байт вместо 10.
В общем - выяснил то, что хотел 

Это сообщение отредактировал(а) Compositum - 11.5.2011, 08:15

sizeof возвращает размер в char'ах. char - это минимально адресуемый объем данных. Именно поэтому, sizeof(char) всегда равен 1.

а как тогда программно узнать размер char в байтах? 

зачем программно, если (оттуда же)


Добавлено через 5 минут и 20 секунд



хммм. должен быть 8. и ещё: ты самое интересное не вывел - sizeof( void* )

Это сообщение отредактировал(а) borisbn - 11.5.2011, 17:48

спасибо! понятно, тогда вопрос отпадает, раз размер всё же в байтах. 

п.с. Жаль, что в своей книге Керниган и Ритчи не рассматривают вопросы локализации и работу с расширенными символами (в приложении так и пишут, мол эту тему опускаем)...

это где такое было? 10 байт

возможно дело в том, что у меня процессор Core I7 (т.е. архитектура процессора - x64) + Ubuntu 11.04 x64.
Приду домой - добавлю строку и для void*, а почему знак умножения?

Добавлено @ 17:59

Справочник по С, автор Шильдт (издание, если не изменяет память - 4-е, изложены полностью C89 и C99).  Если нужен номер страницы - домой приду, сообщу (книги под рукой сейчас нет).

Да, точно 4-е, вот она.

Это сообщение отредактировал(а) Compositum - 11.5.2011, 18:05

а может 0х10 ?

я сейчас уже ухожу с работы. через полтора часа буду дома - проверю ещё раз и отпишусь.

Проверил (стр 45): 80 бит. Соответственно 10 байт, как я и писал.

старые досовские компиляторы выдавали sizeof(int) = 2 байта, так как на x86 была адресация в 16 бит.
не удивлюсь если книженция старая то могла быть написана для досовских компиляторов, а там  возможно и 10 байт было. Завтра на работе посмотрю книженцию. 

Книга издания 2010 года. 


Вывожу:

да ну не может быт 10 байт, там все кратно. а 10 никуда не лезет.

Добавлено через 10 минут и 9 секунд
http://en.wikipedia.org/wiki/C_variable_ty...nd_declarations

Я видел, это в вики. Давайте условимся, что это последний раз, когда я фотографирую книжку - тынц. Таблица 2.1. последняя запись (long double).  Возможно в книге опечатка - за что купил, за то и продаю.

http://en.wikipedia.org/wiki/Extended_precision

У мат. сопроцессора x87, всю жизнь, еще с допотопных времен и по сей день внутренняя разрядность 80 бит, т.е 10 байт.

Добавлено через 1 минуту и 50 секунд
тынц

так и есть в допотопной книге long double  = 80 бит.

Если не верите могу гденить запустить старый Borland там он тоже покажет 80 бит.

я верю 

Народ. Это же выравнивание!!! 64-х битному процессору значительно проще работать с данными, кратными 8-ми байтам. В противном случае, ему приходится делать несколько операций чтения из памяти, если данные находятся на границе 64-х битных ячеек. Скорее всего лишние 6 байт просто не используются.

тоже так думал, т.к. кроме 128-ми битных XMM-регистров (да и то, в них по 2 double) больше 80 бит не слышал, однако:
http://liveworkspace.org/code/c627a9ab4f36...2f8a18e1793ac52

выдаёт

???

Это сообщение отредактировал(а) borisbn - 12.5.2011, 12:50

borisbn, разве на мусор не смахивает?

bsa, не особо:

и потом, я обнуляю все 128 бит

наверное, есть что-то, чего мы не знаем   

borisbn, посмотри ассемблер. Не удивлюсь, если происходит загрузка в штатные 64-х битные регистры результата, а затем уже они записываются в память.

bsa, в gcc посмотреть не могу, т.к. пользую liveworkspace, а в MSVC не могу, т.к.
MSDN:


P.S. На liveworkspace вообще ничего не понимаю: 

даёт 12   

Это сообщение отредактировал(а) borisbn - 12.5.2011, 14:55

borisbn, ну вот видишь. Система лайфворкспейса 32-х битная. А там используется выравнивание 4. Поэтому long double и получился размером 12 байт. А то, что в начале мусор - так это же кусок стека!

bsa, я как увидел 12 байт сразу понял... ( ну... почти сразу  ) и да, там не мусор а счётчик цикла i. мусор будет в доп. 2-х байтах.
Спасибо за консультацию.

Это сообщение отредактировал(а) borisbn - 12.5.2011, 15:20

 счетчик цикла _отражен_ в другой переменной ? а чем это не мусор ?!


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

Фактическая длина встроенной плавающей арифметики не может превышать 80 бит. То что в некоторых системах сайз оф лонг дабл показывает 12, 16, и т.д - это округленная длина, за счет выравнивания. Фактически используется только 10 байт. В остальных байтах находится незначащий мусор.
Имхо выводы такие. Поправьте если ошибся.

> Имхо выводы такие. Поправьте если ошибся.
Имхо точнее не скажешь 
Хотя, то, что длина лонг дабла именно 80 бит - это вывод по многочисленным книгам и статьям, а не из проведённых экспериментов, но не верить этим источникам у меня лично оснований нет

Это сообщение отредактировал(а) borisbn - 13.5.2011, 06:38

емко и кратко   

но  :


тут надо уяснить что обсуждались два вида сущностей :
1. extended precision (floating-point arithmetic) - бинарное представление данных, не имеющих к языку прямого отношения.. 
оно действительно 80 бит.. но бывают и другие точности (precision) в том числе и 64 или 128 бит.. 
2. тип long double, который на ряде платформ выражен адаптером для extended precision.. в стандарте языка не указано, чем должен быть выражен этот тип, и поэтому разработчики имеют право на выбор и на разных архитектурах один и тот же тип может быть выражен разными способами..

в результате long double может не быть 80ти битным по двум причинам :
1. выражен другой точностью нежели extended
2. адаптирован под архитектуру (условно выравнен)

Добавлено через 1 минуту и 54 секунды

можно просто взглянуть в документацию под нужнуюю платформу