 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| Static Library Tips |
|
 |
ralbury Member since: 11/8/2001 From: USA |
|||
 Posted - 11/8/2001 11:27:30 AM |
||||
| Good article. However, the bit about compiling with exceptions depends on the library. In the case of my company, we ship two SDKs. Both are built with C++ but have C APIs. All the calls into the library are protected with critical sections, and all the code in the library interface catches *all* exceptions. This way, the customer doesn't have to worry about exceptions propagating out of the library. Also, we only ship four variants of the libraries (static and dynamic debug and release): we left out the single-threaded version since none of the environments our SDKs are used in are singlethreaded. |
||||
|
||||
|
pointguard1 Member since: 10/5/2001 From: US |
|||
 Posted - 11/14/2001 5:27:55 PM |
||||
| I had trouble when I tried to compile a .lib. I did it a while back so I don't remember the exact error message but I was wondering: can they have header files in them or does it all have to be .cpp files? |
||||
|
||||
|
Void Member since: 9/12/1999 From: Singapore |
|||
 Posted - 11/20/2001 11:11:09 PM |
||||
quote: That dilemma only occurs when using a C API interface for the library. Ideally, C libraries use return codes for reporting errors and clients decide on how the error should be reported. (by throwing or not) For C++ interface libraries, you have not much choice but to throw. Eg. If the ctor fails, using any method other than throwing is tedious and error prone. But what I don't understand is, since you suppress the exceptions inside the library, don't you still have to compile the static library with exceptions enabled?? Do you mean RTTI instead? |
||||
|
||||
|
Void Member since: 9/12/1999 From: Singapore |
|||
|
Posted - 2/28/2002 10:50:05 PM |
||||
| I feel I should add bring up these points in addition to those in the article.. 1. When using C++, your static library forces your clients to use the same compiler This is due to unstandarized name mangling in C++. Your static library will not work if another compiler. There is no other choice than recompiling the static library using other compiler. C code has no such problems. 2. Linking with another library inside your static library doesn't automatically merge them The static library is a collection of .objs in your project only. It doesn't contain other libraries you link with in the library. This means in this scenario.. Your library ( mine.lib) uses another library (other.lib) . The client who links with mine.lib also needs to link with other.lib Think of the library as a collection of .cpp files. Then it makes sense. 3. Your static library forces the users to link with the same library This sounds obvious but has actual subtleties. Say, your static library interface includes a stl header (say, #include <string> ). You compile, fine, distribute. Your client uses a different stl library. Unfortunately, that stl also has the string header. The client links your library interface. It sees the stl header and (usually) links with it's own stl library instead of yours. If the stl implementations of string differ, then no one knows what's will happen (actually it's usually a crash). This is the danger here where the library uses same name and interface. You though it wouldn't happen but it does. The only solution then would be letting the clients recompile(again), defeating the purpose of a precompiled library. .. Edited by - void on February 28, 2002 10:52:02 PM |
||||
|
||||
|
FMH Member since: 6/12/2002 |
|||
|
Posted - 6/12/2002 5:40:33 AM |
||||
| I don't know if anyone can help me in this. I built a static library that includes some resources. In the static library code, I pass the module handle returned by the call GetModuleHandle(NULL) to the API functions the load the resources. Now, I used this static library to build a DLL (the client). The problem is that the resources cannot be loaded when an application uses this DLL. Thanks in advance. |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 9/5/2002 10:36:08 PM |
||||
| Hypothetical question. Say I have a static library that is working perfectly fine and makes use of some windows functions that reside in kernel32 and are included by windows.h Now say I want to port this to another platform that has it's own version of these functions. How do I "link" in that version to the .lib Since MSVC seems to give me no other option (in the place of the LINK tab that is usually in project settings now all I have is a LIBRARY tab). Because of this I believe the only way is to add the include path to where these new functions are declared. Does that sound right? Or am I way off base and these functions don't even need to be linked into the lib in the first place but can instead be linked in by the user (client) of the lib. |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
