Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a basic understanding of programming and I currently learning C++. I'm in the beginning phases of building my own CLI program for ubuntu. However, I have hit a few snags and I was wondering if I could get some clarification. The program I am working on is called "sat" and will be available via command line only. I have the main.cpp.

However, my real question is more of a "best practices" for programming/organization. When my program "sat" is invoked I want it to take additional arguments.

Here is an example:

> sat task subtask

I'm not sure if the task should be in its own task.cpp file for better organization or if it should be a function in the main.cpp? If the task should be in its own file how do you accept arguments in the main.cpp file and reference the other file?

Any thoughts on which method is preferred and reference material to backup the reasoning?

share|improve this question
You don't have to worry about functions being defined in other files as long as you include their headers and link them properly at compile time. If you have written up something already, it will be easier to explain using that. – vpit3833 Jul 11 '12 at 3:49
What is a "CLI program"? – BЈовић Jul 11 '12 at 7:46
CLI == Command Line Interface – invert Jul 11 '12 at 10:12

Your .cpp code files all compile into the same binary/objects, so separating files is merely a convenience for development, making code modular. After parsing the command line parameters, you may decide what calls to perform in your application.

You iterate through application arguments via the argv[] array passed to your main() entry point.

#include <iostream>

int main(int main, char* argv[])
        // Check the number of parameters
        if (argc < 2) {
                // Tell the user how to run the program
                std::cerr << "Usage: " << argv[0] << " NAME" << std::endl;
                /* "Usage messages" are a conventional way of telling the user
                 * how to run a program if they enter the command incorrectly.
                return 1;
        // Print the user's name:
        std::cout << argv[0] << "says hello, " << argv[1] << "!" << std::endl;
        return 0;

As for best practices, it's best not to reinvent the wheel by using a command line parser library as answered here.

share|improve this answer

There's some personal preference, and some slight design benefits involved. Accepting arguments and passing them to other modules/functions is not an issue. What is at issue is how well the overall architecture will be represented if you split it up, versus if you keep it all in one file.

The main reason for splitting it up should be whether it makes organizational sense to.

If I have a program that deals with Desk and Pig objects, I can split all the Desk related class declaration and definition code into Desk.h and Desk.cpp. Likewise for Pig. If the interfaces to these objects is well-defined, changing how the Desk object is implemented shouldn't change the way your main program runs. But now I'm getting into object-orientated design.

What I'm saying is that if there is a good reason from a design standpoint to split Task up from the main() function, then you should do it. From your post I'm not so sure what you are trying to achieve.

What may help more than my attempt at an answer is Wikipedia's article on software design.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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