[MOAB-dev] Incomplete types versus void * in ITAPS interfaces

[Jed Brown]

On Mon 2008-09-08 09:40, Onkar Sahni wrote:
> 
> I am not going into all benefits of the inheritance as I am certainly not
> the right person but will provide some examples... (I mentioned both
> overloading and inheritance etc.).

There are lots of good things about inheritance, but we're not really
using inheritance here since the handles are opaque objects to the user.
The implementation could represent the entities using inheritance and
virtual functions, but that is not exposed in the interface (the user
doesn't call these virtual functions).

From what I can tell, none of your examples use inheritance except to
avoid casting to the parent class (since the compiler will do this
implicitly).  The overloading is mostly cosmetic except that it can be
used with templates.

> One thing I didn't make it clear is that I was thinking from
> user/application point of view so print_EntInfo() example was not good.

Okay, you achieve overloading and possible type-checking in user code
and don't need to cast (as you would in C) because the compiler knows
about the inheritance.  In this case, the inheritance is completely
invisible to the implementation and you're not suggesting any change in
API.  The only potential problem I see is in finding bugs.  That is, you
could have an array of iBase_VertexHandle which were not actually
vertices.  The compiler can't help you find this error because the
correctness of your types can't be determined at compile time.  In this
sense, I would prefer that user code just calls iMesh_getEntType/Topo.
This is of course just a personal preference.


By the way, I changed the typedef in my iBase.h, did not relink MOAB,
recompiled my code (now with type-checking) and everything works fine.
Note that there is no requirement that the typedef be the same for every
implementation.  For instance,

  typedef int MPI_Comm;                            /* MPICH2 */
  typedef struct ompi_communicator_t *MPI_Comm;    /* OpenMPI */

Note that ompi_communicator_t is private.  Since these types are
different sizes on some architectures, it triggered a bug a while back
in the PETSc interface to ML (it had been tested with MPICH2, but not
with OpenMPI on x86_64).

> // overloading functions by users in C++
> userComputeScalarIntegral(iBase_FaceHandle,...)
> userComputeScalarIntegral(iBase_RegionHandle,...)
> 
> Now may be it does make much sense as iMesh doesn't really let you do
> anything special with iBase_FaceHandle (like
> iMesh_F_numEdges(iBase_FaceHandle...)) or iBase_RegionHandle (like
> iMesh_F_numFaces(iBase_RegionHandle,...)).
> 
> // inheritance by users in C++
> class userElementIntegrator() {
> eval(iBase_RegionHandle);
> eval(iBase_EntityHandle);
> }
> 
> userElememtIntegrator::eval(iBase_RegionHandle rgn_hdl) {
>   // only 3D supported as of now
>   ... user code to compute element (3D) matrix
> }
> 
> userElememtIntegrator::eval(iBase_EntityHandle ent_hdl) {
>   // only 3D supported as of now
>   user_error();
> }
> 
> By the way, iMesh already exposes implementation details. Infact ones
> which I do not really like:
> alloc=0;
> iMesh_getEntAdj(...,alloc,...);
> if(alloc)
>   free(...); // oops

What are you asking for, garbage collection?

Jed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <https://lists.mcs.anl.gov/mailman/private/moab-dev/attachments/20080908/eb99a1b8/attachment.pgp>