Re: [eigen] Eigen::Complex attempt

[Mark Borgerding <mark@xxxxxxxxxxxxxx>]

Benoit Jacob wrote:
> 2009/6/17 Mark Borgerding <mark@xxxxxxxxxxxxxx>
>   
> > I just started out by trying to see if I could make the Complex class have an operator & which returns a "pointer object" that could be converted to either
> > Eigen::Complex<T> *
> > or
> > std::complex<T> *
> > That worked and then I just didn't know when to quit.  So now here is a Complex class that has a superset of the std::complex interface and actually uses std::complex whenever it can.  It has more accessors and mutators.
> >
> > http://bitbucket.org/mborgerd/eigen2_for_fft/src/tip/unsupported/Eigen/Complex
> >
> > Note the structure packing should be identical (assuming the C++ standards folks are correct in their assessment that "All existing implementations already have the layout proposed here."  http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387 )
> >     
>
> Ah, thanks a lot for finding this link! This is enough to make me OK
> to make this assumption.
>
> If I understand well, your aim is to make Eigen::Complex entirely
> interoperable with std::complex, and the tricky part was indeed to
> handle pointers, good job.
>
> (I'm not yet able to really review anything).
>
> Benoit
>   


To be honest, I think I may have wasted my time duplicating the entire 
std::complex interface.  If I had stopped to think for a moment, I think 
I would've chosen to simply derive the Eigen::Complex<T> class from 
std::complex<T>. 
The avoidance of subclassing an STL type is so deeply ingrained in me 
that it simply never occurred to me.

If we are willing to buck convention, there are some  goodreasons to 
make Eigen::Complex a subclass of std::complex:

   * Complex should support all the same functions that std::complex
     has, plus more
   * current attempt already assumes same structure size & packing
   * reduce testing workload
   * reduce lines-of-code footprint
   * remove possibility that a trivial operator/method wrapper will NOT
     be optimized away

Here are reasons we might NOT want to make Eigen::Complex a subclass of 
std::complex

   * If we cannot assume a compliant std::complex (note current effort
     assumes this)
   * If we cannot assume a compatible structure packing (see above
     discussion)
   * If we need destructor actions for Eigen::Complex ( std::complex
     destructor is not virtual)
   * If we wish to override and change the behavior of a std::complex
     operator (seems like a good way to anger users)
   * IIRC, method name resolution gets error-prone, e.g. if we make a
     Complex::real() method, then name lookup rules will not
     automatically use any std::complex::real() method
   * It is generally *regarded* as bad practice to subclass from a std
     type. This is not a technical disadvantage per se, but more a
     psychological one.

What else am I missing?  Can anyone come up with other reasons for or 
against subclassing std::complex?


-- Mark Borgerding