Printable View
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.Quote:
Originally Posted by ahmd
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.
Code: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
Not sure what you ask about. Backward compatibility? New features? Else?Quote:
So, if anyone who tried it out, what's your opinion?
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++?
Any chance for some basic integrated refactoring tools for C++, to your knowledge? That would be awesome.Quote:
Originally Posted by nuzzle
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.Quote:
Originally Posted by ahmd
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. :D
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. ;)
... isn't this prohibited by the UN convention against torture :D ?Quote:
Originally Posted by Igor Vartanov
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...Quote:
Originally Posted by superbonzo
@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...
Found this link that may also have some relevance to my question:
http://channel9.msdn.com/Events/Build/2012/3-000
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 >.<).Quote:
Originally Posted by nuzzle
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.
Quote:
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.
A bit off-topic, but I noticed an interesting statement on the page linked to by superbonzo (here):
Finally!Quote:
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.
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...
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.Quote:
MS can't just decide to stop supporting MFC anywhere soon.
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.
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 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.Quote:
Originally Posted by ahmd
Oh, I hope they fix that IntelliSense, or at least make it "as good" as it is for C# in VS2010.Quote:
Originally Posted by TheGreatCthulhu
@superbonzo: Obviously they will introduce new APIs that make sense for the tiled interface. The issue here is a distinction between a mobile and a desktop OS. In case of iOS they made it pretty clear that that is a mobile operating system that behaves in a totally different way than a desktop OS (which, unfortunately now is slowly pushed into a mobile realm as well, but is still not as "mobile-looking" as Windows RT/8.)
In a mobile OS limited multitasking, time and resources allotment, battery savings, etc. is quite appropriate. Also UI for a mobile OS is a totally different beast due to the screen size limitations. But most of the above make no sense to be introduced to a desktop OS. For instance, a full screen app with giant buttons looks ridiculous on my 30-inch display.
So, if Windows RT is designed as a mobile OS (something to run only on phones and small tablets) then, yes, all that tiled interface API limitations make perfect sense. But, what I'm afraid will happen, is that users on Windows RT will begin to expect full desktop app performance due to its identical look to the Windows 8 Pro or Enterprise, which in turn will flood developers' tech support lines with questions like this, "Why can't I run your program on my new Windows 8?" Note that for an end-user there will be no distinction between Windows RT or Windows 8. Both will look the same for them.
So obviously, since those OS's are totally different beasts on the inside, we, developers, won't be able implement most of the features that any C++ developer is familiar with -- stuff like "real" multithreading, services, IPC, etc. And if all you're doing is a picture viewer, then you're in good shape. Anything more complex will make it incompatible with Windows RT... and that is not what people would expect from Windows. So that is what's disturbing to me...
But I'm deviating from the original subject now... So concerning VS 2012, it sounds like there're some improvements.
Quote:
Originally Posted by ahmd
There is nothing scary here. If you code for metro, you are effectively coding for a tablet and not a PC. And users have different expectations of tablets than for desktop apps.
* People accept that a desktop takes some time to boot and load a feature heavy OS. They expect a tablet to be responsive the second you turn it on.
* Tablets run wireless, so need to run on batteries, this means conservative approach to CPU usage AND to which cpu's a tablet manufacturer will use. (Intel Core i5/i7 aren't particularly battery friendly). Tablet apps need to be 'lightweight' because of this.
* metro is the new buzzword. But rest assured, the desktop in windows isn't getting dumped anywhere soon.
As a software developer, you make choices, if you decide to go win32, then yes, it will over time become harder to convince your users that is the right choice for them, they may very well expect a metro interface.
By choosing Win32, you are restricting yourself to intel windows, and not the new windows 9 arm based machines. (which don't have Win32 or a desktop).
It should be possible to make an Win32 based back end, and connect to that from a metro front and control your win32 backend from the Metro front (haven't tried). A big thing/anoyance here from a sales P.O.V. is that you'll HAVE to sell your metro front on the windows store, while the Win32 will have to be sold/installed "the usual way". This may be confusing for your users.
Metro and desktop are different beasts that just happen to run side by side on the same PC. Some apps won't make much sense in the one environment and other apps won't make much sense in the other.
There's clearly a trade-off between desktop and mobile hardware. Intel's Core i5 and i7 might be inefficient for a mobile device but on the other hand ARM CPUs with their RISC architecture would not do well in a desktop world. Plus there's not even a solid 64-bit standard for ARM yet.
In my view I don't see any reason why we all should move to a mobile architecture? Even though I do enjoy using my iPad for recreational means, I still do most of my "serious" computer use on a desktop with a large display, don't you? (Although it is not Windows.)
As for Windows 9 ditching Win32, then it would probably be the time when Windows joins RIMM's BlackBerry ...
I've been hearing about MFC being legacy for years now. I'm thinking that that rap is more urban legend and MSFT wishful thinking than anything else. The other day I downloaded and installed Samsung's Kies program, which allows Samsung's SmartPhone to connect to the PC. Guess what one of the files that was downloaded was? MFC90u.dllQuote:
Originally Posted by nuzzle
Sure, MSFT would just love everyone to program windows in C# with the WPF framework. Just ain't gonna happen.
Like I already said. MFC isn't going anywhere soon. if you have MFC programs, rest assured that MS will continue to pprovide the platform AND will be making improvements to it (in recent versions we got quite a bit of new classes as well as bug fixes).
OTOH. don't expect microsoft to blow a huge amount of advertisement budget on MFC. Not gonna happen. They're also not goign to be promoting it much. They're in the bussiness of selling NEW stuff (and supporting the old quietly). And I mean "selling" both in the literal way of making money, as well as 'pitching' new technologies to users/developers to move to something new because they have a stake in that technology and competitors might not (as much).
@OReubens: What's funny (or I guess, not so funny for developers) is that MS seems to come up with a new programming technique with every release of Windows. For instance, I don't even hear about dot-net anymore. It's all about those Metro-style apps. But they even botched that up... we can't call it Metro anymore because of a German trademark infringement. It's a "new tiled interface" :)
No, it's called "modern windows" apps. :)
And yes. .NET is "old news" as well these days. Again, it will be supported for many many more years to come, but they can't really promote this as "new" anymore. Maybe if some radical change happens, it'll be news again, but for the most part, they'll just assume everyone knows what .net is, that it's there on the machine and you can use it.