C++ Language

Deterministic destruction (RAII), a type system that can encode ownership and interfaces (references, const, overloading, templates), and the STL. You write fewer manual acquire/release pairs and you can express generic algorithms without macros. You still compile to the same kind of machine code and you still have UB if you break the abstract machine.

Pointers and arrays, struct layout and padding, stack vs heap, the compilation and linking model, calling conventions, syscalls and file descriptors, and C undefined behavior (use-after-free, overflows, data races). Android native work constantly drops to that layer. See C.

Resource Acquisition Is Initialization: the constructor acquires a resource (memory, fd, lock, mapping) and the destructor releases it. Scope exit, return and exception unwind all run destructors, so you do not write a cleanup path for every exit. Smart pointers and lock_guard are RAII. The kernel, being C, uses other patterns (devm_*, goto cleanup); that is a different world (Linux kernel & BSP).

The text the compiler actually compiles: one source file after the preprocessor has expanded #include, macros and conditionals. Each .cpp is typically one translation unit and becomes one object file. Templates and inline exist because the compiler does not automatically see the whole program.

Each function, variable, class and template specialization may have only one definition in the program. Inline functions, inline variables and templates may be defined in multiple translation units if those definitions are identical. Two different definitions (often from a header compiled with different macros) are an ODR violation and undefined behavior, even if the linker is silent.

It means the definition is allowed to appear in more than one translation unit and the linker must merge them. It is not a command to put the body in every call site; the optimizer inlines with or without the keyword. Put non-template function definitions in headers only if they are inline (or constexpr, which is implicit inline).

To give a function C linkage: no C++ name mangling, so a C caller, the dynamic linker, or the JVM (JNI) can find the symbol by its C name. It does not make the function "C" internally; it can still use C++ types in the body. You cannot overload two extern "C" functions with the same name.

The compiler encodes parameter types (and some qualifiers) into the linker symbol so foo(int) and foo(double) can both exist. On Android/Linux this is the Itanium ABI scheme (_Z...). nm or llvm-cxxfilt demangles. C symbols are not mangled this way, which is why mixed-language APIs need extern "C".

Virtual bases (from the most-derived constructor), then direct bases in base-list order, then members in declaration order, then the constructor body. Destruction is the exact reverse. Initializer-list order does not change member construction order. If a later member throws, already-constructed members and bases are destroyed.

A per-class table of pointers to virtual functions (plus RTTI and offset-to-top for multiple inheritance). A polymorphic object typically holds a hidden vptr to the vtable of its dynamic type. A virtual call loads the vptr, indexes a slot, may adjust this, and performs an indirect call.

A non-virtual call is resolved at compile time from the static type (and can be inlined easily). A virtual call is resolved at run time from the dynamic type through the vtable. Use virtual for "is-a" interfaces you will call through a base; do not make everything virtual (cost + it becomes part of your ABI).

A virtual function declared = 0. A class with at least one unimplemented pure virtual is abstract: you cannot instantiate it. Derived classes must override it (or stay abstract). A pure virtual destructor still needs a definition, because derived destructors call it.

Copying or assigning a derived object into a base value copies only the base subobject. Virtual overrides and derived members are gone. Avoid it: pass polymorphic types by pointer or reference, and store unique_ptr<Base> in containers, not Base by value.

An lvalue names an object that has identity and is not treated as expiring (a variable, *p). An rvalue is either a prvalue (a temporary / initializer like T{}) or an xvalue (something that is about to expire, like std::move(x)). Rvalues bind to T&& and can be moved from. "Left of equals" is the pre-C++11 slogan and is incomplete.

It is a cast to an rvalue reference: static_cast<T&&>(t). It does not move memory. Overload resolution may then pick a move constructor or move assignment. If none exists, or the object is const, a copy is used. After a move, STL objects are valid but unspecified (usually empty, still destructible).

Copy when you need two independent objects. Move when you are finished with the source and want to transfer its resources in O(1) (buffers, unique ownership). Pass cheap types by value; pass large read-only objects by const T&; pass transferable sinks by value or T&&. Return locals by name so NRVO / elision can apply.

If every resource is already owned by a member that knows how to copy, move and destroy itself (string, vector, unique_ptr), do not write a destructor or copy/move members. The compiler-generated ones are correct. This is the default for new C++ classes.

Rule of Three (C++98): if you need a custom destructor, copy constructor or copy assignment (raw owning pointer), you need all three, or copies will double-free or leak. Rule of Five (C++11): writing any of those suppresses implicit moves, so you must also write or = delete the move constructor and move assignment. All five, or none.

unique_ptr is exclusive, move-only, zero overhead beyond the pointer (empty deleter can EBO). shared_ptr shares ownership with an atomic strong count in a control block; copies are not free. weak_ptr observes without keeping the object alive; lock() tries to promote to shared_ptr. Default to unique_ptr.

They pair allocation with construction so you do not write naked new. make_shared usually does one heap allocation for the object and the control block, and is exception-safer than shared_ptr<T>(new T) in expressions with multiple arguments. Use a custom deleter when you cannot.

Copying an auto_ptr transferred ownership and nulled the source, so passing by value silently emptied the caller. It did not work in standard containers. unique_ptr is move-only and correct. C++17 removed auto_ptr.

new allocates and constructs; delete destroys and deallocates. malloc/free only deal in raw bytes and do not call constructors or destructors. Mixing them ( free of new, delete of malloc) is undefined. Prefer containers and smart pointers over both in C++ code.

A new that constructs an object in storage you already have: new (buf) T(args). It does not allocate. You destroy with p->~T(), not delete p. Used by vector, optional and variant. The buffer must be aligned for T.

vector is the default: contiguous, O(1) index, amortized O(1) append, best cache behavior. deque when you need O(1) insert/erase at both ends and still want random access. list when you need stable iterators and O(1) splice given a position; it is node-based and usually the wrong default because of cache misses. Interview default is vector unless you can name the extra need.

map is an ordered tree (typically red-black): O(log n), no hash, iterates in key order, stable iterators except for the erased node. unordered_map is a hash table: average O(1), worst O(n), needs a hash and equality, rehash invalidates iterators. Use map for order or for types that are painful to hash; use unordered_map for average speed and call reserve when you know the size.

std::string stores a short string inside the string object (commonly 15 characters on 64-bit libc++, sometimes more) and heap-allocates only when it grows past that. Moving a short string may copy those bytes; moving a long string steals a pointer. A char* obtained from c_str() dangles if the string reallocates or dies.

const means this access path will not mutate (plus some compiler assumptions for objects that were defined as const). constexpr means the function or variable can participate in constant evaluation: it may run at compile time if the arguments allow, and the same function can still run at runtime. A constexpr variable is implicitly const.

It promises the function will not throw. If it does, the program calls terminate. The promise is used by the type system: vector relocates by move only when the move constructor is noexcept; otherwise it copies so a throw can still leave the container valid. Mark genuine non-throwing moves and swaps noexcept.

Two threads access the same memory location, at least one access is a write, the object is not atomic, and the accesses are not ordered by happens-before (a mutex, an atomic acquire/release pair, etc.). That is undefined behavior, not "last writer wins". Fix it with a mutex, with std::atomic, or by not sharing.

Use-after-free or a dangling reference; using a vector iterator after a reallocation; signed integer overflow; a data race; accessing an object through an incompatible type (strict aliasing). Also: mismatched new/delete[], calling a virtual through a dangling pointer, and writing through const_cast to a truly const object.

A compiler-generated function object: a unique class with operator() and optional capture members. [] captures nothing; [=] copies; [&] references; prefer explicit [x, &y]. A capture-less lambda can convert to a function pointer. If the lambda outlives the captured locals, you have a dangling reference.

The kernel needs a tiny stack, no hidden allocations, no exceptions, no RTTI, a stable C ABI for modules, and control over every instruction in atomic context. C++ features (exceptions, constructors in unexpected places, name mangling, a heavy runtime) fight that. Linux is a C abstract machine plus kernel APIs. Userspace Android (daemons, HALs, NDK) is where C++ belongs. See Linux kernel & BSP.

LLVM libc++, linked as c++_shared or c++_static. It is not GNU libstdc++. Do not pass std::string or containers across a boundary compiled with a different STL or ABI. Keep public .so APIs in C types, NDK binder types, or AIDL.

Almost always start with unique_ptr: exclusive ownership, no atomic traffic, clear lifetime. Use shared_ptr only when lifetime is genuinely shared and cannot be expressed as "parent owns child" (sometimes caches, graphs, or async callbacks). Shared ownership is a design smell if everything is shared.

A reference is an alias: it must be bound at initialization, cannot be reseated (except via implementation tricks you should not use), and is not nullable. A pointer is an object that holds an address: it can be null, reseated, and used in arithmetic. Use references for required aliases and function parameters; use pointers for optional or reseatable non-owning views, and smart pointers for ownership.

Each used specialization is instantiated in the translation units that need it. Identical instantiations are merged at link time. Instantiating a heavy template in many TUs explodes compile time and object size. Mitigations: explicit instantiation in one .cpp plus extern template in the header, thinner headers, and (C++20, optional in interviews) modules.

A compiler snapshot of a stable prefix of includes so later files skip re-parsing them. It is a build-speed tool, not a language feature. If anything in the prefix changes, the PCH rebuilds. Android/Soong and many desktop builds use them for the expensive STL and platform headers.

Compiled callers assume a layout and a calling convention. Adding a virtual function (vtable slots move), adding a data member, changing a member type, switching -fno-exceptions/-fno-rtti, or mixing libc++ with libstdc++ can break a shared library without a source-level error. PIMPL and C APIs are the usual firewalls. Android VNDK exists because this problem is real at OS scale.

D inherits B and C, both inheriting A. Without virtual inheritance, D contains two A subobjects; names and conversions become ambiguous. Virtual inheritance shares one A, found via a vbase offset. It is slower and more complex; most Android code prefers a single abstract interface or composition instead of diamonds.

In multiple inheritance, a pointer to the second base is not the address of the complete object. Converting Derived* to Base2* adds an offset. A virtual call through Base2 may apply a thunk that adjusts this before jumping to Derived::foo. Single inheritance usually has offset 0.

An empty class object still has size 1 so two instances have distinct addresses. An empty base can occupy zero bytes. unique_ptr<T, EmptyDeleter> can therefore be one pointer wide. C++20 [[no_unique_address]] allows a similar optimization for members. Interviewers use this to see if you know why a custom deleter's size matters.

A glvalue has identity (lvalue or xvalue). A prvalue is a pure initializer/temporary (literals, T{}, a function returning T by value) and is the thing C++17 materializes into an object. An xvalue is an expiring glvalue: std::move(x), or a member of an rvalue. Move constructors bind to rvalues (xvalue or prvalue).

Since C++17, initializing an object from a prvalue of the same type does not require a copy or move (the object is constructed in place). NRVO is optionally constructing a named local directly in the return slot; it is allowed but not required. return std::move(local) turns the local into an xvalue and blocks NRVO, so you may get a move instead of true elision. Return the name.

When the class owns a raw resource or maintains an invariant that member-wise copy/move would break, and you did not wrap that resource in an existing RAII type. Write a correct destructor, deep or deleted copies, and moves that steal and null the source. Self-assignment and moved-from destruction must be safe. Prefer wrapping and returning to Rule of Zero.

T& operator=(T other) { swap(*this, other); return *this; } — the parameter is copy-constructed or move-constructed. If that construction throws, *this is unchanged (strong guarantee). swap exchanges guts and should be noexcept. The parameter then destroys the old guts. Self-assignment is naturally safe because you work on a copy.

A strong (use) count, a weak count, a deleter, and an allocator (type-erased). When the strong count hits 0 the deleter runs and the object is destroyed. When both counts hit 0 the control block is freed. weak_ptr increments only the weak count. Formula: destroy object iff strong==0; free block iff strong==0 and weak==0.

The mixin stores a weak_ptr that shared_ptr's constructor arms when it takes ownership of an object that inherits the mixin. shared_from_this() locks that weak pointer. If no shared_ptr owns the object yet (stack object, raw new without immediately wrapping, or a second control block), you get bad_weak_ptr. Never construct shared_ptr<T>(this) yourself.

When release is not delete: fclose, close, free, ANativeWindow_release, HIDL release, or an arena. Put the deleter type in the unique_ptr signature. A function pointer costs a word; an empty functor can be EBO'd. shared_ptr type-erases the deleter in the control block so the pointer type stays shared_ptr<T>.

Breaking parent/child or observer cycles so refcounts can hit zero; caches that should not keep the object alive; "call me if I still exist" callbacks (Android listeners, Binder death). You lock() to get a shared_ptr or skip the callback if expired. Android's wp<T> is the same idea in the old RefBase world.

Containers allocate raw memory through an allocator, then placement-construct elements, and later destroy then deallocate. allocator_traits supplies defaults so a custom allocator can be small. vector<T, A> is a different type from vector<T>. C++17 pmr adds a runtime memory resource. Interviews want this mental model, not a full allocator implementation.

alignof(T) is the alignment the type requires. alignas(N) requests at least that alignment on a variable or type. Over-aligned types (SIMD, cache-line padded atomics) need C++17 aligned operator new or a custom allocator. Placement new into an under-aligned buffer is UB.

After you destroy an object and placement-new a new one in the same bytes, old pointers can be assumed by the compiler to still refer to the old object (especially with const or reference members). std::launder(p) returns a pointer the compiler must treat as pointing at the new object. You rarely write it by hand; know the sentence for lifetime-reuse questions.

In template<class T> void f(T&& x), T&& is a forwarding (universal) reference: lvalues make T a reference, rvalues make T a non-reference. std::forward<T>(x) casts x back to that category so a callee can move only from rvalues. A non-template T&& is just an rvalue reference and binds only rvalues.

Prefer extra function overloads (including additional function templates). Full specialization of function templates does not participate in overload resolution the way people expect and is easy to get wrong. For classes, full and partial specialization are the normal tools (vector<bool> is the infamous partial-specialization example; do not imitate its proxy-reference design).

Substitution Failure Is Not An Error: if substituting template arguments into a function template's declaration fails, that candidate is discarded. enable_if, void_t and decltype in the signature are the pre-C++20 tools for "this overload exists only if T has X". Hard errors inside the body are still hard errors; the failure must be in the immediate context of the signature.

Concepts name requirements (std::integral, std::ranges::range) and participate in overload resolution with better diagnostics. They replace most enable_if boilerplate. You should still recognize SFINAE in older codebases (including a lot of Android). Interviews often ask you to constrain a template both ways.

Derived inherits Base<Derived>. Base calls static_cast<Derived*>(this)->impl(): compile-time polymorphism, no vtable, easy inlining, but each Derived is a different type so you cannot put them in one vector<Base*>. Use CRTP for mixins and static interfaces; use virtual when you need runtime heterogeneity.

A parameter pack class... Ts holds zero or more types or values and expands with Ts.... Recursive instantiations used to process packs; C++17 folds reduce them: (0 + ... + args), (os << ... << args). make_unique and tuple factories forward packs with std::forward<Args>(args)....

When capacity is exhausted, the vector allocates a larger buffer (libc++ doubles; some libraries use 1.5×), move-or-copies elements, and frees the old buffer. The cost of copies across a sequence of n pushes is a geometric series, so the average extra cost per push is constant. reserve(n) removes the reallocations if you know n.

Any insert or push_back that grows past capacity reallocates and invalidates everything. Even without reallocation, insert in the middle invalidates from the insert point to the end. Erase invalidates from the erase point to the end. reserve that grows also invalidates. Holding data() across a growing push_back is the same bug.

Separate containers from operations. Iterators are the glue. Name the algorithm (find_if, transform, lower_bound) instead of an ad-hoc loop so intent and edge cases stay correct. Algorithms require an iterator category (sort needs random access). Do not hand-roll a binary search in an interview if lower_bound applies.

Ranges algorithms take a range, not two iterators. Views (filter, transform) are lazy and usually non-owning: they dangle if the underlying container dies. They compose with |. You are not expected to implement a view; you should know they do not copy the data by default and that some views are not sized or not random-access.

On a data member, it may be modified from a const member function. Legitimate uses: a mutex protecting logical const, or a cache. On a lambda, mutable makes operator() non-const so by-value captures can be updated. It is not a way to dodge thread safety.

If the object was defined as const (or is a const member of a const object, or lives in ROM), any write through a stripped pointer is UB. Casting away const to call a C API that does not mutate is a common non-UB use. Prefer const-correct overloads so you do not need the cast.

consteval (C++20): the function can only be called at compile time. constinit: this variable must be statically initialized (no dynamic constructor order surprises). Both are light interview topics; mention them as C++20 tools, not everyday NDK vocabulary.

No-throw: cannot throw. Strong: completes or leaves state as before (copy-and-swap). Basic: no leaks and invariants hold, but state may have changed (typical STL container guarantee). No guarantee: leaks or corruption; unacceptable. State which one your function offers.

Unwind tables cost size; an uncaught exception in a daemon or through JNI/Binder is fatal; APIs already use status codes (status_t, ScopedAStatus). The same builds often use -fno-rtti. App NDK modules may enable exceptions, but you must not throw into the VM or across a C callback. Destructors still must not throw.

lock_guard is the default RAII lock: lock in the constructor, unlock in the destructor; no API to unlock early. unique_lock can defer lock, unlock/relock, and is what condition_variable::wait requires because wait must unlock the mutex while sleeping. Prefer lock_guard unless you need those features. C++17 scoped_lock locks multiple mutexes deadlock-avoidingly.

relaxed: atomic RMW or load/store with no inter-thread happens-before. release store pairs with an acquire load: writes before the release become visible after the acquire. acq_rel is both on an RMW. seq_cst is the default single total order; easiest to reason about. Mutex lock/unlock already provide acquire/release.

Hold a unique_lock on the same mutex that protects the predicate. Wait in a loop or with a predicate: cv.wait(lk, [&]{ return ready; });. The wait unlocks, sleeps, re-locks, and rechecks because of spurious wakeups and lost-wakeup races. Notify with notify_one or notify_all after changing the predicate under the mutex.

Not automatically. The object is still alive and must be destructible and usually assignable. STL types specify "valid but unspecified" (often empty). Calling methods that assume old invariants (dereference a moved-from unique_ptr, use a moved-from container as if full) is a logic bug and can become UB. Do not rely on the source still holding its value unless the type documents it (e.g. moved-from unique_ptr is null).

Captures by value of the data you need, or shared_ptr / weak_ptr to the object, or C++17 [*=this] if a copy is correct. [&] and [this] require the referenced objects to outlive the task. This is a common SurfaceFlinger / thread-pool / Binder callback bug.

Type erasure: a vtable-like call and, if the callable does not fit the small buffer, a heap allocation. Copying a function may allocate again. In a hot loop use a template, a function pointer, or a concrete functor. Fine for infrequent callbacks (UI, setup). std::move_only_function is C++23 (optional) for move-only callables.

Export extern "C" JNI functions or RegisterNatives from JNI_OnLoad. Do not let a C++ exception escape into ART; catch and ThrowNew. Manage local refs in long loops. Own Java objects with global refs inside RAII. Own native heaps that Java holds via a jlong and a disposer. See Java for the VM side.

At template definition time the compiler looks up non-dependent names. Dependent names (those that depend on a template parameter) are looked up again at instantiation. That is why you often need this->member or a using in a dependent base, and why a missing typename on a dependent type is an error. It explains "it compiled until I instantiated it" bugs.

template class Foo<int>; in one .cpp forces that specialization to be emitted there. extern template class Foo<int>; in headers tells other TUs not to emit it. This cuts compile time for widely used specializations. It is an ODR/build-hygiene tool, not a new language meaning of the template.

Each base that introduces virtuals typically has its own vptr. A call through Base2* uses Base2's vtable. The slot may point at a thunk that subtracts (or adds) the this offset and then jumps to Derived::fn. Offset-to-top in the vtable recovers the complete object for dynamic_cast and delete. Formula: (*vptr[i])(this + δ).

Trivial: the compiler can treat copy/move/destroy as memcpy-ish (no user special members, no virtuals, trivial members). Standard-layout: C-like layout (one control block of access, no virtuals, consistent types) so you can interoperate with C and offsetof. POD is the old name for roughly both. A virtual function kills both. Android HAL C structs should stay standard-layout.

The destructor starts (or the storage is reused / released). Storage duration is separate: automatic, static, thread, dynamic. A pointer to storage is not a pointer to an object after lifetime ends. Placement new starts a new lifetime in the same bytes. Returning a reference to an automatic object ends lifetime at the } and dangles.

Optional/variant/union-like types destroy T and construct U in the same buffer. After that, the compiler may assume a pointer still refers to the old T if T had const or reference members. std::launder is the standard way to get a pointer to the new object. In interviews, pairing "placement new + explicit dtor + alignment + launder if needed" is a complete answer.

Defaults: construct/destroy via placement new and explicit dtor, rebind to allocate a different type (list nodes), pointer typedefs, and propagation traits (whether a container copy copies the allocator). You can write a minimal allocator with just allocate/deallocate and let the traits fill the rest.

A uniform value type that can hold many concrete types via a hidden vtable or function pointers: std::function, std::any, shared_ptr's deleter, some Binder type-erased callbacks. You pay an indirect call and often a heap allocation. Contrast with templates (open at compile time, no single type) and virtual bases (intrusive, one hierarchy).

When you are on C++17 (common in older NDK and vendor trees), when you must match an existing trait-based API, or when the constraint is a quick void_t detect-member trait. In C++20 new code, prefer a concept or a requires clause. Both implement "this overload exists only if".

(std::cout << ... << args); is a binary left or right fold depending on placement. A unary fold over an empty pack is ill-formed for most operators; &&, || and , have defined empty values. Always think about the zero-argument call of a variadic function.

A replacement for textual includes: a module is compiled once and imported as a semantic unit, which can cut compile time and stop macro leakage. Android builds are still header-dominated; treat modules as optional knowledge. Do not claim the NDK is modules-first unless the interviewer is exploring the standard, not the platform.

C++20 operator<=> returns a comparison category (strong_ordering, partial_ordering, …). The compiler can synthesize == and the relational operators. Useful for writing one comparison instead of six. Optional follow-up: partial_ordering for floats because NaN.

It is the partial order that makes a write visible to a later read. Sequenced-before (same thread) plus synchronize-with (mutex unlock/lock, release/acquire atomics, thread create/join) compose into happens-before. If a write does not happen-before a read of the same location, and they conflict, you have a data race unless the location is atomic.

A lock-free algorithm reads A, another thread changes A to B and back to A, and a compare-exchange succeeds as if nothing happened even though the meaning of A changed (for example a freed-and-reallocated node). Tagged pointers, hazard pointers, epoch reclamation (RCU-like) or just using a mutex are the usual answers. Mention it if they ask about lock-free stacks.

It captures the current exception (current_exception) so you can store it, pass it across threads, and rethrow_exception later. Useful when a worker cannot throw into the thread that must handle the error. On -fno-exceptions builds this machinery is not available; you pass error codes instead.

If move can throw, vector reallocation copies instead, so a throw mid-copy can destroy the extra elements and still leave the original buffer intact (strong guarantee). If you mark a throwing move noexcept, a throw during reallocation calls terminate. Implement moves that only steal pointers and mark them noexcept.

Unqualified lookup also searches namespaces associated with the argument types. using std::swap; swap(a, b); finds a friend swap for your type if you provided one, otherwise std::swap. That is why a hidden friend swap is the recommended customization point. The same mechanism finds operator<<.

T x(U()); is parsed as a function declaration (x returns T, takes a function taking U), not an object. Fix with braces: T x{U{}}; or extra parentheses. It is a C++03 leftover that still bites people who write functional casts as constructors.

Binding a temporary to a local const T& or T&& extends its lifetime to that reference. The extension does not pass through a function that returns a reference to its parameter: const T& f(const T& x){ return x; } const T& r = f(T{}); dangles. Member references and std::tuple of references also do not extend in the way people hope.

You may access an object only through a glvalue of a compatible type (same type, similar, or char/unsigned char/std::byte). Casting a float* to int* and dereferencing is UB; the compiler will assume they cannot alias and reorder loads. Use memcpy, std::bit_cast (C++20), or a union only in the narrow cases the standard allows (and prefer memcpy/bit_cast).

The standard says unsigned arithmetic is modulo 2ⁿ. Signed overflow is UB so compilers can assume x + 1 > x for signed x and can widen to a larger register. Use unsigned (or a checked API) for wraparound; use a wider type if you need to detect overflow. Sanitizers flag signed overflow.

Lambdas are readable, have obvious capture lifetimes, and compose without nested bind placeholders. bind copies arguments, is hard to overload, and surprises people with nested binds. Read bind in old code; write a lambda. std::bind_front (C++20) is a narrower, saner leftover for partial application.

HIDL: hidl_string/hidl_vec, sp<IFoo>, hwbinder, hwservicemanager, no new HALs. AIDL NDK: ordinary std::string/vector (with ABI caution), ndk::ScopedAStatus, AIBinder, servicemanager or vndbinder, required for vendor. Both are Binder; the type system and process rules differ. Details: Binder & AIDL.

They are long-lived, privileged, performance-sensitive userspace daemons: composition every vsync, and networking policy/ioctls. C++ gives RAII and types without the GC pauses of Java. They are not the kernel; they talk to drivers through HAL and syscalls. See Android frameworks.

Different ABIs: layout of string (SSO, pointers), vector, typeinfo, and exception types. The symbols are mangled in related but not interchangeable ways. The call may link if you are unlucky and then corrupt the heap. Use a C API, a POD struct, or a serialization format at the boundary.

A class holds a unique_ptr to an incomplete Impl defined only in the .cpp. Clients do not rebuild when Impl changes; the public class's size stays one pointer. Cost: an extra allocation and a pointer hop. Used to stabilize ABI and to hide platform headers from public headers.

C++20 non-owning view: pointer plus length (or a static extent). It does not allocate and does not extend lifetime. Use it for function parameters that need a contiguous range without forcing vector. Dangling is the same as a pointer. Prefer it over raw pointer + size pairs.

Optional: std::expected, std::mdspan, std::print / println, explicit object parameters ("deducing this"), std::flat_map / flat_set, std::move_only_function. Android NDK language level often lags. Lead with C++11–20 unless they ask about 23.

Construction runs base then members then derived. While the base constructor runs, the object's dynamic type is the base; the vptr points at the base vtable. The derived object is not yet formed, so calling a virtual "hook" from the base constructor will not reach derived. Use a two-phase init or a factory after construction completes.

Light/optional: co_await / co_return split a function into a state machine on the heap (unless optimized). They need a promise type and an executor/awaitable. Android framework code does not generally use them yet. If asked, say they are for async state machines and that lifetime of captured frames is the hard part; do not pretend they are how Binder works.

Members: T* ptr and a deleter. Delete copies. Move steals and nulls. Destructor calls the deleter if non-null. reset deletes then replaces; release returns the pointer and nulls. Provide *, ->, get. Mention array specialization and EBO for empty deleters. Then say you would use the standard type.

The local's lifetime ends at the closing brace. The returned reference dangles. Any use is UB (often a use-after-free when SSO spilled to the heap, or a wild stack read). Fix: return std::string by value and let elision/move handle it, or take an output parameter. Binding the return to a const string& in the caller does not extend a lifetime that already ended.

The original is valid but unspecified: it may be empty. Logging it is not necessarily UB, but you will not see the old text. If you then call an API that assumes a non-empty path (open a file), you get a logic failure. If you had a raw pointer into the old buffer, that pointer is now dangling. Do not use the source except to assign or destroy, unless the type documents more.

Look for cycles: parent owns child and child owns parent, or two listeners hold shared_ptrs to each other. Break one edge with weak_ptr. Tools: ASan leak mode, heap dumps, or logging custom deleters. Also check enable_shared_from_this callbacks that keep a shared_ptr in a global list forever.

Classic vector reallocation: capacity grew, the buffer moved, the iterator is dangling. Fix: reserve first, use indices, or structure the loop so you do not hold iterators across growth. The same bug happens with a pointer from data() or a reference to an element.

Two objects share one allocation. The first destructor frees it; the second is a double-free (UB). Assignment leaks the destination's pointer then double-frees later. This is the Rule of Three/Five failure. Fix: unique_ptr (Rule of Zero) or write all five members correctly (deep copy or deleted copies).

No. It is a data race and therefore UB. You may see lost updates, torn reads, or "impossible" optimizations. Use std::atomic<int> (relaxed is enough for a pure counter) or a mutex. "It works on x86" is not a C++ answer.

Completed bases and members are destroyed in reverse order. The object never started its lifetime, so the destructor of the class itself does not run. Resources held only as raw pointers assigned in the body can leak; RAII members do not. This is a standard argument for acquiring resources in member constructors, not in the body after a naked new.

If another exception is already in flight, std::terminate is called. Even without that, throwing from a destructor is banned by style and by noexcept destructors (the implicit destructor is noexcept if all members are). Swallow, log, or abort deliberately; do not throw.

Slicing: the vector holds Base values. Use vector<unique_ptr<Base>> (or a pointer/reference wrapper to existing objects). Also ensure Base has a virtual destructor if you delete through Base*.

Classic AB-BA: thread 1 holds A waits for B; thread 2 holds B waits for A. Fix: a global lock order, std::scoped_lock(a, b) (tries to avoid deadlock), or one mutex. On Android also think about Binder: do not hold a lock across an outgoing transaction that may re-enter. See Binder & AIDL.

Local references are only batched until the native method returns. In a tight loop, create a local frame or DeleteLocalRef each iteration. Also check for ExceptionOccurred after JNI calls. This is a C++ / JNI lifetime problem, not a Java GC mystery.

Exclusive session: unique_ptr with a custom deleter that powers down the device, or an RAII class. Shared between callbacks: shared_ptr plus weak_ptr for listeners so the HAL can die. Do not use raw new with a manual close on some paths only. AIDL NDK types like ndk::ScopedAStatus already follow RAII for the IPC result.

If push_back reallocated, v[0]'s address changed. The pointer is dangling. reserve before taking the pointer, or take the pointer only after the vector is stable, or use an index.

ABI break: vtable layout and object size (hidden vptr if it was the first virtual) changed. Old binaries still use the old offsets. This is why public NDK APIs and VNDK freeze layouts, and why PIMPL or a C API is used at stable boundaries.

Each copy is an atomic increment/decrement on the control block: cache-line ping-pong. Prefer a raw observer with a documented lifetime, a weak_ptr locked rarely, or a unique owner on the real-time thread. Measure; do not sprinkle shared_ptr in per-frame code out of habit. SurfaceFlinger-style paths care about this.

The object is not yet owned by a shared_ptr; the mixin’s weak pointer is empty. Construct with make_shared (or a factory that wraps immediately) and call shared_from_this only after that. Do not call it from the constructor of the object being made.

new T[n] must be released with delete[] so the compiler can destroy every element and pass the right size to the deallocator. delete on an array is UB. Prefer unique_ptr<T[]> or vector<T> so the pairing is automatic.

The thread still runs this->... on freed memory: use-after-free, UB. Join the thread in the destructor (and define a shutdown order), or capture a shared_ptr / weak pointer, or do not start a thread that outlives the object. Detached threads make this worse because you cannot join.

There is no unwind through that TU: terminate, or a worse abort if the exception personality is missing. Treat it as a process killer. The fix is to keep exceptions inside the library, compile the whole program consistently, or use error codes at the boundary. This is why Android native APIs prefer status returns.

Read the first instantiation that failed and the bottom note (the actual constraint or missing member). The middle is the call stack of templates. With C++20, a concept failure names the requirement. In C++17, look for enable_if / no type named .... Do not start rewriting from a random line in the STL.

If the object was born const, that write is UB. The compiler may keep the original value in a register or place the object in read-only memory (crash on write). If they needed mutation, the object should not have been const, or they should use mutable for a real cache under a lock.

Relaxed gives atomicity of the flag or pointer word, not visibility of the fields written before it. The writer must release-store the pointer (or the flag) after initializing the object; the reader must acquire-load. A mutex around both sides also works. This is the "publish a pointer" interview pair.

Slicing at the call boundary: the parameter is a new Base. Change the helper to Base& or const Base&, or pass unique_ptr<Base>. This is the same bug as vector<Base>.

Missing deleted copies (double close), missing move that sets the source to -1 (double close again), closing -1, not handling self-move, and throwing from the destructor if close fails. Show the five members or a unique_ptr with a deleter that calls close. See the sketch on this page.

When the problem needs index access, binary search, or cache-friendly scans: vector wins. list is for splice and stable node pointers. Saying "list because insert is O(1)" without "given an iterator" and without cache cost is a weak answer. See DSA for complexity framing.

Lost wakeup: notify happened before wait, and you did not check the predicate under the mutex. Always change the predicate under the lock, then notify; wait with a predicate loop so a notification that already happened is still seen. Also: using a different mutex on the two sides, or notify_one when several waiters need to run.

Often it is correct: the object died and lock() failed. Confirm the owner's lifetime (was the shared_ptr dropped too early?). If the callback must run, you needed shared ownership or a queued teardown. If it must not keep the object alive, empty lock is the feature, not the bug.

The old object's destructor never runs: leaks (if it owned heap), skipped side effects, and then you construct a second object in the same bytes without ending the first lifetime (UB). Pair every placement new with p->~T() before reuse or scope exit. Prefer optional<T> or a container.

Often yes: you block NRVO, so you force a move instead of constructing in place. Return local;. std::move on a return is for returning a member or a parameter you want to treat as an rvalue, not for a local of the return type.

Undefined behavior if the dynamic type is derived: only ~Base runs, derived members leak, and the deallocation size may be wrong. Make the destructor virtual (or protected-nonvirtual if you never delete through Base). This is asked constantly.

A future from std::async with default launch may block in its destructor until the task finishes. async(f).get() or even discarding the future can run the work synchronously from the caller's point of view. Prefer an explicit thread pool or store the future if you wanted overlap. Mention this when they ask about async.

A bad or colliding hash (all keys in one bucket), an adversarial key set, or a custom hash that is constant. Fix the hash, use a better mixer, or switch to map if n is moderate and you need worst-case bounds. reserve does not fix a broken hash. Mention load factor and bucket count.

a = a; (or overlapping aliases) frees the resource then copies from the freed pointer. Copy-and-swap is naturally self-assignment safe. A handwritten assign should either check this != &other or copy to a temporary first. Interviewers still like the explicit check plus a correct order: copy, then release, then take.

You held the mutex, made an outgoing Binder call, the other side called back into the same process on a binder thread, and that thread tried to take the same non-recursive mutex. Fix: never hold the lock across IPC; copy the data, drop the lock, then transact; or document a lock order that excludes Binder. Same pattern as Java lock + Binder. See Binder & AIDL.

Two copies of libc++ (or mixed ABIs) mean two heaps and two string layouts. Crossing the boundary can free with the wrong allocator or corrupt SSO. Keep STL types inside one linkage domain; expose C or AIDL types at the .so edge. This is an Android-specific ABI question.