itaps-parallel Re: typedef structure in iMeshP.h

[txie at scorec.rpi.edu]

Hi, All,

Thanks for all the discussions.

Sorry that I was misunderstanding how the incomplete types works. I tested
compiling, linking and running the code just now, and in fact,

#define ITAPS_DECLARE_HANDLE( NAME ) typedef struct NAME##DummyStruct *NAME

in iMeshP.h, this really works without defining private data structures in
the interior implementation. But I feel the term 'NAME##DummyStruct' still
seems confusing.

PS: Jason, thanks for the reminder. But could you please point out your
changes in iMeshP.h when you submit them next time? Thanks.


Thanks,

Ting



> Onkar Sahni wrote:
>> I am not trying to argue on number of ways we can do this... but there
>> should be discussion and consensus on one way of doing it... and as of
>> now
>> I do not like this generic macro ITAPS_DECLARE_HANDLE sitting in
>> iMeshP.h
>> (which is applicable to almost all handles in ITAPS interface including
>> ones in iBase, iRel, iMesh...).
>>
>> If iBase.h is always included (even if a user would only use iGeom) then
>> macro can go in there or we can keep it simple as:
>>
>> // in iMesh.h
>> typedef struct iBase_EntityHandle_Private *iBase_EntityHandle;
>> ....
>>
>> // in iMeshP.h
>> typedef struct iMeshP_PartitionHandle_Private *iMeshP_PartitionHandle;
>> ...
>>
>
> I don't think there's much point in discussing it.  If you don't like the
> macro, then remove it, or move it, or whatever.  I put the macro there,
> and
> as I said in the message you replied to:  I have no objection to either of
> the changes you describe above (except for the C++-style comments.)  (Or
> perhaps just wait until there's some consensus on whether or not we want
> to
> make such changes to existing interfaces before worrying about whether or
> not we are using and want to use the same macro definition for all header
> files.)
>
> - jason
>
>