The C++ community in general suffers a lot from the NIH Syndrome. Matrixes, Strings, Vectors, everybody creates their own which are always, or course, superior to what's already available. Again, is not the language's fault, a language is just a language. It's the way it has been driven. My two cents. "David Kastrup" <dak@xxxxxxx> wrote in message news:86odfstbc6.fsf@xxxxxxxxxxxxxxxxxxxx > figo <rcc_dark@xxxxxxxxxxx> writes: > >> http://www.research.att.com/~bs/applications.html >> >> just as Bjarne once wrote in his TC++PL, its hard to teach an old dog new >> tricks. Its even harder to give quality education about how to use >> something >> to someone who doesnt want to learn. >> >> you hate high level, then continue programming operative systems, >> please NEVER DO something else. C++ was designed to give programmers >> high level tools and still being able to take care about >> performance. >> >> portability wont be possible after a standard is published and some >>couple of years given to the compiler developers. C++ had its >>standard in 1998, and add two or three years for compiler development >>= 2002. "Quite recently", way more recently that your last use of C++ >>I can bet. > > Care to explain why there are still not two numerical C++ libraries > with compatible matrix classes? > > What use is talking about portability and high level when a basic > interoperability feature that has been available since the sixties > (more than 4 decades ago) in Fortran has not yet managed to make it > into C++? C++ by now more or less offers a (somewhat deficient) > standardized way to work with complex numbers, but matrices are still > not standardized in any manner, and libraries won't interoperate. > > So C++ should get its head wrapped around the _low_ level problems > first. It is a bloody shame that it still has not caught up with > Fortran IV (or even Fortran II) with regard to usefulness for > numerical libraries. > > It is not a matter of "hating high level" to see that C++ is mostly > focused about addressing the wrong kinds of problems in the wrong > ways. The pain/gain ratio is just bad. > > -- > David Kastrup > - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
