[Amadeus]

Depends on what you mean by library, good sir. Are you looking to implement a single file that contains a variety of functions that you often use that you can include in all your programs? Or are you looking to create a DLL that can be used by a variety of resources simultaneously?

[Amadeus]

Then I would create two files...a header file (.h extension), and a source file (.cpp extension). In the .h file would go all your function prototypes, all the definitions in your .cpp file.

Here's an example:

http://www.fredosaur...iple-files.html

[mikeblas]

Of course, a source file and a header file do not a library make. A static library is a collection of compiled object files. You'll want to learn how to use the librarian tool for your platform.

On Windows, LIB.EXE is the library management tool.

Say you want to make a library called Fooey.LIB. In it is code from FOO.CPP and BAR.CPP. You'd compile FOO.CPP into FOO.OBJ, and compile BAR.CPP into BAR.OBJ. You can then take FOO.OBJ and BAR.OBJ and put them into Fooey.LIB using LIB.EXE to do it.

The code in FOO.CPP and BAR.CPP probably needs a header file to declare its classes, data, and functions. So, sure: you should also have FOOEY.H, or maybe you just give FOO.H or BAR.H. It's kind of arbitrary, but you do want to end up working towards the convenience of your library's users.

If you want to write Program.CPP, it will build to Program.OBJ. Then, you tell the linker to combine Program.OBJ and Fooey.LIB to produce Program.EXE.

I hope that helps.

[mikeblas]

Happy to help.

Given that additional information, though, I should change my answer. Perhaps the most important thing to do when writing a library is to decide why you want to write a library. What're your goals?

[Amadeus]

mikeblas, on 22 Apr, 2008 - 11:00 PM, said:

Of course, a source file and a header file do not a library make. A static library is a collection of compiled object files. *snip*

Quite true sir - that is why I'd differentiated between two of the more common ideas meant when people ask about libraries.

[mikeblas]

Amadeus, on 23 Apr, 2008 - 05:21 AM, said:

Quite true sir - that is why I'd differentiated between two of the more common ideas meant when people ask about libraries.

Oh, I see. I guess you're assuming that "single file" is a *.CPP file, not a *.LIB file. To me, *.LIB static library files are more common than both a frequently compiled *.CPP file and a *.DLL file. After all, not all platforms support *.DLL files, though almost all platforms support static libraries.

[Amadeus]

I would agree with that, the main assumption I was working off of was that the user simply wished to create a single source file that contained his commonly used functions (although I did ask in case they were actually looking for a library). In my experience, that is what is often meant by 'library' when people are starting out with programming - as they evolve, they will become more familiar with the traditional 'libraries' we use in the programming sense, and how to create them.

[foohoo]

Hi all,

Can I jump in and leach from your question. In the initial response *.DLL extension was mentioned. Can you explain the process that might go into producing a DLL file for this problem? i.e a DLL file that can be used to hold commonly used functions.

thanks,

[Amadeus]

Well, as correctly noted by mikeblas, they are platform dependent, so the methods will vary...here are a few resources:

http://logix4u.net/P..._with_VC++.html

http://www.codeproje...eginnerdll.aspx

http://www.flipcode....sing_DLLs.shtml

[mikeblas]

foohoo, on 23 Apr, 2008 - 06:53 AM, said:

Hi all,

Can I jump in and leach from your question. In the initial response *.DLL extension was mentioned. Can you explain the process that might go into producing a DLL file for this problem? i.e a DLL file that can be used to hold commonly used functions.

thanks,

In Windows, a DLL is actually an executable image, so it's created by the linker instead of the librarian. You can link your OBJ files into the DLL, then tell the linker you're building a DLL by giving the linker the /DLL option on its command line.

You'll want to define a DllMain() function in one of your modules in your DLL, must the same way that you define a main() or WinMain() entry point. DllMain() is called by Windows when the DLL loads, when it unloads, and when threads attach or detach to the DLL. This provides an opportunity to do some initialization and shutdown.

A static library automatically exports all of its public symbols. Any public symbol in any OBJ within the static library can be referenced by a consumer of the library. DLLs don't quite work like that. They require the library developer to individually export each function explicitly. There's a couple of different ways to do this; either with a module definition file, or with special non-standard keywords implemented by your compiler.

Exporting C++ classes is very difficult, as the decorated names used by the compiler for special functions must be used to export the implementation name of the function. The compiler might also generate special functions (like destructors or constructors, for example) that the developer can't even see in their source directly. Further, it's necessary to keep these names ordered in a stable way in order to keep the consumers of the DLL working between builds of the DLL.

Another confusing feature of DLLs is that they also create a static library. If you build FOO.DLL, you also get FOO.LIB. The FOO.LIB static library is typically used by the consumer of the DLL to automatically load and call the entry points in the DLL. Without the static library, the consumer must use the LoadLibrary() and GetProcAddress() APIs to find each function entry point ... and then cast to a function poointer, pass the appropriate arguments, and make the call. Obviously, this is very cumbersome.

I hope that helps. If you have any questions about the process, please let me know.