Joel, Do you mean proto-izing std::complex itself (or some derived class), or using (extending) proto::terminal < std::complex >? On a related note, is there a standard way (yet) of changing a single component of std::complex? I'm not sure that there is... A recent working group draft has: T real() const; void real(T); T imag() const; void imag(T); The Apache stdcxx has only: T real() const; T imag() const; And the GNU libstdc++ has: _Tp& real(); const _Tp& real() const; _Tp& imag(); const _Tp& imag() const; My rationale for using an array value type was to make the interpretation of the type as a 2-element array clean. I'm working with several scientific codes which contain complex types defined as: typedef double complex_t[2]; and I'm preparing to port them to use more modern C++. However, I think that your point about the use of intrinsic functions is a good one. -Hal On Tue, 2009-10-06 at 15:15 +0200, joel wrote:
Either way. You could even just use some other terminal type besides boost::array. std::complex or std::pair would do.
Just dropping in as I have the exact same code lying around. Using std::complex itself as the underlying type of complex terminal is actually a good idea. When you'll have to do thing like cos( z ), you may want to go cak to call std::cos on complex as on some platform it uses some intrinsic that are faster than rewriting the cosinus by yourself. Moreover std::complex isn't more than a pair of T anyway.