John Maddock wrote: > > > The basic point was (IMHO) never answered. I tried to clean up the > > implementation by providing a closed implementation of is_class for more > > compilers. This should decrease the coupling of all the different parts. I > > think that this is a better design than the current one. The example I > > gave which I thought might show the local problem was wrong. My fault, > > granted. But does it speak against cleaning up the code? > > No, it's just that the version you posted only seemed to work with gcc - so > it makes for a more tangled is_class implementation.
It also works for the Intel (EDG-based) compilers (v6 and v7), as Intel kindly allows free personal home use. I never intended to write a GCC-only implementation. Bad luck it doesn't work for Win32-compilers :( > > is_member_function_pointer > > is not a secondary type category > > Which I have already said is a bug, but we need time to do a fix justice. Can't it be just moved to the primary-section or am I missing something here? Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
