Каков разрядный размер long в 64-битной Windows?

В Windows с MSVC++ int и long являются 32-битными: msdn.microsoft.com/en-us/library/3b2e7499.aspx. Однако, чтобы разрешить, например, векторы для хранения более 4G элементов, size_t - 64 бит. Поэтому для итерации нужно использовать int64_t вместо int, например. векторы, которые могут содержать более 4G элементов.

В Cygwinsizeof(long) == 8, даже в Windows :-)

@SergeRogatch они должны использовать size_t или тип итератора для итерации, а не int или int64_t

@ LưuVĩnhPhúc, с size_t становится сложно работать с отрицательными числами, потому что size_t беззнаковый. Итак, for(size_t i=0; i<v.size()-2; i++) не работает для векторных размеров 0 и 1. Другой пример: for(size_t i=v.size()-1; i>=0; i--).

Если вы выполняете математические вычисления с указателями (т.е. со значениями size_t, тогда результат должен храниться в переменной типа ptrdiff_t, которая должна быть достаточно большой для хранения такого результата и является типом подписанный именно по этой причине!)

@rustyx - это компиляторы, а не операционные системы. Cygwin скомпилирован с использованием mingw (порт GCC для Windows) в качестве компилятора. Как и GCC в Linux, он может определять long как 64-битный, однако MSVC++ (компилятор Microsoft) определяет его как 32-битный.

@OrionEdwards На самом деле речь идет о целевой платформе ABI. Cygwin имеет собственный POSIX-подобный ABI и выбирает более удобную для POSIX модель LLP64, тогда как Mingw придерживается Win32 ABI со своей моделью LP64. По этой причине в GCC в комплекте с Mingw long составляет 32 бита, а в GCC в Cygwin - 64 бита.

@rustyx Я чувствую, что мы разговариваем друг с другом. Я хочу сказать, что long существует только в мире компилятора и соглашений, которых он ожидает. Когда дело доходит до запуска кода, это просто «По этому адресу 8 байтов», а термины int, long и т. д. Не существуют.

Есть ли гарантия, что uint32_t и DWORD будут взаимозаменяемыми? Нетрудно представить, что они могут не быть [например, если первый - 32-битный int, а второй - 32-битный long, gcc будет предполагать, что указатель на один тип не сможет создать псевдоним другого, несмотря на их совпадающие представления].

Не то чтобы это важно, но 8-битные байты на самом деле не являются частью спецификации C (пункты 3.6 и 5.2.4.2.1 стандарта C). Хотя вам будет сложно найти машину, на которой не было бы 8 бит, вы можете проверить LONG_BIT, чтобы узнать, насколько велик ваш длинный тип данных.

Конечно, вы правы, это фактически зависит от архитектуры («адресуемая единица хранения данных, достаточно большая, чтобы вместить любой член базового набора символов среды выполнения»), но наиболее часто используемые архитектуры равны 8 битам.

Но OP не спрашивал о компиляторе / платформе его; он спросил конкретно о 64-битной Windows - вероятно, потому что у него не есть удобный доступ к 64-битной системе Windows для тестирования.

Для тех, кто работает уже достаточно давно, 64-битный переход имеет некоторые параллели с переходом от 16-битного к 32-битному переходу середины 80-х годов. Были компьютеры с IL32 и другие с L32 (адаптация новой нотации к старой проблеме). Иногда int было 16-битным, иногда 32-битным.

Не забывайте, что это относится только к Си-иш. У других есть более разумные спецификации, где а) разработчику компилятора не разрешается выбирать размер типов данных волей-неволей или б) физическое представление типов данных не "утекает" или в) целые числа всегда бесконечно велики.

Верно, но для тех языков, которые определяют поведение, в первую очередь нет проблемы. Например, в Java есть «длинный», но размер фиксированный (64-битный?) На всех платформах. Так что проблем с переносом на 64-битную машину нет; размер не меняется.

Утверждать, что Alpha была / есть ILP64, неверно. OpenVMS, Tru64 и Linux, работающие на Alpha, - это «просто» LP64.

@Daniel: спасибо за исправление - я обновил ответ более или менее подходящим образом.

вы думаете, что ILP64 будет более популярным, не было бы проще обрабатывать 64-битный тип данных на 64-битном процессоре?

@TomFobear: ILP64 представляет одну серьезную проблему - как вы называете 32-битный тип? Или, если вы называете 32-битный тип short, как вы называете 16-битный тип? И если вы называете 16-битный тип char для UTF-16 и т. д., Как вы называете 8-битный тип? Таким образом, использование LP64 оставляет вам 8-битный char, 16-битный short, 32-битный int, 64-битный long, с возможностью расширения вверх до 128-битного long long, когда (если?) Это станет актуальным. После этого у вас будет больше степеней 256, чем имен в C (ну, я полагаю, у вас может быть 256-битный intmax_t, и только тогда у вас закончится). В LP64 есть заслуга.

Возможно, это очевидно для вас, ребята, но я думаю, что стоит отметить, что C# использует целые числа, отличные от всего остального. Недавно я столкнулся с проблемой взаимодействия с DLL, поскольку C# использует 64-битные длинные (msdn.microsoft.com/en-us/library/ms173105.aspx).

@Compholio: Для меня это было совершенно не очевидно, но я не программировал на C#. В Java тоже есть свой набор фиксированных размеров для целых чисел.

@ Джонатан Леффлер, когда вы говорите, что код должен быть изменен для использования 64-битных возможностей, вы имеете в виду ограничение в 2 ^ 32 элемента в массиве? Я предполагаю, что вы все еще можете использовать более 4 ГБ кучи для нескольких распределений, например. Знаете ли вы, есть ли индексы в контейнерах типа массива в реализациях MS контейнеров STL 32 бит?

В среде Windows, чтобы использовать 64-битные целые числа в программе, изначально написанной для 32-битной среды, вы должны изменить тип некоторых переменных (в общем). Напротив, в среде LP64 любые переменные типа long автоматически становятся 64-битными при переносе кода. Размеры массивов и т. д. Могут быть проблемой, но если вы выделяете несколько гигабайт памяти, вы обычно знаете об этом и уже предприняли шаги для работы с объектами большого размера.

Документ из X / Open на 64-битные модели программирования: почему именно LP64?. См. Также Нейтралитет размера данных и поддержка 64-битной версии.

@JonathanLeffler: На протяжении десятилетий в области микрокомпьютеров char, short и long были типами фиксированного размера с 8, 16 и 32 битами соответственно. Размер int будет 16 на одних платформах и 32 на других, но код, требующий 16-битного типа, может использовать short, а код, требующий 32-битного типа, может использовать long. Колеса отваливаются, только если int становится 64-битным.

Спасибо за объяснение аббревиатур, стоящих за ILP64, LLP64, LP64!

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

Если бы вы изобретали C заново сегодня, даже если оглянуться назад на 20:20 и иметь 45-летний опыт работы с C, неясно, что вы сделаете это изменение. Существует много различных типов ЦП, и разумные конструктивные решения для 8-битного или 16-битного ЦП не обязательно будут разумными для 64-битного ЦП. Я считаю, что есть еще несколько систем, в которых размер слова не является степенью двойки; их было намного больше, когда был изобретен C. Стандарт - это договор между разработчиками компилятора и программистами, которые его используют. Если вы будете внимательно следовать правилам, вы сможете написать переносимый код.

@deltamind: Легко сказать в ретроспективе, но изначально C должен был работать на машинах с 18-битными и 15-битными целыми числами и 7-битными символами, которые, к счастью, уже не в моде.

Возможно, стоит упомянуть, что ABI ILP32 в 64-битном режиме - это вещь (например, AArch64 ILP32 и x86-64 Linux x32), поэтому проверка sizeof(size_t) или sizeof(void*), чтобы определить, поддерживаются ли 64-битные целые числа изначально / эффективно, может по-прежнему иметь ложноотрицательные результаты. Я не знаю, называет ли это это моделью LL64 (где только long long 64-битный).