In VC++ Express, use "Tools | Settings | Expert Settings" so you have access to the "Property Manager" in the View menu.
VS2010 needs new .vcxproj projects, and no longer allows Tools | Options | VC++ Directories. So now every project includes a smartwinprop.props that does the same thing. However, it does not support relative paths, so you must manually edit it so it points into your directory structure.
Edit the <IncludePath> and <LibraryPath> in
Use File | New | Project | Visual C++ Projects, and then select the Win32 Project template close to the bottom. Select a directory and then enter a project name. In Application Settings, check "Empty project", and press Finish.
Use the menu option: View | "Property manager", and expand your new project. For both debug and release, Right click, and "Add Existing Property Sheet". Select smartwinprop.props from the smartwin directory.
Use the Menu option " View Solution Explorer"
Right click on the project for Properties.
Click on "Common Properties" | "Add New Reference", and add Smartwin. (Assumes a Solution with Smartwin project.)
Click on Configuration Properties. Then set C/C++ | Language | Enable Run-Time Type Info to Yes (/GR) for both Debug and Release.
Set C/C++ | Code Generation | Run time Library to Multi-threaded Debug, and Multi-threaded (Release) (Smartwin and your project must use the same)
Set General | Character Set Library to Multi-Byte, (Debug and Release) (Smartwin and your project must use the same)
Add a .cpp file for your program.
Now would be a good time to build the debug and release versions to check your entries.
Programs compiled in VS2010 release mode worked perfectly. However Microsoft's pointers_to_members #pragma would cause a program to crash in debug mode if part of it was compiled with the pragma, and part without.
The solution adopted was to require /vmg for all SmartWin projects, and removed the #pragma. Since "smartwinprop.props" is now required for SmartWin projects on VS2010, /vmg was placed in that file.
Definition: Use /vmg to declare a pointer to a member of a class before defining the class. This need can arise if you define members in two different classes that reference each other. For such mutually referencing classes, one class must be referenced before it is defined.
Near the top of file include\SmartWin\Smartwin.h there is: // We also need to tell the compiler that it needs to link pointer to members as // virtual multiple inheritance pointers. We generally want as little as possible // of Project Settings therefore we set this directly in the code instead of // forcing the library user to set lots of different settings before managing to // compile his project. #pragma pointers_to_members( full_generality, virtual_inheritance )
The pragma will affect how pointers_to_members (PTM) types are implemented. By default the compiler would try to figure out the best way to represent the PTM, with the above pragma settings, any PTM that follows will have the general representation. Crt headers contain some PTM type functions, in our case ostream file has a few instances of this. One source file (stream_err.cpp) includes Smartwin.h which later also includes CRT headers like ostream. The code generated for stream_err will have PTM implemented in the general representation. Another source file (application.cpp) does not include the pragma but has similar CRT headers. The code generated for application.cpp will have PTM implemented based on the compiler decisions (if compiler can find enough info on PTM then it will choose the best case, else choose general case). The linker will take the obj files and will choose one of the PTM implementations (since their names and signature are the same). The AV occurs because a routine will call the PTM routine assuming to have a return value represented in one way but it is represented in another way.
This issue can be fixed in your source code in different ways. If you really need the pragma then I suggest either making the pragma consistent to all source code or to limit it to only places to where it applies. One question that came up during investigation is if you really need this pragma? I believe having __inheritance keywords to the classes can be a better way of enforcing the class to be treated as virtual_inheritance (http://msdn.microsoft.com/en-us/library/ck561bfk(VS.80).aspx) .