Header for library

[G26pX9L8]

Hi all,

I have a design consideration regarding shared libraries and the common approach to this problem. The following is the situation. I'm currently writing a shared library not bigger than 3 sources files and 1 header. The header contains the prototypes and definitions for the whole library. No so exciting yet...

But now am writing a simple application to demonstrate the possibilities of the library. However to use the library functions I obviously need to include the library header. But when I compile the application the compiler starts to complain about missing functions (because those functions where only defined in the library). What would be the best solution/approach to this issue?

[Computergeek01]

Please forgive my potentially stupid question, did you import the library?

[G26pX9L8]

Yes I did import the library in the source code and linked against it. I'm doing this for years but it's just now I start wondering what the common solution is to such a situation.

Some say you need to create a separate header (containing the library externals) for the programs using your library. I'm an not sure about that...

[AbstractionAnon]

when I compile the application the compiler starts to complain about missing functions (because those functions where only defined in the library).

Since you say the compiler is complaining, I'm assuming this is not occurring at link time. Those are two different problems.

If the compiler is complaining, it would seem that it is not seeing the header file for your library.

If it is the linker that is complaining, that would indicate that the linker is not finding the object file for your library.

Can you please post the exact error messages you're getting?

[G26pX9L8]

It does happens at compiling time. It is nothing more than a warning really:

../src/header.h:13:13: warning: ‘function’ declared ‘static’ but never defined [-Wunused-function]

I can easily resolve the problem, but that's not the point. I want to follow the general way for this situation.

[AbstractionAnon]

I'm assuming that 'function' is not a member of a class.

If that's the case, the problem is that 'function' has translation-unit scope. Therefore, the compiler expects to find a definition of 'function' within whatver translation unit is being compiled and is giving you a warning when it does not find it.

The question is, what are you trying to accomplish by declaring it static?

If you're trying to hide the function from the users of your library, while making 'function' available to your three source files, then you probably want to create a separate header file for private declarations that only your three library source files can see (and not declare 'function' static).

[G26pX9L8]

If you're trying to hide the function from the users of your library, while making 'function' available to your three source files, then you probably want to create a separate header file for private declarations that only your three library source files can see (and not declare 'function' static).

That is exactly what I was trying to do. As far as I know static is always used in libraries that are either (pre)compiled or where code is hidden from the users.

When creating two separate header files I obviously need to update them both any time something in the library structure changes. Is there no alternative option in which a macro is used to skip the functions only available in the library source? That way I would lose the 'hidden' declarations, but would that not be better for design? I'm just trying to find the most accepted way.

[AbstractionAnon]

My thought on best practice would be the two header file approach.

//  public.h
//  All public declarations 

//  private.h
#include "public.h"
//  All private declarations 

Note that public.h can not depend on private.h, but private.h can depend on public.h. Declarations would be in only one place. public.h or private.h.

A less desirable alternative could be done with a single header:

#ifndef PUBLIC_H // standard include guard
#define PUBLIC.h
//  public declarations

#ifdef PRIVATE_H
//  private declarations 
#endif // PRIVATE_H
#endif // PUBLIC_H 

Then in your 3 library source files:

#define PRIVATE_H
#include "public.h" 

The obvious disadvantage of this approach is that your private declarations are visible to anyone that has access to public.h. Generally, something you want to avoid.

[NoXzema]

This is the reason why there are often two separate folders.

The src/ folder holds source and private headers.
The include/ folder holds public headers.

[G26pX9L8]

I'll go with the two separate headers, a solution that seemed be be an good idea from the beginning. Just wasn't sure how it's generally done. Thank you all.