On 06/05/2008, H.S. <[EMAIL PROTECTED]> wrote: > APRACK FORTRAN library needs the input data in a 2D array (the arrays need > to be arranged in column-major format). But, to answer your query, I don't > *have* to read it in an array, I could read it in a list and then copy it to > an array before I call ARPACK routines.
Btw, C++ provides std::valarray precisely with Fortran-like matrices in mind. However, it seems this is the black sheep of the C++ stdlib, since it seems C++ implementations are unable to optimise std::valarray as much as intended (I've never really understood the details), and I've never seen any project use std::valarray at all. :-/ But anyways, valarrays store data precisely in the numeric formats that Fortran expects. On 06/05/2008, Mark Allums <[EMAIL PROTECTED]> wrote: > (And is also an example of something that is wrong with the C++ standard > library, when you need the c_str() member of string so often to get any real > useful work done. Kind of defeats the purpose of having string in the first > place.) Yeah, that's because historically the stream classes were written before the string class. :-/ That's scheduled to be fixed in C++0x. I wish the GNU implementation of C++ already fixed it, since they do have other fixes (e.g. defining at() for std::map which is technically non-standard but completely reasonable). On 06/05/2008, Mark Allums <[EMAIL PROTECTED]> wrote: > But I would rather statically link to stdio than to iostream Although it's true that sometimes the C++ Hello World seems bloated to the C Hello World, the difference becomes negligible in any project of considerable size beyond Hello World. Embedded devices may be a different thing, and I understand that it's allowable and encouraged to write the hackiest code in embedded devices, even liberally sprinkling your C code with ASM. So I hear, so I hear... - Jordi G. H. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
