Google Logging
InitGoogleLogging
glog
logging library
C++ development

What does InitGoogleLogging do?

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

InitGoogleLogging is the initialization call for the glog C++ logging library. You call it early in main so the library can set up its internal logging state before any LOG(...) macros are used. In practice, it establishes the program identity used in log output and prepares glog to honor its configured destinations and flags.

Call It Before Logging Anything

A minimal glog setup looks like this:

cpp
1#include <glog/logging.h>
2
3int main(int argc, char* argv[]) {
4    google::InitGoogleLogging(argv[0]);
5
6    LOG(INFO) << "Application starting";
7    LOG(WARNING) << "A warning message";
8}

The important point is timing. InitGoogleLogging should run before the first real log statement so the library is initialized consistently.

The Program Name Matters

The usual argument is argv[0], which gives glog the program name or executable path. glog uses that identity when naming log files and formatting log output.

That is why you typically see:

cpp
google::InitGoogleLogging(argv[0]);

rather than an arbitrary string. The library wants to know what program is producing the logs.

It Enables glog's Runtime Configuration Model

glog supports configuration through command-line flags and environment-like settings such as:

  • logging to files
  • logging to stderr
  • setting log severity thresholds
  • controlling verbose logging

Initialization is what makes those mechanisms meaningful for the current process. Without that step, the library does not have a fully established logging context.

A common example is redirecting logs to standard error:

cpp
FLAGS_logtostderr = 1;
google::InitGoogleLogging(argv[0]);

Now the later LOG(INFO) messages will go to stderr instead of log files.

It Does Not Replace Cleanup or Signal Handling

InitGoogleLogging is just initialization. It does not automatically mean all advanced features are enabled. Many programs also call cleanup or crash-handling helpers explicitly.

cpp
1#include <glog/logging.h>
2
3int main(int argc, char* argv[]) {
4    google::InitGoogleLogging(argv[0]);
5    google::InstallFailureSignalHandler();
6
7    LOG(INFO) << "Ready";
8
9    google::ShutdownGoogleLogging();
10}

ShutdownGoogleLogging is not always strictly necessary in tiny programs, but it expresses lifecycle clearly. InstallFailureSignalHandler is also separate because failure logging and ordinary initialization are different responsibilities.

Think of It as Library Bootstrap

The easiest mental model is this: InitGoogleLogging bootstraps the glog runtime for the current process.

It does not create your log messages, choose your severities, or decide your logging policy. It prepares the library so those later choices work correctly.

That is why the function is small in code but important in program startup.

Use It Once Per Process

You typically call InitGoogleLogging once in process startup code, not repeatedly in helpers or libraries. Logging initialization is a process-level concern, not something each component should redo independently.

Repeated or scattered initialization logic usually indicates the logging lifecycle has not been centralized properly.

Common Pitfalls

  • Calling LOG(...) before InitGoogleLogging and assuming glog is already fully configured.
  • Passing an arbitrary string instead of the real program name when argv[0] is available.
  • Expecting InitGoogleLogging to automatically install crash handlers or perform full cleanup on its own.
  • Initializing glog in multiple places instead of once at process startup.
  • Treating initialization as optional because basic logging appears to work in a limited test.

Summary

  • 'InitGoogleLogging initializes the glog library for the current process.'
  • It is usually called once, early in main, with argv[0].
  • The call sets up the program identity used by glog and enables normal logging configuration behavior.
  • It is separate from optional helpers such as failure signal handlers and shutdown cleanup.
  • Think of it as the bootstrap step required before using glog reliably.

Course illustration
Course illustration

All Rights Reserved.