C++ vs Java Interview Questions: Live Questions & Comparison

RAII binds a resource — heap memory, a file handle, a mutex lock, a socket — to the lifetime of a stack-allocated object: the constructor acquires it, the destructor releases it. Because C++ guarantees local objects' destructors run during stack unwinding (including when an exception propagates through the scope), RAII gives automatic, exception-safe cleanup with no explicit finally-style block. std::unique_ptr, std::lock_guard, and std::fstream are all RAII wrappers around a raw resource. The other options describe unrelated or incorrect properties: RAII says nothing about constness, doesn't guarantee zero overhead, and specifically exists so cleanup happens at scope exit, not merely at program exit.

String literals are interned into the string constant pool, so a and b reference the exact same pooled object and a == b is true. new String("hi") is explicitly told to allocate a fresh object on the heap, so c is a different reference and a == c is false even though the characters match. == compares references, not contents — .equals() is what compares the actual characters and would return true for all three. The trap is that == appears to work for literals because of interning, then silently breaks for strings built at runtime (from input, concatenation, or new), which is why you should always use .equals() to compare string values.

std::unique_ptr models exclusive ownership: it can be moved (transferring ownership) but not copied, and because only one unique_ptr ever owns the object, it needs no reference count — just a raw pointer and a deleter, making it effectively as cheap as a raw pointer while still freeing automatically. std::shared_ptr is for the different case of multiple simultaneous owners, and pays for an atomically-updated control block to track them. std::weak_ptr doesn't own anything — it exists to observe a shared_ptr-managed object without extending its lifetime, typically to break reference cycles. A raw pointer with manual delete reintroduces exactly the leak/double-free risk smart pointers exist to remove, so it's never the right answer to a memory-safety question even though it technically avoids smart-pointer bookkeeping.

The equals/hashCode contract requires that equal objects return equal hash codes. HashMap first uses hashCode() to pick a bucket, then equals() to find the entry within it. The default Object.hashCode() is identity-based, so two distinct-but-equals objects almost always produce different hash codes, route to different buckets, and a get() with an equal-but-not-same key returns null — the entry is effectively lost. It is not a compile error: the compiler never forces you to override both, which is exactly why this bug is so common. Always override hashCode() whenever you override equals() (and prefer the same fields in both).

std::move is purely a cast (static_cast<T&&>) — it has no runtime effect of its own; it just makes the expression an rvalue so overload resolution can select a move constructor or move-assignment operator if one exists. A well-behaved move constructor steals the source's internal resource (pointer, buffer, handle) rather than deep-copying it, typically by copying the pointer and nulling the source's, which is what makes moves cheap for resource-owning types like std::vector or std::string. That's why the moved-from object is left 'valid but unspecified' — it's safe to destroy, reassign, or call methods with no preconditions on it, but its value is not to be relied upon. The claim that moving is guaranteed to be faster than copying for every type and the claim that std::move always triggers a move are wrong: nothing in the standard requires move to be O(1) for every type (a type with no move constructor falls back to its copy constructor, which may be O(n)), and passing an rvalue to a type with no move constructor simply resolves to the copy constructor instead of failing to compile.

Generics are implemented by erasure: type arguments exist only at compile time and are erased to their bounds (or Object) in the bytecode, so the runtime has no List<String> type to check against. That makes instanceof List<String> a compile error, and only the reifiable unbounded wildcard form instanceof List<?> is permitted. Erasure also forbids new T[10] (the runtime can't know T's reified type) and new ArrayList<String>[5] (generic array creation), because arrays are covariant and reified while generics are not — allowing them would let a String[]-shaped store silently accept the wrong element type and defeat the type system. The usual workaround for generic arrays is an Object[] cast or, better, a List<T>.

True. const on a member function is a promise not to modify the object's logical state through that function — the compiler enforces this by making this a pointer-to-const inside the function, so any member normally can't be assigned to. mutable is the deliberate escape hatch: it marks a member (typically bookkeeping like a cache, a lazily-computed value, or a mutex used only for internal synchronization) as modifiable even through a const object or const member function. It exists precisely so a class can present a const, logically-immutable public interface while still doing internal caching under the hood.

volatile provides a visibility/ordering guarantee — every read sees the latest write and writes aren't reordered around it — but it does NOT make compound operations atomic. counter++ is three steps (read, add one, write back), and two threads can both read the same value, each add one, and both write back the same result, so one increment is lost. To increment atomically use AtomicInteger.incrementAndGet(), a synchronized block, or a lock. volatile is the right tool for a simple flag (one thread writes, others read), but never for a counter or any check-then-act. Confusing visibility with atomicity is one of the most common Java concurrency mistakes.

word is a local variable with automatic (stack) storage duration — it's destroyed when firstWord returns. Returning word by reference (line 3) hands the caller a reference to storage that no longer holds a valid std::string; that's a dangling reference, and using it (line 8's std::cout << w) is undefined behavior — it might print garbage, print the old value by luck (if the memory hasn't been reused yet), or crash, and the exact outcome can differ by compiler, optimization level, and what else is on the stack. Note that line 7 itself is legal C++ — binding a reference to a temporary would normally extend a temporary's lifetime, but that extension does not apply here because the dangling reference was already produced inside firstWord, before the caller ever sees it. The fix is to return std::string by value (not by reference); modern C++'s move semantics and guaranteed copy elision (C++17) make that no more expensive than the broken reference version, so there's no performance reason to reach for the reference here.

Stream operations split into intermediate (lazy, return a new Stream) and terminal (eager, produce a result or side effect and consume the stream). collect, forEach, and count are terminal — they trigger the pipeline and you cannot reuse the stream afterward. map and filter are intermediate: they only describe a transformation and do nothing until a terminal op pulls elements through. The practical consequence of laziness is that a pipeline of map/filter with no terminal op runs zero times — a common 'my forEach printed nothing' confusion — and that intermediate ops are fused and applied element-by-element rather than as separate passes. Other terminal ops include reduce, findFirst, anyMatch, toArray, and min/max.

Polymorphism through virtual functions only works through a pointer or reference to the base class, because dispatch relies on the object's vptr pointing at its actual (dynamic) type's vtable. printArea(Shape s) takes its parameter by value, so the call printArea(c) invokes Shape's copy constructor with a Circle argument — and a Shape copy constructor only knows how to copy the Shape subobject. The radius member and the Circle vtable pointer are left behind entirely; s inside printArea is a genuine, fully-formed Shape, not a truncated Circle, so s.area() correctly (if surprisingly) calls Shape::area(). This is 'object slicing.' The fix is to take the parameter by reference or pointer (void printArea(const Shape& s)), which binds to the existing Circle object instead of copying it, preserving its vtable and dynamic type.

Java is always pass-by-value, with no exceptions. For object types, the value that is copied is the reference itself, not the object — so the parameter and the caller's variable initially point at the same object. Mutating that shared object's state (e.g. list.add(x) or obj.setName(...)) is visible to the caller, which is why people mistakenly call it 'pass-by-reference'. But reassigning the parameter (obj = new Thing()) only rebinds the local copy of the reference; the caller's variable still points at the original object. The tell that it is pass-by-value: a method cannot swap two of the caller's variables or make the caller's variable point somewhere new.