Nowadays, I'm working on a framework library for asynchronous i/o operations. When we designed the interfaces of this library, we thought passing a callbackable delegator to the member functions is good to the user, and of course it is also a very cool, clear designing:).
But, as you all know, there are many candidates in C++ that is suitable for our requirement: normal function pointers, class's static member function pointers, member function pointers, and, those amazing functors. Since all we want to provide is a common library that can be ported across different architectures, different OSes, and of course, different compilers, it is a MUST pre-condition that we should be REALLY clear with some compiler's tricky on implementing these facilities (of course, HOW-TO encapsulating those 4 above candidates into an unified interface is also another important pre-required skill, but this is not the case here). After some researching, I've learned that it is very hard to be familiar with the member function pointers, not because of its odd syntaxes, but because of its implementations by different compiler vendors. For example, you can hardly tell what size it a member function pointer if you don't know what compiler you will be on and what compiler option you'll use, huh, fantastic? Please reading this marverous
post written by Don Clugston. IMHO, there are many odd designing provided by C++, such as multi-inheritence, virtual inheritence, member function pointers, template-template parameters, etc., and member function pointers should be obvious one of the most nastiest ones. Whenever you want use it, please be extremly careful that you won't drive yourself into trouble.
powered by performancing firefox
