Перенос устаревшего кода на 64-битный в C++

Я пытаюсь перенести устаревший 32-битный код на 64-битный. В этом у нас есть такой союз:

union ptType
{
    int * iPtr;
    short * sPtr;
    long * lPtr;
    bool * bPtr;
    double * dPtr;
};

Как вы можете догадаться, это объединение используется для хранения адресов всех этих типов. Я читал о большом количестве указателей и арифметических изменениях в 64-битных версиях. Но я не слишком уверен в таком поведении. Этот код, кажется, работает в QA, но я больше опасаюсь насчет производства, так как там будет огромный трафик.

Как портирование на 64 бит повлияет на поведение кода?


c++ 32bit-64bit
person naveen    schedule 31.03.2013    source источник
comment
Вы не рассказали нам о текущем поведении кода, так откуда мы можем знать, как он изменится?   -  person Alexey Frunze    schedule 31.03.2013
comment
Тип данных не имеет поведения сам по себе. ptType — это тип данных. У меня будет поведение, когда оно используется другим кодом. Итак, какое использование вас беспокоит - можете ли вы опубликовать код, используя объединение, которое вас беспокоит?   -  person user93353    schedule 31.03.2013
comment
Меня беспокоит то, что указатель перечисления сохраняется, а позже к нему обращаются с помощью указателя int. Как он поведет себя в данном конкретном случае? Компилятор, который мы запускаем, имеет все указатели одинакового размера. Но я думаю, что это не гарантировано.   -  person naveen    schedule 31.03.2013

Ответы (1)


arrow_upward
3
arrow_downward

Вы правы, что при большинстве переходов с 32-битной на 64-битную все эти указатели удваиваются в размере. Сама работа этого объединения вряд ли будет проблемой, но вам придется искать места, где он взаимодействует с другим кодом, через приведения типов, жестко заданные размеры и т. д.

person Carl Norum    schedule 31.03.2013
comment
Большую озабоченность вызывают такие вопросы, как порядок следования байтов и выравнивание слов, учитывая, что исходный код допускает некоторые вольности с вещами. - person Hot Licks; 31.03.2013
comment
Переход с 32-битной на 64-битную почти всегда означает Intel, не так ли? В этом случае ни порядок следования байтов, ни выравнивание, скорее всего, не будут проблемой. Может быть, какое-то заполнение структуры - но это не проблема для этого союза. - person Carl Norum; 31.03.2013
comment
@HotLicks - Какие вольности допускает исходный код? А откуда ты знаешь? - person user93353; 31.03.2013
comment
Я проверил весь код. Вместе с ним хранится переменная типа данных, в которой указывается, какой тип указателя хранится в объединении. Так что я предполагаю, что это нормально. Но есть один код, в котором он хранит указатель enum и обращается к нему с помощью указателя int. Меня беспокоит этот конкретный случай. Можете ли вы пролить свет на это. - person naveen; 31.03.2013
comment
@ user1699086, если предположить, что тип enum эквивалентен int, все будет в порядке. Это было бы проблемой и в исходном коде. - person Carl Norum; 31.03.2013
comment
Да. Это то, о чем я думал. Но так как ранее мы использовали gcc 2.8.*, который имел одинаковый размер для указателей enum и int, все было в порядке. Теперь мы переходим на gcc 4.4.* на RHEL 6 64 бит. Это имеет одинаковый размер для них. Но это может измениться, не так ли? - person naveen; 31.03.2013
comment
Стандарт C не требует, чтобы любые два типа указателей имели одинаковый размер. На практике все указатели на данной платформе почти всегда одинаковы. Есть некоторые исключения для некоторых чудаковатых микроконтроллеров с гарвардской архитектурой, но, вероятно, не в вашем случае. - person Carl Norum; 31.03.2013
comment
@CarlNorum - переход с 32 на 64 бит может быть от IBM 360 или DEC VAX к Intel или IBM Power. - person Hot Licks; 31.03.2013
comment
@user93353 user93353 - Использование такого объединения указывает на то, что программист был склонен быть умным с указателями и выравниваниями. Я программирую уже 40 лет, так что я узнаю умного, когда увижу это. Умный не обязательно плохой, но он может преподнести несколько сюрпризов. - person Hot Licks; 31.03.2013