Комментарии 22
>на языках Си/Си++
простите, но, как серпом по яйцам…
простите, но, как серпом по яйцам…
Если Вы имеете ввиду ограничение языков (Си и Си++), то оно совершенно естественно. Вот график:
Этот график показывает сложность 64-битной миграции для разного типа кода по сравнению с ассемблером, в процентах. 100% на нем означает что код надо полностью переписать, 0% — что трогать вообще ничего не надо.
Как видно, для C++ эта сложность максимальная. Так что проблема 64-битной миграции для Си и Си++ стоит наиболее остро.
График составлен по данным Kang Su Gatlin, Visual C++ Program Manager, Microsoft Corporation в 2004 году.
Этот график показывает сложность 64-битной миграции для разного типа кода по сравнению с ассемблером, в процентах. 100% на нем означает что код надо полностью переписать, 0% — что трогать вообще ничего не надо.
Как видно, для C++ эта сложность максимальная. Так что проблема 64-битной миграции для Си и Си++ стоит наиболее остро.
График составлен по данным Kang Su Gatlin, Visual C++ Program Manager, Microsoft Corporation в 2004 году.
нет, я имею в виду написание, это как C# написать СиШарп
ЗЫ откуда 10% в Pure Managed?
ЗЫ откуда 10% в Pure Managed?
>> откуда 10% в Pure Managed?
Из практики переноса разумеется. Это же только в теории все гладко.
Из практики переноса разумеется. Это же только в теории все гладко.
вот, как раз сейчас будем переходить на 64бит, соответственно интересует, какие могут быть грабли
Для начала можно начать c нашей статьи на Хабре:
7 шагов по переносу программы на 64-битную систему
А затем приглашаю в раздел ресурсов на нашем сайте где имеются наши статьи по разработке 64-битных приложений, обзоры сторонних статей, блог по тематике 64-битного программирования и так далее. Примеры статей:
20 ловушек переноса Си++ — кода на 64-битную платформу
Как оценить процесс 64-битной миграции Си/Си++ приложений?
Архитектура AMD64 (EM64T)
64-битный конь, который умеет считать
Что такое size_t и ptrdiff_t
Оптимизация 64-битных программ
7 шагов по переносу программы на 64-битную систему
А затем приглашаю в раздел ресурсов на нашем сайте где имеются наши статьи по разработке 64-битных приложений, обзоры сторонних статей, блог по тематике 64-битного программирования и так далее. Примеры статей:
20 ловушек переноса Си++ — кода на 64-битную платформу
Как оценить процесс 64-битной миграции Си/Си++ приложений?
Архитектура AMD64 (EM64T)
64-битный конь, который умеет считать
Что такое size_t и ptrdiff_t
Оптимизация 64-битных программ
=), к сожалению автор комментария имел ввиду всего лишь претензии н написанию названия языка «С/С++» а не «Си/Си++»…
насколько быстро ваш продукт помогает мигрировать на 64-битную платформу при разовом переходе? ведь из-за времени на изучение принципов работы может потом не оправдать сроки, или вы позиционируетесь исключительно на крупных клиентах, которые будут пользоваться вашим продуктом регулярно?
насколько быстро ваш продукт помогает мигрировать на 64-битную платформу при разовом переходе? ведь из-за времени на изучение принципов работы может потом не оправдать сроки, или вы позиционируетесь исключительно на крупных клиентах, которые будут пользоваться вашим продуктом регулярно?
На вопрос по срокам (на сколько быстро) ответить сложно вот почему. Если есть средний проект, то скомпилировать его можно, к примеру, за неделю. Но потом в течение года выявлять с помощью пользователей дефекты. С использованием нашего инструмента этот годовой срок можно ЗНАЧИТЕЛЬНО сократить :-).
Действительно мы ориентируемся на средние и крупные проекты, поскольку для мелких проектов не так актуален поиск неочевидных проблем. Вернее они более быстро себя проявляют, а авторы представляют, где в проекте можно ожидать возникновение 64-битных ошибок. Где будут скрываться ошибки в больших проектах никто предсказать не в состоянии.
Но в любом случае мы рекомендуем использовать инструмент постоянно (и у нас есть технические возможности для облегчения этого), чтобы после миграции программисты не допускали новых 64-битных ошибок.
Затраты на изучение принципов работы конечно же есть (как и с любым инструментом), но их можно сократить. Вариант использования может быть такой. Сначала несколько профессиональных программистов в проекте разбираются с инструментом, затем исправляют основные обнаруженные в коде проблемы. После чего инструмент устанавливается на машины всех разработчиков и при запуске обнаруживает проблемы только в новом коде, написанном этим разработчиком. Соответственно разработчик может уже не сильно вникать в проблему, а просто исправить код по рекомендации инструмента (есть хорошая справка на русском и английском).
То есть регулярное использование инструмента актуально не только, к примеру, аутсорсинговым компаниям, которые постоянно переносят разные проекты на 64-битные системы, но и «компаниям одного проекта», для которой важна работоспособность 64-битной версии приложения.
Действительно мы ориентируемся на средние и крупные проекты, поскольку для мелких проектов не так актуален поиск неочевидных проблем. Вернее они более быстро себя проявляют, а авторы представляют, где в проекте можно ожидать возникновение 64-битных ошибок. Где будут скрываться ошибки в больших проектах никто предсказать не в состоянии.
Но в любом случае мы рекомендуем использовать инструмент постоянно (и у нас есть технические возможности для облегчения этого), чтобы после миграции программисты не допускали новых 64-битных ошибок.
Затраты на изучение принципов работы конечно же есть (как и с любым инструментом), но их можно сократить. Вариант использования может быть такой. Сначала несколько профессиональных программистов в проекте разбираются с инструментом, затем исправляют основные обнаруженные в коде проблемы. После чего инструмент устанавливается на машины всех разработчиков и при запуске обнаруживает проблемы только в новом коде, написанном этим разработчиком. Соответственно разработчик может уже не сильно вникать в проблему, а просто исправить код по рекомендации инструмента (есть хорошая справка на русском и английском).
То есть регулярное использование инструмента актуально не только, к примеру, аутсорсинговым компаниям, которые постоянно переносят разные проекты на 64-битные системы, но и «компаниям одного проекта», для которой важна работоспособность 64-битной версии приложения.
спасибо за развернутый ответ, а есть какие то ограничения в shareware версии, или базовый функционал присутствует? интересно в работе попробовать продукт
Ограничение не принципиальное. Все ошибки обнаруживаются, но часть номеров ошибок скрыта.
Кроме того, в дистрибутиве идет демонстрационный пример на котором этого ограничения нет.
В отличие от других анализаторов кода наш продукт легко скачать (доступно с сайта без предварительной регистрации), легко попробовать (не надо выпрашивать демо-версию, как у других) и даже легко купить :-). Пробуйте:
www.viva64.com/ru/pvs-studio/download/
Обязательно напишите нам в поддержку через форму связи на сайте — пообщаемся.
Кроме того, в дистрибутиве идет демонстрационный пример на котором этого ограничения нет.
В отличие от других анализаторов кода наш продукт легко скачать (доступно с сайта без предварительной регистрации), легко попробовать (не надо выпрашивать демо-версию, как у других) и даже легко купить :-). Пробуйте:
www.viva64.com/ru/pvs-studio/download/
Обязательно напишите нам в поддержку через форму связи на сайте — пообщаемся.
А зачем вы отметили, что Тула в двухстах километрах от Москвы?
Я один заметил ужасный дизайн времен Windows 98? Ау, 2010-ый год на дворе. Или это олдскул?
Вы про какой дизайн? Конкретнее, пожалуйста :-).
Дизайн логотипа. Я понимаю: программа — программой. Уйма времени. Но, неужели это так не важно для вас, чтобы не уделить внимание одному из того, что кидается сразу в глаза и будет кидаться каждый раз при загрузке, например? Это же лицо. А так логотип напоминает эмблему электротехнического факультета времен 1998-ого года. И вот эта желтая картинка «Ресурсы»… PowerPoint и клипарт? Оригинально.
Дизайн логотипа — какой уж сделал дизайнер, тут на вкус и цвет… С FedEx (какой хвалили в недавнем посте) нам тягаться в любом случае вряд ли удастся.
Ну а про желтую картинку — с замечанием согласен, дизайнер ее уже делает (как и другие картинки на сайте, как и новый дизайн сайта). Но не хотелось только из-за этого откладывать пост.
Ну а про желтую картинку — с замечанием согласен, дизайнер ее уже делает (как и другие картинки на сайте, как и новый дизайн сайта). Но не хотелось только из-за этого откладывать пост.
зачем интструменту, ориентированному на программистов… завихрюшки и всплывающие окошки? суть в том чтоб выявлять ошибки в проекте… а не смотреть как все красиво.учитывайте целевую аудиторию.
Не могу удержаться. Вы, например, сайт Abraxas Software и Gimpel Software не видели. Они тоже инструменты статического анализа делают. И живут успешнее многих. :) Так что дизайн конечно важен, но часто далеко не основное. :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Анализаторы кода PVS-Studio — российский технологический стартап