Including C++ files

[nathan.pavlovsky]

Is it poor convention to create a c++ file only to store various functions, and then include it into the main.cpp?

This would be done so that the functions could be used in different programs as well.

[Schol-R-LEA]

Unfortunately, yes, it is. This post should help explain why.

The solution is to compile the source files in such a way that they can be linked into a single program. How you would do this is going to depend on the compiler and linker (or in many cases, the IDE) you are using. In most IDEs, including Visual Studio, Code::Blocks, and Eclipse, it can be as simple as making sure that the file is in the same project with the main program source file. If you are using a command-line compiler, you can usually list multiple source and object files in the build command. For example, with gcc you can compile the file foo.cpp to a separate object file,

 g++ -Wall foo.cpp -o foo.o

(...the -o switch says to use foo.o as the output file name, while -Wall means, 'display all the warnings that come up when compiling'...)

then you can combine it with the files bar.cpp and main.cpp like so:

 g++ -Wall foo.o bar.cpp main.cpp -o program

the GCC driver program, which for C++ is g++, will automagically call the linker for you.

[mike_2000_17]

I assume that by "including C++ files", you mean something like this:

#include "my_file.cpp"

Then, as Schol-R-LEA said, it is not good practice to do so. In C/C++, you are supposed to do separate compilations of each source file and then link them together. You should get used to this pretty early on. Just imagine for a moment that they would do this in a large project with millions of lines of code... can you imagine how long it would take for a compiler to compile millions of lines of code all at once? And everytime you change anything anywhere you would have to recompile the entire code... not very practical, is it?

You might want to check out my tutorial that explains the whole compilation process for C++.

[nathan.pavlovsky]

Yes, I was thinking of doing #include "file.cpp", but how would I link those two files together in order to access the other's functions?

[nathan.pavlovsky]

I use xCode for mac.

[Slavi]

I think what Mike is trying to explain is that if you have a file that contains 10000 functions inside and you use only 1 or 2 of them, it will be pointless to include the file and compile all functions all the time when they are not needed.

yes, it is possible to do and the answer to your question - yes it is poor convention

[nathan.pavlovsky]

I understand if only one or two functions are used that it is impractical, but what happens if you need almost all of the functions in the other file?

[Slavi]

Again it depends on how many is almost all? 9/10? Also the implementation of the last one, how long does it take for the compiler. I guess you could try and do so but its not a good practice especially if time/efficiency is crutial for your project. And then again in big projects almost all might be 900 out of 1000, will be pointless to really recompile the rest and in my opinion it might make the code itself confusing especially if you work with multiple people. I rather keep things clear and in multiple file so I always only implement what I need

[Schol-R-LEA]

I understand if only one or two functions are used that it is impractical, but what happens if you need almost all of the functions in the other file?

That's what Makefiles, or in the case of most IDEs, project files, are for. I don't know XCode, myself, but it should have some sort of workspace/project management facility, which will handle the building, tracking and linking for you.

[nathan.pavlovsky]

Do any of you know any people that work in xCode and could help with this?
Do many professionals use xCode for C++?

Sorry for wasting everyone's time.

[Moschops]

https://developer.apple.com/library/ios/recipes/xcode_help-structure_navigator/articles/Adding_an_Existing_File_or_Folder.html

[Hiroshe]

Yes, I was thinking of doing #include "file.cpp", but how would I link those two files together in order to access the other's functions?

You should NEVER need to include a .cpp file. Incliding the corresponding .h file has the same effect and is more powerfull, not to mention it will lead to faster compile times.

My suggesting would be to give up on includig a ".cpp" file, and try to do it properly.

I understand if only one or two functions are used that it is impractical, but what happens if you need almost all of the functions in the other file?

Even if you need to access all of the functions, what if you need to access all of the functions elseware? Now you're compiling the same code multiple times! Also, you'll need to include header guard macros in your source file, otherwise you might run into multiple definition errors. The source file might quite a bit larger then it would be if you just linked against a compilation unit.

Do many professionals use xCode for C++?

A lot of projects that are developed for mac do. If the project is supposed to be cross platform, I would expect to see some kind of build system instead of using xCode's build in one. Some project exclusively for Mac also stick to other build systems, so the choice is up to you.

[Schol-R-LEA]

It was no waste of time, I assure you; this is what we are here for, after all.

[nathan.pavlovsky]

Thanks for your comments, everyone. However,I am not closing this thread, until some C++ developer for xCode finds it and puts in their comments on how to link individual functions in various c++ files.

[Schol-R-LEA]

Apple's documentation on Workspaces and Projects should answer most of your questions; while it is aimed mainly at Objective-C, it should be the same for all supported languages. It seems fairly straightforward: you can drag and drop a file into the 'Classes' or 'Other Sources' folder, and that should be sufficient to add the files to your build. I think. If not, the explanation here should work for adding existing files.

You might want to look at this developer's tutorial. It is a bit dated, but still mostly relevant. If that's over your level at this time, try this one, though it doesn't cover the specifc question too much.

[nathan.pavlovsky]

No, I mean linking an individual function inside a file to another file.

[sepp2k]

You don't link individual functions - you link files. If all your files are added to the same project, the compiler (or rather the linker) will link all your files together.

If you get error messages about missing definitions, that means that the file with the missing definition is not part of your project or for some other reason (like a broken makefile or project file) does not get linked.

If you get error messages about missing declarations, that has nothing to do with linking. It simply means that you did not properly declare the function in your header file or did not include the header file in the file where the function is called. It may also mean that you have circular includes.

[Moschops]

You just call it. That's all. Just call the function. So long as the compiler knows it exists (through having seen the function prototype, for example in a header), that's it. At link time, the linker finds that function in other object files and takes care of joining it up for you.

[Schol-R-LEA]

Just to clarify to point: you have an existing source file, which contains a complete program (e.g., it has a main() function and can be compiled and run without any additional files), and you want to use a single function out of that file in another program? That explains a good deal about the confusion you are experiencing, then.

The solution is to separate the functions you want to share into a third file, with only the functions, and then create a fourth file, a header file (with the .h extension) which would contain the class declarations and function prototypes. You would then include the header - not the source file - into both the original program (sans the shared code) and the new program, as well as seeing to it that the shared file is in both builds.

So, if you had the following program:

#include <iostream>
using namespace std;

class Foo 
{
private:
    int bar;

public:
    friend ostream& operator<<(ostream& os, Foo f); 

    int baz()
    {
      // do something and return an int
    }
}    

ostream& operator<<(ostream& os, Foo f)
{
     // implement the output operator for class Foo    
}

int main() 
{
    Foo quux;

    quux.baz();
    cout << quux;

    return 0;
}    

and you wanted to use the class Foo in another program, you would remove Foo from the original program (which you really should have done in the first place for modularity's sake), and create both a header and an implementation file:

Foo.h

// this ensures that the file contents don't get included 
// more than once in a given file
#ifndef FOO_H
#define FOO_H

#include <iostream>

class Foo 
{
private:
    int bar;

public:
    friend std::ostream& operator<<(std::ostream& os, Foo f);

    int baz();   // note the absence of the function's body!!!
}

std::ostream& operator<<(std::ostream& os, Foo f);

#endif FOO_H

and Foo.cpp

#include <iostream>
#include "Foo.h"

int Foo::baz()
{
  // here's where it went to
}

std::ostream& operator<<(std::ostream& os, Foo f)
{
     // implement the output operator for class Foo    
}

Now your program file should look like this:

#include <iostream>
#include "Foo.h"

using namespace std;

int main() 
{
    Foo quux;

    quux.baz();
    cout << quux;

    return 0;
} 

Voila! You now have separate compilation modules.

A few things to note, however. First off, you will want to use an #include guard with a unique guard token (like the FOO_H in my example) around the class declarations in each header. You can have more than one class in a header, and more than one function prototype, but you want the include guard around all of them.

Second, you will note that I moved the method implementations out of the class header and into the implementation file, alone with the stand-alone friend function. Thisis important: with the exception of template functions and very small (one or two line) getter/setter methods inside of a class, you shoyuld never put operational code inside a header function. This is because you would run into the problem of repeatedly compiling the code, as well as potentially having a linker problem as the linker tries to resolve the functions in different object files.

Third, you'll also notice that the I used the scope operator (::) to indicate that the method baz() was part of the class Foo. This is important, and one of the easiest mistakes to make. Note also that the free function did not require scoping (for itself - it did have to scope the std::ostream& type) since it wasn't part of a class.

Fourth, you should never put a using namespace std directive inside a header or a class implementation file - always scope the standard methods explicitly, with the std:: scope. There are a number of reasons for this, but the main one is that if you have the using directive in a header, it will be included in every file that includes that header - which may cause unexpected problems. It is OK to use it in the main file, though it really is better to explicitly scope things as much as you can instead.

Finally, you should never have a single build with more than one main() function. The linker would not be able to single out the one you want, and will return an error.

I hope this explains how to handle this in the future.

[nathan.pavlovsky]

Thanks so much.... and yes, school_r_lea, I had two files with both having main functions among other ones, and I wanted to use some of the other functions in the main program in the other file.