"Hurd, Matthew" <hurdm@sig.com> wrote in message news:BA1220310B07EC4A8E321B451E07AF4784833F@msgbal501.ds.susq.com... | There is an often seen misconception that C/C++ should be as fast as it | gets as the programming model is close to the instruction model of the | machine. In practice FORTRAN is usually faster. | | At one level, in C++ this slowness this is usually because of | temporaries and expression templates and modern optimizing compilers can | often mitigate this for typical math calcs. Other abstraction penalties | apply. yeah, we want move semantics. | Another level is the fundamental differences in aliasing between the | language definitions. | | FORTRAN as a language does not allow aliasing ambiguities which makes | the optimizers job a lot easier and the code can be a lot faster. C/C++ | assumes aliasing potential which makes optimizing very hard.
From what I now, we cannot put C and C++ into the same basket. See Type-Based Alias Analysis:
http://www.ddj.com/documents/s=880/ddj0010d/0010d.htm?temp=fXniOPb1aS I my suggestion for Design by Contract I mentioned that aliasing (or lack of it) could be expressed by a function precondition: void foo( T* l, T* r, size_t sz ) precondition() { std::less<T*>( l + sz, r ) || std::less<T*>( r + sz, l ); }; | You still need to wrap as you can't hope, nor should you try, to offer | all algorithms from all languages. probably not. But simply wrapping stuff is not always an option. For eaxample, in the statistics lib I'm working on, I need to invert matrices. If I write wrappers, I will probably only be ably to support float,double,complex leaving out higher precsion datatypes. br Thorsten