Проблемы компиляции для миграции с VC6 на VC9 - PullRequest
1 голос
/ 30 августа 2010

Я портирую устаревшую систему C ++ с VC6 на VC9.

Приложение (<APP A>) статически связывается с внутренним приложением <APP B> (разработано на месте, но отдельной командой). Локальная копия заголовочных файлов из <APP B> включена в файлы CPP и скомпилирована в <APP A>.

В настоящее время мы не планируем переход <APP B> на VC9. Хотя и <APP A>, и <APP B> будут использовать отдельные ЭЛТ, но никакого конфликта не ожидается.

Проблема, с которой мы сталкиваемся, заключается в том, что включаемые файлы (из локальной копии) не компилируются с VC9.

фатальная ошибка C1083: невозможно открыть, включить file: 'iostream.h': такого файла нет или каталог

Возможные решения: Если я внесу изменения в локальную копию <APP A> и скомпилирую с VC9, то я не уверен, что это может вызвать проблемы во время выполнения.

Есть ли другой способ попросить VC9 скомпилировать файлы <APP A> с <iostream.h> вместо <iostream>?

Ответы [ 3 ]

4 голосов
/ 30 августа 2010

Извините, но у вас множество проблем.

Сначала основы: <iostream.h> - более старый заголовок Microsoft, который использовался для определения, например, ::cout.<iostream> является стандартным заголовком и определяет, например, std::cout.Вы можете использовать оба из них, но этот заголовок должен , а не быть включен в APP.H.<iostream> не определяет типы, которые вы будете использовать в объявлениях.Предположительно, вы полагаетесь на артефакт реализации VC6, а именно на то, что <iostream.h> использует <istream.h> и <ostream.h>.Вы можете вместо этого переключиться на <iosfwd>, что равно , предназначенному для использования в заголовках.

Однако большая проблема заключается в том, что вы предполагаете, что вы можете просто связать "APP A" и APPB "вместе, даже если они скомпилированы с VC6 и VC9. Это верно тогда и только тогда, когда они разделяют extern "C" API. Перенос имен C ++ (намеренно) различается между ними. И поскольку вы упомянули<iostream.h> вместо <stdio.h>, я собираюсь предположить, что ваше общее на самом деле - C ++.

1 голос
/ 30 августа 2010

Я сомневаюсь, что эта ошибка компилятора будет единственной проблемой.Обновление компилятора почти всегда приводит к небольшому количеству проблем.Лучше всего разрешить эти конфликты и серьезно проверить результат.Я не думаю, что некоторые «обходные пути» создадут меньше проблем, поскольку компилятор в любом случае будет другим.

Единственным решением для решения таких проблем при параллельном использовании различных компиляторов является условная компиляция, например:

#if _MSC_VER >= 1200 
   // Code for VC 6.0 or higher goes here
#endif

Имейте в виду, что число _MSC_VER отличается от номера версии Visual Studio.Для Visual Studio 2010, т.е. _MSC_VER определяется как 1600.

1 голос
/ 30 августа 2010

Существует замечательная книга Майкла Фезерса http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052, об этом типе проекта.

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

Без тестов у вас немного больше проблем, вам придется либо написать их, либо молиться, чтобы вы ничего не сломали

...