The final release of the Visual C++ 2008 Feature Pack is now available for download. This release provides several exciting features for C++ developers, such as a major update to MFC and an implementation of TR1. These features are fully covered under Microsoft’s standard support policies.
The Feature Pack is available free of charge to any Visual Studio 2008 Standard or above customer. The download can be found at http://www.microsoft.com/downloads/details.aspx?FamilyId=D466226B-8DAB-445F-A7B4-448B326C48E7&displaylang=en.
Using the included MFC components, developers can create applications with the “look & feel” of Microsoft’s most popular products – Microsoft Office, Visual Studio and Internet Explorer. Some of the interesting MFC components in the Feature Pack 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.
· Visual Studio look: sophisticated docking functionality, auto hide windows, property grids, MDI tabs, tab groups, etc.
· Internet Explorer look: Rebars and task panes
· Vista theme support
· “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
More information on our new MFC support can be found at the sites below:
MFC documentation & walkthroughs http://msdn2.microsoft.com/en-us/library/bb982354.aspx
Channel 9: New Updates to MFC http://channel9.msdn.com/showpost.aspx?postid=355087
TR1 (“Technical Report 1”) is a set of proposed additions to the C++0x standard. Our implementation of TR1 contains a number of important features such as smart pointers, regular expression parsing, containers (tuple, array, unordered set, etc) and sophisticated random number generators.
More information on TR1 can be found at the sites below:
TR1 documentation http://msdn2.microsoft.com/en-us/library/bb982198.aspx
Channel 9: Digging into TR1 http://channel9.msdn.com/showpost.aspx?postid=385821
TR1 slide decks (recommended) http://blogs.msdn.com/vcblog/archive/2008/02/22/tr1-slide-decks.aspx
This Feature Pack is only supported on systems which have the English language (ENU) version of Visual Studio 2008 Standard Edition or above installed. Support for systems with non-English versions of Visual Studio 2008 installed will be available with Visual Studio 2008 Service Pack 1.
The documentation for this feature pack has already been added to MSDN online and will be included with the local MSDN documentation with SP1.
Enjoy all this new functionality!
Visual C++ Development Team
> Could you let us know what kind of changes you made so that we can reproduce the issue on our side.
I'm actually not touching anything when this happens. As I stated originally, I'm just running through the MFC app wizard.
I'm choosing almost all the default values, with the exception of the first page of the wizard. There, I choose the following:
Application type: Single document
Document / View architecture: enabled
Resource language: English
Use unicode libs: enabled
Project sytle: Office
Visual style and colors: Office 2007 (Blue theme)
Enable visual style switching: enabled
Use of MFC: Use MFC in a static lib
On every subsequent page of the wizard, I just go with the default values. Once complete, I build the application (rebuild all) and hit F5.
This results in an assertion firing on line 3891 of afxribbonbar.cpp, which is this line:
The ENSURE macro then throws an unhandled exception that terminates the app.
I haven't yet tried any other project types.
Hope that helps.
> But I'm trying to test out the random number
> generation that is part of TR1, and no dice.
When you create a new MFC project, it "helpfully" adds "#define new DEBUG_NEW" (see http://msdn2.microsoft.com/en-us/library/tz7sxz99.aspx ).
However, this is incompatible with the Standard (and TR1) headers. Paragraph 184.108.40.206.1/2 [lib.macro.names] of the C++ Standard states:
"A translation unit that includes a header shall not contain any macros that define names declared or defined in that header. Nor shall such a translation unit define macros for names lexically identical to keywords."
(When the Standard says "header", it means the Standard headers like <vector>. The Standard uses "source file" to refer to everything else, including files that end with .h or .hpp and that get #included. This is different from ordinary terminology.)
What 220.127.116.11.1/2 is saying is very reasonable - you're not allowed to stomp on the Standard headers with macros. Unfortunately, that's exactly what "#define new DEBUG_NEW" does. The result is horrible compiler errors.
Within an MFC project, you can include <random> (and other Standard and TR1 headers), as long as you do so from "clean" source files - that is, source files that don't define "macros for names lexically identical to keywords" (and so forth) either before OR after the Standard/TR1 headers are included. (Be careful of PCHs that drag in such macros.)
Stephan T. Lavavej
Visual C++ Libraries Developer
Thanks, Stephan - I appreciate the info. Works now.
'When you create a new MFC project, it "helpfully" adds "#define new DEBUG_NEW" (see http://msdn2.microsoft.com/en-us/library/tz7sxz99.aspx ).
However, this is incompatible with the Standard'
My questions here are academic until VS2008 SP1 comes out, but please say if I understand correctly.
(1) A workaround is to delete the line "#define new DEBUG_NEW".
(2) This is a bug in the wizard which might be a fix or might be a won't fix for VS2008 SP1.
By the way, is there a target yet for which year most language versions of VS2008 SP1 might be released?
> (1) A workaround is to delete the line
> "#define new DEBUG_NEW".
Yes, insofar as that stops stomping on the Standard/TR1 headers. I'm not sure how that affects the MFC side of things. (The danger here is presumably using the MFC leak tracking in some translation units and not in others, leading to heap corruption when they pass pointers to each other. It does appear that the MFC leak tracking is optional, according to MSDN - the new project wizard is simply enabling it by default. So, if you really get rid of all occurrences of this macro, you should be fine.)
> (2) This is a bug in the wizard which might be a
> fix or might be a won't fix for VS2008 SP1.
According to my understanding, the wizard has always done this, and it's always opened up the 18.104.22.168.1/2 can of worms - TR1 just happens to trigger actual breakage.
(IIRC, other Standard Library headers attempt to defend themselves against "new" being macro-ized - but if you ask me, we should actually detect and #error when any keywords are macros, rather than defending against it. We do defend against "min" and "max" being macros, but that's because <windows.h> defines them.)
"#define new DEBUG_NEW" is operating by design, and the wizard is enabling it by design. The design just happens to be extremely unfriendly to the Standard headers. (As co-maintainer of the headers being stomped on, this is not my favorite macro.)
> By the way, is there a target yet for which year
> most language versions of VS2008 SP1 might be
I'm not sure what you're asking. VC9 SP1 (any language) has not yet been released, and I don't think we've talked about release dates yet (although we certainly have them in mind).
I can say that it is not yet too late to get fixes for Horrible TR1 (and MFC) Bugs into VC9 SP1, *if* they are reported promptly enough (and the bugs are horrible enough, and the fixes safe enough, etc.).
Stephan T. Lavavej, Visual C++ Libraries Developer
>> By the way, is there a target yet for which year most language versions of VS2008 SP1 might be released?
> I'm not sure what you're asking. VC9 SP1 (any language) has not yet been released
The English language version of VS2008 SP1 might not be urgent, I don't know. Other language versions are comparatively more urgent, because of the promise that the VC++2008 Feature Pack will not be released until SP1. Therefore I asked if there's any target on what year we'll get them.
I don't believe there were any dates published yet regarding VS2008 SP1. I will make sure to post those dates as soon as I have them.
> I'm actually not touching anything when this happens. As I stated originally, I'm just running through the MFC app wizard.
Thanks for clarifying the repro steps for the wizard bug you've been seeing. We did find this in our testing, but too late for the Feature Pack release.
There is a simple work-around, which is to include afxprint.rc along with afxribbon.rc in the RC file for your wizard-generated project.
I've tried running the Boost regression tests against the release feature pack, and while a lot of the problems from the Beta have
been fixed, there are still a few left:
One of the Random tests is failing (http://tinyurl.com/5lt4u7) because of a missing "seed(integer-type s)" member function in xor_combine.
When i mentioned this on the Boost list, it was thought that this was a 'bug' in TR1 due to Table 16 saying that all random number
engines should have that member, but the description of xor_combine not mentioning it.
However, the TR1 spec is also missing this seed member from discard_block, and i see that the feature pack implementation contains it
anyway. So, is the missing function from xor_combine an oversight?
One of the Regex tests is failing (http://tinyurl.com/6ktl8c) due to a problem with a char_class_type typedef.
When i asked about this on the Boost list, the response was that it looks like a feature pack bug:
There are some Bind failures (http://tinyurl.com/5edo35) due to a missing member result_type definition.
Anyone got any thoughts?
I can raise bugs on Connect if they are considered bugs on the feature pack side.
I have been using the beta release of the service pack for the last few months and have successfully update my VC 6.0 programs. I like the new looks.
HoweverI just downloaded and installed the new service pack and now I am getting compile errors such as:
afxcontrolbar.h(25) : error C2084: function 'BOOL IsStandardCommand(UINT)' already has a body
afxcontrolbarutil.h(24) : see previous definition of 'IsStandardCommand'
afxcontrolbar.h(54) : error C2011: 'CMemDC' : 'class' type redefinition
afxcontrolbarutil.h(54) : see declaration of 'CMemDC'
afxbasetabbedpane.h(108) : error C2143: syntax error : missing ';' before '*'
afxbasetabbedpane.h(108) : error C2433: 'CBaseTabbedPane::CMFCAutoHideBar' : 'virtual' not permitted on data declarations
It seems like the new service pack did not install properly over the beta. Any suggestions on how to correct this without completely reinstalling Visual Studio 08 and then running the feature pack install? This would take hours. Is it possible to uninstall the feature packs only?
> I've tried running the Boost regression tests
> against the release feature pack
Awesome! Your bug reports from running the tests against the Feature Pack Beta were really helpful.
> So, is the missing function from xor_combine an
That appears to be the case. (It doesn't help when the TR1 spec contains thinkos.)
We're trying to conform to TR1 + obvious thinko fixes + selected C++0x backports, and this appears to fall under "obvious thinko fix". Please file a Connect bug for this.
> One of the Regex tests is failing
> (http://tinyurl.com/6ktl8c) due to a problem with a
> char_class_type typedef.
Our std::tr1::regex_traits<T>::char_class_type is a typedef for int. TR1 7.2/4 requires that char_class_type be a bitmask type, and [lib.bitmask.types] C++03 22.214.171.124.2/1 explains that "Each bitmask type can be implemented as an enumerated type that overloads certain operators, as an integer type, or as a bitset".
Can you explain what the conformance problem is here? I don't understand what the Boost test is complaining about.
> There are some Bind failures
> (http://tinyurl.com/5edo35) due to a missing member
> result_type definition.
This is a known bug, but it was discovered too late (Feb 7) to be fixed in the Feature Pack. The internal bug number is Dev10.391723.
Feel free to E-mail me directly (email@example.com) if you encounter any other issues.
> Please file a Connect bug for this.
>Can you explain what the conformance problem is here?
Theres a confirmation on whats happening @
Basically, the Boost test is using the VC9 basic_regex along with a Boost traits class, and it's failing because the traits class uses a bitset for char_class_type, which the VC9 basic_regex can't handle.
The same post also contains a simple example of an apparent problem in tr1::result_of.
typedef int (&func_ref)(float, double);
typedef std::tr1::result_of<func_ref(float,double)>::type result_type;
Doesnt compile with the feature pack result_of, but is fine with the Boost version.
Using the Feature Pack in Visual Studio 2008 (<regex> library) I am getting the following linker error:
error LNK2019: unresolved external symbol "void __cdecl std::tr1::_Destroy(class std::tr1::_Node_base *,enum std::tr1::_Node_type)" (?_Destroy@tr1@std@@YAXPAV_Node_base@12@W4_Node_type@12@@Z) referenced in function "public: virtual __thiscall std::tr1::_Node_assert::~_Node_assert(void)" (??1_Node_assert@tr1@std@@UAE@XZ)
When I was using the beta distribution of the Feature Pack I was getting no linker errors.
If I comment out the following line, the linker error disappears:
So, this is associated with the regex constructor which takes a const string. If I use the default constructor, the linker error disappears, also.
> error LNK2019: unresolved external symbol "void __cdecl std::tr1::_Destroy(
Somehow, you're using the Feature Pack Beta headers with the Feature Pack RTW (Release To Web, i.e. final) binaries. std::tr1::_Destroy() in Beta was renamed to std::tr1::_Destroy_node() in RTW, in order to fix a memory leak.
Installing the Feature Pack RTW over the Feature Pack Beta isn't supported. You have to uninstall the Feature Pack Beta (which I am told is robust) before installing the Feature Pack RTW.