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

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

Andrew,


where do we need the

#ifdef __cplusplus
extern "C" {
#endif

tags?

Only around SBML_ODESOLVER_API functions and typdefs, i.e. in the new API 
headers?

How does it relate to our internal C++ code, and the plan to move 
structures and their interfaces to C++?

Rainer


On Mon, 12 Jun 2006, Andrew Finney wrote:

> Rainer
>
>> But then odeModel.h itself needs to have the line
>>
>> #include "sbmlsolver/internal/odeModelInternal.h"
>>
>> to find this structure?
>>
>
> No.  This line only needs to be present in .c files and in other
> *Internal.h files.
>
> yours Andrew
>
>> -----Original Message-----
>> From: Rainer Machne [mailto:ra...@tb...]
>> Sent: 12 June 2006 12:05
>> To: Andrew Finney
>> Cc: SOSlib Development
>> Subject: Re: [SOSlib-devel] API reorganization[Scanned]
>>
>>
>> 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
>