[typeof] determining Boost Typeof support
Much of the core functionality of the mcs::units library coming up for review works without compiler support for typeof, but other parts require it. I looked through the docs and didn't find any way to explicitly check if typeof is supported, either natively or through Boost Typeof on any given compiler... Suggestions? Matthias
"Matthias Schabel" <boost@schabel-family.org> wrote
Much of the core functionality of the mcs::units library coming up for review works without compiler support for typeof, but other parts require it. I looked through the docs and didn't find any way to explicitly check if typeof is supported, either natively or through Boost Typeof on any given compiler... Suggestions?
If BOOST_TYPEOF_NATIVE is defined, BOOST_TYPEOF will work w/o type registration through either true native support of the compiler or MSVC-specific trick (in which case MSVC_TYPEOF_HACK is also defined). Otherwise, if BOOST_TYPEOF_EMULATION is defined, BOOST_TYPEOF will work through emulation for all registered types, templates, and their combinations. Otherwise <boost/typeof/typeof.hpp> is not included. HTH, Arkadiy
"Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote
If BOOST_TYPEOF_NATIVE is defined, BOOST_TYPEOF will work w/o type registration through either true native support of the compiler or MSVC-specific trick (in which case MSVC_TYPEOF_HACK is also defined).
Hmmm, I just noticed that this is not named correctly. Should be probably BOOST_TYPEOF_MSVC_HACK. This is not a matter of functionality -- just compliance to the macro naming rules... Will we have a chance to correct this in this release? Regards, Arkadiy
Arkadiy Vertleyb wrote:
"Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote
If BOOST_TYPEOF_NATIVE is defined, BOOST_TYPEOF will work w/o type registration through either true native support of the compiler or MSVC-specific trick (in which case MSVC_TYPEOF_HACK is also defined).
Hmmm, I just noticed that this is not named correctly. Should be probably BOOST_TYPEOF_MSVC_HACK. This is not a matter of functionality -- just compliance to the macro naming rules... Will we have a chance to correct this in this release?
Sorry, but no. Thomas -- Thomas Witt witt@acm.org
participants (3)
-
Arkadiy Vertleyb -
Matthias Schabel -
Thomas Witt