Комментарии 51
Эх… Это ограничение на размер поста… В «предпросмотре» все хорошо. А здесь обрезается. И ведь главное немножко не влезает. Напишу в виде комментария.
Есть еще одна неприятная новость. Вам вряд ли удастся использовать инструменты, подобные BoundsChecker для поиска ошибок в ресурсоемких 64-битных программах, поглощающих большой объем памяти. Дела в колоссальном замедлении тестируемых программ, что делает такой подход крайне неудобным. Инструмент Parallel Inspector входящий в состав Intel Parallel Studio в режиме диагностики всех ошибок связанных с работой с памятью, замедлит скорость выполнения приложения в среднем в 100 раз (рисунок 10). Вполне есть вероятность, что тестируемый алгоритм, который работает 10 минут, придется оставлять на ночь и смотреть результаты работы только на следующий день. При этом я уверен, что Parallel Inspector в режиме поиска ошибок работы с памятью один из самых полезных и удобных инструментов. Просто надо быть готовым к изменению практики диагностики ошибок и закладывать это в планы освоения 64-битных систем.
Рисунок 10. Окно настроек программы Parallel Inspector перед запуском приложения.
Последнее. Не забудьте добавить тесты, проверяющие совместимость форматов данных между 32-битной и 64-битной версией. Совместимость данных при миграции достаточно часто нарушается из-за записи в файлы таких типов как size_t или long (в случае Linux систем).
Библиографический список
1. Wikipedia. 64-bit. http://www.viva64.com/go.php?url=203
2. Wikipedia. AMD64. http://www.viva64.com/go.php?url=204
3. Wikipedia. IA-64. http://www.viva64.com/go.php?url=205
4. Wikipedia. Itanium. http://www.viva64.com/go.php?url=206
5. Андрей Карпов. Забытые проблемы разработки 64-битных программ http://www.viva64.com/art-1-1-1609701563.html
6. Wikipedia. WOW64. http://www.viva64.com/go.php?url=207
7. Nick Hodges. The Future of the Delphi Compiler. http://www.viva64.com/go.php?url=208
8. Mike Becker. Accessing 32-bit DLLs from 64-bit code. http://www.viva64.com/go.php?url=209
9. Eric Palmer. How to use all of CPUID for x64 platforms under Microsoft Visual Studio .NET 2005. http://www.viva64.com/go.php?url=210
10. Андрей Карпов, Евгений Рыжков. Поиск ловушек в Си/Си++ коде при переносе приложений под 64-битную версию Windows. http://www.viva64.com/art-1-1-329725213.html
11. Андрей Карпов. 64 бита, /Wp64, Visual Studio 2008, Viva64 и все, все, все… http://www.viva64.com/art-1-1-253695945.html
12. Андрей Карпов, Евгений Рыжков. 20 ловушек переноса Си++ — кода на 64-битную платформу. http://www.viva64.com/art-1-1-1958348565.html
13. Евгений Рыжков. Viva64: что это и для кого? http://viva64.com/art-1-1-2081052208.html
14. Андрей Карпов. Сравнение диагностических возможностей анализаторов при проверке 64-битного кода. http://www.viva64.com/art-1-1-1441719613.html
Есть еще одна неприятная новость. Вам вряд ли удастся использовать инструменты, подобные BoundsChecker для поиска ошибок в ресурсоемких 64-битных программах, поглощающих большой объем памяти. Дела в колоссальном замедлении тестируемых программ, что делает такой подход крайне неудобным. Инструмент Parallel Inspector входящий в состав Intel Parallel Studio в режиме диагностики всех ошибок связанных с работой с памятью, замедлит скорость выполнения приложения в среднем в 100 раз (рисунок 10). Вполне есть вероятность, что тестируемый алгоритм, который работает 10 минут, придется оставлять на ночь и смотреть результаты работы только на следующий день. При этом я уверен, что Parallel Inspector в режиме поиска ошибок работы с памятью один из самых полезных и удобных инструментов. Просто надо быть готовым к изменению практики диагностики ошибок и закладывать это в планы освоения 64-битных систем.
Рисунок 10. Окно настроек программы Parallel Inspector перед запуском приложения.
Последнее. Не забудьте добавить тесты, проверяющие совместимость форматов данных между 32-битной и 64-битной версией. Совместимость данных при миграции достаточно часто нарушается из-за записи в файлы таких типов как size_t или long (в случае Linux систем).
Библиографический список
1. Wikipedia. 64-bit. http://www.viva64.com/go.php?url=203
2. Wikipedia. AMD64. http://www.viva64.com/go.php?url=204
3. Wikipedia. IA-64. http://www.viva64.com/go.php?url=205
4. Wikipedia. Itanium. http://www.viva64.com/go.php?url=206
5. Андрей Карпов. Забытые проблемы разработки 64-битных программ http://www.viva64.com/art-1-1-1609701563.html
6. Wikipedia. WOW64. http://www.viva64.com/go.php?url=207
7. Nick Hodges. The Future of the Delphi Compiler. http://www.viva64.com/go.php?url=208
8. Mike Becker. Accessing 32-bit DLLs from 64-bit code. http://www.viva64.com/go.php?url=209
9. Eric Palmer. How to use all of CPUID for x64 platforms under Microsoft Visual Studio .NET 2005. http://www.viva64.com/go.php?url=210
10. Андрей Карпов, Евгений Рыжков. Поиск ловушек в Си/Си++ коде при переносе приложений под 64-битную версию Windows. http://www.viva64.com/art-1-1-329725213.html
11. Андрей Карпов. 64 бита, /Wp64, Visual Studio 2008, Viva64 и все, все, все… http://www.viva64.com/art-1-1-253695945.html
12. Андрей Карпов, Евгений Рыжков. 20 ловушек переноса Си++ — кода на 64-битную платформу. http://www.viva64.com/art-1-1-1958348565.html
13. Евгений Рыжков. Viva64: что это и для кого? http://viva64.com/art-1-1-2081052208.html
14. Андрей Карпов. Сравнение диагностических возможностей анализаторов при проверке 64-битного кода. http://www.viva64.com/art-1-1-1441719613.html
Эпический пост, впрочем магически мой код обычно работал для x64 без изменений вообще…
Работоспособность кода на 64-битность системе зависит от множества факторов. Основные: возраст и размер проекта, объем потребляемой памяти. Отсюда и сильные вариации. От простой перекомпиляции до многих месяцев устранения ошибок.
мои игрушки перестали работать на 64 битных системах.
только потому, что используемая библиотека dx8vb.dll перестала поддерживаться мелкософтом, была выкинута из DirectX и хваленая мелкософтовская обратная совместимость оказалась мифом ((
сказать, что обидно это значит ничего не сказать — перетащить проекты из vb6 в vb2008 задача нетривиальная ((
только потому, что используемая библиотека dx8vb.dll перестала поддерживаться мелкософтом, была выкинута из DirectX и хваленая мелкософтовская обратная совместимость оказалась мифом ((
сказать, что обидно это значит ничего не сказать — перетащить проекты из vb6 в vb2008 задача нетривиальная ((
Когда-то в своё время наткнулся на ваши статьи на viva64, прочитал все с интересом, теперь есть возможность сказать «спасибо, понравилось» :)
Господи, как всё сложно то.
Кстати, вполне себе давно существует 64битный gcc под Win
sourceforge.net/projects/mingw-w64/files/
Ну и большинство ловушек, в общем то, оставили бедным людям на радость создатели winAPI((( У меня лично ни разу ещё не возникло проблем с перекомпиляцией кода под другие платформы.
Кстати, вполне себе давно существует 64битный gcc под Win
sourceforge.net/projects/mingw-w64/files/
Ну и большинство ловушек, в общем то, оставили бедным людям на радость создатели winAPI((( У меня лично ни разу ещё не возникло проблем с перекомпиляцией кода под другие платформы.
>убыстрит скорость
Вы и на c++ пишете также?
Вы и на c++ пишете также?
CWinApp? MFC?
По-моему, в этом случае переход на x86-64 отличный повод не мучаться, а просто переписать весь UI на чем-нибудь адекватном :)
По-моему, в этом случае переход на x86-64 отличный повод не мучаться, а просто переписать весь UI на чем-нибудь адекватном :)
Это совсем разные задачи. Одно дело — пересмотреть код на наличие «магических чисел» и проверить всякие сдвиги в памяти — и совсем другое дело переводить всю программу на «что-то адекватное». Трудозатраты могут отличаться в десятки раз. Высшее руководство на это не пойдет практически никогда.
Ну и обойдут эту компанию конкуренты, использующие новые подходы и технологии. Банально окажется, что они будут реализовывать необходимую функциональность за месяц, а ваша компания, со старым подходом, за полгода
Как, без сомнения, верно заметил уважаемый автор статьи, стоит заранее определиться с жизненным циклом приложения и целями, которые перед ним ставятся.
Есть целая пропасть вариантов от «давайте за два дня на коленке напишем что-нибудь, оно закроет наши текущие потребности и ладно» до «в этот продукт будут вложены миллионы и годы разработки с расчетом на то, что он станет флагманом в данной нише». Для каждого из этих (и всех промежуточных) вариантов есть свой оптимальный путь развития. Некоторые из них предполагают полный рефакторинг (и переход на х64), другие — нет.
Разговаривать о сферическом приложении в вакууме и как его верно было бы писать — глупо.
Есть целая пропасть вариантов от «давайте за два дня на коленке напишем что-нибудь, оно закроет наши текущие потребности и ладно» до «в этот продукт будут вложены миллионы и годы разработки с расчетом на то, что он станет флагманом в данной нише». Для каждого из этих (и всех промежуточных) вариантов есть свой оптимальный путь развития. Некоторые из них предполагают полный рефакторинг (и переход на х64), другие — нет.
Разговаривать о сферическом приложении в вакууме и как его верно было бы писать — глупо.
хм… а никто не говорил разве компаниям-разработчикам, что с++ далеко не тривиальный язык и пускать на нем писать можно не всех? :) за код, который Вы приводили в статье, убивать мало) или отпускать программировать на более простых языках — Java, C#, Basic и т.п., где такие ошибки допустить невозможно)
Когда программный проект делают два разработчика, то они почти всегда профессионалы.
Когда в проекте 10-20 разработчиков, то все новички под присмотром старших.
Когда в проекте 100 человек, то уровень людей настолько разный, что «пускать на нем писать не всех» просто нереально.
Когда в проекте 10-20 разработчиков, то все новички под присмотром старших.
Когда в проекте 100 человек, то уровень людей настолько разный, что «пускать на нем писать не всех» просто нереально.
Тогда убить придется сразу всех… :)
Вы зря считаете, что это удел только плохих программистов и кривых проектов. :) Пара примеров:
Проблемы 64-битного кода в реальных программах: FreeBSD
Проблемы 64-битного кода в реальных программах: виртуальные функции
Проблемы 64-битного кода в реальных программах: qsort
Вы зря считаете, что это удел только плохих программистов и кривых проектов. :) Пара примеров:
Проблемы 64-битного кода в реальных программах: FreeBSD
Проблемы 64-битного кода в реальных программах: виртуальные функции
Проблемы 64-битного кода в реальных программах: qsort
а кто сказал, что OpenSource свободен от некачественного кода и плохих программистов?)
и таки мне хочется надеяться что не всех и толковые программисты существуют :)
и таки мне хочется надеяться что не всех и толковые программисты существуют :)
Да открытость/закрытость таки же ничего не гарантируют, просто в открытом коде ошибки всем видны и есть надежда, что кто-то да и пришлет по доброте душевной патч, и иногда даже это на практике происходит. Конечно от кривой архитектуры это всё не спасет, но вот пользователи других платформ вполне могут указать на косяки с портируемостью, хотя бы потому, что заинтересованы получить рабочую версию приложения.
Ну и немаловажен тот факт, что opensource развивался в среде юниксоидов, а портируемость и переносимость это одна из основ Unix философии. То есть культура писать портируемый код гораздо более развита.
Ну и немаловажен тот факт, что opensource развивался в среде юниксоидов, а портируемость и переносимость это одна из основ Unix философии. То есть культура писать портируемый код гораздо более развита.
Когда-то, около года назад, мы переносили своё приложение на x64. Программа работала с мультимедиа (видео там, флеш и т.д.). Перенесли. А потом оказалось, что во-первых, ActiveX компонента флеша под 64-битную платформу не существует, а во-вторых, количество видео-кодеков, оптимизированных под x64 — ничтожно. Ну и все, на этом переход закончился. Решили на годик-другой отложить это дело. Рано еще.
То есть как нету? Есть amd64 сборка флеша, разве её не достаточно? И разве семейство кодеков ffmpeg не оптимизировано под amd64? Уже давно сижу практически на чисто 64 битной системе и проблем с декодированием видео не испытываю. Может не там искали?
хех… думается автор вышеизложенного поста таки имел в виду windows, а не gnu/linux :)
в свободной системе то понятно давно таких проблем нет, переход на 64 бита уже более-менее состоялся
в свободной системе то понятно давно таких проблем нет, переход на 64 бита уже более-менее состоялся
ну как это нет проблем, сколько лет x64-сборку флеша под линукс ждали? (свободные недоаналоги флеша в расчет не берем)
Дык кодеки то кроссплатформенные, ffmpeg входит в состав cccp, k-lite codec pack, вешаются в систему, как direct show фильтры. С лицензией тоже всё впорядке. LGPL вполне хорошо подходит и для проприетарных приложений.
А разве под винду так и не сделали 64 битную сборку флеша? Вроде же они клялись недавно, что теперь у них на всех платформах есть 64битный флеш.
А разве под винду так и не сделали 64 битную сборку флеша? Вроде же они клялись недавно, что теперь у них на всех платформах есть 64битный флеш.
>>код который работал вчера, неожиданно может перестать работать на следующий день
У меня такое случается сплошь и рядом, даже без перехода на х64. А когда найдёшь ошибку, не понимаешь, как с этой ошибкой приложение смогло отработать целый месяц в продакшн.
У меня такое случается сплошь и рядом, даже без перехода на х64. А когда найдёшь ошибку, не понимаешь, как с этой ошибкой приложение смогло отработать целый месяц в продакшн.
хотелось бы еще упомянуть функции с переменным числом аргументов — немало они моей крови попили.
Я не решился опубликовать здесь монстра — 20 ловушек переноса Си++ — кода на 64-битную платформу. Тем более эта статья 2007 года уже устарела. Мы теперь знаем куда больше ловушек. Недавно мы подготовили курс по разработке 64-битных приложений, где ошибки и способы их диагностики описаны гораздо полнее. Скоро представим публике.
Спасибо за статью, познавательно.
Боже мой, вы и досюда добрались…
Недавно искал информацию по теме — вот эти ваши чуть отличающиеся статьи, неявно рекламирующие Viva64, по всему интернету. На каждом мало мальски популярном форуме вы завели тему и скопировали туда эту статью.
Нет, я понимаю, это полезная статья, но не надо же столько спамить!
или совсем с продажами плохо?
Недавно искал информацию по теме — вот эти ваши чуть отличающиеся статьи, неявно рекламирующие Viva64, по всему интернету. На каждом мало мальски популярном форуме вы завели тему и скопировали туда эту статью.
Нет, я понимаю, это полезная статья, но не надо же столько спамить!
или совсем с продажами плохо?
что бы не быть голословным: www.google.ru/search?hl=ru&lr=&newwindow=1&q=64+bit+viva64&start=10&sa=N
Андрей Карпов добрался и до сюда.
Андрей Карпов добрался и до сюда.
Я Вам помогу :))))
www.google.ru/search?hl=ru&newwindow=1&q=64-bit+-viva64
www.google.ru/search?hl=ru&newwindow=1&q=64-bit+-viva64
я не про то, что не могу найти информацию, а про то, что вы ОЧЕНЬ много спаммите повсюду. по мне это не очень хорошая реклама, вообщем-то, неплохого софта.
но знаете, когда фирма дохзодит до того, тчо раздает бумажки у метро — определенный слой населения перестает пользоваться ее услугами. с вашим спамом так же.
но знаете, когда фирма дохзодит до того, тчо раздает бумажки у метро — определенный слой населения перестает пользоваться ее услугами. с вашим спамом так же.
>> вы ОЧЕНЬ много спаммите повсюду
Вы правда считаете, что лучше было бы не писать ни одной статьи, не упоминать инструмент нигде?
Именно таким способом — абсолютным молчанием — по Вашему продвигаются программные продукты?
Вы правда считаете, что лучше было бы не писать ни одной статьи, не упоминать инструмент нигде?
Именно таким способом — абсолютным молчанием — по Вашему продвигаются программные продукты?
нет, абсолютное молчание конечно не хорошо.
но не проще было в google adsense правильные ключевые слова назначить?
вот, почитайте пожалуйста: www.google.ru/search?hl=ru&source=hp&q=%D0%BD%D0%B0%D0%B2%D1%8F%D0%B7%D1%87%D0%B8%D0%B2%D0%B0%D1%8F+%D1%80%D0%B5%D0%BA%D0%BB%D0%B0%D0%BC%D0%B0&btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA+%D0%B2+Google&lr=&aq=f&oq=
но не проще было в google adsense правильные ключевые слова назначить?
вот, почитайте пожалуйста: www.google.ru/search?hl=ru&source=hp&q=%D0%BD%D0%B0%D0%B2%D1%8F%D0%B7%D1%87%D0%B8%D0%B2%D0%B0%D1%8F+%D1%80%D0%B5%D0%BA%D0%BB%D0%B0%D0%BC%D0%B0&btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA+%D0%B2+Google&lr=&aq=f&oq=
>> но не проще было в google adsense правильные ключевые слова назначить?
Нет.
У нас есть опыт с рекламой от Google, выводы из которого тянут на отдельную статью, но кратко изложу здесь.
В чем суть adwords? Это когда по ключевым словам в поиске показывается на первой странице рекламный текст. Но если по этим же ключевым словам есть возможность на той же первой странице показывать адекватные собственные статьи, которые реально интересны людям, то это работает ЗНАЧИТЕЛЬНО лучше adwords. Прежде всего потому, что человек прочитав статью запоминает ее. И когда через год-два ему надо будет вспомнить об этой теме, то он вспомнит. А adwords кто запоминает :-).
Так что мы сознательно после экспериментов отказались от adwords в пользу написания хороших (не «копирайтерских») статей по нашей теме.
И тот факт, что Вы нас «узнали», говорит о работоспособности идеи.
Ну а про «навязчивость» — коллега ниже ответил. Мало российских компаний софтовых, вот и выглядит навязчиво.
Нет.
У нас есть опыт с рекламой от Google, выводы из которого тянут на отдельную статью, но кратко изложу здесь.
В чем суть adwords? Это когда по ключевым словам в поиске показывается на первой странице рекламный текст. Но если по этим же ключевым словам есть возможность на той же первой странице показывать адекватные собственные статьи, которые реально интересны людям, то это работает ЗНАЧИТЕЛЬНО лучше adwords. Прежде всего потому, что человек прочитав статью запоминает ее. И когда через год-два ему надо будет вспомнить об этой теме, то он вспомнит. А adwords кто запоминает :-).
Так что мы сознательно после экспериментов отказались от adwords в пользу написания хороших (не «копирайтерских») статей по нашей теме.
И тот факт, что Вы нас «узнали», говорит о работоспособности идеи.
Ну а про «навязчивость» — коллега ниже ответил. Мало российских компаний софтовых, вот и выглядит навязчиво.
К сожалению, размещение статей сейчас является единственным эффективным методом рассказать разработчикам о том, что мы есть и что мы делаем. Эффективность контекстной рекламы, баннеров, прямого маркетинга в нашем случае крайне низкая. Дорогие виды продвижения нам сейчас недоступны.
Замечу, что на общем фоне мы не так уж выделяемся, если говорить об англоязычном интернете. Дело в том, что почти нет российских компаний, которые выпускают российские продукты в области программирования и пишут об этом на русском языке. В основном все статьи переводные. Вот и кажется, что нас МНОГО везде. ;)
Замечу, что на общем фоне мы не так уж выделяемся, если говорить об англоязычном интернете. Дело в том, что почти нет российских компаний, которые выпускают российские продукты в области программирования и пишут об этом на русском языке. В основном все статьи переводные. Вот и кажется, что нас МНОГО везде. ;)
>> Недавно искал информацию по теме — вот эти ваши чуть отличающиеся статьи, неявно рекламирующие Viva64.
Иногда и явно :-).
Статьи посвящены реальным проблемам и способам с ними справиться. Упоминание еще и инструмента — это «плата» читателя за то, что он нашел ответ на свой вопрос.
Используйте «доступность» авторов статей и инструмента с пользой. Задайте им интересующий вас (по теме) вопрос, попросите о новой функциональности. Ведь не всегда есть возможность влиять на развитие того или иного инструмента для программистов.
Иногда и явно :-).
Статьи посвящены реальным проблемам и способам с ними справиться. Упоминание еще и инструмента — это «плата» читателя за то, что он нашел ответ на свой вопрос.
Используйте «доступность» авторов статей и инструмента с пользой. Задайте им интересующий вас (по теме) вопрос, попросите о новой функциональности. Ведь не всегда есть возможность влиять на развитие того или иного инструмента для программистов.
Мы готовы и делаем совместные статьи! Если у Вас есть интересные идеи или просто интересные наблюдения, связанные с параллельностью или 64-битностью — пишите нам. Мы обсудим создание совместную статью. Мы живые, мы общаемся, мы прислушиваемся к людям! Мы не абстрактные разработчики и авторы, с которыми нет связи. Мы готовы к общению! Поддержите нас и не ругайте. :) Так сложно быть самостоятельным разработчиком программного обеспечения.
Где вы были неделю назад?! ;) Пришлось набить шишки самому, правда там был C++.NET.
Visual C++ не поддерживает 64-битный встроенный ассемблер. Может быть, это повод отказаться от Visual C++?
Че-то как-то все мрачно… А если у меня 200 мб исходников — мне все пересматривать?
Для «пересматривания» большого количества исходников есть инструменты, на навязчивую рекламу которых в комментариях выше жутко ругаются ;)
Хрен с рекламой, но реально — дает ли это пропиаренненое решение 100% уверенность, что все глюки отловлены? Или все равно глазами смотреть и через тесты гонять?
100% гарантию может дать только методология математического доказательства корректности программного кода. Этот вариант естественно не рассматриваем. Любой инструмент позволяет обнаружить часть программных ошибок.
Можно привести аналогию. Задача — выловить всю рыбу в пруду. Ручной метод — удочка. Инструментальный метод — большая сеть. Естественно сеть не даст гарантии, что выловлена вся рыба, но это явно лучше, чем удочка.
Инструменты статического анализа выявляют в программах те места, которые с большой вероятностью содержат ошибку. Пример кода, на который выдаст предупреждение статический анализатор, встроенный в Visual Studio Team System (ключ /analyze): «if (m_x < 10 && m_x < 10)» — слева и справа от && одинаковые выражения. Это пример диагностики, которая практически всегда выявляет ошибку. В другом случае, диагностика гораздо менее точна. Пример:
Имеется здесь 64-битная ошибка или нет, сказать сложно даже человеку. Ему необходимо знать с какими (маленькими или большими) массивами работает функция. Однако анализатор Viva64 предупредит об потенциальный ошибке и человек решит, стоит исправить int на size_t, отключить это диагностическое сообщение или указать в настройках, что программа не обрабатывает массивы более 2 гигабайт (Viva64 не будет считать этот код опасным).
И еще инструменты статического анализа часто выдают ложные срабатывания, предлагая обратить внимание на совершенно безобидный код.
Статический анализ не исключает просмотр человеком исходного кода. Но позволяет существенно сократить объем, необходимый для просмотра. Если прочитать 200 МБайт исходного кода почти нереальная задача (внимание быстро рассеивается и эффективность чтения очень низкая), то используя статический анализ можно просмотреть почти все места, потенциально содержащие 64-битные ошибки за несколько дней. Да, не все места, но почти все.
Программа ВСЕГДА содержит ошибки. Задача свести какой-то класс ошибок к разумному минимуму. Будь то ошибки GUI, ошибки, приводящие к замедлению или не освобождения памяти. Нет смысла стараться вывести все 64-битные ошибки, оставив тысячи обыкновенных. :) Звучит несколько необычно, но думаю Вы согласитесь. :)
Вывод – 100% уверенности от использования Viva64 нет. Но очень близко. И еще мы плотно работаем с клиентами и быстро реализуем их пожелания по диагностике и интерфейсу инструмента.
Можно привести аналогию. Задача — выловить всю рыбу в пруду. Ручной метод — удочка. Инструментальный метод — большая сеть. Естественно сеть не даст гарантии, что выловлена вся рыба, но это явно лучше, чем удочка.
Инструменты статического анализа выявляют в программах те места, которые с большой вероятностью содержат ошибку. Пример кода, на который выдаст предупреждение статический анализатор, встроенный в Visual Studio Team System (ключ /analyze): «if (m_x < 10 && m_x < 10)» — слева и справа от && одинаковые выражения. Это пример диагностики, которая практически всегда выявляет ошибку. В другом случае, диагностика гораздо менее точна. Пример:
void Foo(char *array, size_t size) {
for (int i = 0; i < size; ++i)
array[i] = 'A';
}Имеется здесь 64-битная ошибка или нет, сказать сложно даже человеку. Ему необходимо знать с какими (маленькими или большими) массивами работает функция. Однако анализатор Viva64 предупредит об потенциальный ошибке и человек решит, стоит исправить int на size_t, отключить это диагностическое сообщение или указать в настройках, что программа не обрабатывает массивы более 2 гигабайт (Viva64 не будет считать этот код опасным).
И еще инструменты статического анализа часто выдают ложные срабатывания, предлагая обратить внимание на совершенно безобидный код.
Статический анализ не исключает просмотр человеком исходного кода. Но позволяет существенно сократить объем, необходимый для просмотра. Если прочитать 200 МБайт исходного кода почти нереальная задача (внимание быстро рассеивается и эффективность чтения очень низкая), то используя статический анализ можно просмотреть почти все места, потенциально содержащие 64-битные ошибки за несколько дней. Да, не все места, но почти все.
Программа ВСЕГДА содержит ошибки. Задача свести какой-то класс ошибок к разумному минимуму. Будь то ошибки GUI, ошибки, приводящие к замедлению или не освобождения памяти. Нет смысла стараться вывести все 64-битные ошибки, оставив тысячи обыкновенных. :) Звучит несколько необычно, но думаю Вы согласитесь. :)
Вывод – 100% уверенности от использования Viva64 нет. Но очень близко. И еще мы плотно работаем с клиентами и быстро реализуем их пожелания по диагностике и интерфейсу инструмента.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
7 шагов по переносу программы на 64-битную систему