C++ Interview Questions

The preprocessor handles directives like #include, expanding them into actual code. The compiler translates that expanded source code into object code. The linker combines that object code with any needed libraries into a final executable file, which the operating system then actually runs.

A header file declares functions, classes, or variables that can be shared across multiple source files. Angle brackets tell the compiler to look in the standard system include directories, used for standard library headers. Quotes tell it to look in the current project directory first, used for a header file you actually wrote yourself.

A compile-time error is caught by the compiler before the program ever actually runs, like a missing semicolon or a genuine type mismatch. A runtime error only actually surfaces while the program is executing, like dividing by zero or accessing an invalid memory address, which the compiler generally has no way to catch in advance.

Undefined behavior means the language standard genuinely places no requirement at all on what the program actually does once it occurs, accessing an out-of-bounds array index, for instance, could crash immediately, silently produce a wrong result, or appear to genuinely work correctly on one compiler while failing entirely on another. It's more dangerous than an ordinary runtime error precisely because it can seem to work fine during testing and only fail unpredictably later, in a genuinely different environment or under a slightly different compiler optimization.

main() is the entry point every C++ program starts executing from. It's required because the operating system needs one single, consistent, known place to actually start running the program, and by the language's own standard, that specific place is always the function named main.

cout is used for output, writing data to the standard output stream, typically the console. cin is used for input, reading data from the standard input stream, typically whatever the user actually types at the console. Both are part of the iostream library.

int for whole numbers, float and double for decimal numbers (double offering greater precision), char for a single character, and bool for a true or false value. C++ also provides modifiers like short, long, signed, and unsigned to adjust a type's actual range and behavior.

float typically uses 4 bytes and offers roughly 6 to 7 decimal digits of precision. double typically uses 8 bytes and offers roughly 15 to 16 decimal digits, meaningfully more precise, which is why double is the more common default choice for most calculations unless memory usage is genuinely a tight, real constraint.

A signed integer can represent both negative and positive values, splitting its available range between the two. An unsigned integer can only represent non-negative values, but in exchange gets a larger positive range for the same number of bits, since it doesn't need to reserve any of that range for negative numbers.

Type casting converts a value from one data type to another. Implicit casting happens automatically, like an int being promoted to a double during a mixed arithmetic expression. Explicit casting is written directly by the programmer, like (int)someDouble, needed when converting in a direction that could genuinely lose data, which the compiler wants you to acknowledge deliberately.

A local variable is declared inside a function (or a block) and only exists during that specific block's execution, inaccessible from outside it. A global variable is declared outside every function, accessible from anywhere in the entire file, and it persists for the entire lifetime of the program.

It marks a variable as unable to be modified after it's initially initialized, and attempting to change it later triggers a compile-time error. It's commonly used for values that genuinely shouldn't change, like a mathematical constant, and it also helps the compiler catch an accidental, unintended modification early, before it ever becomes a genuine runtime bug.

int add(int a, int b); is a function declaration, telling the compiler the function's name, its return type, and its parameters, without providing the actual implementation yet. int add(int a, int b) { return a + b; } is the actual function definition, providing the real, complete implementation.

Pass by value copies the argument's actual value into the function's own parameter, so any change made inside the function has no effect at all on the original variable outside it. Pass by reference, using &, gives the function direct access to the original variable itself, so a change made inside the function genuinely does affect the original variable back in the calling code.

A default argument provides a fallback value used automatically when the caller doesn't actually supply one for that specific parameter. void greet(string name = 'Guest') lets you call greet() with no argument at all, and it'll genuinely use 'Guest' by default instead.

Function overloading lets you define several functions sharing the exact same name but differing in their actual parameter types or the number of parameters. The compiler determines which specific overloaded version to actually call based on the arguments genuinely provided at each individual call site.

In C++, these terms are genuinely used interchangeably. A function prototype (or declaration) specifies a function's name, return type, and parameter types, without providing the actual body, letting the compiler correctly verify calls to that function elsewhere in the code even before it's actually fully defined further down in the file.

An inline function is a suggestion to the compiler that it should genuinely insert the function's actual code directly at each call site, rather than performing a genuine, separate function call with its associated overhead. It's typically used for a very small, simple function called extremely frequently, where the small savings from avoiding real call overhead can genuinely add up meaningfully across many, many actual calls.

A friend function is a non-member function explicitly granted access to a class's own private and protected members, declared using the friend keyword inside the class itself. It solves the problem of needing a genuinely external function, like an overloaded operator that takes the class as its second argument, to access private data it otherwise genuinely couldn't reach through the class's own normal public interface alone.

A class is a blueprint defining an object's actual data members and the methods operating on them. In C++ specifically, a class and a struct are functionally almost identical, with the one real, meaningful difference being their default access level: a class's members default to private, while a struct's members default to public.

A constructor is a special member function automatically called when a new object of that class is actually created, typically used to initialize the object's own data members. It shares the exact same name as the class itself and genuinely has no explicit return type at all, not even void.

A destructor is automatically called when an object is actually destroyed, whether that's a local object going out of scope, or an object explicitly deleted with delete. It's used to clean up any resources the object was actually holding, like memory it had explicitly allocated itself, and its name is the class name prefixed with a tilde, like ~MyClass().

public members are accessible from genuinely anywhere outside the class. private members are accessible only from within the class itself. protected members are accessible from within the class and from any of its subclasses, but genuinely not from unrelated outside code.

this is an implicit pointer available inside every non-static member function, pointing directly to the specific object the method was actually called on. It's commonly used to genuinely distinguish a member variable from a parameter sharing the exact same name, or to actually return a reference to the current object itself from within a method.

It means defining several methods within the exact same class sharing an identical name but differing in their actual parameter list, the same underlying concept as regular function overloading, just applied specifically to a class's own member functions.

A pointer is a variable that stores the actual memory address of another variable, rather than storing a value itself directly. int* ptr; declares a pointer to an int. Assigning it with ptr = &someInt; makes it actually point directly to someInt's own real memory location.

& is the address-of operator, returning a variable's actual memory address. * is the dereference operator, accessing the actual value stored at whatever address a pointer currently holds. int x = 5; int* p = &x; *p accesses the value at that specific address, which is 5.

A null pointer, represented as nullptr in modern C++, points to genuinely nothing at all, no valid, actual memory address. It matters because attempting to dereference a null pointer, actually trying to access the value it supposedly points to, causes undefined behavior, typically an actual program crash, which is exactly why checking a pointer against nullptr before actually using it is a genuinely important, common habit.

A void pointer, void*, can point to an object of any actual data type, but it can't be dereferenced directly without first being explicitly cast back to a genuine, specific concrete type, since the compiler has no way of knowing on its own what type of data it actually points to. It's occasionally used for genuinely generic, low-level code, but modern C++ generally prefers templates for that same kind of type-generic behavior instead.

A pointer can be reassigned to point to something else entirely, and it can genuinely be null. A reference must actually be initialized when it's first declared, can never be reassigned to refer to something else afterward, and genuinely can't be null. References are generally considered safer and simpler to actually work with in situations where reassignment genuinely isn't ever needed at all.

Pointer arithmetic lets you move a pointer forward or backward by an actual specific number of elements, not raw bytes, adjusted automatically based on the pointer's own underlying data type's actual size. If ptr points to the first element of an int array, ptr + 1 correctly points to the very next int, automatically advancing by exactly 4 bytes on a typical, standard system.

int numbers[5] = {1, 2, 3, 4, 5}; declares an array of 5 integers with those specific given values. Array elements are accessed using a zero-based index, so numbers[0] genuinely refers to the very first element.

A C-style string is a plain array of characters ending in a null terminator, '\0', requiring careful, manual management using functions from the C library like strcpy and strlen. std::string is a proper C++ class handling memory management automatically, offering far more convenient built-in methods, and is the strongly preferred, safer choice in essentially all genuinely modern C++ code.

For a plain, fixed-size array, sizeof(array) / sizeof(array[0]) calculates the total number of elements by dividing the array's total size in bytes by one single element's own size. This specific technique genuinely doesn't work once the array has decayed into a plain pointer, like when it's passed into a separate function.

When an array is passed to a function, or otherwise used in most expressions, it automatically decays into a plain pointer to its very first element, genuinely losing the array's own actual size information entirely in the process. This is exactly why a function receiving an array as a parameter also typically needs a separate, explicit parameter specifying its actual length.

The + operator directly concatenates two std::string objects, string result = str1 + str2;, or you can use the += operator to append one string genuinely directly onto the end of an already-existing one.

A virtual function lets a derived class override a base class's method, and the correct, actual overridden version gets called at runtime based on the object's genuine actual type, even when it's accessed through a base class pointer or reference. Without it, calling a method through a base class pointer would always genuinely call the base class's own version, regardless of the actual real object type it's pointing to.

A pure virtual function is declared with = 0 and genuinely has no implementation in the base class itself, requiring every derived class to actually provide its own concrete implementation. A class containing at least one pure virtual function becomes an abstract class, which can't itself be instantiated directly.

The diamond problem arises when a class inherits from two parent classes that both, in turn, inherit from the exact same common ancestor, resulting in that shared ancestor's data actually being duplicated twice within the final derived object. Virtual inheritance ensures only one single, shared copy of that common ancestor genuinely exists, resolving the ambiguity.

Overriding happens when a derived class provides its own implementation of a virtual function already defined in its base class, using the exact same signature, resolved dynamically at actual runtime. Overloading happens when multiple functions share the exact same name but differ in their actual parameters, resolved instead at compile time, based purely on the arguments genuinely provided.

The stack stores local variables and function call information, automatically managed, growing and shrinking as functions are actually called and return. The heap is used for dynamically allocated memory, requested explicitly with new and released explicitly with delete, and it genuinely persists until you actually free it yourself, or the entire program actually ends.

int* ptr = new int; allocates memory for a single int on the heap. delete ptr; releases that memory back once you're genuinely done with it. For an array, new int[10] allocates an array, and delete[] ptr; (with the specific brackets) is required instead to correctly deallocate an array.

A memory leak happens when memory is dynamically allocated with new but never actually released with a matching delete, so that memory genuinely stays reserved and unusable for the rest of the program's entire run, even though nothing in the program can actually reach or use it anymore. It's a genuinely common bug in manual memory management, since it's easy to actually forget a delete, especially along an error-handling code path.

A dangling pointer points to memory that's already been freed, either through an explicit delete or because the actual object it pointed to has already gone out of scope. It's genuinely dangerous because using it afterward, reading or writing through it, causes undefined behavior, since that specific memory might already have been reused for something entirely different by then.

A shallow copy duplicates an object's own actual member values directly, including any raw pointer members, so both the original and the copy end up genuinely pointing to the exact same underlying dynamically allocated memory. A deep copy duplicates that underlying pointed-to data as well, so the two objects end up genuinely, fully independent of each other, with no shared underlying memory at all.

The STL is a collection of ready-made, generic template classes and functions providing common data structures, vector, map, set, and algorithms, sort, find, for-each, that work genuinely correctly across essentially any actual data type. It saves you from needing to hand-write these same, extremely common data structures and algorithms entirely yourself from scratch.

An array has a genuinely fixed size, decided at the moment it's first declared. A vector can dynamically resize itself as needed, automatically growing to actually accommodate more elements being added over time, which is exactly why a vector is generally preferred over a plain array whenever the actual number of elements genuinely isn't known reliably in advance.

std::vector stores elements in contiguous memory, giving fast, constant-time access by index, but slower insertion or removal genuinely in the middle, since subsequent elements need to be shifted. std::list is implemented as a doubly linked list, giving fast insertion and removal anywhere once you already have an iterator pointing there, but slower access by index, since it has to actually walk the list sequentially from one end.

An iterator is an object that lets you traverse a container's elements one at a time, sequentially, in a way that's genuinely consistent across different container types. Rather than accessing a vector by raw index and a list by chasing raw pointers manually, the exact same *it++ style loop genuinely works for essentially both, through their respective iterators.

std::map keeps its keys genuinely sorted internally, implemented as a balanced tree, giving O(log n) operations. std::unordered_map, implemented as an actual hash table, gives average O(1) operations but stores its keys in genuinely no particular, predictable order at all. You'd choose map specifically when you genuinely need sorted iteration, and unordered_map when raw, average lookup speed matters more than any actual ordering.

std::set stores unique elements in sorted order, backed internally by a balanced tree, automatically rejecting an attempt to insert a duplicate value. A vector allows duplicates and requires manually checking and filtering them out yourself if uniqueness is actually needed, which makes set the more natural, purpose-built choice whenever a collection genuinely needs both uniqueness and sorted order together.

Operator overloading lets you redefine what a standard operator, like +, actually does specifically for objects of a custom class you've written. Overloading + for a Vector2D class to genuinely perform actual, correct vector addition, rather than the operator's default numeric meaning, is a genuinely classic, common example.

A function template lets you write a single, genuinely generic function that works correctly across multiple different data types, without needing to actually write a genuinely separate, near-identical overloaded version for each individual type by hand. template <typename T> T max(T a, T b) { return a > b ? a : b; } works correctly for int, double, or any other type genuinely supporting the > operator.

A class template lets you define a class whose actual internal data type is genuinely a parameter, decided later, at the actual point the class is genuinely used. std::vector<T> is itself a genuinely classic example, the exact same underlying vector implementation working correctly whether it's actually storing int, string, or any other custom, user-defined type.

Template specialization lets you provide a genuinely different, custom implementation of a template specifically for one particular type, when the generic, default version genuinely wouldn't behave correctly or efficiently for that specific type. It's needed when a specific type requires genuinely different handling from what the general template otherwise correctly and safely assumes for every other type.

A try block wraps code that might genuinely throw an exception. A catch block, matched by the actual exception's specific type, handles it if one is genuinely thrown. throw actually raises an exception, immediately transferring control directly to the nearest matching catch block found, rather than continuing execution at the point where the exception was originally actually thrown.

Catching a genuinely specific exception type, like std::out_of_range, handles only that exact particular kind of error. Catching by std::exception& catches genuinely any exception deriving from that common standard base class, which is useful as a genuinely broad, final fallback, though it does lose the ability to actually handle each genuinely different, specific error type in its own distinctly appropriate way.

C++ instead relies on RAII (Resource Acquisition Is Initialization), where a resource's actual cleanup happens automatically in an object's own destructor, which is guaranteed to run when that object genuinely goes out of scope, whether that's through normal, ordinary completion or through an actual exception genuinely being thrown and propagating past it.

The C++ runtime calls std::terminate(), which by default genuinely calls abort(), immediately ending the program. This is exactly why it's genuinely important to have at least one, sufficiently broad catch block somewhere reasonably high up the call chain to actually handle an unexpected error gracefully, rather than letting the whole program simply crash outright.

std::unique_ptr represents genuinely exclusive ownership, only one unique_ptr can ever actually point to a given object at any one time, and it genuinely can't be copied, only moved. std::shared_ptr allows multiple shared_ptr instances to jointly own the exact same object together, using an internal reference count, and the object is only actually deleted once that reference count genuinely reaches zero.

std::weak_ptr holds a genuinely non-owning reference to an object already managed by a shared_ptr, without itself actually increasing that reference count at all. It solves the real, specific problem of a reference cycle between two shared_ptr objects, where each one holding a genuine shared_ptr to the other would otherwise prevent either one from actually ever being deleted at all.

RAII ties a resource's actual lifetime directly to an object's own lifetime, acquiring the resource in the object's constructor and genuinely releasing it in the destructor, which runs automatically and reliably regardless of how that specific scope is actually exited, whether through normal completion or an actual exception. It's central because it makes resource cleanup genuinely automatic and reliable, rather than depending on a programmer remembering to manually clean things up correctly every single time.

Move semantics let you transfer ownership of a resource from one object directly to another, without genuinely performing an expensive, full deep copy of the underlying data. It solves the real, genuine performance problem of unnecessarily copying a large, expensive-to-duplicate object, like a big vector, when the actual original object was genuinely about to be discarded right afterward anyway.

A copy constructor creates a genuinely new, fully independent object by actually duplicating an existing object's own underlying data entirely. A move constructor instead genuinely transfers ownership of that existing object's own resources directly into the new object, leaving the original source object in a valid but genuinely unspecified, now-empty state, without ever actually performing a real, expensive full copy at all.

Calling that ambiguous method through the derived class directly results in a genuine compile-time error, since the compiler genuinely can't determine on its own which specific base class's version you actually intended. You'd resolve it explicitly by qualifying the specific call with the actual intended base class's own name, like BaseClassA::methodName().

A mixin adds a specific, genuinely reusable piece of behavior to a class through inheritance, without itself representing a genuinely complete, meaningful is-a relationship on its own. It's typically implemented as a small class template that a target class inherits from, using CRTP (Curiously Recurring Template Pattern), letting the mixin genuinely call methods actually defined on the specific derived class itself.

CRTP has a class inherit from a template instantiated specifically with itself as the actual template argument, class Derived : public Base<Derived>. It's genuinely used to achieve a form of static, compile-time polymorphism, avoiding the genuine runtime overhead of an actual virtual function call, useful in genuinely performance-critical code where that specific overhead actually matters.

Template metaprogramming uses C++ templates to genuinely perform computation directly at compile time, rather than at actual runtime, which can meaningfully improve real runtime performance by shifting real work earlier, into the actual compilation process itself. It's genuinely powerful but can also produce famously cryptic, genuinely difficult-to-read compiler error messages when something actually goes wrong.

SFINAE describes a specific rule where, if substituting a specific template parameter would genuinely produce an invalid type or expression, the compiler simply and quietly removes that particular overload from actual consideration entirely, rather than genuinely raising a hard compile error outright. It's used, often through std::enable_if, to selectively enable or genuinely disable a specific function overload based on a given type's own actual properties.

The capture clause, in the square brackets, determines which genuinely outer-scope variables the lambda can actually access from inside its own body. [x] captures x by value, taking an actual independent copy at the moment the lambda is created. [&x] captures it by reference instead, so the lambda genuinely sees any subsequent change made to the actual original variable afterward.

std::move() doesn't itself genuinely move anything at all. It's simply a cast that converts its argument into an rvalue reference, signaling to the compiler that this particular object is genuinely safe to actually move from, which then triggers a move constructor or move assignment operator to actually run instead of a genuinely more expensive copy.

std::thread creates and actually runs a new thread. std::mutex protects genuinely shared data from being simultaneously, unsafely accessed by more than one thread at once. std::condition_variable lets one thread actually wait efficiently for a specific signal or condition from another thread, rather than wastefully polling repeatedly in a tight loop.

A data race happens when two or more threads simultaneously access the exact same shared memory location, with at least one of them genuinely writing to it, and there's no actual synchronization at all coordinating that access. std::mutex prevents this by ensuring only one thread at a time can genuinely hold the lock and actually access the specific protected data, forcing every other thread to actually wait its own turn.

std::optional represents a value that might or might not genuinely be present, making that specific possibility fully explicit and directly visible right in the actual function's own return type itself. It avoids the genuine ambiguity of a sentinel value like -1, which could theoretically also be a genuinely valid, real actual result in some other, different context, and it avoids the actual, real risk of ever needing to dereference a genuinely null pointer at all.

Structured bindings let you unpack a struct, a pair, or a tuple directly into several genuinely separate, individually named variables in a single line, auto [name, age] = getPerson();, rather than needing to actually access each individual field separately through .first, .second, or a similarly named individual member one at a time.

A profiler like gprof, Valgrind's Callgrind, or perf actually measures precisely where a program's genuine execution time is truly being spent, at the specific function level, rather than genuinely guessing at what's slow purely based on which code merely looks the most complex at a glance.

Modern CPUs are dramatically faster at accessing data already sitting in a nearby CPU cache than data that has to actually be fetched all the way from main memory. Code that accesses memory in a genuinely predictable, sequential pattern, like iterating straight through a contiguous vector, benefits enormously from cache locality compared to code that jumps around unpredictably between scattered, genuinely non-contiguous memory locations, like chasing pointers through a linked list.

In practice, std::vector is very often genuinely faster overall even for workloads theoretically favoring a list's own supposed O(1) insertion, purely because of vector's dramatically superior cache locality. I'd default to vector unless actual profiling on genuinely real data specifically shows list's own particular insertion pattern is truly the actual, real bottleneck.

If a class genuinely needs a custom destructor, copy constructor, or copy assignment operator, it very likely genuinely needs all three, since they're all typically related to the exact same underlying resource-management concern. The Rule of Five extends this to modern C++, additionally including the move constructor and the move assignment operator alongside those original three.

Favor RAII consistently so resources are genuinely cleaned up automatically regardless of how a given scope is actually exited, and design operations to be genuinely atomic where reasonably possible, either an operation genuinely fully succeeds, or it leaves the object's actual state genuinely completely unchanged, rather than ever leaving it stuck somewhere awkwardly in between the two.

Static polymorphism, achieved through templates or overloading, is fully resolved at compile time, with genuinely zero runtime overhead. Dynamic polymorphism, achieved through virtual functions, is resolved at actual runtime instead, adding a small, real overhead but offering genuinely more real flexibility when the specific actual type genuinely isn't known until runtime itself.

Migrate incrementally, starting with the genuinely highest-risk areas, code that's caused actual real memory-related bugs before, rather than attempting to rewrite the entire, complete codebase all at once in one single, large, disruptive pass. Leaning on real, existing test coverage to actually catch a regression early matters just as much here as it does for genuinely any other kind of large-scale migration.

I check whether ownership of every dynamically allocated resource is genuinely clear and correctly modeled, typically through the appropriate smart pointer type, whether the design is genuinely exception-safe, and whether it's realistically going to actually perform well at the genuine, real scale the application actually needs, beyond simply working correctly on a small, simple test case.

Automate what can genuinely be automated, static analysis tools that flag raw memory management directly in code review, enforced in CI so standards aren't purely a matter of individual opinion. For the more genuinely subtle design conventions that resist full automation, I'd document the handful of decisions that actually matter most, along with the real, concrete reasoning behind each one.

I'd weigh the genuinely concrete new features that would actually meaningfully help, like concepts or coroutines, against the real compiler-support requirements and the genuine cost of a team's own existing familiarity with older, more established C++ idioms. I'd pilot the actual upgrade on a genuinely smaller, lower-risk component first before rolling it out much more broadly across the entire codebase.

A crash dump, analyzed with a debugger like gdb, often reveals the exact actual call stack at the specific real moment of the crash, which is a genuinely strong starting point. Memory corruption bugs, an out-of-bounds write or a genuine use-after-free, are common actual causes of exactly this kind of intermittent, inconsistent crash, and a tool like AddressSanitizer run during earlier actual testing can help catch that exact same class of bug well before it ever genuinely reaches production.

Track memory usage over time specifically to catch a genuine, slow memory leak before it eventually causes an actual real out-of-memory crash, alongside standard latency and error-rate metrics. For a genuinely native application specifically, I'd also want visibility into things like actual thread pool utilization and lock contention, which don't always show up cleanly in a generic, standard application-level metrics dashboard.

Treat the library's actual public headers as a genuine contract. Adding a new function is generally safe. Changing an existing function's actual signature, or a class's own binary layout, can genuinely break other code linking against it even without an actual visible compile error, which is exactly why C++ library versioning needs real, careful, deliberate attention that a simpler, higher-level language's own equivalent often doesn't genuinely require to the same degree.

Mitigate first: schedule a genuinely regular, planned restart of the actual service as an immediate, short-term stopgap, buying real, needed time to actually properly diagnose the real, underlying root cause. Then use a genuine memory profiler to identify exactly what's actually accumulating and never being properly released, which is almost always more directly informative than attempting to trace the actual real leak purely by reading through code alone.

Start from actual load testing at realistic traffic patterns rather than a purely theoretical, rough calculation, since real bottlenecks, lock contention under genuine concurrency, memory allocation overhead under sustained load, often only actually surface under genuinely real, sustained load rather than in a simple, isolated, artificial benchmark test.

This is a judgment question interviewers use to see how you reason under genuine uncertainty, not to test a specific textbook fact. A strong answer names the actual constraint that forced the decision, the realistic options that were genuinely on the table, why you picked one knowing it wasn't guaranteed to be right, and what you'd do differently with what you know now.

I'd walk through one of their actual pieces of code together, showing concretely how a real memory leak or an actual use-after-free bug could genuinely occur given their exact current approach, then show how the equivalent smart pointer version genuinely eliminates that entire specific class of bug outright, rather than simply telling them smart pointers are genuinely better in the abstract.

I wouldn't push a full, disruptive rewrite of everything that already exists. I'd apply modern practices consistently to genuinely new code first, letting the team directly see the real, concrete difference in reliability and readability on code they already recognize firsthand, rather than mandating an immediate, wholesale, disruptive change to the entire, already-working existing codebase all at once.

I'd bring actual, real benchmark data comparing the two directly, rather than a purely general, abstract belief about raw arrays inherently always being genuinely faster. In practice, std::vector often performs essentially identically once properly compiled with real optimizations genuinely enabled, and grounding the discussion in real, actual measured numbers resolves this kind of disagreement far faster than continuing to debate it in the abstract.

I'd translate the risk into terms leadership already tracks: the cost of a specific past crash or security issue traced back to manual memory handling, and how much longer a typical change in that specific area now takes compared to a genuinely well-modernized part of the same codebase. Framed as a reliability and velocity issue with a real, already-incurred cost behind it, it competes far better for prioritization than framed as a general code-quality concern.