Losery C++ Class question

Factual Questions
1

So I finally got around to being serious about learning C++, and decided to try writing a really basic crypto utility. Nothing fancy, just basic stuff for programming practice. Everything worked, so I decided to rewrite it using a class instead of a string of functions.

Now that I’ve debugged my class and put it in a separate file, I want to compile it and be able to distribute it (in theory, if it were something important or valuable to somebody other than myself) as separate object & header (class.h & class.o) files.

So what’s the trick? How do I set it up so that doing #include “path/class.h” (which contains only the interface) will automatically link in class.o at compile time? Is it a matter of putting the object file in some directory, or more complicated than that?

Keep in mind that I am new at C++ (this is my first try at writing a multi-source file program), and I’m well aware I may be missing some really stupid basic concept.

Thanks for the help and apologies for the stupid question are both offered in advance. :slight_smile:

2

I guess I should point out that the subject line means a question about the c++ data structure “classes”, not a class in c++.

3

You’re confusing a couple of things here.

The #include line is a compile-time mechanism which effectively reads the file into the source at that point. It can be used (and heavily misused) for many things, but the usual thing is to put your class definition and any other “published” definitions in a .h file.

The .o file is the output of the compiler, and is an object file intended to be used by the linker (or, possibly, the link phase of your “compiler”). At link time, your .h file is no longer needed.

How both of these mechanisms work is actually system dependent. There will be some command line, environmental or configuration setting used by your compiler or IDE to determine a search path for header files (the #include lines). If the user is just invoking a command line compiler on UNIX, this search path may be specfied using “-I” options, or environment variables. If the user is using an IDE, it will have its own config settings.

The most straight-forward way in which your .o might get used is simply as an argument to the linker (or compiler which has a link phase).

If you were going to distribute these things to be used by other people, you would have to deliver the two pieces, and it would be up to the developer that was going to use them to install them in the correct places for their environment. The simplest way they might do that is to simply compile their code, which uses your interface, with appropriate flags for where to pick up your header file, and linking in your object:

gcc -I/Joe_Cool/include myfile.cpp /Joe_Cool/obj/Joes_Class.o

This allows their file to “see” your header which they placed in /Joe_Cool/include, and the resultant myfile.o is linked with your .o to produce a final executable containing both his code and yours.

In fact, you would probably have several object files to deliver, and you would probably package them into a library file. You would probably also provide either a “readme” file describing what the relevent files to use your classes are, or an install utility which would allow your stuff to be integrated with various popular IDE’s by interacting with the user and taking care of the correct configuration settings.

You might also want to distribute your stuff as a dynamic library, etc, but I don’t want to get into too much right now.

4

Oh, and I should mention that the object extension is also system dependent. On windows boxes, a “.obj” file gets produced, not a “.o”.

When it comes to distributing software for use, I’m glossing over a LOT of stuff. You’ll discover the issues as you go along.

5

Assuming you don’t want the end user to see your implementations, you should make a static library. If you’re using MS Visual C++ 6.0, you have the option to create a win32 static library when you make a new project. If you’re using a different compiler, you’ll have to look it up yourself.

You will also need to distribute the uncompiled header files along with the library.

6

So, if I were to purchase the “whatever” class from vendor X, I would have to do something like that?

What I get from this discussion is that it’s really not something I need to be worrying about at this stage of my development, right? Thanks for the help. :slight_smile:

7

If you purchased it, it would probably be part of a library package, and they should provide ample documentation on how to use it in your particular environment, or perhaps an install program that would hand-hold you through the appropriate configuration. But, yes, at the end of the day, the code you wrote would have to be able to reference definitions in their .h files, and you would have to link to their compiled objects.

They might also simply provide you with the source to build in your particular environment, but that’s not common for commercial distributions that you pay money for (yes, I’m aware of the current “open source” movements). It IS common if you are interested in using freeware or shareware utility packages distributed by private individuals.

For whatever your own environment is, you should understand generally where your compiler looks for header files, where your linker picks up libraries and objects from, and the options you have available to you.

There are a lot of things involved with packaging software for distribution, and different types of libraries for particular platforms and types of use (such as .dll’s vs. static libraries and single vs. multithreaded compilation on Windows). You are correct that you probably don’t want to worry too much about the issue right yet, but it is very good that you are thinking about it.