Making progress - got example1 to work, but needed
#if defined (_MSC_VER) # pragma warning(push) # pragma warning(disable: 4100) // 'source' : unreferenced formal parameter #endif
to avoid a blizzard of warning messages.
As I mentioned earlier, I don't have access to a current Visual C++ compiler, but I'm happy to add relevant warning suppressing #pragmas...sounds like it doesn't like me naming arguments in template declarations...
Might be helpful to enable demangling only if gcc? (Doubt if Borland is up to the mpl part?)
I've put two preprocessor switches in the utility.hpp header that should allow you to have more fine-grained control over the use of and method for demangling : if the source file has a #define MCS_USE_DEMANGLING, the standard C++ ABI demangler is used, while #define MCS_USE_BOOST_REGEX_DEMANGLING uses both the standard demangler and boost.regex to clean up the resulting mpl typenames to make them a bit easier to read. In any case, this stuff is probably only interested to people who are interested in the guts of the dim analysis code, since it is all hidden by the unit/quantity classes... Anyway, you can replace the utility.hpp header in mcs/units with the attached one, then comment out the #define at the top of unit_example_1.hpp to eliminate demangling completely. Does anyone know if GCC is the only compiler to support demangling? If it is, I will just put all the demangling stuff inside the #ifdef __GNUC__ as Paul suggests...
Example 2 still doesn't work (as noted by Deane).
Deane's last post indicated that he now had all tests running...am I wrong, Deane?
Do you need a using boost::mpl::size_t;? to resolve the ambiguity?
I think it's the opposite problem - the cxxabi.h header has a bunch of references to size_t that aren't qualified with std::. Anyway, I think the problem went away (again, per Deane) when I moved my using namespace boost::mpl; inside the boost::units namespace. Again, please correct me if I'm wrong... Thanks for the input. Matthias