template instantiation question

[mop65715]

Consider

# include <iostream>

template < typename value_type >
struct your_policy {
 static
 value_type write_to_register ( value_type value ) {
   return ( 1 );
 }
 static
 value_type read_from_register ( value_type value ) {
   return ( 2 );
 }
}; // your_policy

template < typename value_type >
struct our_policy {
 static
 value_type write_to_register ( value_type value ) {
   return ( 3 );
 }
 static
 value_type read_from_register ( value_type value ) {
   return ( 4 );
 }
}; // our_policy

template < typename unsigned_type, typename policy >
struct lets_see {
public: // only for testing
 lets_see () 
 {}

 static
 unsigned_type & dummy ( void ) {
   static unsigned_type x;
   return ( x );
 }

public:

 lets_see & operator= ( unsigned_type const val ) {
   dummy() = policy< unsigned_type >::write_to_register( val );
   return ( *this );
 }

 operator unsigned_type ( void ) const {
   unsigned_type result = 
      policy< unsigned_type >::read_from_register( dummy() ) ;
   return ( result) ;
 }

};

I'd like for the user to be able to specify the desired policy during template instantiation. For instance:

int main ( void ) {

  lets_see < unsigned int, your_policy < unsigned int > > a; 
  lets_see < unsigned int, our_policy  < unsigned int > >  b; 
  a.dummy() = 5; 
  std::cout << a << '\n';
  std::cin.get(); 
}

I'm getting errors though that I'm unsure how to resolve. How would I achieve this?

[Paul McKenzie]

 lets_see & operator= ( unsigned_type const val ) {
   dummy() = policy< unsigned_type >::write_to_register( val );
   return ( *this );
 }

 operator unsigned_type ( void ) const {
   unsigned_type result = 
      policy< unsigned_type >::read_from_register( dummy() ) ;
   return ( result) ;
 }

The policy in this context doesn't need a template argument. That is the error that Comeau C++ reports.

The lets_see struct shouldn't be templatizing the policy as your code is doing. The lets_see struct has no idea what the policy is, but you're giving it template arguments within the lets_see struct, as if lets_see knows more about the policy argument than it should.

Those arguments were already taken care of in main() when you instantiated the template. This code compiles correctly using Comeau:

# include <iostream>

template < typename value_type >
struct your_policy {
 static
 value_type write_to_register ( value_type value ) {
   return ( 1 );
 }
 static
 value_type read_from_register ( value_type value ) {
   return ( 2 );
 }
}; // your_policy

template < typename value_type >
struct our_policy {
 static
 value_type write_to_register ( value_type value ) {
   return ( 3 );
 }
 static
 value_type read_from_register ( value_type value ) {
   return ( 4 );
 }
}; // our_policy

template < typename unsigned_type, typename policy >
struct lets_see 
{
public: // only for testing
 lets_see () 
 {}

 static
 unsigned_type & dummy ( void ) 
{
   static unsigned_type x;
   return ( x );
 }

public:

lets_see & operator=( unsigned_type const val ) 
{
   dummy()=policy::write_to_register( val );
   return ( *this );
 }

 operator unsigned_type ( void ) const {
   unsigned_type result = 
      policy::read_from_register( dummy() ) ;
   return ( result) ;
 }

};

int main () 
{

  lets_see < unsigned int, your_policy < unsigned int > > a; 
  lets_see < unsigned int, our_policy  < unsigned int > >  b; 
  a.dummy() = 5; 
  std::cout << a << '\n';
  std::cin.get(); 
}

Regards,

Paul McKenzie

[mop65715]

The policy in this context doesn't need a template argument. That is the error that Comeau C++ reports.

For starters, thanks Paul. Two questions:
a) Can you show me a context where it does matter?
b) On an slightly unrelated note. Consider the case where the layout defined in a requirements document is as follows:

[ 0..3 ] (Hd 1 = 0x0)
[ 4..7 ] (Hd 2 = 0x0)
[8..11] (Hd 3 =0x0)
[12..15 ] (Hd 4 =0x2).

Where the HD representation is the field names and MSB is bit 0. When I read this data from _raw_ memory I obtain 0x0002. Trouble I'm on a little endian machine so as part of my policy class the raw value gets converted to 0x0200. In doing so HD 2 is now a 2 which does not align with the requirement. That tells me the requirements document claim of MSB being bit 0 is FALSE. To me if the implementation that's transmitting the data is sending the data with MSB being bit 0 (big endian) and I'm on a little endian machine. That translation will result in HD 4 on an LE not being set to a 2 but to a zero and HD2 will equate to a 2. Am I off on this?