Re: Something about template , static interface and Concept.

Because of my poor English, I think the source code is the best
way to express what i mean.

But, I was wrong!

What i want are the advices of my strange design and
ask for any more grace solutions.

Here is my explain of the code.

1, what is the term "Interface" mean ?
      In C++ the traditional dynamic interface is an pure virutal
class.
   It has NO any real functions, only typedef and pure virtuan
functions
   in it.

      // The example of dynamic interface.
      class dynamic_interface
      {
      public:
        typedef int type_0 ;
        typedef long type_1 ;
        typedef float type_2 ;
        typedef double type_3 ;

        // it is very necessary to has a virtual dector.
        virtual ~dynamic_interface( void ) {}

        virtual void function0( void ) = 0 ;
        virtual void function1( void ) = 0 ;
        virtual void function2( void ) = 0 ;
        virtual void function3( void ) = 0 ;
      } ;

    The dynamic interface is widely used by Microsoft's COM, DirectX

2, The dynamic interface mechanism take full use of the polymorphism
of C++.
    On can write the code like this to use dynamic interface.
        void use_dynamic_interface( dynamic_interface* ptr )
        {
          if( ptr )
          {
            // Here, we do not know what the real type of the ptr
pointing to.
            // The only thing we know is the ptr represent an object
that
            // "Implemented" the interface.
          }
        }

3, In many circumstance, the dynamic interface is overkilled,
especially
    in the realm of Generic Programming. So Boost lib and the other
Great Minds
    use "static interface". I think "static interface" is just another
name of
    the "Generic Concept".

4, Boost lib provide a concept_check lib to support the compil-time
checking.
    But I think my solution is simpler ( But not as strong as boost. )

    In my design, the "Static interface" has two version,
       The one is a proxy to the real implementation class,
    and the other is a "filter" to the implementation class.

           The former turns any call over to the implementation
class.
       The aim is to provide a stable interface to the user.
           The latter filter-out any functions that do not belongs to
the
       interface.

     The template class si_root has two versions of partial
specialization respectively.

5, The ugly macros are designed to be used to combine many "static
interface" into one.

6, Now, here is the use of the "static interface" :

       // This empty sub-class "create" a compound interface that
support the
       // four static interfaces : si_0, si_1, si_2, si_3.

       template< typename T >
       struct my_interface
         : public typedef STATIC_INTERFACE_4( T, si_0, si_1, si_2,
si_3 )
       {
       } ;

       // Now, use the "static interface":
       // NOTE:
       // It is very like the function in item 2

       template< typename T >
       void use_dynamic_interface( my_interface<T>& i )
       {
          // Here, we can call any functions in the interface
          // si_0, si_1, si_2, si_3.

          // and use any typedefs in the inteface
          // si_0, si_1, si_2, si_3.
       }

7, Now, here is the use of the "Concept" version:

       // I want a class that support interfaces : si_0, si_1, si_2,
si_3,
       // to be the base class of my design:
       template< typename T_Base >
       class my_design : public STATIC_CONCEPT_4( T_Base, si_0, si_1,
si_2, si_3 )
       {
         // here, we can say that the base class has the following
features:
         // a) it has four methods :
         // void function0( void ) ;
         // void function1( void ) ;
         // void function2( void ) ;
         // void function3( void ) ;

         // b) it has four typedefs
         // typedef xxx type_0 ;
         // typedef xxx type_1 ;
         // typedef xxx type_2 ;
         // typedef xxx type_3 ;

       } ;