Привет всем!

Есть большой проект, написанный на C++ в Visual Studio 2003.
В проект пришли новые разработчики, которые говорят, что 2003 студия их не устраивает. (2005 стабильнее и удобнее. Компилятор C++ в 2005 также лучше чем в 2003).
Вопрос в том, насколько будет безопасным переход на 2005 студию.
Я уверен, что во время перехода на VS2005 мы получим какое-то количество ошибок от компилятора.
Но насколько велика вероятность того, что мы получим ошибки в Runtime.

Заранее спасибо за ваши ответы.

Lonely Dog пишет:

> Вопрос в том, насколько будет безопасным переход на 2005 студию.

Хочу об одной пакости предупредить. Там какая-то проблема с линкером
была, заключалась в очень медленной его работе при каких-то условиях.
Поищи в сети на эту тему, там есть даже официально зарегистрированная
проблема в MS.

> Я уверен, что во время перехода на VS2005 мы получим какое-то количество
> ошибок от компилятора.

Да, 2005 — более стандартный. Но вашему коду это будет только на пользу.

> Но насколько велика вероятность того, что мы получим ошибки в Runtime.

Думаю, это здесь вообще ни при чем.

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

LD>Есть большой проект, написанный на C++ в Visual Studio 2003.
LD>Вопрос в том, насколько будет безопасным переход на 2005 студию.
LD>Я уверен, что во время перехода на VS2005 мы получим какое-то количество ошибок от компилятора.
LD>Но насколько велика вероятность того, что мы получим ошибки в Runtime.

Переходили на 2005SP1 С++ проект

Были проблемы с неработоспособностью EXEшника — линкер собирал некорректный EXE
IDE более кривое по сравнению с 2003. Впрочем это субъективно, но у нас многим не понравилось. ИМХО 2003 пошустрее и поудобнее.
deprecated самодеятельность от M$ — паубывау бы
в проекте была тьма проблем, компилер 2005й старый код переваривал плохо, приходилось делать косметические правки кода чтоб его заткнуть

LD>В проект пришли новые разработчики, которые говорят, что 2003 студия их не устраивает. (2005 стабильнее и удобнее. Компилятор C++ в 2005 также лучше чем в 2003).
"Нравится больше" — это не аргумент для перевода проекта. Мало ли что их не устраивает. Мне например вообще VC6 среда + ICC больше нравилась — она быстрее да и ICC лучший код генерит. Так что, приду я к вам и вы весь проект под VC6 и ICC будете переводить?
Скоро еще и 2007 выйдет — опять аврал и переезд кода будет?
Кроме того, а что будете делать со старыми разработчиками которых 2003 устраивает?

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

MZ>Хочу об одной пакости предупредить. Там какая-то проблема с линкером
MZ>была, заключалась в очень медленной его работе при каких-то условиях.
MZ>Поищи в сети на эту тему, там есть даже официально зарегистрированная
MZ>проблема в MS.
Угу, спасибо.

MZ>Да, 2005 — более стандартный. Но вашему коду это будет только на пользу.
Кто бы спорил. Конечно это плюс.

>> Но насколько велика вероятность того, что мы получим ошибки в Runtime.

MZ>Думаю, это здесь вообще ни при чем.
А вот здесь не согласен. Например, насколько я знаю, в 2005 новую версию msvcrt.dll нельзя просто скопировать на машину. Нужно ставить через MSI. Опять же, все эти deprecated фичи.

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


CC>Были проблемы с неработоспособностью EXEшника — линкер собирал некорректный EXE
Угу, спасибо.

CC>IDE более кривое по сравнению с 2003. Впрочем это субъективно, но у нас многим не понравилось. ИМХО 2003 пошустрее и поудобнее.
У нас народ говорит, что 2005 удобнее и стабильнее. в VS2003 отладчик у них зависает раз 10 в день.

CC>deprecated самодеятельность от M$ — паубывау бы
Это ведь можно и отключить.

CC>в проекте была тьма проблем, компилер 2005й старый код переваривал плохо, приходилось делать косметические правки кода чтоб его заткнуть
Это не проблема.

CC>"Нравится больше" — это не аргумент для перевода проекта. Мало ли что их не устраивает. Мне например вообще VC6 среда + ICC больше нравилась — она быстрее да и ICC лучший код генерит. Так что, приду я к вам и вы весь проект под VC6 и ICC будете переводить?
CC>Скоро еще и 2007 выйдет — опять аврал и переезд кода будет?
CC>Кроме того, а что будете делать со старыми разработчиками которых 2003 устраивает?
Старые тоже не против.
Пока протестую я, т.к. не очень понимаю, к чему этот переход может привести.

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

LD>насколько я знаю, в 2005 новую версию msvcrt.dll нельзя просто скопировать на машину. Нужно ставить через MSI. Опять же, все эти deprecated фичи.

Совсем не обязательно — можно в манифест соответствующие зависимости добавить и рядом с собой положить. Посмотрите исходники Programmer’s Notepad, он как раз рядом с собой кладет и MSI не использует.

Если лень качать и смотреть, то:

#pragma comment(linker, "\"/manifestdependency:type='Win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='X86' publicKeyToken='1fc8b3b9a1e18e3b' language='*'\"")

А лежит все вот так:

C:\Program Files\Programmer's Notepad:

clips
Microsoft.VC80.CRT
schemes
taggers
credits.txt
ctags.exe
ctags_COPYING
ctags_README
dbghelp.dll
libexpat.dll
license.html
license.txt
pcre-license.txt
pn.exe
pn2.chm
pnse.dll
readme.txt
roadmap.txt
SciLexer.dll
unins000.dat
unins000.exe

...

C:\Program Files\Programmer's Notepad\Microsoft.VC80.CRT:

Microsoft.VC80.CRT.manifest
msvcm80.dll
msvcp80.dll
msvcr80.dll

где Microsoft.VC80.CRT.manifest это:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <noInheritable></noInheritable>
    <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    <file name="msvcr80.dll" hash="10f4cb2831f1e9288a73387a8734a8b604e5beaa" hashalg="SHA1"><asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:Transforms><dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity"></dsig:Transform></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></dsig:DigestMethod><dsig:DigestValue>n9On8FItNsK/DmT8UQxu6jYDtWQ=</dsig:DigestValue></asmv2:hash></file>
    <file name="msvcp80.dll" hash="b2082dfd3009365c5b287448dcb3b4e2158a6d26" hashalg="SHA1"><asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:Transforms><dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity"></dsig:Transform></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></dsig:DigestMethod><dsig:DigestValue>0KJ/VTwP4OUHx98HlIW2AdW1kuY=</dsig:DigestValue></asmv2:hash></file>
    <file name="msvcm80.dll" hash="542490d0fcf8615c46d0ca487033ccaeb3941f0b" hashalg="SHA1"><asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:Transforms><dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity"></dsig:Transform></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></dsig:DigestMethod><dsig:DigestValue>YJuB+9Os2oxW4mY+2oC/r8lICZE=</dsig:DigestValue></asmv2:hash></file>
</assembly>

Lonely Dog пишет:
> А вот здесь не согласен. Например, насколько я знаю, в 2005 новую версию
> msvcrt.dll нельзя просто скопировать на машину. Нужно ставить через MSI.
> Опять же, все эти deprecated фичи.


ну собирай со старой RTL.

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

SDB>Здравствуйте, Lonely Dog, Вы писали:

LD>>насколько я знаю, в 2005 новую версию msvcrt.dll нельзя просто скопировать на машину. Нужно ставить через MSI. Опять же, все эти deprecated фичи.

SDB>Совсем не обязательно — можно в манифест соответствующие зависимости добавить и рядом с собой положить. Посмотрите исходники Programmer’s Notepad, он как раз рядом с собой кладет и MSI не использует.
Да это вообще не проблема.
Мы счас собираем со статической версией CRT.

Есть опыт переноса небольшого (<30000 строк) проекта с MS VS6 — 2003 на VS2005.
Проект был на С++, MFC, MDI, многопоточность. Код слабо документирован, написан начинающими
программистами, но работает годами, все фичи на месте. Время поджимало, поэтому рефакторинга избегали.
Так как часть разработчиков работало в шестерке, старались обеспечивать компиляцию в разных версиях.

1. Ошибки компиляции — в основном связаны с индексами в операторах цикла for — исправляются легко.

2. Размер time_t изменен. Может измениться физическое представление структур данных. Соответственно легко напороться на проблему с несовместимостью версий файлов сохраненных данных, если использовалась запись структуры как бинарного объекта, например:
file.Write( &obj, sizeof( obj));

3. Выползают ошибки в коде, которые не обнаруживались в VS6, все работало и BounceCheсker просмотрел.
Трудно привести пример, но это так. Контроль нарушения стека рулит. Можно даже посоветовать использовать новую студию как средство обнаружения ошибок в коде. А после очистки кода можно опять собрать проект в старой, если надо.

4. Замеченные несовместимости:
— в шестерке деструкторы нужно делать публичными, даже если конструктор приватный.
— интерлокед функции имеют другую сигнатуру.
— достает петрушка с INVALID_HANDLE_VALUE — сменился у нее тип,
а мы везде использовали эту константу как признак неудачного открытия файла.

5. Такое ощущение, что по-другому работает MFC.
Вызов GetMainWindow() в зависимости от рабочего потока стал возвращать нулевой указатель, с понятными последствиями. Или это такое безопасное приведения типа? Пришлось (стиснув зубы старался удержаться от серьезного рефакторинга) ввести статический указатель на главное окно.

6. Такое ощущение, что по-другому работают потоки. В работающий годами код пришлось вносить изменения. Например, в функции инициализации потока, уже после вызова CreateThread устанавливался флаг разрешения работы потока. В программе скомпилированной в новой студии поток стартует до завершения функции инициализации и соответственно получает еще не установленный флаг.
Да, ошибка, но она раньше не проявлялась. Все, что связано с потоками, пришлось перетряхивать, заново отлаживать. (Может это эффект стресс-теста — смотри ниже)

7. Возникало ощущение, что программа, собранная в новой студии, уступает в производительности,
собранной в старой.!?? Возможно это связано с тем, что оперативки было не много, а студия висела в памяти и наверное vs2005 захватывает больше памяти, а приложению остается меньше.

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

P.S. Тема то серьезная, может гуру накидают поконкретнее ссылок, а то у меня все больше ощущения.

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

FF>7. Возникало ощущение, что программа, собранная в новой студии, уступает в производительности,
FF>собранной в старой.!?? Возможно это связано с тем, что оперативки было не много, а студия висела в памяти и наверное vs2005 захватывает больше памяти, а приложению остается меньше.

При сборке htmlayout в VS2005 зафиксировал примерно 5-7% просаживание в скорости исполнения по сравнению с тем же кодом но собранным с пом. VS6.

Такое впечатление что VS2005 генерит код лучше для замороченных templates но в целом VS6 генерит код для "C с классами" лучше.
Мы тут как-то (на РСДН) развлекались шустриками — VS6 объективно лучше. Может конечно на определнных типах задачах поэтому — ИМХО.

Хотя вот мнение game developers ...

Bloatware Avenger said...

I've been using Visual C++ 6.0 for some years as a professional games developer. In September we decided to upgrade and our experiences have been amazingly incredible. Visual C++ 6.0 took about 150 megabytes of HD, vs some gigabytes of the new version. Visual C++ 6.0 needs less than half the RAM, it's incredibly faster compiling, and the code compiled for 386 is not much slower than the SSE optimized code that the 2005 version generates. Forget about the promised speed increases in optimized code, it's not true. What they have optimized are the standard libraries, like STL, but I take my work seriously enough to not to depend on such a crap and slow library. If you generate optimized code by yourself the 2005 version is not going to improve anything at all. It was fun to see 200 fps (6.0, compiled for 386) vs 201 fps (2005, compiled for Athlon + SSE). I totally agree with the author, and also recommend Visual C++ 6 to any Ansi C + ASM developer. Even if you can't use SSE assembler. Shame on you Microsoft for requiring this rubbish compiler for 360 development. We now use a mixed enviroment, the 2005 version is only useful for what's needed, but the bulk of the work is done again on the great 6.0 one. Visual C++ 6.0 have it's own flags, but overall compared it's a very superior product. Intellisense is fast and doesn't produce 15 megabytes cache files for a project that generates a 30k executable. But hey, it's Microsoft. After trying Windows Vista I'm going to stick with XP, too. Bloatware everywhere guys

http://blog.gamecraft.org/2005/11/microsoft-visual-studio-2005

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

CS>При сборке htmlayout в VS2005 зафиксировал примерно 5-7% просаживание в скорости исполнения по сравнению с тем же кодом но собранным с пом. VS6.

А где именно просаживание происходит не пробовал посмотреть? Профайлером пройтись. Или ты таким не занимаешься?

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

MZ>>Думаю, это здесь вообще ни при чем.
LD>А вот здесь не согласен. Например, насколько я знаю, в 2005 новую версию msvcrt.dll нельзя просто скопировать на машину. Нужно ставить через MSI. Опять же, все эти deprecated фичи.

Скажите пожалуйста а для приложения скомпилированного в 2003 достаточно ли просто скопировать msvcrt.dll или надо что то еще дополнительно делать.

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

LD>Привет всем!

LD>Есть большой проект, написанный на C++ в Visual Studio 2003.
LD>В проект пришли новые разработчики, которые говорят, что 2003 студия их не устраивает. (2005 стабильнее и удобнее. Компилятор C++ в 2005 также лучше чем в 2003).
LD>Вопрос в том, насколько будет безопасным переход на 2005 студию.
LD>Я уверен, что во время перехода на VS2005 мы получим какое-то количество ошибок от компилятора.
LD>Но насколько велика вероятность того, что мы получим ошибки в Runtime.

LD>Заранее спасибо за ваши ответы.

Поясни пожалуйста чем не устраивает разработчиков 2003 версия?

FarFrom пишет:
> 2. Размер time_t изменен. Может измениться физическое представление
> структур данных. Соответственно легко напороться на проблему с

Размет time_t может быть оставлен 32-хразрядным, если определить
макрос _USE_32BIT_TIME_T

FarFrom пишет:
> 6. Такое ощущение, что по-другому работают потоки. В работающий годами
> код пришлось вносить изменения. Например, в функции инициализации
> потока, уже после вызова CreateThread устанавливался флаг разрешения
> работы потока. В программе скомпилированной в новой студии поток
> стартует до завершения функции инициализации и соответственно получает
> еще не установленный флаг.
> Да, ошибка, но она раньше не проявлялась. Все, что связано с потоками,
> пришлось перетряхивать, заново отлаживать. (Может это эффект
> стресс-теста — смотри ниже)

А это у вас гонки. Как только CreateThread вызван, поток
уже может начать выполняться и устанавливать флаги какие-то для
него уже поздно.
Это просто компилятор наверное код по-другому
генерирует, более распарралеливаемый, вот гонки и вылезли.
2005 vs как таковое здесь ни при чем.

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

A>Здравствуйте, c-smile, Вы писали:

CS>>При сборке htmlayout в VS2005 зафиксировал примерно 5-7% просаживание в скорости исполнения по сравнению с тем же кодом но собранным с пом. VS6.

A>А где именно просаживание происходит не пробовал посмотреть? Профайлером пройтись. Или ты таким не занимаешься?

Профайлером проходился но по набору фнкций а не всему проекту.
Как я сказал я использую простой C с классами поэтому я не понимаю почему вообще должна быть разница.

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

FF>В целом вывод: если вам примерно такой проект как у меня достался, и если есть время
FF>- переносите обязательно — много ошибок в коде можете исправить.
FF>Ну и новых в этом процессе можете понаделать... Успехов.
Проект большой. Порядка 120000 строк ( без учета CustomActions в инсталяторах и без учета плагинов.)
Я в этом проекте с самого начала, т.ч .уровень разработчиков примерно знаю.
Думаю, особо тупых ошибок нет.
MFC мы не используем, т.ч. с этой стороны проблем не будет.
Спасибо за отзыв.

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

А>Здравствуйте, Lonely Dog, Вы писали:

MZ>>>Думаю, это здесь вообще ни при чем.
LD>>А вот здесь не согласен. Например, насколько я знаю, в 2005 новую версию msvcrt.dll нельзя просто скопировать на машину. Нужно ставить через MSI. Опять же, все эти deprecated фичи.

А>Скажите пожалуйста а для приложения скомпилированного в 2003 достаточно ли просто скопировать msvcrt.dll или надо что то еще дополнительно делать.
Вроде достаточно скопировать.
Но точно я не знаю, т.к. у нас для всего софта пишутся инсляторы.

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

CS>Как я сказал я использую простой C с классами поэтому я не понимаю почему вообще должна быть разница.

"Programmers are notoriously bad at guessing which parts of their code are performance bottlenecks." (чье это?) Я бы скорее удивился, если бы разницы не было.