Re: [eigen] Eigen::Complex attempt |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Eigen::Complex attempt*From*: Mark Borgerding <mark@xxxxxxxxxxxxxx>*Date*: Wed, 17 Jun 2009 10:44:07 -0400

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

* 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

* 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.

-- Mark Borgerding

**Follow-Ups**:**Re: [eigen] Eigen::Complex attempt***From:*Gael Guennebaud

**References**:**[eigen] Eigen::Complex attempt***From:*Mark Borgerding

**Re: [eigen] Eigen::Complex attempt***From:*Benoit Jacob

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Eigen::Complex attempt** - Next by Date:
**Re: [eigen] Eigen::Complex attempt** - Previous by thread:
**Re: [eigen] Eigen::Complex attempt** - Next by thread:
**Re: [eigen] Eigen::Complex attempt**

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