2. Cpp Interview Questions - thealexcons/low-latency-systems-notes GitHub Wiki

At least 1. The compiler will add a dummy byte(s) because if the size is 0, two distinct objects of class Test will have the same address which is illegal:

Test t1, t2; // both stack objects will have the same address if their size is 0

The value is 'T'. Due to operator precedence, the expression evaluates as *(p++). The postfix increment returns the old value, so it reduces to *p, which is the first character of the string.

The map is using a char* as the key, so the default comparison function compares two character pointers instead of the contents of the string. So, two map items will be the same only if the exact same pointer is used. If the intent is that the string contents are to be the keys, then you need to define a string comparison function, as below:

struct StrCmp { 
  bool operator()(char const *a, char const *b) const 
  { 
      return std::strcmp(a, b) < 0; 
  } 
}; 
  
//StrCmp specified in map declaration 
std::map<const char *, int, StrCmp> strMap;

It will be the size of a pointer (8 bytes on a 64bit machine). The reason is that the destructor is declared virtual so the compiler will create a virtual table pointer in all objects of class Test.

It is constant time. A deque is implemented as a (dynamic) array of pointers to fixed size chunks (arrays). Using the knowledge of the size of the chunks, it is constant time to determine what chunk/array contains the item, and then constant time to find the item within the chunk. This always involves two memory accesses.

No, this code has undefined behaviour. The second line will increment the address by 1 (4 bytes), so we are then deleting the address at (p+1) which was not created by new[].

It will be 1 (the size of a char) because static data members don't contribute to the size of an object.

No, it won't compile. We have a user-defined copy constructor, so the compiler will not generate a default constructor required for the last statement (see rule of 5).

No, it won't compile. We are passing an rvalue (string literal) into the function, but in C++ a non-const reference cannot bind to an rvalue (temporary object). We can fix this by changing the parameter to void f(const std::string& s) or void f(std::string&& s), since they both bind to rvalues.

const is wanted because you don't want to change the object from which the copy is made. Consider if we passed the other object by value: this will create a copy, which invokes the copy constructor again, leading to infinite recursion. Hence, we must pass in the object by reference.

Technically yes. But it is dangerous to do so. Because if stack unwinding is in progress for a previous exception and then an object’s destructor throws another exception, its ambiguous which exception the C++ runtime should handle from a safety perspective, so the standard says to abort the program instead.

Yes. In fact, throwing an exception from a constructor is good for two reasons:

1. Constructors don't have a return value to signal failure
2. There will be no memory leak, unless the constructor itself is allocating memory (can be solved by using smart pointers to avoid memory leaks).

Yes, it compiles and the output is "Derived::f()". Although Derived::f() is private, since p is a pointer of type Base and this class has a function f(), the type-checking passes. Since Base::f() is virtual, dynamic dispatch at runtime will find the actual function from the derived class.

The placement new operator allows you to specify at what address a new object should be allocated. This is useful when we need to create multiple objects of the same type during execution but don't want to dynamically allocate each one of them. We can instead allocate a chunk of memory at the start and then use the placement new operator to directly create these objects in the pre-allocated memory slots. Also, once an object is destroyed, we can use the memory vacated to construct other objects. This is different to the regular new because it does not allocate memory, it simply constructs the object on already-allocated memory, whereas the regular new will allocate and initialise the memory with that type.

class Test {}; 
  
// pre-allocated buffer for 10 Test objects 
char *buf  = new char[10*sizeof(Test)]; 
  
// using placement new to place object directly in pre-allocated memory 
Test *tp = new (buf) Test();

Policy classes are used to inject behaviour into some other class. These are commonly found in STL containers to specify allocators, comparators, etc. in order to dictate how a specific part of the container should behave. These are passed in typically through templates, for example:

template<class T, class Allocator = std::allocator<T>>
class vector { ... }

Copy elision is a compiler optimisation that eliminates unnecessary copying or moving of objects. An example of when copy elision may be useful is shown below:

class Test { 
public: 
  Test() {} 
  ~Test() {} 
  Test(const Test&) {} 
};

Test foo() { 
  return Test(); 
} 
  
int main() { 
  Test t = foo(); // line X 
}

In line X, if copy elision is applied, the returned object is directly constructed in t and no copy constructor is invoked. From C++17, copy elision is guaranteed for cases like the one above.

No. When using the initialiser list in the constructor, the data members will be initialised in the order in which they are declared in the class and NOT in the order in which they appear in the initialiser list. Hence, y will be initialised to x+1 but x will not have been initialised, causing undefined behaviour.

In the template function foo, we try to use a dependent name T::f as a type (as an int pointer) for the variable x (since it depends on the template parameter T). However, if we call foo<Y>() with Y defined as struct Y { static int f = 23; };, we are declaring a multiplication expression inside foo (ie: 23 * x). To avoid this ambiguity, C++ requires you to explicitly state the intent when a dependent name is to be treated as a type. The function should look like:

template<class T> void foo() { 
    typename T::f *x; // treat T::f as a type
} 

No because function templates cannot be partially specialised in C++. They can be not specialised at all (in this case, 0 out of 2 template arguments) or fully specialised (both T and U).

Deleting b is undefined behaviour because it points to a Derived object but class Base has no virtual destructor, so it cannot find the overriden constructor in Derived. To solve this, Base should have a virtual destructor. In summary, always make base classes' destructors virtual when they're meant to be manipulated polymorphically (which always happens through pointers).

Alternatively, if you want to prevent the deletion of an instance through a base class pointer, you can make the base class destructor protected and nonvirtual; by doing so, the compiler won't let you call delete on a base class pointer.