From: daniel.kruegler@googlemail.com   
      
   On 2011-08-11 04:07, Carlos Moreno wrote:   
   >   
   > Hi,   
   >   
   > Is the use of the curiously recurring template pattern   
   > necessary for an implementation of expr. templates?   
      
   No.   
      
   >  From what I understand, it does seem to make the   
   > coding easier; but in the situation where I'm using   
   > it (which unfortunately I can't post actual code,   
   > since I'm working under NDA --- for now, at least),   
   > I'm being victim of an elusive bug, and my main   
   > suspect is that there may be something strange   
   > with the way the CRTP is applied in my case.   
   >   
   > The basic idea with the CRTP is to have one class   
   > representing expressions, and its operands are   
   > instances of this very class --- parameterized by   
   > the specific type of expression). So, how about   
   > using the specific type of expression instead,   
   > and have different classes having different   
   > operands as data members, with utility functions   
   > a la make_pair, which use function overloading   
   > to return the correct type for the object. (I know   
   > with the example of vectors arithmetic it sounds   
   > absurd, given the large amount of combinations   
   > of operations --- but in my case, the number of   
   > operations is much lower, so I think it wouldn't   
   > be that insane to try eliminating the CRTP)   
   >   
   > Of course I could simply try, but I figured if there is   
   > some fundamental reason why it has to be done   
   > that way, someone out here would know and maybe   
   > I could save the trouble of trying to find myself in a   
   > dead-end.   
   >   
   > Thanks for any comments!   
      
   When I wrote my first matrix and vector classes I became inspired by The   
   remark in Bjarne Stroustrups book "The C++ Programming Language" where   
   he describes in section 22.4.7 (I refer to the fourth edition in German)   
   about temporary objects, copies, and loops. The trivial example is a   
   lightweight lazy result type   
      
   struct MVmul {   
     const Matrix& m;   
     const Vektor& v;   
     MVmul(const Matrix& mm, const Vektor& vv) : m(mm), v(vv) {}   
         [..]   
   };   
      
   used for the multiplication operation   
      
   inline MVmul operator*(const Matrix& mm, const Vektor& vv) {   
     return MVmul(mm, vv);   
   }   
      
   and the Vektor class that can be initialized or assigned to by above   
   result type:   
      
   class Vektor {   
     //...   
   public:   
     Vektor(const MVmul& m) {   
       mul_and_assign(this, &m.m, &m.v);   
     }   
     Vektor& operator=(const MVmul& m) {   
       mul_and_assign(this, &m.m, &m.v);   
       return *this;   
     }   
     //...   
   };   
      
   as well as combinations with other operations, e.g.   
      
   struct MVmulVadd {   
     const Matrix& m;   
     const Vektor& v;   
     const Vektor& v2;   
     MVmulVadd(const MVmul& mv, const Vektor& vv) : m(mm.m), v(mv.v),   
   v2(vv) {}   
         [..]   
   };   
      
   inline MVmulVadd operator+(const MVmul& mv, const Vektor& vv) {   
     return MVmulVadd(mv, vv);   
   }   
      
   etc. This worked quite well for a reasonable amount of supported   
   expressions. You need to decide whether this is sufficient for your   
   purposes.   
      
   Even the standard library makes above form of expression templates   
   visible in the description of std::valarray when referring to   
   std::slice_array, std::gslice_array, std::mask_array, and   
   std::indirect_array.   
      
   HTH & Greetings from Bremen,   
      
   Daniel Krügler   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)