Re: [eigen] Eigen::Complex attempt

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


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



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/