That approach sounds fine. I think that initializing the COOKIEs was not liked by some compilers. Ugh.
Matt On Fri, Oct 10, 2008 at 1:31 PM, Lisandro Dalcin <dalcinl at gmail.com> wrote: > In petsc4py, I've just implemented support for compose()/query() in my > base Object class. However, I wanted to implement query() in such a > way that 'dynamic_cast' (in the C++ sense, i.e, downcast) the composed > PETSc object and return to Python code an instance of the appropriate > Python type. Then, if you compose() a Mat, then query() will return a > Mat. > > I manages all this inside a private python dictionary mapping > PetscCookie -> Python type. Of course, this required to make sure that > ALL PetscXXXInitializePackage() have been called before adding stuff > to my dict. All is working fine; moreover, this machinery is also > being used in slepc4py and tao4py (yes, I have those...), then after > importing slepc4py or tao4py, the dictionary is populated as > appropriate. > > Then, the question are: Do this approach sound good enough? Is it too > much hackery? Can I relly in the long future that this approach will > always work? > > BTW, now I have a clear use case for initalizing all the XXX_COOKIE's > to 0 in core PETSc. This will really help me to spot package > initialization problems. In fact, I had to manage some of those > problems in petsc-2.3.2, petsc-2.3.3 and tao-1.9 . > > PS: The renaming DA_COOKIE -> DM_COOKIE does not play well with all > this, but I do not care about it right now. > > > -- > Lisandro Dalc?n > --------------- > Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC) > Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC) > Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET) > PTLC - G?emes 3450, (3000) Santa Fe, Argentina > Tel/Fax: +54-(0)342-451.1594 > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener
