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

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

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
>