jed |
November 20, 2009 13:52 |
Quote:
Originally Posted by walli
(Post 237088)
That was more about C style programming than PETSc.
|
Note that while it is written in C, it is very much object oriented. PETSc objects use a variant of the delagator/pimpl pattern, but see object creation is (by default) managed by an inversion of control known as dependency injection. You might have heard of this in the context of frameworks like Spring. This has the advantage that your code never makes explicit reference to the implementation of your objects, just the interface that they implement. With this design, it is natural that every object has a plugin architecture. That is, you can compile a preconditioner and custom matrix format to a shared library send it to someone else who does not have source for anything, and they can select your preconditioner at run time just like the ones distributed with PETSc.
Quote:
Speaking about PETSc, I particularly don't like the inflationary use of the CHKERR-stuff.
|
Yes, I don't even see them anymore. The reason for this (and a couple other macros used within PETSc) is mostly to be able to get full stack traces when something goes wrong, as well as to detect memory corruption and leaks. C++ exceptions have serious interoperability problems and lack the semantics required to get reliable stack traces in parallel, as well as to automatically attach a debugger on the site where the error occurred (even in parallel). You certainly don't have to use these macros, but they really do make debugging easier.
|