Есть тонны незнакомого мне кода для 32-битной платформы.
Моя задача сейчас дать эстимации сколько времени потребуется на портирование этого кода на 64 бита.

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

Здравствуйте, Аноним, Вы писали:

А>Есть тонны незнакомого мне кода для 32-битной платформы.
А>Моя задача сейчас дать эстимации сколько времени потребуется на портирование этого кода на 64 бита.

А>С тонкостями самого портирования уже ознакомился, а вот как делать эстимации пока не ясно.
А>Идеи? рукомендации? ссылки?

"Задача"?! Непрофессионально. Таск
"Портирование"?! Вероятно, имелся в виду портинг

"Эстимации" — дааа, возьму на вооружение.

A>"Эстимации" — дааа, возьму на вооружение.
неделя-две — чтоб "заработало"
если наше понятия "тонны" совпадает
отлов багов будет продолжаться месяц-два.

Здравствуйте, Аноним, Вы писали:

A>>"Эстимации" — дааа, возьму на вооружение.
А>неделя-две — чтоб "заработало"
А>если наше понятия "тонны" совпадает
А>отлов багов будет продолжаться месяц-два.

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

Возможно не все проекты нуждаются в портировании, но заранее я утверждать не могу.

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

Пересчитать количество ворнингов компилера — этого явно недостаточно, т.к. есть C-Style касты к какому нибудь int или long, сдвиговые операции, касты поинтеров к числам и назад и куча других подводных камней, которые компилятор может и не выловить (даже с включеными 64-bit porting warning'ами).

Могу предложить несколько вариантов по оценке сложности миграции кода на 64-битную систему:

1. Обратиться к нам в ООО "Системы программной верификации". Мы не только можем выполнить оценку сложности миграции, но и профессионально осуществить саму миграцию кода. (См. раздел услуги)
   
2. Купить PVS-Studio (Viva64). Во-первых, на основе того, что выдаст анализатор – можно предположить объем работ (мы поможем). Во вторых более быстро и качественно осуществить переход.
   
3. Можно не купить PVS-Studio, но все-таки оценить объем работ. Можно скачать демонстрационную версию PVS-Studio и запустить ее на Вашем проекте. В результате по количеству сообщений и их типу определить, как много работы предстоит. Анализатор в демонстрационном режиме обнаруживает все ошибки, но выдает в диагностических сообщениях номера строк только для некоторых из них. Для оценки объема работ это не принципиально.
   
4. Мы можем плотно с Вами пообщаться и предоставить вам наш прототип программы для оценки сложности переноса кода на 64-битную систему. Использовать его сам по себе пока нельзя, но вместе мы сможем что-то посчитать, а заодно усовершенствовать модель оценки. (смотри запись в блоге "Первые наши практические исследования в области расчета метрик")
   
5. А вообще Вам напрямую к нам — http://www.viva64.com/ru/main/. Пишите в support – пообщаемся.

С уважением, Андрей Карпов
к.ф.-м.н., Технический директор
ООО "Системы программной верификации"
Сайт: www.viva64.com
E-Mail: karpov@viva64.com
Тел.: +7 (4872) 38-59-95 (GMT + 03:00)

А>Пересчитать количество ворнингов компилера — этого явно недостаточно, т.к. есть C-Style касты к какому нибудь int или long, сдвиговые операции, касты поинтеров к числам и назад и куча других подводных камней, которые компилятор может и не выловить (даже с включеными 64-bit porting warning'ами).

Для этого в PVS-Studio есть специальный ражим, позволяющий обнаруживать явные потенциально опасные приведения типов. При этом обнаруживаются именно опасные с точки зрения 64-битности, а не все подряд. Таким образом, можно найти:

void foo(int a);
size_t n;
foo(int(n));

но не обращать внимания, на безопасные конструкции с точки зрения 64-битности:

void foo(int a);
float n;
foo(int(n));

Здравствуйте, Аноним, Вы писали:

Интересно, проект случайно не связан со сферой мультимедия?

P.S.
Совсем забыл. У меня в блоге есть специальная заметка на эту тему: Поиск ошибок явного приведения типа в 64-битных программах.

Здравствуйте, Аноним, Вы писали:

А>Есть тонны незнакомого мне кода для 32-битной платформы.
А>Моя задача сейчас дать эстимации сколько времени потребуется на портирование этого кода на 64 бита.

Очень зависит от качества самого кода. Мы спортировали довольно большой проект (больше 150К строк, точнее лень считать) за один день. Всего-то понадобилось дописать несколько недостающих низкоуровневых функций и исправить пару ошибок. Но мы-то с самого начала думали о том, как наш код будет работать на разных платформах, а если код написан неаккуратно, в худшем случае его будет проще выкинуть и переписать заново.

Здравствуйте, Аноним, Вы писали:

А>Мой вопрос был в том, какую методику можно использовать для оценки времени необходимого для портирования.

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

Здравствуйте, Analytic2007, Вы писали:

A>Могу предложить несколько вариантов по оценке сложности миграции кода на 64-битную систему:
A>

A>
1. Обратиться к нам в ООО "Системы программной верификации". Мы не только можем выполнить оценку сложности миграции, но и профессионально осуществить саму миграцию кода. (См. раздел услуги)
   A>
2. Купить PVS-Studio (Viva64). Во-первых, на основе того, что выдаст анализатор – можно предположить объем работ (мы поможем). Во вторых более быстро и качественно осуществить переход.
   A>
3. Можно не купить PVS-Studio, но все-таки оценить объем работ. Можно скачать демонстрационную версию PVS-Studio и запустить ее на Вашем проекте. В результате по количеству сообщений и их типу определить, как много работы предстоит. Анализатор в демонстрационном режиме обнаруживает все ошибки, но выдает в диагностических сообщениях номера строк только для некоторых из них. Для оценки объема работ это не принципиально.
   A>
4. Мы можем плотно с Вами пообщаться и предоставить вам наш прототип программы для оценки сложности переноса кода на 64-битную систему. Использовать его сам по себе пока нельзя, но вместе мы сможем что-то посчитать, а заодно усовершенствовать модель оценки. (смотри запись в блоге "Первые наши практические исследования в области расчета метрик")
   A>
5. А вообще Вам напрямую к нам — http://www.viva64.com/ru/main/. Пишите в support – пообщаемся.
   A>

Большое спасибо за тул.
Весьма полезно, хотя иногда и промахивается.
Миграцию кода будем делать мы — собственно за это нам деньги и платят.

Кстати, оказалось, что начальство уже в процессе покупки нескольких лицензий, так что до встречи в суппорте

А>Большое спасибо за тул.
А>Весьма полезно, хотя иногда и промахивается.
А>Миграцию кода будем делать мы — собственно за это нам деньги и платят.
Пишите нам и вместе сделаем, чтобы не промахивался.

А>Кстати, оказалось, что начальство уже в процессе покупки нескольких лицензий, так что до встречи в суппорте
Предлагаю написать мне в личный ящик karpov@viva64.com. Пока поговорим о том, что промахиается и чего не хватает и так далее. Да и прогонят нас отсюда.

С уважением, Андрей Карпов
к.ф.-м.н., Технический директор
ООО "Системы программной верификации"
Сайт: www.viva64.com
E-Mail: karpov@viva64.com
Тел.: +7 (4872) 38-59-95 (GMT + 03:00)

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Аноним, Вы писали:

А>>Есть тонны незнакомого мне кода для 32-битной платформы.
А>>Моя задача сейчас дать эстимации сколько времени потребуется на портирование этого кода на 64 бита.

Pzz>Очень зависит от качества самого кода. Мы спортировали довольно большой проект (больше 150К строк, точнее лень считать) за один день. Всего-то понадобилось дописать несколько недостающих низкоуровневых функций и исправить пару ошибок. Но мы-то с самого начала думали о том, как наш код будет работать на разных платформах, а если код написан неаккуратно, в худшем случае его будет проще выкинуть и переписать заново.

Платформенно-зависимые вещи спускать на самый нижний уровень или хотябы в отдельный namespace, но все переписывать это перебор

Здравствуйте, Аноним, Вы писали:

А>Платформенно-зависимые вещи спускать на самый нижний уровень или хотябы в отдельный namespace, но все переписывать это перебор

Если у вас по всему коду пытаются засовывать поинтеры в переменные типа int, и это размазанно тонким слоем, у вас не останется особого выбора, кроме как выкинуть все это нахрен

Здравствуйте, Аноним, Вы писали:

А>Есть тонны незнакомого мне кода для 32-битной платформы.
А>Моя задача сейчас дать эстимации сколько времени потребуется на портирование этого кода на 64 бита.

А>С тонкостями самого портирования уже ознакомился, а вот как делать эстимации пока не ясно.
А>Идеи? рукомендации? ссылки?

Если совсем непонятно с чего браться, то можно пройтись по коду имея в виду следующее (MSDN):

Common Visual C++ 64-bit Migration Issues  

When you use Visual C++ to create applications to run on a 64-bit Windows operating system, you should be 
aware of the following issues:

An int and a long are 32-bit values on 64-bit Windows operating systems. For programs that you plan to compile 
for 64-bit platforms, you should be careful not to assign pointers to 32-bit variables. Pointers are 64-bit on 
64-bit platforms, and you will truncate the pointer value if you assign it to a 32-bit variable.
size_t, time_t, and ptrdiff_t are 64-bit values on 64-bit Windows operating systems.
time_t is a 32-bit value on 32-bit Windows operating systems in Visual C++ versions before Visual C++ 2005. 

In Visual C++ 2005 and later, time_t is a 64-bit integer by default. For more information, see Time Management.
You should be aware of where your code takes an int value and processes it as a size_t or time_t value. It is 
possible that the number could grow to be larger than a 32-bit number and data will be truncated when it is passed 
back to the int storage.

The %x (hex int format) printf modifier will not work as expected on a 64-bit Windows operating system. 
It will only operate on the first 32 bits of the value that is passed to it.
Use %I32x to display an integer on a Windows 32-bit operating system.
Use %I64x to display an integer on a Windows 64-bit operating system.
The %p (hex format for a pointer) will work as expected on a 64-bit Windows operating system.

For more information, see:

Compiler Options 

/Wp64 

__w64

Найти здесь:
http://msdn.microsoft.com/en-us/library/3b2e7499(VS.80).aspx

A>Common Visual C++ 64-bit Migration Issues

Это, к сожалению, капля в море.
(и /Wp64 в частности, вообще серьезно воспринимать не стоит)

Для тех, кто хочет узнать побольше, как всегда приглашаю в раздел наших статей по тематике 64-бит и коллекции ссылок. Например, предлагаю следующие статьи:

1. 7 шагов по переносу программы на 64-битную систему
   
2. 20 ловушек переноса Си++ — кода на 64-битную платформу
   
3. 64 бита, /Wp64, Visual Studio 2008, Viva64 и все, все, все...
   
4. Оптимизация 64-битных программ
   
5. 64-битный конь, который умеет считать
   
6. Безопасность 64-битного кода

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Аноним, Вы писали:

А>>Платформенно-зависимые вещи спускать на самый нижний уровень или хотябы в отдельный namespace, но все переписывать это перебор

Pzz>Если у вас по всему коду пытаются засовывать поинтеры в переменные типа int, и это размазанно тонким слоем, у вас не останется особого выбора, кроме как выкинуть все это нахрен

Это еще мелочи, как то встречал что указатели с одной inproc dll передавали в другую через базу данных Вот это полет мысли

Здравствуйте, Аноним, Вы писали:

А>Это еще мелочи, как то встречал что указатели с одной inproc dll передавали в другую через базу данных Вот это полет мысли

Спасибо, хоть в HTTP-ные куки не засовывали