5. The Main Function

Lesson 5 extension · one boundary, two directions

main admits input and reports an outcome

The smallest main can look like a ceremonial marker placed at the top of a program. Execution begins here, so the explanation appears finished. It is not. The important question is what crosses this boundary in each direction: invocation data enters the program, and a termination status returns to the invoking environment.

The special role of main is defined by C++. The operating system does not search through C++ source code until it finds a function with the right spelling. In a hosted implementation, the program provides one global function called main, and the implementation arranges for it to be called after the required start-up work. A toolchain and operating system do lower-level work before that point, but those mechanisms are outside the portable source-level model.

Begin with the two common portable forms: int main() and int main(int argc, char* argv[]). The second parameter can equivalently be written as a pointer to pointer. An implementation may permit other forms, but that does not make them portable course material. The declared return type is int; void main() is not a portable C++ form.

Count first, then justify every index

The parameter names are chosen by the programmer, so the example below uses argumentCount and arguments rather than relying on the traditional abbreviations. The rule is unchanged. argumentCount is non-negative, and arguments[argumentCount] is a null pointer marking the end of the array. Valid argument strings occupy the indices below that boundary.

If argumentCount is greater than zero, arguments[0] represents the name used to invoke the program, or it may point to an empty string when that information is unavailable. Do not turn a common observation, such as seeing a full executable path, into a guarantee. Later elements contain text supplied through the invoking environment. Quoting and tokenisation are handled before main receives the array, so quote characters typed in a shell are not necessarily present in the resulting argument string.

#include <iostream>

int main(int argumentCount, char* arguments[]) {
    std::cout << "Argument count: " << argumentCount << '\n';

    for (int index{0}; index < argumentCount; ++index) {
        std::cout << index << ": " << arguments[index] << '\n';
    }

    return 0;
}

Suppose the executable is invoked as course_demo alpha beta. A typical environment supplies an argument count of 3. The first loop iteration reads index 0, the second reads index 1 and the third reads index 2. When index becomes 3, the condition index < argumentCount is false and the loop stops. The program has accounted for every argument string without crossing the boundary.

Changing the loop condition to index <= argumentCount does not include one more useful element. It attempts to stream the null sentinel as though it pointed to a character sequence. The error is not merely that the loop ran once too often; the program confused the marker of the boundary with data inside the boundary.

All later arguments remain text. If a person intends arguments[1] to mean the number 50, intention has not performed a conversion or proved that 50 is acceptable. The program must check that the argument exists, that its complete syntax represents the required value and that the value lies within the accepted range. A generated parser that works for one friendly example has passed one example, not the input contract.

Printed output and termination status answer different questions

std::cout communicates text through an output stream. Returning from main communicates a termination status to the host environment. They are separate channels. A program can print a correct partial report and still return failure because a later operation could not be completed. It can also print the word "success" and return a status that tells an automated caller the opposite. The printed word is not in charge.

Returning zero denotes successful termination in the portable C++ model. EXIT_SUCCESS and EXIT_FAILURE from <cstdlib> provide portable values for successful and unsuccessful termination. Other integer meanings belong to the surrounding platform or application convention and must be checked against the relevant specification rather than invented. Reaching the closing brace of main has the same success effect as return 0;, although the explicit return remains useful while the contract is being taught.

This distinction becomes visible when another program is the caller. A test runner, build script or deployment pipeline may ignore ordinary output and make its next decision from the termination status alone. If the program reports an error in prose but returns success, a person may notice the message while the automation proceeds as though the operation succeeded.

A short main still contains policy

Line count is a poor measure of the responsibility at the top of a program. A short main can still decide how invocation text is validated, where configuration comes from, which operation runs, how diagnostics are reported and how an application result becomes a process status. Moving detailed work into named functions makes those decisions easier to inspect; it does not make them disappear.

Consider a main containing four calls: read the command line, load configuration, run the application and translate the result into an exit status. The code may fit on one screen. The test is whether each failure has one accountable route. If configuration cannot be loaded, which function describes the problem, which channel carries the diagnostic and which status reaches the invoking process? Those are boundary decisions, not decoration around the real program.

I therefore want main to show policy without absorbing every mechanism. It should make the route from external input to application decision and back to external status visible. Parsing details, file operations and application logic can live elsewhere, where they can be named and tested. The top-level account must still be honest.

Trace the complete exchange

Draw the argument array for two invocations of the example: course_demo and course_demo alpha beta. Label every valid index, add the null pointer at arguments[argumentCount], and trace the loop condition before each access. Do not borrow an argument count from the example; derive it from the array you drew.

For each run, record two results separately: the text written to standard output and the status returned by main. Then make one deliberate mistake by changing < to <= and identify the first expression that no longer satisfies its obligation. If your explanation says only "out of bounds", continue. Name the value reached, explain why it is a sentinel rather than an argument string, and show which earlier condition should have prevented the access.

Argument count: 1
0: course_demo

Argument count: 3
0: course_demo
1: alpha
2: beta