Visual Studio 2012 and C++, MFC

[ahmd]

I was wondering if anyone has Visual Studio 2012 installed. I saw a lot of promotional material but it doesn't say much about C++ and MFC in it. So, if anyone who tried it out, what's your opinion? Again, I'm asking only from the standpoint of C, C++ and MFC. I know that Intellisense for these languages was really bad in VS 2010. They didn't fix it in VS 2012 by any chance, did they?

[nuzzle]

I was wondering if anyone has Visual Studio 2012 installed. I saw a lot of promotional material but it doesn't say much about C++ and MFC in it. So, if anyone who tried it out, what's your opinion? Again, I'm asking only from the standpoint of C, C++ and MFC. I know that Intellisense for these languages was really bad in VS 2010. They didn't fix it in VS 2012 by any chance, did they?

My take on this is that VS 2012 lets you use the new C++ 11 standard to the fullest extent offered by MS. If you want more of C++ 11 you need to upgrade. VS 2010 probably is a dead-end in this respect.

Regarding the MFC I think you should be happy if you can still use them in VS 2012. MFC is definitely legacy now and to get MS to even mention them you'll have to torture a representative. The longer you stick to MFC the stronger you'll feel MS coercing you to move on to .NET and even better, Metro.

Regarding intellisense, VS is playing catch-up. Eclipse for example is way ahead in "everything at your fingertips" friendliness in general. This must be a major embarrassment for MS so you can expect improvements in VS 2012.

[Igor Vartanov]

C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\atlmfc\src\mfc

afxabort.cpp
afxacceleratorkey.cpp
afxacceleratorkeyassignctrl.cpp
afxanimationcontroller.cpp
afxasert.cpp
afxautohidebar.cpp
afxautohidebutton.cpp
afxautohidedocksite.cpp
afxbasepane.cpp
afxbaseribbonelement.cpp
afxbasetabbedpane.cpp
afxbasetabctrl.cpp
afxbasetoolbar.cpp
afxbutton.cpp
afxcaptionbar.cpp
afxcaptionbutton.cpp
afxcaptionmenubutton.cpp
afxcmdusagecount.cpp
afxcolorbar.cpp
afxcolorbutton.cpp
afxcolordialog.cpp
afxcolormenubutton.cpp
afxcolorpickerctrl.cpp
afxcolorpopupmenu.cpp
afxcolorpropertysheet.cpp
afxcommandmanager.cpp
afxcontextmenumanager.cpp
afxcontrolbarimpl.cpp
afxcontrolrenderer.cpp
afxcrit.cpp
afxctrlcontainer.cpp
afxcustomcolorspropertypage.cpp
afxcustomizebutton.cpp
afxcustomizemenubutton.cpp
afxdatarecovery.cpp
afxdbcs.cpp
afxdesktopalertdialog.cpp
afxdesktopalertwnd.cpp
afxdialogex.cpp
afxdialogimpl.cpp
afxdockablepane.cpp
afxdockablepaneadapter.cpp
afxdockingmanager.cpp
afxdockingpanesrow.cpp
afxdocksite.cpp
afxdragframeimpl.cpp
afxdrawmanager.cpp
afxdropdownlistbox.cpp
afxdropdowntoolbar.cpp
afxeditbrowsectrl.cpp
afxfontcombobox.cpp
afxframeimpl.cpp
afxframewndex.cpp
afxfullscreenimpl.cpp
afxglobals.cpp
afxglobalutils.cpp
afxheaderctrl.cpp
afximageeditordialog.cpp
afximagepaintarea.cpp
afximpl.h
afxinl1.cpp
afxinl2.cpp
afxinl3.cpp
afxinl4.cpp
afxjumplist.cpp
afxkeyboardmanager.cpp
afxkeymapdialog.cpp
afxlinkctrl.cpp
afxlistctrl.cpp
afxmaskededit.cpp
afxmdichildwndex.cpp
afxmdiclientareawnd.cpp
afxmdiframewndex.cpp
afxmem.cpp
afxmenubar.cpp
afxmenubutton.cpp
afxmenuhash.cpp
afxmenuimages.cpp
afxmenutearoffmanager.cpp
afxmousemanager.cpp
afxmousepropertypage.cpp
afxmultipaneframewnd.cpp
afxolecntrframewndex.cpp
afxoledocipframewndex.cpp
afxoleipframewndex.cpp
afxoleserverdocex.cpp
afxoutlookbar.cpp
afxoutlookbarpane.cpp
afxoutlookbarpaneadapter.cpp
afxoutlookbarpanebutton.cpp
afxoutlookbartabctrl.cpp
afxpane.cpp
afxpanecontainer.cpp
afxpanecontainermanager.cpp
afxpanedialog.cpp
afxpanedivider.cpp
afxpaneframewnd.cpp
afxpopupmenu.cpp
afxpopupmenubar.cpp
afxpreviewviewex.cpp
afxpropertygridctrl.cpp
afxpropertygridtooltipctrl.cpp
afxpropertypage.cpp
afxpropertysheet.cpp
afxrebar.cpp
afxrebarstate.cpp
afxrecentdocksiteinfo.cpp
afxregpath.cpp
afxrendertarget.cpp
afxribbonbar.cpp
afxribbonbutton.cpp
afxribbonbuttonsgroup.cpp
afxribboncategory.cpp
afxribboncheckbox.cpp
afxribboncollector.cpp
afxribboncolorbutton.cpp
afxribboncombobox.cpp
afxribboncommandslistbox.cpp
afxribbonconstructor.cpp
afxribboncustomizedialog.cpp
afxribbonedit.cpp
afxribboninfo.cpp
afxribboninfo2.cpp
afxribboninfoloader.cpp
afxribbonkeyboardcustomizedialog.cpp
afxribbonkeytip.cpp
afxribbonlabel.cpp
afxribbonlinkctrl.cpp
afxribbonmainpanel.cpp
afxribbonminitoolbar.cpp
afxribbonpalettegallery.cpp
afxribbonpanel.cpp
afxribbonpanelmenu.cpp
afxribbonprogressbar.cpp
afxribbonquickaccesstoolbar.cpp
afxribbonslider.cpp
afxribbonstatusbar.cpp
afxribbonstatusbarpane.cpp
afxribbonundobutton.cpp
afxrichpreviewctrlimpl.cpp
afxsettingsstore.cpp
afxshelllistctrl.cpp
afxshellmanager.cpp
afxshelltreectrl.cpp
afxshowallbutton.cpp
afxsmartdockingguide.cpp
afxsmartdockinghighlighterwnd.cpp
afxsmartdockingmanager.cpp
afxsound.cpp
afxspinbuttonctrl.cpp
afxsplitterwndex.cpp
afxstandardcolorspropertypage.cpp
afxstate.cpp
afxstatusbar.cpp
afxtabbedpane.cpp
afxtabctrl.cpp
afxtabview.cpp
afxtagmanager.cpp
afxtaskdialog.cpp
afxtaskspane.cpp
afxtaskspaneframewnd.cpp
afxtls.cpp
afxtoolbar.cpp
afxtoolbarbutton.cpp
afxtoolbarbuttoncustomizedialog.cpp
afxtoolbarbuttonslistbutton.cpp
afxtoolbarcomboboxbutton.cpp
afxtoolbardatetimectrl.cpp
afxtoolbardropsource.cpp
afxtoolbardroptarget.cpp
afxtoolbareditboxbutton.cpp
afxtoolbarfontcombobox.cpp
afxtoolbarimages.cpp
afxtoolbarmenubutton.cpp
afxtoolbarmenubuttonsbutton.cpp
afxtoolbarnamedialog.cpp
afxtoolbarscommandslistbox.cpp
afxtoolbarscustomizedialog.cpp
afxtoolbarskeyboardpropertypage.cpp
afxtoolbarslistcheckbox.cpp
afxtoolbarslistpropertypage.cpp
afxtoolbarsmenupropertypage.cpp
afxtoolbarsoptionspropertypage.cpp
afxtoolbarspineditboxbutton.cpp
afxtoolbarstoolspropertypage.cpp
afxtoolbarsystemmenubutton.cpp
afxtooltipctrl.cpp
afxtooltipmanager.cpp
afxtrace.cpp
afxusertool.cpp
afxusertoolsmanager.cpp
afxvisualmanager.cpp
afxvisualmanageroffice2003.cpp
afxvisualmanageroffice2007.cpp
afxvisualmanagerofficexp.cpp
afxvisualmanagervs2005.cpp
afxvisualmanagervs2008.cpp
afxvisualmanagerwindows.cpp
afxvisualmanagerwindows7.cpp
afxvslistbox.cpp
afxwinappex.cpp
afxwindowsmanagerdialog.cpp
amd64
appcore.cpp
appdlg.cpp
apphelp.cpp
apphelpx.cpp
appinit.cpp
appmodul.cpp
appprnt.cpp
appterm.cpp
appui.cpp
appui1.cpp
appui2.cpp
appui3.cpp
arccore.cpp
arcex.cpp
arcobj.cpp
arcstrm.cpp
array_b.cpp
array_d.cpp
array_o.cpp
array_p.cpp
array_s.cpp
array_u.cpp
array_w.cpp
auxdata.cpp
barcool.cpp
barcore.cpp
bardlg.cpp
bardock.cpp
barstat.cpp
bartool.cpp
ccdata.cpp
cmdtarg.cpp
ctlcache.cpp
ctlconn.cpp
ctlcore.cpp
ctldata.cpp
ctlevent.cpp
ctlfont.cpp
ctlframe.cpp
ctlimpl.h
ctlinl.cpp
ctlinplc.cpp
ctllic.cpp
ctlmodul.cpp
ctlnownd.cpp
ctlobj.cpp
ctlpbag.cpp
ctlpict.cpp
ctlppg.cpp
ctlprop.cpp
ctlpropx.cpp
ctlpset.cpp
ctlpstg.cpp
ctlpstm.cpp
ctlquick.cpp
ctlrefl.cpp
ctlreg.cpp
ctltrack.cpp
ctlview.cpp
daocore.cpp
daodfx.cpp
daoimpl.h
daoview.cpp
dbcore.cpp
dbflt.cpp
dbimpl.h
dblong.cpp
dbrfx.cpp
dbvar.cpp
dbview.cpp
dcmeta.cpp
dcprev.cpp
dispimpl.h
dlgclr.cpp
dlgcomm.cpp
dlgcore.cpp
dlgdata.cpp
dlgdhtml.cpp
dlgfile.cpp
dlgfloat.cpp
dlgfnt.cpp
dlgfr.cpp
dlgprnt.cpp
dlgprntx.cpp
dlgprop.cpp
dlgtempl.cpp
dllinit.cpp
dllmodul.cpp
doccore.cpp
dockcont.cpp
dockstat.cpp
docmapi.cpp
docmgr.cpp
docmulti.cpp
docsingl.cpp
doctempl.cpp
dumpcont.cpp
dumpflt.cpp
dumpinit.cpp
dumpout.cpp
dumpstak.cpp
elements.h
except.cpp
filecore.cpp
filefind.cpp
filelist.cpp
filemem.cpp
fileshrd.cpp
filest.cpp
filetxt.cpp
filex.cpp
fixalloc.cpp
fixalloc.h
indicate.rc
inet.cpp
inetcall.cpp
l.chs
l.cht
l.deu
l.esn
l.fra
l.ita
l.jpn
l.kor
l.rus
list_o.cpp
list_p.cpp
list_s.cpp
map_pp.cpp
map_pw.cpp
map_so.cpp
map_sp.cpp
map_ss.cpp
map_wo.cpp
map_wp.cpp
mfcdll.rc
mfcintl.rc
mtcore.cpp
mtex.cpp
nolib.cpp
objcore.cpp
occcont.cpp
occddx.cpp
occddxf.cpp
occdlg.cpp
occevent.cpp
occimpl.h
occlock.cpp
occmgr.cpp
occsite.cpp
oleasmon.cpp
olebar.cpp
olebind.h
olecall.cpp
olecli1.cpp
olecli2.cpp
olecli3.cpp
olecnvrt.cpp
oleconn.cpp
oledata.cpp
oledisp1.cpp
oledisp2.cpp
oledlgs1.cpp
oledlgs2.cpp
oledlgs3.cpp
oledll.cpp
oledobj1.cpp
oledobj2.cpp
oledoc1.cpp
oledoc2.cpp
oledoccl.cpp
oledocip.cpp
oledocob.cpp
oledoctg.cpp
oledocvw.cpp
oledrop1.cpp
oledrop2.cpp
oleenum.cpp
oleexp.cpp
olefact.cpp
oleimpl2.h
oleinit.cpp
oleipfrm.cpp
olelink.cpp
olelock.cpp
olemisc.cpp
olemon.cpp
olemsgf.cpp
olepset.cpp
olereg.cpp
olestrm.cpp
olesvr1.cpp
olesvr2.cpp
oletsvr.cpp
oletyplb.cpp
oleui1.cpp
oleui2.cpp
oleunk.cpp
olevar.cpp
olevar1.cpp
oleverb.cpp
plex.cpp
prompts.rc
rawdllmainproxy.c
sockcore.cpp
sockexp.cpp
sockimpl.h
stdafx.cpp
stdafx.h
strcore.cpp
thrdcore.cpp
timecore.cpp
tooltip.cpp
trckrect.cpp
validadd.cpp
viewcmn.cpp
viewcore.cpp
viewedit.cpp
viewform.cpp
viewhtml.cpp
viewoled.cpp
viewprev.cpp
viewprnt.cpp
viewrich.cpp
viewscrl.cpp
winbtn.cpp
wincore.cpp
wincore2.cpp
winctrl1.cpp
winctrl2.cpp
winctrl3.cpp
winctrl4.cpp
winctrl5.cpp
winctrl6.cpp
winctrl7.cpp
winctrl8.cpp
winfrm.cpp
winfrm2.cpp
winfrmx.cpp
wingdi.cpp
wingdix.cpp
winhand.cpp
winhand_.h
winmain.cpp
winmdi.cpp
winmenu.cpp
winmini.cpp
winocc.cpp
winsplit.cpp
winstr.cpp
winutil.cpp

So, if anyone who tried it out, what's your opinion?

Not sure what you ask about. Backward compatibility? New features? Else?

[ahmd]

Thank you, fellas. And sorry for the delay...

@nuzzle: Yes, I agree that MFC is clearly a legacy stuff. I haven't looked into the new C++ 11 standard. As long as it has nothing to do with the .NET framework, I'm all for it.

@Igor Vartanov: Yes, Backward compatibility and New features is what I'd like to know. Also what's your overall take on it (MS VS 2012) in regards to C/C++?

[TheGreatCthulhu]

Regarding intellisense, VS is playing catch-up. Eclipse for example is way ahead in "everything at your fingertips" friendliness in general. This must be a major embarrassment for MS so you can expect improvements in VS 2012.

Any chance for some basic integrated refactoring tools for C++, to your knowledge? That would be awesome.

[superbonzo]

Backward compatibility and New features is what I'd like to know

take also a look here; regarding overall c++ support, see here and here.

[Igor Vartanov]

@Igor Vartanov: Yes, Backward compatibility and New features is what I'd like to know. Also what's your overall take on it (MS VS 2012) in regards to C/C++?

Well, I've rebuilt a couple of my MFC/ATL projects in VS2012, and everything went just fine. Another thing is that the projects are pretty much trivial in aspect of MFC use, though at least some level of backward compatibility is confirmed.

As for new features, unfortunately I cannot say anything certain. As I said before, I constantly drift off the Windows waters during last couple of years, so I'm about to start fearing of losing my C++ background.

Funny thing, this summer I've been interviewed in some local company, rather big one, and they said they actively hire C++ specialists... to retrain them to mobile developers, Android Java and iOS Objective C. Seems nobody needs pure C++ devs anymore.

[superbonzo]

hire C++ specialists... to retrain them to mobile developers, Android Java and iOS Objective C

... isn't this prohibited by the UN convention against torture ?

[Igor Vartanov]

... isn't this prohibited by the UN convention against torture ?

Well, they are fair enough, and ask you to agree to be tortured. "You know," they said, "there's no C++ project carries on right now..." Oh my, there are about two fifty heads in the company, and no C++ project in progress...

[ahmd]

@superbonzo: Thanks for the links.

@Igor Vartanov: I heard that there's an issue with XP support, which will be a major drawback for me. Although it seems like they fixed the issue with the size of executables built with VS 2012. I think I saw it somewhere in the superbonzo's links above. That is good.

As for your "Java and Objective C" comment then you'd be surprised how close those languages are to C. Java is pretty much what C# was modeled on and Obj-C is a superset of C (in other words code written in C will compile with an Obj-C compiler.) I actually like Obj-C way better. There's a slight learning curve for it but then it becomes very simple. I've been doing a lot of Obj-C for almost 2 years now. In my case I have to also make sure that the old C++ code continues to work in the current environment though. And I always get this "oh-man" feeling when I have to go back to a Windows platform for that...

[ahmd]

Found this link that may also have some relevance to my question:
http://channel9.msdn.com/Events/Build/2012/3-000

[OReubens]

Regarding the MFC I think you should be happy if you can still use them in VS 2012. MFC is definitely legacy now and to get MS to even mention them you'll have to torture a representative. The longer you stick to MFC the stronger you'll feel MS coercing you to move on to .NET and even better, Metro.

I will agree MFC is 'legacy' and in some area's it shows, but it is still very much alive and is getting updates and bug fixes (I have personally posted several bugs on MS connect, and most are solved, unfortunately some aren't going to get fixed >.<).
As much as MS wants, .NET doesn't solve everything, and neither does metro. Some applications just don't make a whole lot of sense as a metro app, or are even impossible to do. A key feature here is that metro apps don't "run" in the background, only 1 app is active at a time and all other apps get just a very small amount of time to update their 'tile'.
Any app that needs constant background processing won't work as a metro app.

MFC isn't going to see a lot of attention because it's nothing new. Even if they add new stuff, it's still "old". A LOT of apps are MFC based, MS can't just decide to stop supporting MFC anywhere soon.

Regarding intellisense, VS is playing catch-up. Eclipse for example is way ahead in "everything at your fingertips" friendliness in general. This must be a major embarrassment for MS so you can expect improvements in VS 2012.

[TheGreatCthulhu]

A bit off-topic, but I noticed an interesting statement on the page linked to by superbonzo (here):

C++/CLI IntelliSense. C++/CLI now has full IntelliSense support. IntelliSense features such as Quick Info, Parameter Help, List Members, and Auto Completion now work for C++/CLI. In addition, the other IntelliSense and IDE enhancements listed in this document also work for C++/CLI.

Finally!

[ahmd]

Yes, I agree about the Metro stuff. I watched some Channel9 demos about the "new" way MS want us to code their apps and I "got scared." All this talk of "can't run in the background", "only one app active", "time allotments for apps", "app can be terminated at any time" -- this is exactly what Apple does with their iOS. How do I know? Because I am an iOS developer. Why do I still program under Windows? Because Windows was one of those platforms where developers weren't restricted by the OS and it gave way more options to "improvise" in our code. So what now? We've got another clone...

MS can't just decide to stop supporting MFC anywhere soon.

The "scary" part is that it's not just MFC that is not supported under the new Windows RT platform, it is Win32 in general. Have you watched the video from that link I posted above. Somewhere in the middle where he runs the compatibility tool (that displays all illegal APIs under Win RT) he starts reading them from the list and the first one he mentions is LoadLibrary. Can you imagine writing a C++ piece of code without that API? Also GDI is gone, COM is strictly limited, etc.

I'm not sure how much of a future that Windows RT platform has, but if it takes off most of the Win32 APIs as we know them now will be a thing of the past.

[superbonzo]

anyway, note that all those forbidden APIs have a replacement where it makes sense and note that MFC GUIs make no sense in the metro environment, as other lowlevel APIs for good reasons.
And I'm very happy to see that standard C++ ( including things like <thread> and the extra <filesystem> ) do work on metro app. And I'm even more happy to see that whatever you can do in winRT + C++X you can do in WRL and standard C++. Correct me if I'm wrong, but this alone is much more than what Apple offers on iOS in terms of code "improvisability" and freedom.
Moreover, any existing GUI code will still need a restyling in order to be optimal for the metro user experience, whatever APIs it uses internally.

I'm not sure how much of a future that Windows RT platform has, but if it takes off most of the Win32 APIs as we know them now will be a thing of the past.

I don't think so, because you can always write whatever app you like with any language/techonology you like as long as it runs in the "usual" windows8 desktop environment. Yes, WindowsRT is limited to metro apps, but it represents only half of the MS platform on new tablet devices. IMO, this is a big difference compared to Apple's tablet offering.