Visual Cee Plus Plus

A rich, well-textured and full-bodied editor, coupled to a pitiful implementation of a powerful and almost very expressive language.

Are you referring to the version in Visual Studio .NET here? As I understand it, the newest C++ compiler is much closer to true standard-compliance.

Part of VisualStudio


Ironically, a couple of years ago while still in JobSearch? mode, I took a pair of online skill/knowledge evaluation tests. The job requirement included C++ so the pimp -- uhm, headhunter -- had me take the C++ test. I was a little rusty (having spent the whole of the prior year doing data warehouses) but didn't score too badly. The ... uhm, headhunter then realized that the requirement said "Visual" and had me take the other online test (same authoring company) for Visual C++ to "be more correct."

I got killed on that test. There were maybe 6 questions that had anything to do with C++ while the rest were all about MFC, interfacing to VB, and other MicroSoft component questions.

It's wryly funny that a page with this title has about the same actual C++ related content. -- GarryHamilton

That is funny - I've been using Visual C++ for the past five years writing traightforward Win32 programs. My bookshelf has the Microsoft exam study guide for Visual C++, and I've hardly used anything in it. Never had a use for MFC, ActiveX objects, VB interfaces, or the wizards. I like the IDE, but the really useful stuff is customizing it and memorizing the shortcuts. MFC reliance is one of the worst code smells. In my opinion, the exam is a scam to get money and foist questionable standards on developers. One could have ten years C++ experience, but be "beaten" by a neophyte who toed the Microsoft PR line and only learned what would be obsolete in a year. It's a terrible test for C++ proficiency or Visual C++ experience. I'd worry about any projects where the company wanted "an MFC expert". See DeathMarch.

See also MicrosoftCertifiedProfessional.


[Moved from PoorCppProgrammers; given the identities of the authors and the time since they've frequented WikiWiki, this information may be out of date.]

MicroSoft Visual C++ isn't bad. It isn't all that good either, but it isn't bad: It has some convenient features.

I'd say it isn't horrible, but is bad. It has some bletcherous features, and several big compliance issues. The latter is enough to downgrade it today.

Compliance is relatively unimportant for some people. Me for one. VC++ is, overall, the best C++ compiler on the market. Using a loose definition of C++ since it isn't compliant :-)

I wish they would do variable declarations in for statements properly. Not that it makes any difference in my code, but the fact that their application programmers have written lots of bad code seems like a poor excuse for defying industry standards.

variable declarations in for statements, templates, STL, etc. etc. standard C++ is a better language that what is available to VC++ users, and that is a shame.

My biggest gripe is over reliance on the preprocessor rather than using the language itself. Much of MFC programming is done is a pseudo-language that few understand, but low and behold, it compiles to normal C syntax expressions.

Visual C++ in VS DotNet is 100% STL and C++ library compliant (see ScottMeyers Appendix A of his excellent EffectiveSTL). We took highly templatized code with heavy use of templates, template member functions, partial specification and it ported right over with no changes. We don't use MFC. We use StandardTemplateLibrary. -- Anonymous Hey, that's great news. MS dragging it's heels on STL was a real problem for us. I guess once .net settles down I will have another look. Does it handle member templates properly yet? Yes, I used them yesterday And the variable declaration problem described above? Yes Is the standard namespace done properly as well? Yes

Again, please read Scott Meyers in EffectiveStl where he has a chapter for getting around Visual C++ 6.0's problems and if you use VC++ 7 (DotNet) he says "ignore this whole chapter". He wrote his book on this compiler. The people I work with were using Metrowerk's compiler on Windows because of all these problems but as I said they were very surprised that it's all gone in 7.0

-- sg

Well, all of the above is good news. I did a little digging around, and it seems MS has solved their library problem in typical MS fashion, they bought one that was done right (not that this is necessarily a bad thing!). Unfortunately, the compiler itself still needs work, as for example partial template specialization still doesn't seem to work. If I am wrong about the that, I would love to know it! It seems that you (Sam) claim to have used it (if that is what you meant by template 'specification'), but the stuff I tried (on a friends beta version) didn't work at all!

[MS has never written it's own STL - they've always packaged the Dinkum STL. Dinkum has steadily improved over the years, the reputation for a poor STL implementation has more to do with the length of time between the release of VS 6 and VS .NET than anything else.]

How is "managed" C++ 100% compliant with any standard?

Just 'cos it's VC.NET doesn't mean that it's managed.

Here we go again. There is *nothing* that says you have to write managed code. If you want to write code that runs under the managed CLR with garbage collection and have it be non-standard with the C++ standard, then use the Managed Extensions. If not, like us, the *default* is unmanaged and you can write completely standard compliant code with STL compliance and have it run on multiple platforms. Our code runs on Palm, Mac and unmanaged Windows .NET (unchanged and with full StandardTemplateLibrary). By writing interface wrappers we have extended it to to interface with managed CsharpLanguage on MicrosoftDotNet but by *our* choice. You can take advantage of the better compiler and the complete STL compliance only and never deal with the managed stuff. It's your choice, not Microsoft's. -- sg

If you are writing anything beyond text book examples, what choices do you have on a Microsoft platform? I believe the only option you have to write pure C++ code is by using the raw Windows API set. It is true Microsoft did not fully eliminate that option, but it is certainly not practical. So where is the choice? What is really irritating is none of the Microsoft extensions are necessary, all of them could have been done quite well within the C++ language. What are the alternatives to the Windows API, MFC, or .NET for handling keyboard and display?

What are you talking about? All of the standard C++ mechanisms for input and output work with MS C++. Obviously, you don't get access to the GUI this way, you're restricted to command line applications. Are you even a C++ programmer? Managed C++ is an extension of C++ that is compiled to the .NET framework - no, managed C++ cannot be compiled to native (x86) code. You don't have to use managed C++ unless you want to write C++ code targeting the .NET platform. If you don't, which covers most people, then you get a quite good compiler and a decent STL. That's all. --ChrisMellon?

If you are writing anything beyond text book examples, what choices do you have on a Microsoft platform? I believe the only option you have to write pure C++ code is by using the raw Windows API set. It is true Microsoft did not fully eliminate that option, but it is certainly not practical.... Well, gee, I dunno, but I've been writing real, revenue-generating Windows apps, both GUI and command-line, using the Win16 and/or Win32 APIs (sometimes with some abstractions on top, but nothing nearly as enormous as MFC or .NET) for over 10 years, and I don't see where it's any less practical today than it was then. -- MikeSmith


Here's a message from a MS guy that lists the non-compliance issues. Don't know if I got the hyperlink right. Search for "Remaining compliance issues for VC 7.0" on Usenet. http://groups.google.com/groups?q=g:thl1248883294d&hl=en&selm=OjjSh71qAHA.2164%40tkmsftngp02

-- AndrewQueisser

We have found the following work as standard:

 14.1 Reference Non-Type template parameters (also 14.3.2)

- 14.5.2 User-Defined Conversion Templates

- 14.5.4 Partial Specialization of Class Templates

- 14.5.5.2 Partial Ordering of Function Templates

- 14.6 Dependent Names

- 14.7.1 Nested Classes in Class Templates

- 14.7.3 Explicit Specialization of Member Templates

- 15.4 Exception Specifications

I can only imagine this was an early message. ScottMeyers has found the STL compliance to be 100%. From Appendix A of ScottMeyers EffectiveStl: "If you are using Visual C++ .NET, your STL platform doesn't have the problems described below and you may ignore this appendix."

-- sg

BTW, all these are fixed and implemented in ManagedCeePlusPlus, also known as Visual C++ .NET 2003 (aka Everett). All of ISO/ANSI implemented except for Export Template.


There are alternatives, both gratis and FreeSoftware, to Microsoft's VisualCeePlusPlus if you want to program with the MicrosoftWindowsApi:

If you want to use an IntegratedDevelopmentEnvironment, DevCpp is a useful one: http://www.bloodshed.net/devcpp.html. It includes MinGW, but can be configured to work with other compilers, as listed at http://www.bloodshed.net/compilers/.

http://www.digitalmars.com/ has a free c++ compiler that is noted for producing very fast results


See MicrosoftFoundationClasses, ClassWizard, NanoCppUnit


EditText of this page (last edited November 13, 2014) or FindPage with title or text search