Mickey Moore <mgmoore@austin.rr.com> writes: | Regarding std::complex, just about a month ago, I posted to | comp.lang.c++.moderated about these very issues. The current status | is in this paper: | http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1589.html | The layout guarantee seems certain, and it lays out possible solutions | for the second issue. I don't see much that I can add other than to | give my recommendation on the solution and prod them to pick one | already. I've already been doing both on clc++m; I suppose I could | write Howard Hinnant directly, but he's responded to several threads | so he's probably read most of my posts. | | This is becoming a digression, but my opinion, for what it's worth: | std::complex should never have been encapsulated as it was in the | first place. And to justify this, in addition to the efficiency | issues, there is clarity of the code's intent. Consider: | | 1a) z = complex<double>(z.real(), 1); | 2a) z.imag() = 1; | | 1b) z = complex<double>(z.real(), z.imag() + 1); | 2b) z.imag() += 1; | | I think it's clearly much easier to read the intent of the code in the | second cases. The original issue was submitted and fix proposal was agreed upon, and even went into a Ready status (I think). Then, when I was not watching out, it suddenly came out in Open status along with some rationale I still find strange. Quantum process, mind you. -- Gaby