tags:

views:

324

answers:

4

I have a static library that I want to distribute that has includes Foo.c/h and someone picks it up and includes my static library in their application.

Say they also have Foo.c/h in their application. Will they have linking errors?

+6  A: 

The name of a source file is not significant in the linking process.

If the file has the same contents, then you'll have a problem, assuming that the .c file contains exported symbols (e.g. non-static or non-template functions, or extern variables).

Daniel Earwicker
+2  A: 

It depends. If the foo.c and foo.h define the same functions and/or variables, then yes, there will be multiple definition errors. If they just have the same file names, but contain different code, there will be no problem.

anon
A: 

if you are giving out your static lib you dont need to include foo.c as this will be part of the lib and yes if they have there own foo.c it will confuse the compiler and linker and might cause problems if you both have like functions or it will include the wrong header.

Your best way to solve this is to use a namespace for your code thus keeping it unique.

namespace myfooname
{

void foo()
{
//stuff
}


}
Lodle
+1  A: 

Linker an File Name
The linker itself has the least problems, but some IDE's will complain if the files are added - even if they are in different folders. But that's usually not much of a problem.

Do not distribute a static library (without source)

First, you shouldn't redistribute a static library alone. The code - and the compatibility - depends on the compiler, and many of the common settings, like which run time library (static/dynamic, debug/release, happily the single threaded's are gone from VC), some C++ settings such as exception handling, virtual member function pointer representation and others. You end up building hundreds of variants to support just the mainstream compilers, and you still end up with someone who needs it just a bit different.

Always include source, so the user can rebuild the static library on his box. Alternatively use a dynamic library - but that has its own gotchas.

namespace
As mentioned, use a namespace to avoid collisions. Don't go overboard, if you have source included the user can always remaname it. But keep in mind that using namespace declarations should not occur in a header, so code needs to be adjusted slightly.

peterchen
All the issues that you mention that cause problems with static libraries also cause problems with DLLs, and indeed with any compiled code.
anon
With a DLL, you can move the allocation into the DLL, exporting a factory. This gets you rid of the run time library choice. But you are right, that doesn't help with exceptions or the "more tricky" things.
peterchen
Or to put it differently: in my experience a well-designed DLL is less of a problem _in practice_.
peterchen