-1

I have a question about how large c++ projects with many components are supposed to be managed (I guess is the best term). For all intents and purposes I'm a beginning programmer. I understand the basics of compiling, header files, etc., but I've never really worked on anything bigger than homework assignments. So, let's take something like a game engine that has various components like a memory manager, renderer, physics simulation, and so on. How would one work on these components separately, but in a way that makes it easy to integrate back into the whole? For example, would you make a separate visual studio project for each piece with its own main? If you have one big project for everything, how would you work on one component without potentially another unfinished component making it fail every compile? I feel like I'm missing some major concept. Like, for projects with multiple programmers that have to check out portions to work on... do they grab all the code so they can compile, or do they set up their own temporary project to work on their bit? Both options sound wrong. You have to have a main function to compile right?

I would very much appreciate anyone educating me on this topic as I feel this is something i should have and just somehow missed completely.

2
  • Didn't you say you already know about header files? :)
    – Sarien
    Commented Oct 27, 2013 at 21:47
  • I did, but clearly I don't... at least in this context. Please feel free to enlighten me.
    – Morgan
    Commented Oct 27, 2013 at 21:51

3 Answers 3

1

When you are working with larger programs it is customary to have one source file with a main program and the rest (there can be many source files) are called from main. Then you need a build strategy. You can write a script file that compiles each of your source files and then links them all together. Unfortunately this can lead to long build times, so professional programmers use of make files which rebuild only the files that change. As a further refinement, you can organize groups of sources into libraries and build the libraries separately and then link them with your remaining compiled source files.

Try looking up gmake (for linux) to see how to build larger projects. I guess you are using Microsoft VC++, in which case compiled files have .obj extensions and libraries .lib extensions. Microsoft have there own way of building libraries which is slighly more complicated than using gmake.

When you look further you'll come across shared libraries (dynamic link libraries on windows - DLLs).

2
  • Thanks so much for the info, I'll research libraries and make files.
    – Morgan
    Commented Oct 27, 2013 at 22:09
  • Microsoft have there own way of building larger projects - this is integrated into Visual Studio. On Linux and MacOS we use gmake to build larger programs. If you want to experiment with gmake you can install MinGW on Windows (or codeblocks). I've got lots of gmake examples on my website at seddon-software.co.uk. P.S. if you like an answer please up vote it
    – resigned
    Commented Oct 27, 2013 at 22:14
0

This isn't really a great question for Stack overflows format. C++ does support language facilities for managing large code bases, like namespaces, classes, and header files. But your question seems to suggest a lack of perspective as to what they are for, or a limited understanding of the technical framework and process for contributing code to a software project. Which isn't a c++ specific issue.

When working on a living project, a primary concern is dealing with complexity. Or, in other words, reducing the number of things you have to think about at any one point in time. What that means is if another programmer is working on the user interface, ideally your code in the physics engine shouldn't have to change to reflect those changes. So interfaces, for forming abstractions and hiding information, are essential.

Granted I'm pretty green as well, so I can't give any real solid advice. I only mention this point to give some perspective as to how vague your question is. If I understand your question correctly, you might enjoy a book like Code Complete 2 by McConnell.

1
  • Thanks I'll check that book out.
    – Morgan
    Commented Oct 28, 2013 at 0:27
0

Large projects are separated into pieces. Normally, you should have the ability to compile each piece separately. The best practice that I know is to declare the interfaces among the various components, minimizing dependencies as close as possible to zero, and then building 'test' programs, which are small and serve two reasons: test a small piece of code, have main(). The directory structure is usually:

yourlib/
  lib/
  ext-inc/
  test/
  other dirs/
  ...

the lib contains the output library object (.a, .so) the ext-lib contains the headers external code will use (sometimes called 'public' or just 'inc') the test directory usually have a main.c (cpp) file and might have some more, as needed.

When you checkout(svn) / clone(git) / sync(p4) / etc. you would take everything, but work only on your area. once done, you merge/submit your changes into the main branch.

2
  • Morgan doesn't know about libraries, so its probably better not to introduce GIT, SVN, Perforce etc at this point, important though these are. They can come later.
    – resigned
    Commented Oct 27, 2013 at 22:26
  • This may be both a bit advanced for the OP and a bit out of date, but Large Scale C++ Software Design by John Lakos has a lot of good advice in it.
    – user888379
    Commented Oct 27, 2013 at 22:45

Not the answer you're looking for? Browse other questions tagged or ask your own question.