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

A>Для сведения. Недавно попробовал собрать свой проект 2015 студией (Update1) Долго искал, где скачать MBSC for MFC для нее, пока не понял, что все вернули назад, и MBSC теперь опять поставляется с самой студией.
A>Ошибку https://connect.microsoft.com/VisualStudio/feedback/details/807871/atl-mfc-cstringa-setsysstring-throw-atl-memeory-exception-for-emty-string-in-vc-2013 поправили (для меня это было критично, и на 2013 я не перешел).
+100500
Глас разума восторжествовал в кулуарах MS
Это я насчёт того, что поддержка MBCS — одно из ключевых свойств MSVC. Хорошо, что ее вернули!
Насчет ошибки — не сталкивался (просто не требовался вызов SetSysString в моих проектах).

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

Знаете, идеального статического анализатора С++ не существует, поэтому переходить на новую версию стоит хотя бы потому, чтобы узнать сколько еще проблем таит ваш код. У нас проект ~700 модулей. Самым сложным был переход с проектов Visual Studio 6 на CMake генератор, с одновременным переходом c Debug-a на Release сборку. Далее мы систематически меняли студии, благо благодаря CMake-у это делает за несколько минут, правда, далее требуется корректировка кода для выравнивания с текущими требования С++. В этом плане самый сложный переход был с Visual Studio 6 на Visual Studio 2010. Сейчас перешли на 2015 за день. Код работает всей линейке от XP до Windows 10 и тоже MBCS.

В плане новшеств в MFC 2015 наконец-то добавили нативную поддержку Layout Manager-a, который позволяет в редакторе ресурсов задать правила реcайзинга: https://msdn.microsoft.com/en-us/library/mt270148.aspx

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

По XP там все не так весело — http://stackoverflow.com/questions/34074204/visual-studio-2015-cannot-produce-an-atl-dll-that-successfully-registers-on-wind

Я еще на VC++ 6 понял, что от CRT в DLL больше вреда, чем пользы, и всегда с CRT линкуюсь статически.

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

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

АШ>Знаете, идеального статического анализатора С++ не существует, поэтому переходить на новую версию стоит хотя бы потому, чтобы узнать сколько еще проблем таит ваш код.
+100500
Совершенно верно! Переход на MSVC2013 выявил некоторые слабые места в проекте, которые удалось подправить именно в процессе портирования!

АШ>У нас проект ~700 модулей. Самым сложным был переход с проектов Visual Studio 6 на CMake генератор, с одновременным переходом c Debug-a на Release сборку. Далее мы систематически меняли студии, благо благодаря CMake-у это делает за несколько минут, правда, далее требуется корректировка кода для выравнивания с текущими требования С++. В этом плане самый сложный переход был с Visual Studio 6 на Visual Studio 2010. Сейчас перешли на 2015 за день. Код работает всей линейке от XP до Windows 10 и тоже MBCS.
Не пользуюсь утилитой CMake — вся сборка происходит средствами пакета MSVS. Стоит ли плодить лишние сущности, когда всё, что мне надо, есть в студии?
Только для того, чтобы менять студии — имеет ли это смысл?
Все равно стараемся переходить на самую современную, которая имеется на данный момент.

АШ>В плане новшеств в MFC 2015 наконец-то добавили нативную поддержку Layout Manager-a, который позволяет в редакторе ресурсов задать правила реcайзинга: https://msdn.microsoft.com/en-us/library/mt270148.aspx
Это интересно, однако я уволился из той компании, где был этот MFC проект.
Впрочем, это уже совсем другая тема — в раздел "о работе".
Посему, актуальность работы с MFC проектами лично для меня на данный момент отошла на задний план

З.Ы. Я уволился из той компании, где был MFC проект — в октябре 2015, посему довёл проект до MSVS-2013 (Community) update 5.
Это было самое свежее из студий (стабильно опробованных), на момент моего ухода с проекта.

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

AG>Не пользуюсь утилитой CMake — вся сборка происходит средствами пакета MSVS. Стоит ли плодить лишние сущности, когда всё, что мне надо, есть в студии?
AG>Только для того, чтобы менять студии — имеет ли это смысл?
AG>Все равно стараемся переходить на самую современную, которая имеется на данный момент.

У нас часть базовых транспортных библиотек в дереве исходников кроссплатформенные и используются под Unix/Linux, поэтому CMake. Помимо этого, CMake обеспечивает текстовое human-readable описание проекта, благодаря небольшому фасадному обвесу:

ROLIS_EXECUTABLE(formenginetest  
  COMPILE_FLAGS
    -DGOOGLETEST_ENABLED
  SOURCES
    ${HEADERS}
    ${SRC}
    ${TESTS}
    ${FORM_GENERATED_SOURCE_FILES} 
    ${DATATYPE_GENERATED_SOURCE_FILES} 
    ${XSD_FILES} 
    ${XML_FILES} 
  DEPENDS
    ctextg2
    ${XERCES_LIBRARIES} 
    ${GTEST_MAIN_LIBRARY}
    ${GTEST_LIBRARY}
  CONSOLE
  MFC
)

И, согласитесь, править, искать в тесте неизмеримо легче, чем в тех же многоконфигурационных студийных xml-ях, описывающих проект.

AG>З.Ы. Я уволился из той компании, где был MFC проект — в октябре 2015, посему довёл проект до MSVS-2013 (Community) update 5.
AG>Это было самое свежее из студий (стабильно опробованных), на момент моего ухода с проекта.

Понятно, все течет, все меняется.

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

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

AG>>Не пользуюсь утилитой CMake — вся сборка происходит средствами пакета MSVS. Стоит ли плодить лишние сущности, когда всё, что мне надо, есть в студии?
AG>>Только для того, чтобы менять студии — имеет ли это смысл?
AG>>Все равно стараемся переходить на самую современную, которая имеется на данный момент.

АШ>У нас часть базовых транспортных библиотек в дереве исходников кроссплатформенные и используются под Unix/Linux, поэтому CMake. Помимо этого, CMake обеспечивает текстовое human-readable описание проекта, благодаря небольшому фасадному обвесу...
Я выделил основное, что определяет применение утилиты CMake.
Что же касается визуального анализа настроек проекта, то тут в Unix/Linux средствах оно действительно проще и лаконичнее,
если смотреть файл настроек XML формата в текстовом редакторе.
Я убедился в лаконичности настроек проекта для *.pro файлов из Qt (изучаю Qt продукты, для самообразования).
В то же время, GUI студии обеспечивает достаточно удобный вариант просмотра и редактирования всех настроек, для C++ проекта в солюшене.

АШ>Знаете, идеального статического анализатора С++ не существует, поэтому переходить на новую версию стоит хотя бы потому, чтобы узнать сколько еще проблем таит ваш код. У нас проект ~700

Поддерживаю. Недавно переводил старый код 300 Мб исходников с 6 студии на 2013. Понятно, что MFC там не так и много. Одно приложение. Куча дллок. Но всё меня приятно удивило.
1) Поддержка интелисенс. Всё видит.
2) Требования на МФС стали мягче. Не важно, что у вас за длл, легко перевести с шаред длл, на статик линкед и обратно.
3) Старые либы с 6 студии понимает (ряд проектов без исходников). Причём удалось прилинковать даже либы с CRT single threaded.
4) Пишет ошибки на код, который я не могу понять как вообще компилировался в 6 студии.
5) с++ стал гораздо умней. Компилятор и подскажет и не даст ошибиться. Шутка конечно, но что-то есть. Один unique_ptr по сравнению с auto_ptr чего стоит. Сколько проверок накручено в STL...