[MOAB-dev] Q on initializing MOAB iMesh interface
Iulian Grindeanu
iulian at mcs.anl.gov
Sat Jan 8 15:08:57 CST 2011
Hello,
Yes, I think this would be better. It should continue to allow multiple iMesh instances.
Also, iGeom implementation in MOAB should be changed in a similar way.
Currently only one iGeom instance is possible; a similar class is needed, that contains the
global variables defined in iGeom_MOAB.cpp, and a pointer to Core (or MBiMesh?)
Thanks,
Iulian
----- Original Message -----
> Hi all,
> Currently in MOAB's iMesh implementation, the class structure looks
> like:
>
> class MBiMesh : public Core
> {...}
>
> It's done this way because the iMesh implementation needs to keep some
> member data that Core doesn't need. However, it
> also makes it impossible to construct an iMesh object from an existing
> Core object. I'd like to change that. What I'd
> like to do is change MBiMesh from "isA" to "hasA", i.e. to make
> MBiMesh point to an Interface object. The MBiMesh
> object would keep track of whether it constructed MOAB or was passed
> one, so it would know whether it could destroy it
> in iMesh_dtor. I'd also like to enable the Interface::query_interface
> method to return an iMesh instance, consistent
> with other interfaces it already handles. The net effect of all this
> would that applications could gain access to an
> iMesh interface on a transient basis, e.g. if they wanted to call a
> service implemented in iMesh but not MOAB.
>
> Does anybody see any problem with this approach, or think I should do
> it differently?
>
> - tim
>
> --
> ================================================================
> "You will keep in perfect peace him whose mind is
> steadfast, because he trusts in you." Isaiah 26:3
>
> Tim Tautges Argonne National Laboratory
> (tautges at mcs.anl.gov) (telecommuting from UW-Madison)
> phone: (608) 263-8485 1500 Engineering Dr.
> fax: (608) 263-4499 Madison, WI 53706
More information about the moab-dev
mailing list