Re: [SOSlib-devel] API reorganization[Scanned]

[Rainer M. <ra...@tb...>]

Hi Andrew

I am still confused by the current structure of header files.

E.g. in

cvodedatatype.h

there are the two  typedefs

   typedef struct cvodeData cvodeData_t ;
   typedef struct cvodeResults cvodeResults_t ;

But in cvodeDataStruct.h there is only the structure cvodeData, whereas 
cvodeResults is still in cvodedata.h

If I try to change this, i.e. move the two structures into an internal 
header and only have the typedefs in the API header, compilation fails due 
to the mutual dependencies, i.e. cvodeResults_t being a data field in 
cvodeData.

For odeModelStruct I get similar problems with

typedef int (*EventFn)(cvodeData_t *, int *);

which is required by odeModel and itself requires cvodeData.

I had to change it to
typedef int (*EventFn)(void *, int *);



So to be honest, I would prefer at the moment to just remove all the 
...datatype.h and ...Struct.h files, because they are just inconsistent 
and confusing and the mutual dependencies are very complicated.

Actually I have already done this here, because I 
thought it might be good to merge the files before splitting them up in 
internal and API headers again.

Rainer




On Mon, 12 Jun 2006, Rainer Machne wrote:

>
> Andrew
>
>> I strongly suggest you create a new directory for
>> 'internal' headers.
>
> Ok. I'll make another directory src/sbmlsolver/internal then.
>
>> ... External applications can then be built
>> without the internal header directory being on
>> their include path.
>
> Ok, so in odeModel.h I have
>
>  typedef struct odeModel odeModel_t;
>
> But then odeModel.h itself needs to have the line
>
> #include "sbmlsolver/internal/odeModelInternal.h"
>
> to find this structure?
>
> Couldn't applications which include odeModel.h still have direct access to
> the the structure because they have the internal header file included via
> odeModel.h?
>
>
>> The internal headers could be called something like
>> odeModelInternal.h or odeModel_Internal.h
>
> So these internal header files can replace both odeModelStruct.h and
> odemodeldatatype.h, right?
>
>> Note you obviously don't have to declare structures and function
>> prototypes
>> in headers.  They can be declared in .c files
>
> Most of our structures and many functions are used in several .c files, so
> these need internal header files if we want to avoid having to use the
> API functions internally, which could become quite painful.
>
>
> Rainer
>
>
>
>
>
>
>
> On Mon, 12 Jun 2006, Andrew Finney wrote:
>
>> Rainer
>>
>> Sounds good
>>
>> I strongly suggest you create a new directory for
>> 'internal' headers.  External applications can then be built
>> without the internal header directory being on
>> their include path.  This would then make it very easy to detect
>> if a dependency on the internal headers has 'drifted' into
>> the API.
>>
>> The internal headers could be called something like
>> odeModelInternal.h or odeModel_Internal.h
>>
>> Note you obviously don't have to declare structures and function
>> prototypes
>> in headers.  They can be declared in .c files
>>
>> yours Andrew
>>
>>> -----Original Message-----
>>> From: sbm...@li...
>>> [mailto:sbm...@li...] On
>>> Behalf Of Rainer Machne
>>> Sent: 12 June 2006 11:18
>>> To: SOSlib Development
>>> Subject: [SOSlib-devel] API reorganization[Scanned]
>>>
>>> Hi All
>>>
>>> the point # 1.4 API reorganization of our online development wiki
>>> (http://www.tbi.univie.ac.at/wiki/index.php/SOSlibDevel)
>>>
>>> might be one thing that should be done soon, before
>>> implementing more functionality.
>>>
>>>
>>>
>>> For some c files we have three header files, e.g.
>>>
>>> odeModel.h
>>> odeModelStruct.h
>>> odemodeldatatype.h
>>>
>>> which confuses me a bit.
>>>
>>>
>>> In odeModel.h we have all the API function definitions,
>>> in odemodeldatatype.h there is only
>>>   typedef struct odeModel odeModel_t;
>>> and in odeModelStruct.h the odeModel structure is defined.
>>>
>>> It was initially thought, and I want to keep it that way, that
>>> applications include the odeModel.h file.
>>>
>>> Then we also have the
>>> #ifdef __cplusplus
>>> extern "C" {
>>> #endif
>>>   definitions in all header files.
>>>
>>> So what are the requirements for all this?
>>>
>>> The main point is to
>>>
>>> * hide structures and internal functions from calling applications.
>>>
>>> The second point is that we need to
>>>
>>> * map the C code to C++.
>>>
>>> Right?
>>>
>>>
>>>
>>> The following would be my plan:
>>>
>>> in odeModel.h
>>> * SBML_ODESOLVER_API functions
>>> * structure type definitions (only e.g. typedef struct odeModel
>>> odeModel_t)
>>>
>>> in odeModelStruct.h
>>> * the full structure declaration
>>>
>>> Questions:
>>>
>>> What about the third file in the odeModel example. Is this required?
>>>
>>> Where should we move the declarations for internal (non-API)
>>> functions?
>>>
>>> * in odeModel.h but e.g. outside of the
>>> extern "C" {
>>> definitions?
>>>
>>> * in odeModelStruct.h? Should we rename it then?
>>>
>>> happy about any suggestions,
>>> Rainer
>>>
>>>
>>>
>>> _______________________________________________
>>> sbmlsolver-devel mailing list
>>> sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>>
>>
>>
>> _______________________________________________
>> sbmlsolver-devel mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>
>
>
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>