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

  • Nice to see more exciting features moving into C++. Thanks for all the efforts

  • Loving it! Better late than never.

  • Kudos to MS for not waiting until the next edition of VS to add these features.

  • I will appreciate the addition of TR1.

    However, I am a little disappointed that parts of C++0x, which is not completely finalized, are being implemented before the existing 1998 (superseded in 2003) standard is fully implemented.

    Noticeably missing is 1) export, 2) two-phase name lookup, and 3) exception specifications.

    I must question your priorities and dedication to standards.

  • Auf der TechEd wurde die Katze aus dem Sack gelassen. Ale Contenti stellte die neuen Features der MFC

  • [Brian K]

    > Noticeably missing is 1) export, 2) two-phase name lookup, and 3) exception specifications.

    > I must question your priorities and dedication to standards.

    A few points to consider:

    A. Libraries != compiler. You're talking about Core Language conformance issues. Fixing them would require front-end compiler work (and potentially some back-end). Resources (libraries dev time) spent on TR1 couldn't be spent on language conformance. Devs aren't interchangeable cogs! :-)

    B. Resources aren't free, and I can think of plenty of compiler bugs that affect the day-to-day work of programmers much more severely. Compiler fixes are more expensive than you might expect, because Intellisense has to be taught to understand whatever the actual compiler understands.

    C. export isn't necessary. Evidence item #1: the two major C++ compilers, VC and GCC, don't support export and have made no movements towards supporting export. Any program that can be compiled with VC or GCC doesn't need export. Evidence item #2: any program using export can be trivially rearranged into a program not using export. Whether you think export is *useful* is another matter (I am of the opinion that it is not useful, given the complexity that it introduces), but it's certainly not necessary.

    D. Two-stage name lookup, which is closely related to export, is rather obscure. I personally would like to see it implemented, but I've never come across a use for it.

    E. The consensus of the modern C++ community is that exception specifications aren't useful.  Boost doesn't use them, etc. If you ask me, this is the most significant of the conformance issues that you mention, but it doesn't affect code that doesn't use exception specifications (which should be just about everything).

    Not only are there many compiler bugs that I'd like to see fixed before the issues you mention, there's also lots of C++0x features I'd like to see in VC10. They would benefit a lot more programmers (and the Standard Library) in terms of code clarity and performance.

    Thanks,

    Stephan T. Lavavej

    Visual C++ Libraries Developer

  • I would like to see improvements to the linker option Eliminate Unreferenced Data, so that any unused functions and/or data is not included in the final output. I did mention this while VS2005 was in beta and was told that this feature already worked correctly, but unfotunately I didn't have time to reply then. This is simply not true though, as is nicely demonstrated y the following article on CP:

    http://www.codeproject.com/library/tlibc.asp

  • Stephan,

    I am of a similar opinion as Brian K.

    The very first thing that I do with a new compiler to gauge standards compliance is to try export. VC++, just like GCC, always fails. However, Comeau C++ and Borland Builder X do implement it. Next I usually test exception specifications. And the story continues from there, usually not so good for VC++.

    Quote:

    -"export isn't necessary"

    -"Two-stage name lookup [...] is rather obscure"

    -"[...] exception specifications aren't useful."

    While I disagree, I respect your opinion. However, like it or not, the undeniable fact is that these are all part of the standard. If you only implement the parts that you like or which are convenient, then you can not claim to care about standard conformance.

    Export, for example, has been in the standard for almost a decade. And there is still "no movements towards supporting [it]". Rather, you are beginning to implement TR1 from C++0x, which isn't even finalized yet. As Brian wrote, your priorities and dedication to standards should be reviewed.

    "Compiler fixes are more expensive than you might expect, because Intellisense has to be taught to understand whatever the actual compiler understands."

    Non sequitur. Intellisense is an IDE feature. VC++ is a compiler separate from any IDE. While Intellisense is useful, it is not necessary to compile code. I still laugh about how the VB team changed the LINQ syntax just to get better Intellisense. Absolute nonsense.

    The expense in compiler fixes is in ensuring that older code, possibly even incorrect, still compilers correctly. This occasionally requires the need for extra command switches etc.

    > Resources (libraries dev time)

    > spent on TR1 couldn't be spent

    > on language conformance.

    I had assumed that Microsoft would be licensing the Dinkumware implementation, which is reportedly complete. Is this incorrect? Or is there further work required to work with VC++?

    The general tone of my post may seem negative. However, I am well aware of the conformance improvements made in the last few versions and must applaud your efforts for that. However, it is the big issues mentioned above and their lack of priority that I find most troubling.

    > They would benefit a lot more

    > programmers (and the Standard

    > Library) in terms of code clarity

    > and performance

    Clarity, yes, but correctness before performance. There is nothing more correct than the standard.

  • "Compiler fixes are more expensive than you might expect"

    In that sentence the word "you" means ...... OK, let's see, what does the "K" stand for?

    "Intellisense has to be taught to understand whatever the actual compiler understands"

    It does?  When did that happen?  (And if Intellisense really has that improvement then, at the risk of going off-topic, may I ask if the debugger does too?)

    "any program using export can be trivially rearranged into a program not using export"

    Any program using "for" can be trivially rearranged into a program not using "for".  Athough this discussion has involved a mix of standardization and other issues, I think this question concerned standardization, so rearrangement isn't an answer.  Even if it's like trigraphs, i.e. even if no one in the world likes it, I think this question concerned standardization.

    By the way, at risk of going off topic again, I'll ask a question about standardization too.  Will "void main" finally get a warning?

    (The reason I don't ask if the concatenation

    L"wide string" "narrow string"

    will finally get a warning is that I've already been told that's a "won't fix".)

  • Sorry for a bug in my previous comment.  To the best of my recollection

    L"wide string" "narrow string"

    properly gets a warning (or maybe an error) and the "won't fix" is for something roughly like this:

    L    "this shouldn't be a wide string but will be, and it should get a diagnostic but won't"

  • [Craig]

    > The very first thing that I do with a new compiler to gauge standards compliance is to try export.

    I can think of many better things to try.

    > However, like it or not, the undeniable fact is that these are all part of the standard.

    To be clear: I personally want two-stage name lookup and exception specification support.  (I also want export to be erased from human memory - I don't always get what I want.)

    > And there is still "no movements towards supporting [it]".

    Riddle me this: why doesn't GCC support export?

    > Rather, you are beginning to implement TR1 from C++0x, which isn't even finalized yet.

    Are you seriously arguing that export is more useful than TR1?  (Disregarding the fact that compiler devs aren't library devs and vice versa.)

    The most important missing thing in C++98-minus-export isn't export, it's shared_ptr.

    > Non sequitur. Intellisense is an IDE feature. VC++ is a compiler separate from any IDE.

    > While Intellisense is useful, it is not necessary to compile code.

    It is our policy to have Intellisense and the actual compiler support the same code.  As it stands, Intellisense is actually powered by a variant of the actual compiler. (Parsing C++ is hard!)

    To fend off responses of "but they don't actually support the same code" - yes, we know that Intellisense has bugs. Many bugs. We're working on that.

    (I myself don't use Intellisense because I don't use the IDE to edit or compile code, but everyone else does.)

    > I had assumed that Microsoft would be licensing the

    > Dinkumware implementation, which is reportedly complete.

    We are, and it is.

    > Or is there further work required to work with VC++?

    As ever, development is not as simple as it might seem.  :-)

    For example, we had to add TR1 to our build system (getting the source files picked up into the DLL/LIB and getting the headers/sources copied to the right directories in setup). We had to make TR1 work with /clr. We've had to make the TR1 headers (and their regression tests) /analyze-clean. We're fixing correctness and performance bugs. And we have to add IDE visualizers for TR1 types. I've even found defects in TR1 along the way (Library Issues 726 and 727).

    Dinkumware's implementation is great, and they're awesome to work with. But there's lots of VC-specific work to do, and everything benefits from having extra eyes look at it.

    > However, it is the big issues mentioned above and their lack of priority that I find most troubling.

    In the end, priorities are determined by seeing what the VC team thinks is most valuable in addition to customer feedback. So if you think something is important, keep mentioning it to us!  :-)

    (Honestly, though, you'll have much better luck with Anything But Export.)

    [Norman Diamond]

    > Any program using "for" can be trivially rearranged into a program not using "for".

    That's a logic change.

    > Will "void main" finally get a warning?

    I wish!  (I complain bitterly every time I see that particular heresy.)

    Stephan T. Lavavej

    Visual C++ Libraries Developer

  • Hello Stephan,

    Why do you hate export so mutch?

    Why don't you love standard so mutch?

    SzL

  • [Laszlo Szoke]

    > Why do you hate export so mutch?

    It doesn't buy me anything, and it costs a lot.

    Doesn't buy me anything: Export doesn't unlock magical powers of templates. It "maybe" speeds up builds (some say yes, some say no, I say PCHs), and it enables "a different style of code organization" which I find utterly worthless.

    Costs a lot: It's difficult for compiler writers to implement. It's also difficult to understand all of its consequences. C++ is already difficult enough to understand, being jam-packed with useful features.

    > Why don't you love standard so mutch?

    Oh, I love the Standard (I also love capitalizing it). That doesn't mean that I love everything in the Standard unconditionally.

    There are things that I adore (everything that makes the STL possible). Things that are complicated, but useful (overload resolution, template argument deduction). Things that I haven't found uses for in my own code, but that are definitely useful (virtual inheritance). Things that I'm not too fond of, but understand the reasons for their existence (things for C compatibility, like the conversion rules). Things that I think should always be avoided (C casts, shadowing). Things that might be useful, but are often abused (the ability to replace the global allocation and deallocation functions). Things that seemed like a good idea at the time, but we know better know (auto_ptr, mem_fun, bind1st). There are plain ugly things that will hopefully disappear (stuff lurking in Annex D). And then there is export.

    "Why export? Well, the Standard Library had vector<bool>, so the Core Language felt lonely..."

    Stephan T. Lavavej

    Visual C++ Libraries Developer

  • Hello Stephan,

    Any chance of removing checked iterators from the Release mode and the "security warnings" when calling some standard C and C++ functions? After all, if we cared for security more than performance we wouldn't use C++ ;)

  • [Nemanja Trifunovic]

    > Any chance of removing checked iterators from the

    > Release mode

    You can disable "iterator checking" in Release mode by defining _SECURE_SCL to 0 . However, you must be VERY CAREFUL. There are rules that you must follow in order to avoid violating the One Definition Rule. If you aren't familiar with ODR violations, the most important thing about them is that they are extremely, horribly bad.

    I described the rules here: http://blogs.msdn.com/vcblog/archive/2007/08/10/the-future-of-the-c-language.aspx#4617984

    I must stress that rule #2 applies to all of your separately compiled libraries, such as Boost.

    Note that "iterator checking" (_SECURE_SCL) is usually not that expensive, especially when you avoid handwritten loops in favor of STL algorithms, which you should be doing anyways.  It's "iterator debugging" (_HAS_ITERATOR_DEBUGGING), obtainable in Debug mode only, that is expensive.

    > and the "security warnings" when calling some

    > standard C and C++ functions?

    Disable warning 4996.

    > After all, if we cared for security more than

    > performance we wouldn't use C++ ;)

    It is possible to be both secure and performant.

    Stephan T. Lavavej

    Visual C++ Libraries Developer

Page 1 of 3 (43 items) 123