Core Application Framework

An executable needs one place where platform arguments become library values, options are parsed, shared services are created, work begins, failures are reported, and shutdown is coordinated. Application provides that boundary while allowing the program itself to stay as small or as structured as its problem requires.

The topics in this chapter begin with five ways to organize an application. They then continue into the application-part framework and version metadata that larger programs commonly need.

Choosing an Application Design

The same Application lifecycle supports a compact pair of functions, synchronous processing, asynchronous event dispatch, command modules, and dependency-managed services. Choosing an Application Design compares these designs and helps you select the smallest one that matches the program’s control flow.

Writing Small Applications with Functions

A short executable often needs the framework lifecycle without needing a new class. Writing Small Applications with Functions shows how initialization and main functions can configure and run such a program.

Building Event-Driven Applications

Servers, monitors, and asynchronous clients spend most of their lifetime reacting to events. Building Event-Driven Applications explains how the default main implementation enters the application event loop and how callbacks complete the process through quit().

Building Procedural Applications

Converters, report generators, and batch tools often follow one synchronous path from parsed input to an exit code. Building Procedural Applications shows how an Application subclass can express that path in an overridden main().

Organizing Command-Style Tools

Some executables contain several actions selected by the first command-line argument. Building Command-Style Applications connects action objects with option modules so parsing, help, and dispatch remain close to each command.

Composing Applications from Services

Long-running programs may need independently managed services with explicit startup and shutdown dependencies. Building an Application from Parts introduces application-owned parts and the lifecycle integration supplied by the default application main loop.

Designing Application Parts continues with service interfaces, dependency declarations, lifecycle hooks, command-line forwarding, failure handling, and cross-thread access. Running Application Parts Independently explains how to run the same kind of service graph without an Application owner.

Running as a Service or Foreground Daemon

Servers can use one executable for interactive development, foreground operation under a POSIX supervisor, and a Windows service. Creating Services and Foreground Daemons explains graceful termination, readiness reporting, and application-part integration.

Adding Build Version Information

Applications can expose a version derived from Git without copying it into source code. Adding Git Version Information to Your App explains the CMake setup and how the generated value reaches application metadata.