Заключение
…
Мы будем рады получить ваши отзывы, замечания, поправки, дополнения и непременно внесу их в следующую версию статьи.
6. Упаковка указателей
…
В конце хочется заметить, что плохим стилем будет упаковка указателя в типы всегда равные 64-битам. Показанный далее код вновь придётся исправлять с приходом 128-битных систем.
PVOID p;
// Bad style. The 128-bit time will come.__int64 n = __int64(p);
p = PVOID(n);
А что, существуют 128-битные платформы? Хотя бы в планах?
Здравствуйте, 0x8000FFFF, Вы писали: FFF>После чего в своем коде используются не стандартные int, long и т д... а свои введенные, аля FFF>INT8, INT16, INT24, INT32, INT64, а так же размеры адресного пространства и многие другие вещи.
Int24 – это на каких платформах бывает?
Пётр Седов (ушёл с RSDN)
Re[4]: 20 ловушек переноса Си++ - кода на 64-битную платформ
ПС>Здравствуйте, 0x8000FFFF, Вы писали: FFF>>После чего в своем коде используются не стандартные int, long и т д... а свои введенные, аля FFF>>INT8, INT16, INT24, INT32, INT64, а так же размеры адресного пространства и многие другие вещи. ПС>Int24 – это на каких платформах бывает?
Здравствуйте, Lepsik, Вы писали: ПС>>А что, существуют 128-битные платформы? Хотя бы в планах? L>PlayStation 2 computer entertainment system's Emotion Engine CPU is a 128-bit processor.
PlayStation 2 – это 32-битная платформа (там всего лишь 32 MB оперативной памяти). int и указатели там 32-битные.
Пётр Седов (ушёл с RSDN)
Re[5]: 20 ловушек переноса Си++ - кода на 64-битную платформ
Здравствуйте, Аноним, Вы писали:
K>>>>unsigned char *array[50]; K>>>>unsigned char size = sizeof(array); K>>>>32-bit system: sizeof(array) = 200 K>>>>64-bit system: sizeof(array) = 400
А>Ну так это проблема не 64-битных систем, а кривости рук разработчика. Если ему придется заменить на char *array[100] возникнет точно такая проблема.
Да. Но, смысл был в том, чтобы подчеркнуть важность предупреждений выдаваемых компилятором, при переносе
программы на новую платформу.
Re[2]: 20 ловушек переноса Си++ - кода на 64-битную платформ
Здравствуйте, Аноним, Вы писали:
А>сходу не увидел про работу с файлами и off_t и f_pos. А>имхо надо бы добавить
Лично я с проблемами при работе с файлами не сталкивался. А, фантазировать не хочется. Буду благодарен Вам за пример подобных ошибок (связанных с off_t и f_pos).
Re[4]: 20 ловушек переноса Си++ - кода на 64-битную платформ
Ну, по поводу оперативности.... Статья на русском ужу готова была. При чем мы месяц назад хотели ее здесь на RSDN выложить. Написали письмо. В ответ уже месяц тишина.
Re[4]: 20 ловушек переноса Си++ - кода на 64-битную платформ
Здравствуйте, Пётр Седов, Вы писали:
ПС>Мы будем рады получить ваши отзывы, замечания, поправки, дополнения и непременно внесу их в следующую версию
Эх. Учтем. Спасибо.
ПС>А что, существуют 128-битные платформы? Хотя бы в планах?
Если и нет — то будут.
Re[2]: 20 ловушек переноса Си++ - кода на 64-битную платформ
Здравствуйте, 0x8000FFFF, Вы писали:
FFF>Обычно все проблемы решаются, когда пишешь изначально кросплатформенный код. FFF>Пишется библиотека, определяются общие типы, которые уже опредлеляются для каждой платформы, операции над типам, учитываются BigEngian, LittleEndian или другая платформа.
FFF>После чего в своем коде используются не стандартные int, long и т д... а свои введенные, аля FFF>INT8, INT16, INT24, INT32, INT64, а так же размеры адресного пространства и многие другие вещи.
FFF>После чего имеем код, который компилится под любую платформу и прекрасно там работает =)
1) Мы сами пробовали такой подход и остались недовольны. Но спорить не буду.
Это отдельную статью писать надо.
2) То, что предлагается, к сожалению никак не может помочь при переносе УЖЕ существующего кода.
Re[2]: 20 ловушек переноса Си++ - кода на 64-битную платформ
Здравствуйте, Eugene Kilachkoff, Вы писали:
EK>-1. Что у вас с кернингом? В evince под линуксом (движок xpdf) буквы просто наезжают друг на друга, в acrobat reader'е под виндой эффект меньше, но все равно есть.
Будем смотреть. Спасибо.
EK>0. Английский язык, мягко говоря, стремный. Например "capable to keep" --> "capable of keeping" и многое другое, русскоязычное построение предложений просто выпирает.
Знаем. Постараемся улучшить. Кто читает английский вариант — большая просьба присылать пометки (karpov@viva64 .dot. com). Будем очень благодарны.
EK>Далее по разделам.
EK>2. Это не проблема функций с переменным числом аргументов. Функция int sum_int(unsigned count,...); от этого не страдает. Это проблема функций с c-style форматными строками.
Не обязательно. Можно и нечто новое придумать. Проблема функций с c-style форматными строками — просто самая распространенная.
Here is a table of the common data models that Lua supports:
Data model
short
int
long
long long
void*
size_t
ptrdiff_t
Platform examples
LP32
16
16
32
-
32
16
32
WIN16, MSDOS-large
ILP32
16
32
32
[64]
32
32
32
WIN32, Unix-32bit
L64
16
32
64
-
32
32
32
PS2
LP64
16
32
64
64
64
64
64
Unix-64bit
LLP64
16
32
32
64
64
64
64
WIN64
ILP64
16
64
64
64
64
64
64
(abandoned ~'95)
Поэтому с точки зрения C/C++-программиста PlayStation 2 – это 32-битная платформа. Оно и понятно: чтобы адресовать 32 MB оперативной памяти, 32-битного указателя вполне достаточно (а вот 128-битный указатель – это был бы перебор).
и за статью 
Знаем. Постараемся улучшить. Кто читает английский вариант — большая просьба присылать пометки (karpov@viva64 .dot. com). Будем очень благодарны.