У нас имеется достаточно крупное, в солюшене 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>переносить и не нужно. Хватает переноса дополнительных окон. > > А если их — два? Или, не дай бог, ещё больше?
Либо по два на дополнительный монитор, либо по одному окну на каждый
доп.монитор. У меня было три. В нотике, и два внешних.
В нотике удобно смотреть лог компиляциии при отладке все отладочнные
окна. В доп мониторе -- дерево проекта. В основном мониторе -- код.
