Announcing a major MFC update plus TR1 support

Announcing a major MFC update plus TR1 support

  • Comments 43

As an update to Visual Studio 2008, we’re pleased to announce a major new release of the Microsoft Foundation Classes (MFC).  Using these components, developers will be able to create applications with the “look & feel” of Microsoft’s most popular applications – including Office, Internet Explorer and Visual Studio.  Some of the specific features include:

·         Office 2007 Ribbon Bar:   Ribbon, Pearl, Quick Access Toolbar, Status Bar, etc.

 

·         Office 2003 and XP look:  Office-style toolbars and menus, Outlook-style shortcut bar, print preview, live font picker, color picker, etc.

 

·         Internet Explorer look:  Rebars and task panes.

 

·         Visual Studio look: sophisticated docking functionality, auto hide windows, property grids, MDI tabs, tab groups, etc.

 

·         Vista theme support:  Dynamically switch between themes!

 

·         “On the fly” menus and toolbar customization:  Users can customize the running application through live drag and drop of menu items and toolbar buttons.

 

·         Shell management classes:  Use these classes to enumerate folders, drives and items, browse for folders and more.

 

·         + many additional controls

 

In addition, we will also be delivering TR1 support.  Portions of TR1 are scheduled for adoption in the upcoming C++0x standard as the first major addition to the ISO 2003 standard C++ library. Our implementation includes a number of important features such as smart pointers, regular expression parsing, new containers (tuple, array, unordered set, etc), sophisticated random number generators, polymorphic function wrappers, type traits and more!  We are not currently shipping C99 compatibility or support for special math functions. 

While we’re announcing these today, please note they won’t be final until Q1CY08.  Since we know you want to get your hands on them, we’ll have a beta sometime near the first of the new year.  The components will be available to all Visual Studio 2008 Standard and above customers.   This is just the first step in our drive to improve the native development experience.  There’s a lot more that we’re working on, but we hope you enjoy this first milestone.

There’s a lot more to tell you about the MFC libraries so keep watching this blog for more information!  You should also check out Pat Brenner’s video on Channel 9 where he talks about the new libraries.  You can also read what Soma had to say at http://blogs.msdn.com/somasegar/archive/2007/11/09/visual-c-libraries-update.aspx.

Visual C++ Development Team

  • [Nemanja Trifunovic]

    > Thanks! That's great information.

    > But why did I find about it by accidentally checking out the VC++ dev blog?

    Because our _SECURE_SCL/_HAS_ITERATOR_DEBUGGING messaging hasn't been detailed enough.

    [jalf]

    In my experience, STL-heavy code has indistinguishable performance in VC8 SP1 with _SECURE_SCL enabled and GCC 4.2.1. Certain constructs are significantly impacted by _SECURE_SCL (my worst-case example from an arithmetic encoder slows down by 10x-22x), but these aren't common.

    Making people fear the STL is bad. However, people feared the STL long before VC8, and they fear it with other compilers too. _SECURE_SCL is not the root of all evil.

    Had I worked at Microsoft when _SECURE_SCL was implemented (I didn't), and had I been responsible for deciding whether to enable or disable it by default (as a dev, I don't get to decide such things), I might have decided to disable it by default. Personally, I think that it is hard to commit heap overruns and other problems with the STL if you know what you're doing. (In contrast, knowing what you're doing generally won't stop you from committing buffer overruns and other badness with C-style code.) I prefer to assume that programmers will be knowledgeable but human (there is really no way to stop bad programmers from writing bad code, and C++ doesn't go down that road). In practice, not all C++ programmers know how to use the language and library as well as they should, so committing security errors with the STL is probably more common than I'd like to expect. Hence, I can see the rationale for the on-by-default decision.

    That's my only point: that the enabled-by-default setting is not *unreasonable*. You are free to disagree with it (and like I said, I lean in that direction too), but the purpose of the default isn't to scare people away from using the STL.

    > I see posts by people online every day, who say "I know I've

    > been told to use the STL, but it's just too slow.

    I doubt that this is because of _SECURE_SCL.  I'd tend to expect that those people are doing something egregiously wrong (my favorite is compiling in debug mode - argh - or maybe copying vectors when they should be passing by const reference).

    > Don't you think it is a serious problem if developers shy away from the STL completely?

    Yes, that would be bad.

    > It's everyone who overly fear it (or rather, fear the performance characteristics they observe in STL code because of it), who are the issue.

    In my experience, people who avoid the STL do so because of exception handling.  (Exception denial frustrates me greatly.)

    > Why is windows.h so absolutely horrible?

    > [...] the whole #define hell you have going now?

    Here, "you" = "not VC". windows.h is part of the Platform SDK; while it ships with VC, it's not maintained by VC.

    > Or just a WindowsEx.h which does the most obvious fixes, such as not defining the min/max macros

    Define NOMINMAX before including windows.h, and then it won't stomp all over <algorithm> and friends.

    [Derrick]

    > "what exactly do you plan to use 'export' for that you cant do now??"

    > Better code organization.

    There's nothing stopping you from doing that right now.  Remember, you can declare templates before defining them, and you can even stick the definitions in sub-header files.

    Templates *inherently* cannot be separately compiled.  What export does isn't separate *compilation* in the usual sense.

    > Rather than even giving a time frame, apparently the standard is so unimportant

    > that it is not even on the radar as one developer said he wants "export to be erased from human memory".

    I'd like to point out a few things:

    1. I'm not a compiler dev.

    2. I'm not a compiler PM, or anyone else who is involved with deciding what to implement.

    3. I consider the Standard extremely important...

    4. ... except for export.

    5. VC has *massively* increased its conformance from VC6, through VC7.1, to VC8 and now VC9.

    Maybe Microsoft should print T-shirts - one saying "IMPLEMENT EXPORT NOW" and another saying "DOWN WITH EXPORT". I sense a billion-dollar business on the horizon...

    Stephan T. Lavavej

    Visual C++ Libraries Developer

  • Stephan wrote:

    -I consider the Standard extremely important...

    -... except for export.

    Extremely important, but apparently not important enough to be standard conformant which includes export. An implementation is either conformant or non-conformant; there is no middle-ground. While it is impressive that "VC has *massively* increased its conformance", if MS is not prepared to fully implement the standard, even in future versions, that is of course your prerogative. But at least have the courage to say that standard conformance is not a priority. And if you are not implementing the C++ standard, then what exactly are you implementing and what is the C++ in the name "Visual C++"?

  • """An implementation is either conformant or non-conformant; there is no middle-ground."""

    IMHumbleO, wrong.

    There's a lot of middle ground. A non-conformant compiler must be fixed, but with reasonable priorities.

    """Not everyone know that these macros exist in the first place. (You could at least make them configurable in project settings)""" [2]

  • ikk,

    I agree with Derrick. A compiler is either conformant or non-conformant. The so-called "middle-ground" is moderate leeway given to compilers that fully intend to become more compliant in future versions. However, Microsoft has made it clear that they are not interested in implementing the standard (which includes export). Thus, in future versions, they will still be non-conformant. It's been nine years already without any progress, but perhaps if they would give a general target for implementing export, the situation can be reanalyzed.

  • For some programming languages, every compiler is non-conforming.

    For some languages including C, every program on the face of the earth is a conforming compiler, whether or not it was intended to be a compiler.  Also every program that has been exported from earth is a conforming C compiler.  Some of us wish that the limits section would be debugged to change this, but meanwhile it's a fact.

    Nonetheless, when we know what the standard is trying to say that we should do, and if other parts of the standard don't prohibit it, then we ought to try.

  • I don't think I would buy a "Implement export now" T-shirt, but unlike most other posters above requesting export, I wish it was in VC++ because its absence is costing me a lot of time, daily, juggling around with code rearrangement.

    Yes, you can theoretically rearrange code so that all your templates definitions can be found at link time, while keeping build time reasonable. However, my bet is that you have not been through this exercise for real, because if you did, you'd find that WITHIN a compiler, it's an easy job, but accross 2 vendors and over years of maintenance spanning several major updates, it's a nightmare.

    This morning I just added into Borland 2007 the use of some tiny IO function for the F80 type... I'm still trying to link it. It worked fine with BCB6, fine also with VS8 beta 2, but I can't have it link in my current configuration. Although I agree that in this case it's a Borland problem, each vendor has their "smart template" link policy that just drives me nuts. Plus, because of VC's lack of support for export, I cannot use Borland's.

    Yes, I could rearrange 13 years of code so that we stick to just one vendor. Give me better marshalling between .NET and native C++, and I'll consider using WindowsForms instead of VCL (high on my list: stress test of the new marshalling functions of VS8 once it's out of beta). Give me some really good MFC facelift and I give up VCL (it better be good... I have no idea how anything based on MFC could even get close to the productivity of VCL, but I'm willing to try).

    ...or give me export and I am a happy multi-vendor customer.

    Note: I had template link nightmares within one vendor, when moving from BCB1 to BCB3 for example... This is not a vendor problem, just a lack of norm for template link that transforms the "rearrangement" workaround into a trial-and-error build workout.

  • For thos who still insist on an implementation of export "for completeness's sake", you should give the "Export Restrictions" articles by Herb Sutter a serious read.

    Part 1: http://www.ddj.com/cpp/184401563

    Part 2: http://www.ddj.com/cpp/184401584

    (Apologies for resurrecting a weeks-old thread, but I just discovered this while arguing with a co-worker about the same subject.)

  • There are no "export restrictions".

    As the article explains, that is how export was designed and standardized. Nothing more and nothing less.

    I want it because it is part of the standard. It has been part of the standard for almost a decade. Other compilers (Comeau, Borland) implement it, but since VC++ does not it is difficult to compile standard-compliant code with multiple compilers. Asking for standard compliance should not be so unreasonable.

  • Thank you very much for the link to this superb article. I was unaware of all these issues, and now I understand the "... and there is export" comment of the blog author in a post above, which without the proper explanation of Herb Sutter's article, sounded pretty much like a smartxxx remark at best, I'm sorry to say.

    I realize now that my link problems are more or less poor behavior of linkers over large programs, not solvable by the use of export. So please, disregard my earlier post of Nov 21.

    Still, can you (and CodeGear's) guys stop and work this out once for good? I shouldn't have to solve linker problems in 2007 by shuffling compilation order, dup(multip)licating explicit instantiations, regroup .obj files into smaller libraries and more generally rain dance around my computer. Thank you.

  • [Phidias]

    > now I understand the "... and there is export"

    > comment of the blog author in a post above

    I should have simply linked those articles, or Sutter's "Why We Can't Afford Export" paper, in the first place.

    Shame on me for trying to argue from first principles instead of citing authorities.

    > Still, can you (and CodeGear's) guys stop and work

    > this out once for good? I shouldn't have to solve

    > linker problems in 2007 by shuffling compilation

    > order, dup(multip)licating explicit instantiations,

    > regroup .obj files into smaller libraries and more

    > generally rain dance around my computer. Thank you.

    I'm not sure what you're talking about.  It sounds like you're working with a broken library.

    The inclusion model "just works" when you define templates in headers.  Explicit instantiations are generally never necessary.

    The linker could certainly have bugs, but I'd suspect a broken library first.

    Stephan T. Lavavej

    Visual C++ Libraries Developer

  • Stephan,

    > I should have simply linked those articles, or Sutter's "Why We Can't Afford Export" paper, in the first place.

    >Shame on me for trying to argue from first principles instead of citing authorities.

    What authority? Like it or not, the simple undeniable fact is that export *is* part of the C++ standard. No matter what argument you make against it, a compiler that does not implement it is non-compliant.

    Sutter and others tried to get export removed from the standard. That was rejected by the standard committee.

    The only way out of implementing export is for Microsoft to declare that VC++ is not a C++ compiler and thus exempt from implementing the C++ standard.

    You can claim to care about standards if you only selectively implement the parts that you like and omit the others.

  • I have to agree with Craig here. I don't really care about export myself, however, I do care that Microsoft is at least intending to conform to standards. Simply by definition, if Microsoft is not going to implement export, then they should not claim to be standards compliant. For this particular case, it makes sense to me for the community to modify the standard in the future, and that Microsoft be a part of this effort. They shouldn't sit in a corner and force everyone to do it 'their' way. Ever hear of blowback?...

    With all that said, I applaud Microsoft for continually working to improve the compiler and their libraries. I've definitely seen the quality go up of the past decade. Compliance has gotten closer, which is good because in some cases, VC++ would simply be out of the running.

    I wonder how Microsoft can determine what their customers want. If they look at whether or not developers buy and use their tools, then they will be misguided in believing that what they (the compiler/library people) are doing is a good thing. This is because, many times, organizations are forced into using Microsoft tools given the company's monopolistic nature. From my perspective, the development tools coming out of Microsoft are pretty much the best out there. So, obviously you guys are doing something right.

  • Don&#39;t take me wrong, I do love C# and managed code, but often we need to develop in C++ and for good

Page 3 of 3 (43 items) 123