У нас имеется достаточно крупное, в солюшене 25 под-проектов, приложение на MFC 9.0 (разработанное на VS2008 + SP1).
Приложение класса SCADA. В нем куча потоков. В GUI мы применяем MFC Feature Pack, компоненты ActiveX.
Широко применяем STL коллекции.
Пока нас вполне устраивает существующее положение дел, тем более, что пользовательская аудитория достаточно консервативна.
В ТЗ на приложение у нас определена поддержка OS Windows XP и Windows 7 (32 и 64). Приложение тестировалось с этими системами.
Хотя, вполне возможно, что вскоре появится требование поддерживать также и Windows 8.
В данном контексте — что нам даст портирование нашего приложения на VS2012 (VS2013) и применение новой библиотеки MFC?
Стоит ли переходить на новую версию Visual Studio?
И если да, то на какую?
P.S. Наша программа, это 32-х разрядное приложение, НЕ Unicode (а MBCS).
Здравствуйте, AlexGin, Вы писали:
AG>У нас имеется достаточно крупное, в солюшене 25 под-проектов, приложение на MFC 9.0 (разработанное на VS2008 + SP1). AG>Приложение класса SCADA. В нем куча потоков. В GUI мы применяем MFC Feature Pack, компоненты ActiveX. AG>Широко применяем STL коллекции.
AG>Пока нас вполне устраивает существующее положение дел, тем более, что пользовательская аудитория достаточно консервативна. AG>В ТЗ на приложение у нас определена поддержка OS Windows XP и Windows 7 (32 и 64). Приложение тестировалось с этими системами. AG>Хотя, вполне возможно, что вскоре появится требование поддерживать также и Windows 8.
AG>В данном контексте — что нам даст портирование нашего приложения на VS2012 (VS2013) и применение новой библиотеки MFC?
Из того что может оказаться полезным в данном контексте:
— c++ 11 (var, lambda, foreach, rvalue, shared_ptr хотя бы) — банально меньше текста писать и проще.
— мультипоточная быстрая сборка ака /MP (если не юзаете incredibuild)
— более вменяемый intellisense, возможность (минимального) рефакторинга (если не юзаете visual assist)
— вменяемая система сборки (.vcxproj и .props совместимый с msbuild не через ж.)
— поддержка GIT из коробки (ну и TFS, если вы его используете)
— "Only my code" в дебаггере
— Просмотр объявления (Alt+F12)
— Продвинутый скроллбар (тот который был раньше RockScroll)
— возможность перетащить окно или панель VS на другой экран
— поддержка WinRT и C++/CX (может стать актуально в связи с Windows 8)
— Встроенная поддержка (нативных) юнит-тестов.
— работает не так тормозно как 2008
— встроенный профайлер проапгрейдили
— rest sdk, таски
AG>Стоит ли переходить на новую версию Visual Studio? AG>И если да, то на какую?
На последюю.
AG>P.S. Наша программа, это 32-х разрядное приложение, НЕ Unicode (а MBCS).
Здравствуйте, bnk, Вы писали:
bnk>Из того что может оказаться полезным в данном контексте:
bnk>- c++ 11 (var, lambda, foreach, rvalue, shared_ptr хотя бы) — банально меньше текста писать и проще.
В общем — некоторые вкусности и полезности. Насколько они принципиальны для нашего проекта, мне пока сложно судить.
bnk>- "Only my code" в дебаггере
В старой, 2008 студии, я также вижу в окне отладчика свой код. В чем же разница?
bnk>- возможность перетащить окно или панель VS на другой экран
Удобненько!
bnk>- поддержка WinRT и C++/CX (может стать актуально в связи с Windows 8)
То есть, при переходе к поддержке Win8, вполне реально потребуется переход на новую VS и библиотеку MFC...
bnk>- работает не так тормозно как 2008
Это насчет самой среды разработки VS, или кода, который она генерирует?
Кстати, попробовал откомпилировать одну из моих небольших утилит (сделанных в 2008 студии на MFC 9.0), на VS2012.
Размер релизного exe-шника вырос в 4-5 раз
AG>>P.S. Наша программа, это 32-х разрядное приложение, НЕ Unicode (а MBCS).
bnk>Фигово кстати. В VS2013 поддержку MBCS задеприкатили. Возможно в следующих релизе вообще уберут: bnk>http://blogs.msdn.com/b/vcblog/archive/2013/07/08/mfc-support-for-mbcs-deprecated-in-visual-studio-2013.aspx
В общем — вредители от M$!!!
Перевод большого проекта на Unicode, без особой на то надобности, потянет за собой немалые трудозатраты
Большое спасибо, уважаемый bnk, за столь развернутый ответ!
Здравствуйте, AlexGin, Вы писали:
bnk>>- c++ 11 (var, lambda, foreach, rvalue, shared_ptr хотя бы) — банально меньше текста писать и проще. AG>В общем — некоторые вкусности и полезности. Насколько они принципиальны для нашего проекта, мне пока сложно судить.
Ну вот смотри, хотя бы, вместо:
for (MyLongTypeName::value_type<AnotherName>::const_const iterator it = myobject.myvalues.begin(); it != myobject.myvalues.end(); ++it)
{
Value val = (*it);
/// ...
}
Можно написать
for (auto val : myobject.myvalues)
{
/// ...
}
bnk>>- "Only my code" в дебаггере AG>В старой, 2008 студии, я также вижу в окне отладчика свой код. В чем же разница?
В том что ты не видишь "чужой" код в стеке и не заходишь в него — он отфильтровывается
bnk>>- поддержка WinRT и C++/CX (может стать актуально в связи с Windows 8) AG>То есть, при переходе к поддержке Win8, вполне реально потребуется переход на новую VS и библиотеку MFC...
Не совсем. Т.е. десктопные приложения могут работать как обычно через WinAPI (т.е. весь код должен без проблем запуститься на Win8),
но если понадобится работать с каким-то новым АПИ Win8, оно может оказаться доступно только через WinRT (т.е. <барабанная дробь> недоступно через WinAPI).
bnk>>- работает не так тормозно как 2008 AG>Это насчет самой среды разработки VS, или кода, который она генерирует?
Насчет самой (я про 2013). Ну субъективно конечно
AG>Кстати, попробовал откомпилировать одну из моих небольших утилит (сделанных в 2008 студии на MFC 9.0), на VS2012. AG>Размер релизного exe-шника вырос в 4-5 раз
Здравствуйте, bnk, Вы писали:
bnk>Здравствуйте, AlexGin, Вы писали:
bnk>>>- c++ 11 (var, lambda, foreach, rvalue, shared_ptr хотя бы) — банально меньше текста писать и проще. AG>>В общем — некоторые вкусности и полезности. Насколько они принципиальны для нашего проекта, мне пока сложно судить.
bnk>Ну вот смотри, хотя бы, вместо: bnk>
bnk>for (MyLongTypeName::value_type<AnotherName>::const_const iterator it = myobject.myvalues.begin(); it != myobject.myvalues.end(); ++it)
bnk>{
bnk> Value val = (*it);
bnk> /// ...
bnk>}
bnk>
Понятно. Проход по коллекции сделали удобнее.
bnk>>>- "Only my code" в дебаггере AG>>В старой, 2008 студии, я также вижу в окне отладчика свой код. В чем же разница?
bnk>В том что ты не видишь "чужой" код в стеке и не заходишь в него — он отфильтровывается
Это хорошо, позволяет ускорить процесс отладки.
bnk>>>- поддержка WinRT и C++/CX (может стать актуально в связи с Windows 8) AG>>То есть, при переходе к поддержке Win8, вполне реально потребуется переход на новую VS и библиотеку MFC...
bnk>Не совсем. Т.е. десктопные приложения могут работать как обычно через WinAPI (т.е. весь код должен без проблем запуститься на Win8), bnk>но если понадобится работать с каким-то новым АПИ Win8, оно может оказаться доступно только через WinRT (т.е. <барабанная дробь> недоступно через WinAPI).
Новый API, характерный для Win8, в обозримом будущем применять не планируем.
bnk>>>- работает не так тормозно как 2008 AG>>Это насчет самой среды разработки VS, или кода, который она генерирует?
bnk>Насчет самой (я про 2013). Ну субъективно конечно
AG>>Кстати, попробовал откомпилировать одну из моих небольших утилит (сделанных в 2008 студии на MFC 9.0), на VS2012. AG>>Размер релизного exe-шника вырос в 4-5 раз
bnk>Может рантайм чек. bnk>Или может еще вот что — они добавили MFC контролы из Feature Pack в дизайнерский Toolbox в VS: bnk>http://blogs.msdn.com/b/vcblog/archive/2012/02/06/10263387.aspx
В этой простой утилите, откомпилированной в VS2008, НЕТ контролов из Feature Pack. Простой, старый-добрый MFC (времен VS 6.0)!
Удивило, что размер exe-шника (release) так сильно разбух (более 5 с половиной метров, вместо прежних 1,3).
bnk>Лечится через (если этой фичей не пользуешься): bnk>
bnk>#define _AFX_NO_MFC_CONTROLS_IN_DIALOGS
bnk>
Попробую, может как-то и вылечится
Ладненько, огромное спасибо!
В общем — есть над чем подумать и что погуглить
Прочитал статью.
Теперь понятно в чем собака зарыта
У меня в этой утилите библиотека MFC прилинкована статически!
Именно из-за этого и имеет место такое сильное "разбухание" exe файла!
По крайней, ясно куда копать!
On 15.07.2014 01:27, AlexGin wrote:
> У нас имеется достаточно крупное, в солюшене 25 под-проектов, приложение > на MFC 9.0 (разработанное на VS2008 + SP1).
Какое ж это крупное ? средненькое...
... > В данном контексте — что нам даст портирование нашего приложения на > VS2012 (VS2013) и применение новой библиотеки MFC?
Скорее всего, ничего, кроме ловли новых глюков и -- главное --
поддерживаемости платформы для сборки вашего приложения.
При переходе на 64 bit -- соответственно, снятие ограничений по объемам
памяти в 2Gb.
> Стоит ли переходить на новую версию Visual Studio?
Да, стоит.
> И если да, то на какую?
Последнюю или предпоследнюю.
Последняя лучше, если сможете на неё перейти. Если нет -- то на
предпоследнюю, отлов багов, потом -- на последнюю.
> — c++ 11 (var, lambda, foreach, rvalue, shared_ptr хотя бы) — банально > меньше текста писать и проще. > — мультипоточная быстрая сборка ака /MP (если не юзаете incredibuild) > — более вменяемый intellisense, возможность (минимального) рефакторинга > (если не юзаете visual assist) > — вменяемая система сборки (.vcxproj и .props совместимый с msbuild не > через ж.) > — поддержка GIT из коробки (ну и TFS, если вы его используете) > — "Only my code" в дебаггере > — Просмотр объявления (Alt+F12) > — Продвинутый скроллбар (тот который был раньше RockScroll) > — возможность перетащить окно или панель VS на другой экран > — поддержка WinRT и C++/CX (может стать актуально в связи с Windows 8) > — Встроенная поддержка (нативных) юнит-тестов. > — работает не так тормозно как 2008 > — встроенный профайлер проапгрейдили > — rest sdk, таски
Здравствуйте, MasterZiv, Вы писали:
MZ>On 15.07.2014 09:39, AlexGin wrote: >> bnk>- *возможность перетащить окно или панель VS на другой экран* >> Удобненько!
MZ>Так ещё в VC 5 была такая возможность.
Неужели? Я имел в виду, что была решена та проблема,
что все окна текстовых редакторов и панелей (кроме панелей инструментов) были дочерними окнами "главного окна" студии,
и поэтому их нельзя было вытащить за окно студии (например перетащить на другой экран)
On 21.07.2014 16:44, bnk wrote:
> MZ>Так ещё в VC 5 была такая возможность. > > Неужели? Я имел в виду, что была решена та проблема, > что все окна текстовых редакторов и панелей (кроме панелей инструментов) > были дочерними окнами "главного окна" студии, > и поэтому их нельзя было вытащить за окно студии (например перетащить на > другой экран)
Ну да. В VC6 я всё время работал на 3 экранах. VC 5 имела ровно тот же
(новый для VC5) GUI, что и vc6.
Здравствуйте, MasterZiv, Вы писали:
>> MZ>Так ещё в VC 5 была такая возможность. >> >> Неужели? Я имел в виду, что была решена та проблема, >> что все окна текстовых редакторов и панелей (кроме панелей инструментов) >> были дочерними окнами "главного окна" студии, >> и поэтому их нельзя было вытащить за окно студии (например перетащить на >> другой экран)
MZ>Ну да. В VC6 я всё время работал на 3 экранах. VC 5 имела ровно тот же MZ>(новый для VC5) GUI, что и vc6.
Обратите внимание на
(кроме панелей инструментов)
Даже в 2008 нельзя вытащить документ ис главного окна.
Здравствуйте, MasterZiv, Вы писали:
MZ>Чего? Вместо того, чтобы выбросить этот UNICODE, они обрубают самый MZ>правильный MBCS ?
+100500
А выбрасывание MBSC, это тот еще цирк.
Масса программ его используют и портирование большого проекта займет уйму времени!
Hint: это политический шаг, направленный на то, чтобы постепенно вытеснять MFC и заставлять девелоперов переходить на .NET
Здравствуйте, MasterZiv, Вы писали:
MZ>Какое ж это крупное ? средненькое...
По масштабам нашей команды (где разработкой занимаюсь только я), немаленькое
MZ>... >> В данном контексте — что нам даст портирование нашего приложения на >> VS2012 (VS2013) и применение новой библиотеки MFC?
MZ>Скорее всего, ничего, кроме ловли новых глюков и -- главное -- MZ>поддерживаемости платформы для сборки вашего приложения. MZ>При переходе на 64 bit -- соответственно, снятие ограничений по объемам MZ>памяти в 2Gb.
То есть, пока смысл перехода особо не виден... Я также придерживаюсь данного мнения.
>> Стоит ли переходить на новую версию Visual Studio?
MZ>Да, стоит.
Ради чего конкретно:
1) для удовлетворения профессионального любопытства (а также и ЧСВ) — возможно да;
2) для нужд текущего проекта — скорее всего, нет необходимости торопиться с переходом.
>> И если да, то на какую?
MZ>Последнюю или предпоследнюю. MZ>Последняя лучше, если сможете на неё перейти. Если нет -- то на MZ>предпоследнюю, отлов багов, потом -- на последнюю.
В перспективе, я так полагаю, будем переходить. Однако, пока эта задача не самая приоритетная.
Я так понял, что даже переход на Win8, вполне реализуем на текущей версии библиотеки MFC (v 9.0).
Тем более, что особых функций Win8 пока не предполагаем поддерживать.
On 21.07.2014 19:02, bnk wrote:
> Я имел в виду поддержку multiple monitor, добавленную в VS 2010. Раньше > 2010 это же одно окно было, не?! > Со скриншотами и видео: > > http://weblogs.asp.net/scottgu/multi-monitor-support-vs-2010-and-net-4-series > > Или ты имеешь в виду, что эта же фича была в VC5, выпущенном в 97 году?
Не знаю, какие такие фичи, бралось окно, раздокировалось, и
перетаскивалось на другой монитор.
Главное окно с документом (т.е. с кодом) никуда с главного экрана
переносить и не нужно. Хватает переноса дополнительных окон.
On 23.07.2014 15:51, AlexGin wrote:
> Ради чего конкретно: > 1) для удовлетворения профессионального любопытства (а также и ЧСВ) — > возможно да; > 2) для нужд текущего проекта — скорее всего, нет необходимости > торопиться с переходом.
Ну да, если у тебя 2008-ая студия, то ещё какое-то время можно будет
потянуть с переходом.
Здравствуйте, MasterZiv, Вы писали:
MZ>Главное окно с документом (т.е. с кодом) никуда с главного экрана MZ>переносить и не нужно. Хватает переноса дополнительных окон.
On 23.07.2014 17:52, VladFein wrote:
> MZ>Главное окно с документом (т.е. с кодом) никуда с главного экрана > MZ>переносить и не нужно. Хватает переноса дополнительных окон. > > А если их — два? Или, не дай бог, ещё больше?
Либо по два на дополнительный монитор, либо по одному окну на каждый
доп.монитор. У меня было три. В нотике, и два внешних.
В нотике удобно смотреть лог компиляциии при отладке все отладочнные
окна. В доп мониторе -- дерево проекта. В основном мониторе -- код.
Здравствуйте, MasterZiv, Вы писали:
>> MZ>Главное окно с документом (т.е. с кодом) никуда с главного экрана >> MZ>переносить и не нужно. Хватает переноса дополнительных окон. >> >> А если их — два? Или, не дай бог, ещё больше?
MZ>Либо по два на дополнительный монитор, либо по одному окну на каждый MZ>доп.монитор. У меня было три. В нотике, и два внешних. MZ>В нотике удобно смотреть лог компиляциии при отладке все отладочнные MZ>окна. В доп мониторе -- дерево проекта. В основном мониторе -- код.
Прошу прощения, не ясно выразился.
А есле документов (кода) два или больше? Как их разнести?
On 23.07.2014 19:05, VladFein wrote:
> Прошу прощения, не ясно выразился. > А есле документов (кода) два или больше? Как их разнести?
В старых VC было никак. Но это всё нужно для ОТЛАДКИ, а это ТОЛЬКО ОДИН
КУСОК КОДА ЕДИНОМОМЕНТНО, один фрейм стека.
А, хотя, нет -- сплиттер же можно было сделать, и смотреть можно было на
до 4-ре куска кода одномоментно. Но вынести кусок MDIChild из главного
окна нельзя было.
Здравствуйте, MasterZiv, Вы писали:
MZ>В старых VC было никак. Но это всё нужно для ОТЛАДКИ, а это ТОЛЬКО ОДИН MZ>КУСОК КОДА ЕДИНОМОМЕНТНО, один фрейм стека.
Неужели? Я имел в виду, что была решена та проблема,
что все окна текстовых редакторов и панелей (кроме панелей инструментов) были дочерними окнами "главного окна" студии,
и поэтому их нельзя было вытащить за окно студии (например перетащить на другой экран)
On 28.07.2014 20:04, VladFein wrote:
> Неужели? Я имел в виду, что была решена та проблема, > что все окна текстовых редакторов и панелей (кроме панелей > инструментов) были дочерними окнами "главного окна" студии, > и поэтому их нельзя было вытащить за окно студии (например > перетащить на другой экран)
Здравствуйте, aloch, Вы писали:
A>Здравствуйте, AlexGin, Вы писали:
AG>>P.S. Наша программа, это 32-х разрядное приложение, НЕ Unicode (а MBCS).
A>В VC++2013 c НЕ Unicode (а MBCS) беда — поддержку выкинули из стандартной поставки. Нужно отдельно качать и ставить пакет поддержки. И по моему опыту в нем есть ошибки (https://connect.microsoft.com/VisualStudio/feedback/details/807871/atl-mfc-cstringa-setsysstring-throw-atl-memeory-exception-for-emty-string-in-vc-2013)
A>Я со своим проектом, в котором местами используется MFC (а он прошел все студии, начиная с 1.5), остановился на VC++2012. Все более менее нормально.
Спасибо, за ответ, уважаемый aloch!
Я для себя определился таким образом: пока (ИМХО еще может и год) — вопрос по портированию для нашего проекта не актуален.
Вполне работоспособен и поддерживаем код, сгенерированный в VS2008. Тем юолее, что там имеется MFC Feature Pack.
А в перспективе — портирование вполне может включить в себя и работы по переходу на Unicode.
Конечно, трудоемкость этот факт подымает (и зна-а-ачительно!), однако, можно будет рассчитывать
на возможность продвижения нашего продукта в рамках международных рынков!
Уже сейчас совершенно спокойно можно переходить на VC++2012 и оставаться на нем довольно долго. Более того, можно использовать для разработки среду студии 2013 (в ней гораздо лучше поддерживается интелисайс для С++), а компилировать проект компилятором VC2012 (такая штатная возможность есть в новых студиях, в 2008 ее нет).
Я для себя в своей программе MFC (и VB6) использую только в старом коде, который нет возможности переписать. Все новое — только на .Net / WinForms / WPF, что и Вам советую...
Здравствуйте, aloch, Вы писали:
A>Здравствуйте, AlexGin, Вы писали:
A>Уже сейчас совершенно спокойно можно переходить на VC++2012 и оставаться на нем довольно долго. Более того, можно использовать для разработки среду студии 2013 (в ней гораздо лучше поддерживается интелисайс для С++), а компилировать проект компилятором VC2012 (такая штатная возможность есть в новых студиях, в 2008 ее нет).
Попробую, может это и хороший вариант.
A>Я для себя в своей программе MFC (и VB6) использую только в старом коде, который нет возможности переписать. Все новое — только на .Net / WinForms / WPF, что и Вам советую...
+100500
Тем более, что раньше я занимался довольно много на C# (WinForms)!
Прекрасно понимаю, что разработка форм и прочего GUI в C# идет быстрее и проще, чем в MFC.
Просто много кода (старого и даже "древнего") и переход на .NET может оказаться весьма долгим.
А я могу добавить такую же функциональность в мое (разработанное мною на MFC) приложение?
В библиотеке MFC, идущей с новыми вижуал студиями можно сделать аналогично?
З.Ы. Это бы, хоть как-то оправдывало переход (портирование существующего кода) на новую VS...
Здравствуйте, VladFein, Вы писали:
VF>Здравствуйте, MasterZiv, Вы писали:
>>> MZ>Так ещё в VC 5 была такая возможность. >>> >>> Неужели? Я имел в виду, что была решена та проблема, >>> что все окна текстовых редакторов и панелей (кроме панелей инструментов) >>> были дочерними окнами "главного окна" студии, >>> и поэтому их нельзя было вытащить за окно студии (например перетащить на >>> другой экран)
MZ>>Ну да. В VC6 я всё время работал на 3 экранах. VC 5 имела ровно тот же MZ>>(новый для VC5) GUI, что и vc6.
VF>Обратите внимание на VF>
VF>(кроме панелей инструментов)
VF>Даже в 2008 нельзя вытащить документ ис главного окна.
ИМХО, это будет протеворечить самой концепции MDI.
З.Ы. Поднял старую тему, поскольку переход на новую VS интересен, однако пока не понятна выгода (прежде всего — для end-user-a) от него...
Здравствуйте, AlexGin, Вы писали:
AG>А я могу добавить такую же функциональность в мое (разработанное мною на MFC) приложение? AG>В библиотеке MFC, идущей с новыми вижуал студиями можно сделать аналогично?
AFAIK MFC не обновляли особо с того времени как в него добавили Feature Pack (от BCGSoft), т.е. с VS2008.
Здравствуйте, bnk, Вы писали:
bnk>Здравствуйте, AlexGin, Вы писали:
AG>>А я могу добавить такую же функциональность в мое (разработанное мною на MFC) приложение? AG>>В библиотеке MFC, идущей с новыми вижуал студиями можно сделать аналогично?
bnk>AFAIK MFC не обновляли особо с того времени как в него добавили Feature Pack (от BCGSoft), т.е. с VS2008.
+100500
Я примерно так и понимал
Вот и получается — что или работать с VS2008, или (если уже по крутому) — портировать все на C# (может даже на WPF, так как WinForms уже больше устарел, нежели MFC)!
Здравствуйте, bnk, Вы писали:
bnk>Здравствуйте, MasterZiv, Вы писали:
MZ>>Ну да. В VC6 я всё время работал на 3 экранах. VC 5 имела ровно тот же MZ>>(новый для VC5) GUI, что и vc6.
bnk>Я имел в виду поддержку multiple monitor, добавленную в VS 2010. Раньше 2010 это же одно окно было, не?! bnk>Со скриншотами и видео:
bnk>http://weblogs.asp.net/scottgu/multi-monitor-support-vs-2010-and-net-4-series
bnk>Или ты имеешь в виду, что эта же фича была в VC5, выпущенном в 97 году?
Посмотрел в VS 2012 и 13 (установил их примерно месяц назад) — поддержка мультимониторности. Удобненько.
В среде 2008-й такой возможности, к сожалению, нет.
Еще одна удобная возможность — в окне "Solution Explorer", внутри файлов *.cpp видны некоторые ключевые элементы реализации в классах.
Это также можно отнести к удобным нововведениям.
Однако, не обходится, как и во всех продуктах от M$, без ложки дегтясложностей. Главная из которых — уход от MBCS в MFC приложениях для VS2013
Именно в силу этого, пока портирование больших проектов на новую студию выглядит очень геморройно...
Тут уже высказывали мысль над двухэтапным переходом — сначала на VS2012, а только затем уже — на VS2013.
Этот путь, очевидно, намного менее тяжелый. Вполне возможно, что так и придётся в будущем действовать.
Какие-либо из утилит общего комплекса ПО, вполне вероятно будем уже портировать на .NET (C#).
P.S. ИМХО "пуританский" GUI в VS2012 и VS2013 скорее напоминает приложение 20-ти летней давности (времён Windows 3.11 for workgroups), нежели современное приложение
Похоже, M$ следует девизу "назад в будущее"...
Здравствуйте, AlexGin, Вы писали:
AG>Однако, не обходится, как и во всех продуктах от M$, без ложки дегтясложностей. Главная из которых — уход от MBCS в MFC приложениях для VS2013
Здравствуйте, AlexGin, Вы писали:
bnk>>- поддержка WinRT и C++/CX (может стать актуально в связи с Windows 8) AG>То есть, при переходе к поддержке Win8, вполне реально потребуется переход на новую VS и библиотеку MFC...
Я на 2005ой сижу, под 2k пишу. Результат работает и на 8ке. Правда не MFC, а WTL и WinAPI
Здравствуйте, утпутуук, Вы писали:
У>Здравствуйте, AlexGin, Вы писали:
bnk>>>- поддержка WinRT и C++/CX (может стать актуально в связи с Windows 8) AG>>То есть, при переходе к поддержке Win8, вполне реально потребуется переход на новую VS и библиотеку MFC...
У>Я на 2005ой сижу, под 2k пишу. Результат работает и на 8ке. Правда не MFC, а WTL и WinAPI
+100500
Я не собирираюсь утверждать — что надо/не надо использовать. Тем более, что мне не известны подробности и особенности ваших проектов.
Просто я пытаюсь разобраться, насколько критичен переход на новую студию + библиотеки (для проектов на MFC).
Лично я портировал старый проект с VS2003 на VS2008 для поддержки новых контролов (MFC Feature Pack).
Что даст переход на VS20012/13 — пока мне не ясно...
Портировал коды нашего проекта на MSVS 2013 (Community Edition, Update 4)
Всё оказалось даже намного проще, чем я ранее предполагал!
Просто скачал пакет MBCS for MFC для этой студии — файл vc_mbcsmfc.exe и установил его.
Доработки в кодах проекта — потребовались минимальные. Старый код успешно работает под MSVS 2008.
При динамической линковке (c DLL-ками MFC классов) — код получается компактный, почти как для 2008-й.
Среда разработки — ИМХО более удобная, чем в 2008-й.
До этого, пробовал портировать на MSVS 2012 — у меня создалось впечатление, что MSVS 2012 достаточно глючная и нестабильная.
Огромное приемущество перед старой (2008-й) студией — в MSVS 2013 поддерживается новый стандарт: C++11.
Здравствуйте, bnk, Вы писали:
bnk>>>- работает не так тормозно как 2008 AG>>Это насчет самой среды разработки VS, или кода, который она генерирует?
bnk>Насчет самой (я про 2013). Ну субъективно конечно
+100500
Кстати, коды которые генерирует для MFC приложений MS VS-2013 Community Edition (Update 5) —
выполняются быстрее, чем сгенерированные на MS VS-2008 (SP1)!
Здравствуйте, 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 в моих проектах).
Знаете, идеального статического анализатора С++ не существует, поэтому переходить на новую версию стоит хотя бы потому, чтобы узнать сколько еще проблем таит ваш код. У нас проект ~700 модулей. Самым сложным был переход с проектов Visual Studio 6 на CMake генератор, с одновременным переходом c Debug-a на Release сборку. Далее мы систематически меняли студии, благо благодаря CMake-у это делает за несколько минут, правда, далее требуется корректировка кода для выравнивания с текущими требования С++. В этом плане самый сложный переход был с Visual Studio 6 на Visual Studio 2010. Сейчас перешли на 2015 за день. Код работает всей линейке от XP до Windows 10 и тоже MBCS.
Здравствуйте, Анатолий Широков, Вы писали:
АШ>Здравствуйте, 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 описание проекта, благодаря небольшому фасадному обвесу:
И, согласитесь, править, искать в тесте неизмеримо легче, чем в тех же многоконфигурационных студийных 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...
.jpg)
