Avoid the Top 4 Static Keyword Traps in C/C++ Interviews and Secure Your Offer
The article explains the four most frequently tested static keyword pitfalls in C/C++ interviews—local variable initialization, thread‑unsafe functions, file‑level global scope, and class member sharing—detailing their underlying lifetime and scope rules, common misconceptions, and a concise answer template to prevent losing an offer.
Static keyword core effect
static changes the lifetime and scope of a variable or function without altering its type, read/write permissions, or stored value.
Lifetime : a static local variable is allocated in the program’s static data segment, lives for the entire execution, and is initialized only once.
Scope : a static global variable or function is visible only within the translation unit where it is defined.
Trap 1 – static local variable initialized only once
Misconception: the variable is re‑initialized on each call.
Correct rule: initialization occurs on the first call; subsequent calls reuse the existing value.
void test() {
static int a = 1;
a++;
std::cout << a;
}
// Calls: 2 3 4Reason: static locals reside in the static data segment, which is allocated at program start, so the memory persists across calls.
Trap 2 – static locals make a function non‑re‑enterable and thread‑unsafe
When a static local variable is accessed by multiple threads, recursive calls, timers, or callbacks, data races can occur because the variable is a single process‑wide resource.
#include <stdio.h>
#include <pthread.h>
void *thread_func(void *arg) {
static int cnt = 0;
for (int i = 0; i < 50000; ++i) {
cnt++; // non‑atomic race
}
printf("Thread finished, cnt = %d
", cnt);
return NULL;
}
int main() {
pthread_t t1, t2;
pthread_create(&t1, NULL, thread_func, NULL);
pthread_create(&t2, NULL, thread_func, NULL);
pthread_join(t1, NULL);
pthread_join(t2, NULL);
return 0;
}All threads share the same static variable; without synchronization the program may produce corrupted counts or crash. The function is therefore non‑re‑enterable and thread‑unsafe. Protect the variable with a mutex or use a non‑static local when sharing is not required.
Trap 3 – static global variable has file‑level visibility
Ordinary global variable : visible to all translation units; can be referenced with extern, which can cause naming conflicts.
static global variable : visible only in the defining source file; other files cannot access it even with extern. This provides module encapsulation.
Trap 4 – static class member belongs to the class, not to any object
Static members are allocated in the static data area at compile time and exist independently of any object instance.
All instances share the same memory; modifying the member through one object changes the value seen by all others.
Before C++11 a static member must be defined outside the class; C++11 allows in‑class initialization for const integral types.
Standard interview answer template
static local variable : moves storage from stack to static data segment, lifetime spans the whole program, initialized once; function becomes non‑re‑enterable and thread‑unsafe.
static global variable : limits scope to the current source file, achieving module privacy and avoiding cross‑file name clashes.
static ordinary function : visible only within the defining file, used to hide implementation details.
static class member (C++) : belongs to the class, not to any object; shared by all instances; requires separate definition (pre‑C++11).
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Deepin Linux
Research areas: Windows & Linux platforms, C/C++ backend development, embedded systems and Linux kernel, etc.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
