Question 1

In C++ inheritance, which of the following can a derived class inherit from its base class (subject to access control)?

Accepted Answer

Introduction / Context: Inheritance is a fundamental concept in object oriented programming and is heavily used in C++. It allows a derived class to reuse and extend the behaviour and state of a base class. Understanding exactly what elements of a base class are inherited is crucial for designing class hierarchies correctly. This question asks you to identify whether a derived class inherits data, functions, or both from its base class. Given Data / Assumptions: The language is C++. We are discussing single or multiple inheritance from a base class to a derived class. Access specifiers such as public, protected, and private control visibility but do not change the basic rule of what is inherited. Static members and friend relationships obey specific rules but follow the same inheritance visibility patterns. Concept / Approach: In C++, a derived class inherits both the data members and the member functions of its base class, subject to access controls. Public and protected members are inherited and accessible according to the inheritance mode and access rules, while private members are inherited but not directly accessible in the derived class. Member functions, including virtual functions, are also inherited and can be overridden where appropriate. This allows a derived class to reuse state and behaviour without reimplementing everything from scratch. Step-by-Step Solution: Step 1: Consider a base class with data members, such as int x, and member functions, such as void display(). Step 2: Define a derived class that publicly inherits from the base class. Step 3: Observe that the derived class objects contain the base class data members as part of their layout, even if some members are private and cannot be accessed directly. Step 4: Note that the derived class can call inherited public and protected member functions and can override virtual functions to extend behaviour. Step 5: From this, conclude that inheritance covers both data members and member functions, not just one or the other. Verification / Alternative check: You can verify this by creating a simple base class with a protected data member and a public function that uses it. Then derive a class and add a method that calls the base class function or directly uses the protected member. The derived class has access to both and can manipulate the inherited state and behaviour. Additionally, tools that display object layout will show that the derived class instance includes memory for base class data fields, confirming that data members are indeed inherited physically. Why Other Options Are Wrong: Option Data members only: This ignores the fact that member functions, including virtual functions, are also inherited and available to the derived class. Option Member functions only: This incorrectly suggests that the state represented by data members is not inherited, which is not true in C++. Option None of the above: This is incorrect because C++ inheritance explicitly covers both data members and functions, according to access rules. Common Pitfalls: A common confusion is about private members of the base class. They are inherited but cannot be accessed directly in the derived class; instead, they are accessible through public or protected member functions of the base class. Another pitfall is to assume that inheritance copies code in a textual sense, whereas it is actually a relationship defined in the type system and object layout. Keeping in mind that both data and behaviour are inherited helps in designing coherent and reusable class hierarchies. Final Answer: A derived class in C++ inherits Both data members and member functions from its base class, subject to access control rules.

Question 2

In C++ object oriented programming, what is meant by a pure virtual function in a class definition?

Accepted Answer

Introduction / Context: Pure virtual functions are a key concept in C++ object oriented programming. They are used to define interfaces and to create abstract base classes that cannot be instantiated directly. This question checks whether you understand what a pure virtual function is and how it differs from an ordinary virtual function in a class definition. Given Data / Assumptions: We are working in standard C++ with classes, inheritance and virtual functions. The term pure virtual function refers to a member function declared with the syntax virtual return_type name(parameters) = 0; inside a class. Such functions participate in run time polymorphism through virtual dispatch. Concept / Approach: A pure virtual function is a virtual function that is declared but not required to have an implementation in the base class. By writing = 0 at the end of the declaration, you tell the compiler that this function has no default behavior in the base class and must be provided by derived classes if those derived classes are to be concrete types. Any class that contains at least one pure virtual function becomes an abstract class, which means objects of that class cannot be created directly. Instead, you work with pointers or references to the base class that actually refer to instances of derived classes which implement the pure virtual functions. Step-by-Step Solution: Step 1: Recall that pure virtual functions are declared with = 0 in a class body.Step 2: Recognise that they express an interface requirement for derived classes.Step 3: Note that the base class does not need to supply a normal implementation, although C++ technically allows a definition if needed.Step 4: Compare the options and look for the one that mentions a virtual member function declared with = 0 and required to be overridden.Step 5: Option A matches this description, so it is the correct answer. Verification / Alternative check: Consider class Shape { public: virtual void draw() = 0; };. Shape is an abstract base class because draw is pure virtual. You cannot create Shape s; but you can derive classes such as Circle or Rectangle that provide void draw(). When you call draw through a Shape pointer or reference, C++ uses dynamic dispatch to select the correct derived implementation. This behaviour confirms that a pure virtual function provides a common interface without a required base implementation. Why Other Options Are Wrong: Option B focuses on return types and inlining rather than the = 0 syntax and interface requirement. Option C describes a non virtual function, which is unrelated. Option D confuses pure virtual functions with compile time features, while they are actually used at run time. Option E describes static member functions, which are not virtual and do not participate in polymorphism. Common Pitfalls: A common mistake is to think that a pure virtual function can never have a definition in the base class. C++ allows a definition, but the class remains abstract as long as the declaration uses = 0. Another pitfall is forgetting to override a pure virtual function in a derived class, which keeps the derived class abstract. Remember that pure virtual functions are mainly about designing clean interfaces and abstract base classes. Final Answer: A virtual member function declared with = 0 that has no required implementation in the base class and must be overridden in derived classes.

Question 3

In object oriented programming, what does inheritance allow you to do when designing related classes?

Accepted Answer

Introduction / Context: Inheritance is one of the core pillars of object oriented programming, together with encapsulation and polymorphism. It allows new classes to be defined based on existing ones, making it easier to reuse code and express relationships between concepts. This question checks whether you understand the main purpose of inheritance in class design rather than confusing it with unrelated features such as operating system access or database generation. Given Data / Assumptions: We are using a class based object oriented language such as C++ or Java. Classes can extend or derive from other classes. The term inheritance refers to this language feature, not to database or file system concepts. Concept / Approach: Inheritance allows a class, often called a derived or child class, to reuse and extend the behaviour of another class, often called a base or parent class. Common state and operations are defined once in the base class, and derived classes inherit these members automatically. They can then add new members or override virtual methods to provide specialised behaviour. This forms a hierarchy where base classes capture general concepts and derived classes capture more specific concepts. For example, Animal can be a base class, while Dog and Cat are derived classes that inherit and refine the behaviour of Animal. Step-by-Step Solution: Step 1: Focus on what inheritance does at the language level: it connects classes in a parent child relationship.Step 2: Recognise that the key benefits are code reuse and the ability to express is a relationships, such as Dog is an Animal.Step 3: Option C states that inheritance allows you to create a hierarchy of related classes that share behaviour and reuse base class code.Step 4: Option A describes standalone classes with no relationship, which is the opposite of inheritance.Step 5: Other options talk about unrelated features, so option C is the correct choice. Verification / Alternative check: In C++, if you write class Animal { public: void eat(); }; and then class Dog : public Animal { };, every Dog object has the eat method inherited from Animal. You do not have to rewrite the implementation. You can add new methods like bark in Dog while still treating Dog objects as Animals in code that uses polymorphism. This demonstrates how inheritance creates a hierarchy and promotes reuse. Why Other Options Are Wrong: Option A ignores the relationship aspect and describes isolated classes. Option B mentions operating system methods, which are accessed through libraries, not through inheritance alone. Option D describes the opposite of polymorphism, which inheritance usually enables through virtual methods. Option E talks about automatic database generation, which may be supported by frameworks but is not the built in purpose of inheritance in the programming language. Common Pitfalls: Developers sometimes misuse inheritance to share code between classes that do not have a clear is a relationship, leading to rigid hierarchies. In such cases, composition can be a better choice. For exam purposes, remember that the textbook answer is that inheritance lets you build class hierarchies and reuse base class code in derived classes. Final Answer: Create a hierarchy of related classes that share common behaviour and can reuse code from base classes.

Question 4

In C++ programming, how many basic kinds of constructors are traditionally classified, for example default, parameterised and copy constructors?

Accepted Answer

Introduction / Context: Constructors are special member functions used to initialise objects in C++. Textbooks and exam questions often talk about basic kinds of constructors, which helps students learn the different ways objects can be created. This question asks how many basic constructor types are traditionally listed and expects that you know the common classification rather than every advanced variation defined by the standard. Given Data / Assumptions: We are looking at classic C++ teaching that groups constructors into a small number of basic kinds. The most widely taught categories are default, parameterised and copy constructors. Modern C++ also has move constructors, but many introductory treatments still mention three basic kinds. Concept / Approach: A default constructor can be called without arguments and creates a default initialised object. A parameterised constructor takes one or more arguments that control how the object is initialised. A copy constructor takes a reference to another object of the same type and constructs a new object as a copy of that object. Together, these three categories cover the most common ways that C++ classes initialise objects and are frequently highlighted in interview and exam questions as the basic kinds of constructors. Step-by-Step Solution: Step 1: List the basic constructor types taught in many C++ courses: default, parameterised and copy constructors.Step 2: Count these categories, which gives the number three.Step 3: Option C states that there are 3 basic kinds and even names them.Step 4: Options A and B suggest fewer categories, which would require grouping different behaviours together.Step 5: Option D and option E are clearly incorrect because C++ does have constructors and the standard does not require four or more basic kinds in every classification. Verification / Alternative check: If you open typical C++ textbooks or interview preparation material, you will often see a section titled types of constructors with three bullet points: default, parameterised and copy. Move constructors are usually introduced later when discussing C++11 and beyond. For exam style questions, setters expect the answer three unless move constructors are explicitly included as a separate category in the question stem, which is not the case here. Why Other Options Are Wrong: Option A and option B do not match the widely used breakdown and would leave out at least one of the classic constructor types. Option D claims that four or more kinds are mandatory, which does not match common teaching nor the intent of this question. Option E is completely wrong because constructors are a fundamental part of C++ class design. Common Pitfalls: Students sometimes confuse the number of constructor overloads in a specific class with the conceptual categories of constructors. A single class can have many overloaded constructors, but they still fall into these basic groups. Also, do not forget that modern C++ adds move constructors, but for traditional exam questions, three basic types are usually expected as the answer. Final Answer: 3 (default constructor, parameterised constructor and copy constructor are commonly counted).

Question 5

In C++ programming, what is a template and why is it used?

Accepted Answer

Introduction / Context: Templates are one of the most powerful features of C++, enabling generic programming and allowing code to be written once and reused with many different data types. Understanding what a template is and why it exists is crucial for anyone studying C++ or preparing for interviews that involve the Standard Template Library. This question focuses on the core definition and purpose of templates rather than on syntax details. Given Data / Assumptions: We are working in standard C++ with support for class templates and function templates. The question mentions the term template in the language sense, not in the context of code editors or project wizards. Templates are resolved at compile time rather than at run time. Concept / Approach: A template is a blueprint or formula for creating a family of types or functions. Instead of writing separate versions of a class for int, double and other types, you define a class template with a type parameter. The compiler generates specific versions, known as instantiations, when you use the template with concrete types. The same idea applies to function templates, which allow algorithms like sort or swap to work with different element types as long as the required operations are supported. This approach improves code reuse and type safety compared to using void pointers or macros. Step-by-Step Solution: Step 1: Identify that the question is about the C++ language feature used for generic programming.Step 2: Recall that templates are defined with syntax like template.Step 3: Recognise that templates describe patterns for classes or functions that the compiler expands for specific types.Step 4: Option A describes a compile time pattern used to generate generic classes or functions for different data types.Step 5: Other options talk about editor features, runtime libraries or preprocessor directives, so option A is correct. Verification / Alternative check: Consider std::vector or std::list from the Standard Template Library. These are class templates that can be instantiated as std::vector, std::vector and many other combinations. They use the same source code but produce different concrete types at compile time. Similarly, std::sort works as a function template that you can call with arrays or containers of various element types. This behaviour matches the description in option A. Why Other Options Are Wrong: Option B confuses templates with editor tools like snippets. Option C claims templates are runtime libraries limited to input and output, which is incorrect because templates exist at compile time and are used across the entire library. Option D restricts templates to attributes only, ignoring function templates. Option E misrepresents templates as preprocessor directives, but they are part of the C++ language itself, not of the preprocessor. Common Pitfalls: Beginners sometimes think templates are equivalent to macros, but macros perform simple textual substitution without type checking, while templates are type safe and integrated with the compiler. Another pitfall is forgetting that template code is only generated when it is actually used, which can lead to linker errors if definitions are not visible at the point of instantiation. For exam questions, emphasise that a template is a compile time blueprint for generic classes and functions. Final Answer: A template is a compile time pattern or formula for generating generic classes or functions that can work with different data types.

Question 6

In C++ templates, what is meant by template specialisation?

Accepted Answer

Introduction / Context: Template specialisation is an important advanced feature of C++ templates. It allows library authors to provide special behaviour for particular template arguments while still offering a generic implementation for other cases. This question asks you to describe what template specialisation means in this context. Given Data / Assumptions: We are using C++ templates for classes or functions. There is a primary template that defines generic behaviour for a range of types or values. We want to adjust that behaviour when certain template arguments are used. Concept / Approach: Template specialisation lets you write a specific version of a template for a given set of template arguments. In full specialisation, you provide a complete alternative definition when all template parameters match certain values or types. In partial specialisation, you specialise a subset of parameters, such as all pointer types or all containers of a particular form. When the compiler encounters a use of the template, it chooses the most specialised matching definition. This enables optimised or tailored behaviour for special cases without losing the convenience of a general template for the rest. Step-by-Step Solution: Step 1: Recall that primary templates provide default generic behaviour.Step 2: Recognise that specialisation occurs when you override this behaviour for a specific set of template parameters.Step 3: Option A states that template specialisation means providing a custom implementation for a particular data type or set of arguments.Step 4: Options B, C and D describe restrictions or deprecations that are not the purpose of specialisation.Step 5: Option E talks about where templates are placed in files, which is unrelated to the concept of template specialisation, so option A is correct. Verification / Alternative check: Consider a simple primary template template struct Traits { static const bool is_pointer = false; };. You can then define a specialisation template struct Traits { static const bool is_pointer = true; };. When you use Traits, the primary template applies, and is_pointer is false. When you use Traits, the specialised version applies and is_pointer is true. This is a classic example of template specialisation in action. Why Other Options Are Wrong: Option B suggests that specialisation is about default arguments, which is not accurate. Option C describes deprecation, which is controlled by attributes or compiler warnings, not by specialisation. Option D implies that specialisation is only about pointer types, but pointers are just one use case. Option E talks about the placement of code in header or source files, which is a separate issue related to template instantiation rules. Common Pitfalls: Developers sometimes overuse specialisation, leading to complex and hard to maintain code. Another pitfall is confusing full specialisation with partial specialisation and expecting both to work identically for function templates. Function templates do not support partial specialisation in the same way class templates do. In exam settings, focus on the core idea that template specialisation provides custom implementations for particular template arguments. Final Answer: Providing a custom implementation of a template for a specific data type or set of template arguments instead of using the primary generic definition.

Question 7

In standard C++ templates, how many kinds of entities can be used directly as template parameters, for example types, non type values and templates themselves?

Accepted Answer

Introduction / Context: C++ templates are very flexible and allow several different kinds of entities to be passed as parameters. Understanding these categories helps when reading template declarations and designing generic libraries. This question asks how many kinds of entities can be used directly as template parameters in standard C++ and hints at the common classification by giving examples. Given Data / Assumptions: We are considering the C++ language as defined by the standard, not compiler specific extensions. Template parameters can represent types, certain values and even other templates. The question refers to how many kinds of entities are directly parameterised, not to how many parameters a specific template might have. Concept / Approach: There are three main categories of template parameters in C++. Type parameters represent a type, such as typename T. Non type parameters represent values of certain allowed types, such as integers or pointers, for example template. Template template parameters represent templates themselves, allowing you to pass container templates or other generic structures as arguments. These three categories cover the standard ways templates can be parameterised, and exam questions commonly ask you to recognise them and count them. Step-by-Step Solution: Step 1: List the known categories of template parameters: type, non type and template template parameters.Step 2: Count these categories, which gives the number three.Step 3: Option C explicitly states that there are 3 kinds and names them.Step 4: Option A and option B undercount the categories by ignoring at least one of them.Step 5: Option D and option E add unsupported categories such as namespaces or unspecified compiler extras, so option C is correct. Verification / Alternative check: If you look at template syntax examples from documentation, you will see patterns like template, template and template class Container>. These examples illustrate type parameters, non type parameters and template template parameters respectively. There is no separate category for namespaces or arbitrary expressions as standalone parameter kinds, which confirms that three is the correct count. Why Other Options Are Wrong: Option A would only be correct if C++ supported type parameters and nothing else, which is not the case because non type parameters are widely used, for example in array bounds and compile time constants. Option B misses the template template parameter category. Option D incorrectly claims that namespaces themselves are template parameters, which is not supported by the language. Option E suggests compiler defined extra categories, but the question is clearly about the standard language rules. Common Pitfalls: Developers sometimes confuse non type template parameters with regular function parameters, forgetting that template parameters must be compile time constants of allowed types. Another pitfall is misunderstanding template template parameters and expecting them to be more flexible than they are. For exam purposes, remember the standard classification into three kinds of template parameters in C++. Final Answer: 3 (type parameters, non type value parameters and template template parameters).

Question 8

In C++ exception handling, when is it appropriate to use exceptions instead of returning simple error codes from a function?

Accepted Answer

Introduction / Context: Exceptions in C++ provide a structured way to signal and handle error conditions that prevent a function from completing its intended work. Using exceptions appropriately helps keep normal code clean while centralising error handling. This question asks when it is suitable to use exceptions rather than returning error codes directly from a function. Given Data / Assumptions: We are working in C++ with try, catch and throw constructs available. Functions may have contracts or postconditions that describe what they promise to do on success. Sometimes those contracts cannot be met due to problems such as missing resources or invalid input. Concept / Approach: The general guideline is to use exceptions for exceptional conditions, not for routine control flow. An exceptional condition is one in which a function cannot meet its specification, and simply returning a normal value would not be expressive enough or would clutter the interface. Exceptions allow you to separate normal code from error handling code and to propagate errors up the call stack until a suitable handler is found. For simple or very common conditions, error codes or optional return types may still be appropriate, but for serious violations of a function contract, exceptions are a good fit. Step-by-Step Solution: Step 1: Focus on the idea that exceptions are used when a function cannot complete its promised work normally.Step 2: Recognise that using exceptions for every branch of logic would make the code harder to read and may be slower.Step 3: Option A states that exceptions are used when postconditions cannot be satisfied and normal return values are not a clean way to represent the problem.Step 4: Options B, C, D and E either exaggerate the performance benefits or restrict exceptions to cases that do not match best practices.Step 5: Therefore, option A is the correct answer. Verification / Alternative check: Consider a function that opens a file and reads its contents. If the file does not exist or the permissions are wrong, the function cannot fulfil its contract of returning valid data. If you use exceptions, you can write straightforward code for the success path, and throw an exception when opening fails. The caller can then handle all file related errors in one place. This design reflects the idea in option A that exceptions signal failure to meet the function contract. Why Other Options Are Wrong: Option B incorrectly claims that exceptions automatically make normal control flow faster, which is not guaranteed and often not the primary reason for using them. Option C and option E are too narrow and ignore many valid use cases. Option D suggests using exceptions for normal business logic, which leads to confusing control flow and poor performance. Common Pitfalls: One common mistake is to overuse exceptions for control flow, such as throwing an exception for every minor validation error. Another pitfall is to ignore exceptions entirely and rely only on error codes, which can result in repetitive checks and missed error handling. Good C++ style uses exceptions for significant contract failures and keeps normal code paths clean and readable. Final Answer: When the function cannot satisfy its postconditions or contract and a normal return value cannot represent the error cleanly.

Question 9

In structured exception handling in C++, where are exceptions typically handled in relation to the regular program code?

Accepted Answer

Introduction / Context: C++ provides structured exception handling through try, catch and throw. The idea is to keep normal control flow separate from error handling code, which improves readability and maintainability. This question asks where exceptions are handled in relation to the ordinary program logic. Given Data / Assumptions: We are using standard C++ with exception handling enabled. Functions may throw exceptions when they encounter errors. Code can use try blocks with associated catch handlers. Concept / Approach: In structured exception handling, you write normal program logic in a try block or in functions called from that block. When an exception is thrown, the usual sequential flow of statements is interrupted. Control jumps to the nearest matching catch block that can handle the exception type. This means that error handling logic is written in a separate region of code rather than being mixed with every individual statement, which makes both the normal path and the error handling path easier to understand. Step-by-Step Solution: Step 1: Recall that try blocks mark regions of code where exceptions may occur.Step 2: Recognise that catch blocks are placed after the try block and contain the handling logic.Step 3: Together, try and catch blocks form a structure that separates normal code from error handling code.Step 4: Option B describes this arrangement as handling exceptions outside the regular sequential path in dedicated blocks.Step 5: Other options either place exceptions in impossible or meaningless locations, so option B is correct. Verification / Alternative check: Consider a code fragment: try { openFile(); readData(); processData(); } catch(const std::exception& ex) { logError(ex); }. The regular flow of opening, reading and processing is kept together. If an error occurs and an exception is thrown, control leaves the try block and moves to the catch block where the error is handled. This confirms that exceptions are handled in dedicated regions outside the main sequential flow. Why Other Options Are Wrong: Option A suggests mixing error handling with every statement, which is closer to manual error checks rather than exception handling. Option C claims that exceptions are only handled inside the operating system, which is not true for C++ application code. Option D and option E place exceptions in comments or restrict them to headers, which has no meaning in real programs. Common Pitfalls: Some programmers forget to structure their code with clear try and catch blocks and instead let exceptions propagate without any top level handling, which can terminate the program abruptly. Others catch exceptions too broadly and then ignore them, hiding bugs. Proper exception handling uses well placed try and catch blocks to separate concerns while still ensuring that errors are reported or recovered from appropriately. Final Answer: Outside the regular sequential code path, in dedicated try and catch blocks that surround sections of code.

Question 10

In C++ dynamic memory management, which of the following options correctly lists the operators used for allocation and deallocation on the free store (heap)?

Accepted Answer

Introduction / Context: Dynamic memory allocation in C++ allows programs to request and release memory at run time. This is done using specific operators that are part of the language syntax. Understanding which operators are used for allocation and deallocation on the free store is fundamental for safe memory management and for avoiding leaks. This question focuses on identifying the correct pair of operators. Given Data / Assumptions: We are working in C++ rather than in C. Dynamic memory allocation on the free store is handled with language level operators, not just with library functions. We are interested in the standard pair used together for creating and destroying objects. Concept / Approach: In C++, the new operator allocates memory for an object or an array of objects on the free store and calls the appropriate constructor. The corresponding delete operator releases that memory and calls the destructor. For arrays, delete[] is used, but conceptually it is still the delete operator family. While C standard library functions such as malloc and free are also available in C++, they do not call constructors or destructors and are not considered operators in the C++ language sense. Correct pairing of new with delete is crucial to avoid memory leaks and undefined behaviour. Step-by-Step Solution: Step 1: Identify the C++ operators that allocate and free memory while constructing and destroying objects.Step 2: Recall that new is used for allocation and delete for deallocation.Step 3: Option D states that both new and delete are used together for allocation and deallocation.Step 4: Options A and B list only one of the operators each, which is incomplete as an answer to the question.Step 5: Option C and option E either list unrelated names or confuse C library functions with C++ operators, so option D is correct. Verification / Alternative check: Consider code such as int* p = new int(5);. This line allocates memory on the free store and initialises the integer with the value 5. When you are done, you write delete p; to release the memory. Similarly, for arrays you might write double* a = new double[10]; and later delete[] a;. In both cases, new is paired with some form of delete, confirming that these operators are used together for dynamic memory management. Why Other Options Are Wrong: Option A and option B mention only one operator each, but the question asks for the operators involved in allocation and deallocation. Option C lists compare, which is not a memory management operator. Option E mentions malloc and free, which are C library functions, not C++ operators, and they do not integrate with constructors and destructors in the same way. Common Pitfalls: A common mistake is to mix allocation and deallocation mechanisms, such as allocating with new and freeing with free, which leads to undefined behaviour. Another pitfall is forgetting to call delete or delete[] for every successful call to new or new[], causing memory leaks. Remember for exam questions that the language level operators are new and delete for dynamic memory on the free store. Final Answer: Both new and delete are used together for allocation and deallocation.

Question 11

In C++ exception handling, why can using exception objects be considered more expensive than returning simple error codes?

Accepted Answer

Introduction / Context: Exceptions in C++ provide a powerful mechanism for handling error conditions, but they also come with costs. These costs are mostly related to what happens when an exception is actually thrown, not when code executes normally. This question asks why using exception objects can be considered more expensive than returning simple error codes in some situations. Given Data / Assumptions: We are using C++ with standard exception support. Exception handling uses objects that carry information about the failure. When an exception is thrown, stack unwinding occurs and destructors are called for local objects. Concept / Approach: When an exception is thrown, the runtime must locate the appropriate handler, perform stack unwinding and manage the lifetime of the exception object. The exception object is typically constructed at the throw point and may be copied or moved as the runtime transfers control to a catch block. This process takes time and uses memory for the exception object and for the bookkeeping needed to unwind the stack. In contrast, returning a simple error code usually involves setting a return value and does not trigger stack unwinding. This is why exceptions are said to be more expensive when they are actually thrown, even though they have little or no overhead in the normal case where no exception occurs. Step-by-Step Solution: Step 1: Focus on what happens when an exception is thrown: creation of an exception object and stack unwinding.Step 2: Recognise that constructing and possibly copying exception objects consumes execution time and memory.Step 3: Option A states that this creation and destruction of exception objects during stack unwinding is the source of extra cost.Step 4: Option B incorrectly claims that exception objects are created for every successful call, which is not true.Step 5: Options C, D and E exaggerate or misrepresent the behaviour of exceptions, so option A is correct. Verification / Alternative check: Performance measurements often show that code where exceptions are never thrown runs at similar speed to code without exceptions. However, when an exception is thrown, the cost per event is high because the runtime must walk the call stack, destroy local objects and transfer control. This supports the idea that exceptions are more expensive at the moment of failure due to the work involved with exception objects and stack unwinding. Why Other Options Are Wrong: Option B is wrong because exception objects are created only when an exception is actually thrown, not on every function call. Option C suggests that optimisations are completely disabled for the entire program, which is not accurate; compilers can still perform many optimisations in the presence of exceptions. Option D claims that exception objects automatically delete all dynamic memory, which is not how exceptions work. Option E confuses compile time exception specifications with run time costs. Common Pitfalls: A common misconception is that exceptions are always slow, even when they are not thrown. In reality, most of the cost appears when an exception is raised. Another pitfall is using exceptions for normal control flow, which magnifies these costs unnecessarily. Good practice is to reserve exceptions for rare, exceptional conditions where their expressiveness outweighs the overhead. Final Answer: Because constructing, copying and destroying exception objects during stack unwinding consumes additional execution time and memory resources.

Question 12

In the C++ standard library, within which namespace are the standard exception classes, such as std::exception and std::runtime_error, defined?

Accepted Answer

Introduction / Context: The C++ standard library groups its classes and functions into namespaces to avoid name clashes and to organise components logically. Exception classes that represent common error conditions are part of this standard library. This question asks in which namespace these standard exception classes are defined. Given Data / Assumptions: We are talking about standard exception classes such as std::exception, std::logic_error and std::runtime_error. These classes are defined by the C++ standard library, not by user code. They must live in a well known namespace so that programmers can refer to them consistently. Concept / Approach: All standard C++ library components are defined in the namespace std. This includes containers, algorithms, strings, streams and exception classes. The use of std as a namespace keeps the global namespace clean and allows user code to define its own classes without conflicting with standard names. To reference standard exceptions, you either qualify them with std:: or bring them into scope with a using declaration, although fully qualified names are often preferred in header files to avoid pollution. Step-by-Step Solution: Step 1: Recall that the C++ standard library is contained in namespace std.Step 2: Recognise that exception classes like exception and runtime_error are part of that library.Step 3: Therefore they are also defined in namespace std and should be written as std::exception and std::runtime_error.Step 4: Option A explicitly states namespace std.Step 5: Other options suggest fictional namespaces or the global namespace, so option A is correct. Verification / Alternative check: If you inspect standard library headers such as or , you will see declarations similar to namespace std { class exception; class runtime_error; }. This confirms that these classes are defined within the std namespace. Code examples in documentation also show usage like throw std::runtime_error("message");. Why Other Options Are Wrong: Option B and option C invent namespaces that are not part of the standard. Option D claims that exceptions live in the global namespace, which would conflict with the convention that all standard library components are under std. Option E introduces another non standard namespace. None of these match the language specification. Common Pitfalls: Beginners sometimes omit the std:: prefix and rely heavily on using namespace std; in global scope, which can lead to name clashes in larger projects. While this does not change where the classes are defined, it can cause confusion. In exam questions, however, you simply need to remember that standard exceptions are in the std namespace. Final Answer: namespace std

Question 13

In a run time polymorphic class hierarchy in C++, what is the main effect of introducing a clear interface, for example through abstract base classes with virtual functions?

Accepted Answer

Introduction / Context: In C++, run time polymorphism is usually achieved through base classes with virtual functions and derived classes that override those functions. Introducing a clear interface, often as an abstract base class, is considered good design practice because it decouples users of the hierarchy from specific implementations. This question asks what happens when such an interface is introduced into a polymorphic class hierarchy. Given Data / Assumptions: We have a set of classes that form a run time polymorphic hierarchy. There is an interface or abstract base class that declares virtual functions. Concrete derived classes implement these virtual functions. Concept / Approach: The main effect of introducing a clear interface is to separate what clients expect from how the behaviour is implemented. Clients can hold pointers or references to the base class and call virtual functions without knowing which concrete subclass is in use. This separation improves modularity, allows easier substitution of implementations and simplifies testing, because you can swap in different derived classes as needed. It also encourages design based on abstractions and promotes the open closed principle, where new behaviour can be added via new derived classes without changing existing client code. Step-by-Step Solution: Step 1: Focus on the role of an interface or abstract base class in a polymorphic hierarchy.Step 2: Recognise that it defines a contract that all derived classes must follow.Step 3: Note that this contract separates interface from implementation, because the interface specifies what can be done while derived classes specify how it is done.Step 4: Option A states exactly this separation of interface from implementation and the benefit that clients can depend on abstractions.Step 5: Options B, C, D and E describe restrictions or behaviours that conflict with the purpose of polymorphic interfaces, so option A is correct. Verification / Alternative check: Consider an abstract base class Shape with a virtual function draw(), and derived classes such as Circle and Rectangle that implement draw(). Client code can work with Shape* or Shape& and call draw() without caring which concrete class is used. If a new class Triangle is added later, existing code does not need to change as long as it uses the Shape interface. This demonstrates how introducing an interface separates usage from implementation. Why Other Options Are Wrong: Option B claims that interface and implementation are merged into a monolithic class, which is the opposite of what interfaces are designed to achieve. Option C suggests interfaces remove the need for virtual functions, but interfaces in C++ rely on virtual functions for dynamic dispatch. Option D eliminates inheritance, which would break polymorphism altogether. Option E asserts that all classes become final, which would prevent extension and contradict the goal of flexible hierarchies. Common Pitfalls: One mistake is to design interfaces that are too large, forcing derived classes to implement methods they do not need. Another pitfall is to couple client code to concrete classes instead of to the interface, which reduces the benefits of polymorphism. Good practice is to keep interfaces focused and to use them consistently across the hierarchy so that the separation from implementation is clear. Final Answer: It separates the interface of the hierarchy from the concrete implementations, allowing clients to depend on abstract types rather than on specific classes.

Question 14

In C++ or similar object oriented languages, which description best matches the protected access specifier for a class member?

Accepted Answer

Introduction / Context: Access specifiers control how class members can be used from different parts of a program. In C++ and many other object oriented languages, the three main access levels are public, protected and private. This question focuses on the meaning of protected, which is often used when designing class hierarchies. Given Data / Assumptions: We are working with classes that may have base and derived relationships. Members can be declared as public, protected or private. We want to understand who can access a protected member. Concept / Approach: A protected member is accessible from within its own class and from classes derived from that class, but not from other unrelated code. This forms a middle ground between public, which is accessible everywhere, and private, which restricts access to the declaring class only. Protected access is useful when you want derived classes to be able to manipulate certain internal details of the base class while still hiding these details from external clients. Step-by-Step Solution: Step 1: Recall that public members are accessible from any code that can see the class.Step 2: Recall that private members are only accessible from within the class itself and its friends.Step 3: Protected members are in between, accessible to the class and its derived classes.Step 4: Option C states that the member is visible inside its own class and to derived classes, but not to unrelated code.Step 5: Options A, B, D and E either misidentify the scope or confuse protected with other concepts, so option C is correct. Verification / Alternative check: Consider class Base { protected: int value; }; and class Derived : public Base { void set() { value = 10; } };. The member value is accessible inside Derived because it is protected in Base. However, in a separate function void f() { Base b; b.value = 5; } the compiler will report an error, because value is not accessible from unrelated code. This matches the description given in option C. Why Other Options Are Wrong: Option A describes block scope rather than class member access. Option B corresponds more closely to public access, where members are visible everywhere. Option D claims the member is invisible even inside its own class, which would make it useless. Option E introduces namespaces, which are orthogonal to class member access. Common Pitfalls: Programmers sometimes use protected when they really want private, exposing more of the implementation than necessary to derived classes. Another common confusion is between protected inheritance and protected access, which are related but distinct concepts. For exam purposes, remember that protected members are visible inside the class and in derived classes, but not in arbitrary external code. Final Answer: The member is visible inside its own class and to derived classes, but not to unrelated external code.

Question 15

In C++ programming, what is Run Time Type Information (RTTI) used for?

Accepted Answer

Introduction / Context: Run Time Type Information, commonly called RTTI, is a feature in C++ that allows programs to discover the dynamic type of objects during execution. This is especially useful in polymorphic hierarchies where you work with base class pointers or references and may need to know the exact derived type at run time. This question asks what RTTI is used for in that context. Given Data / Assumptions: We are using C++ with virtual functions and polymorphic classes. Objects may be referenced through pointers or references to a base class. We sometimes need to query the actual derived type or perform safe downcasts. Concept / Approach: RTTI enables two main facilities in C++. The first is typeid, which returns a std::type_info object describing the dynamic type of an expression when used with a polymorphic object, or the static type otherwise. The second is dynamic_cast, which performs a type safe cast that checks at run time whether the object being cast is of the requested type. If the cast is invalid, dynamic_cast returns null for pointers or throws an exception for references. These features rely on additional type information stored by the compiler and help ensure that operations on polymorphic objects remain safe. Step-by-Step Solution: Step 1: Recall that RTTI is associated with features like typeid and dynamic_cast in C++.Step 2: Recognise that these features allow you to examine or convert the dynamic type of an object safely at run time.Step 3: Option A states that RTTI provides information about an object type at run time for safe downcasts and type queries.Step 4: Options B, C and D describe uses unrelated to dynamic types.Step 5: Option E claims RTTI removes type checks, which is the opposite of its purpose, so option A is correct. Verification / Alternative check: Consider a hierarchy with class Base { virtual ~Base() {} }; and class Derived : public Base { };. If you have Base* p = new Derived; you can write if(Derived* d = dynamic_cast(p)) { /* use d */ }. Here dynamic_cast checks at run time whether p actually points to a Derived object. Similarly, typeid(*p) can reveal the dynamic type of the object. Both operations rely on RTTI data generated by the compiler. Why Other Options Are Wrong: Option B talks about local variables, which are not the focus of RTTI. Option C refers to line counts in source files, which is a documentation issue rather than a type system feature. Option D introduces logging for performance statistics, which is unrelated to RTTI. Option E misrepresents RTTI as an optimisation that removes type checks, while in reality it enables additional safety checks at run time. Common Pitfalls: Developers sometimes overuse RTTI and dynamic_cast where virtual functions or proper design of interfaces would be cleaner. Another pitfall is disabling RTTI through compiler options and then expecting typeid or dynamic_cast to work fully. While RTTI is useful, it should be applied judiciously and not as a substitute for good polymorphic design. For exam questions, remember that RTTI is about obtaining type information and performing safe casts at run time. Final Answer: It provides information about an object type at run time, enabling safe downcasts and type queries using mechanisms such as typeid and dynamic_cast.

Question 16

When implementing components of the C++ standard library, which of the following design practices are generally recommended?

Accepted Answer

Introduction / Context: The C++ standard library sets a style and quality benchmark for user code. Many guidelines have emerged from how the library is written, including naming conventions, return value choices and the use of swap functions. This question asks you to identify which combination of practices is generally considered good style when implementing standard like library components. Given Data / Assumptions: We are thinking about how standard library classes and functions are designed. Public names must follow rules that avoid conflict with user code and implementation details. Returning objects by value and providing swap functions are important design decisions. Concept / Approach: Public names in the standard library avoid trailing underscores, which are often reserved for implementation details or internal identifiers. Returning complex objects by value is common in modern C++, especially when compilers can apply return value optimisation and move semantics to make this efficient. Providing a member swap function can improve performance and exception safety, because it allows algorithms such as std::swap to exchange resources with minimal overhead. Taken together, these practices reflect a design philosophy of clarity, efficiency and compatibility with generic algorithms. Step-by-Step Solution: Step 1: Evaluate option A, which relates to naming conventions; avoiding trailing underscores on public names is consistent with common style.Step 2: Evaluate option B, where returning objects by value is widely used in modern C++ to express value semantics and leverage optimisations.Step 3: Evaluate option C, where providing member swap functions is known to help with performance and exception safety.Step 4: Since all three individual practices are reasonable and encouraged in standard like code, a combined option stating that all are recommended should be correct.Step 5: Option D explicitly states that all of the mentioned practices are recommended, so it is the correct answer. Verification / Alternative check: Looking at standard library types such as std::string or std::vector, you will see that they have clear public names without trailing underscores, are often returned by value from functions and provide member swap functions. These real examples support the idea that the practices named in options A, B and C align with standard library implementation style. Why Other Options Are Wrong: Options A, B and C each capture only one aspect of good practice and do not fully answer the question that asks for the overall set of recommended design practices. Option E claims that none of the mentioned practices should be used, which contradicts how the standard library is actually written. Common Pitfalls: Some developers overuse underscores or internal naming conventions in their public interfaces, which can confuse users. Others avoid returning objects by value due to outdated worries about performance, even though modern compilers optimise such code well. Forgetting to provide swap can also make generic algorithms less efficient. For exam purposes, remembering that all three practices are recommended will help you choose option D. Final Answer: All of the mentioned design practices are generally recommended for coding standard C++ library components.

Question 17

In the C++ Standard Template Library (STL), how are elements of a container typically accessed in a generic way?

Accepted Answer

Introduction / Context: The C++ Standard Template Library introduces containers that store elements and algorithms that operate on those elements. To connect algorithms with different container types in a generic way, the STL uses iterators. This question asks how elements of a container are typically accessed when you want to write code that works with many container types. Given Data / Assumptions: We are using STL containers such as std::vector, std::list and std::deque. STL algorithms are designed to be generic and work with multiple container types. There is a mechanism that allows algorithms to traverse containers without knowing their concrete implementation. Concept / Approach: Iterators are objects that behave somewhat like pointers and provide a uniform interface for accessing elements in a container. Each container type defines iterator types, such as iterator and const_iterator, which allow algorithms like std::sort, std::find and std::for_each to read or modify elements. This design decouples containers from algorithms: algorithms operate on iterator ranges, and containers provide iterators that represent the sequence of elements. As a result, the same algorithm implementation can work with many different containers without modification. Step-by-Step Solution: Step 1: Recall that STL documentation often mentions that algorithms take iterator pairs [first, last) to access elements.Step 2: Understand that iterators are provided by containers and can move through the elements.Step 3: Option A states that elements are accessed by using iterators to traverse the container.Step 4: Options B, C, D and E describe approaches that either require special compiler knowledge or misuse global variables and macros, which are not how STL is designed.Step 5: Therefore, option A is the correct answer. Verification / Alternative check: Consider std::vector v; with some values. An STL algorithm like std::sort is called as std::sort(v.begin(), v.end());. Here v.begin() and v.end() are iterators that mark the start and end of the sequence. The algorithm needs no knowledge of the internal storage of std::vector. The same pattern applies to many other containers and algorithms, confirming that iterators are the generic access mechanism. Why Other Options Are Wrong: Option B suggests modifying the compiler, which is neither practical nor necessary. Option C restricts access to array indexing, but many containers do not support random access by index. Option D describes global variables pointing everywhere, which would be unsafe and does not match the STL design. Option E overuses macros, which STL deliberately avoids in favour of type safe templates and iterators. Common Pitfalls: Beginners sometimes focus only on index based access with std::vector and ignore iterators, which limits their ability to use other containers effectively. Another pitfall is misusing iterators after a container is modified in a way that invalidates them. For exam questions, emphasise that iterators are the standard generic way to access container elements in the STL. Final Answer: By using iterators that can traverse the container and refer to its elements.

Question 18

In the C++ Standard Template Library (STL), what does a sequence adaptor such as std::stack or std::queue provide?

Accepted Answer

Introduction / Context: The C++ Standard Template Library contains not only basic containers but also container adaptors, including sequence adaptors such as std::stack, std::queue and std::priority_queue. These adaptors sit on top of underlying sequence containers and change how you interact with them. This question asks what a sequence adaptor provides in terms of functionality and interface. Given Data / Assumptions: We are considering sequence container adaptors like std::stack and std::queue. These adaptors are built on top of underlying sequence containers such as std::deque or std::vector. The main role of an adaptor is to change the interface presented to the user. Concept / Approach: A sequence adaptor reuses an existing container type to store elements but exposes only a limited set of operations that correspond to a specific abstract data type. For example, std::stack uses an underlying container and allows push, pop and top, but does not expose random access or iteration. Similarly, std::queue provides operations such as push, pop, front and back to model a first in first out queue. This design separates storage from interface and lets you choose the underlying container type through template parameters while using a simple adaptor interface at the call site. Step-by-Step Solution: Step 1: Recall that adaptors wrap existing containers and restrict or change the interface.Step 2: Recognise that std::stack and std::queue are examples of sequence adaptors that present stack like or queue like operations.Step 3: Option A states that a sequence adaptor provides an interface that adapts an underlying sequence container into a restricted view such as a stack or queue.Step 4: Options B, C, D and E describe memory management, code generation, associative containers or hardware drivers, none of which match the STL definition of a sequence adaptor.Step 5: Therefore, option A is the correct answer. Verification / Alternative check: Looking at the declaration of std::stack, you will see a template parameter for the underlying container, often defaulted to std::deque. The public interface of std::stack does not expose operations like insert at arbitrary positions, even though the underlying container might support them. Instead, it offers push, pop and top, which implement last in first out semantics. This is exactly what it means to adapt a sequence container to a stack interface. Why Other Options Are Wrong: Option B confuses sequence adaptors with low level memory allocators. Option C talks about generating source code at run time, which the STL does not do. Option D claims adaptors replace associative containers, but associative containers such as std::map are separate types with different interfaces. Option E refers to device drivers, which are outside the scope of container adaptors. Common Pitfalls: Developers sometimes assume that they can treat a sequence adaptor exactly like its underlying container and are surprised when operations such as iteration are not available. Another pitfall is forgetting that you can customise the underlying container when better performance or memory characteristics are needed. For exam purposes, remember that sequence adaptors provide a restricted interface that adapts an underlying sequence container to a specific abstract data type such as a stack or queue. Final Answer: An interface that adapts an underlying sequence container to provide a restricted view such as stack or queue behaviour.

Question 19

In an associative container such as std::map in C++, each stored element conceptually consists of how many parts?

Accepted Answer

Introduction / Context: Associative containers in the C++ Standard Template Library, such as std::map and std::unordered_map, store elements that associate keys with values. Understanding how many parts each element has is important for reasoning about how these containers behave and how you access their contents. This question focuses on the conceptual structure of an element in an associative container like std::map. Given Data / Assumptions: We are considering associative containers such as std::map. Each element connects a key of type Key to a value of type T. The internal representation is often a std::pair. Concept / Approach: In std::map, each element is stored as a pair, where the first component is the key and the second component is the mapped value. The key is used to order or hash the elements and to perform lookups, while the mapped value holds the associated data. Conceptually, this means that each element consists of two parts. Even though the implementation may use additional metadata such as tree nodes or hash buckets, those are not considered parts of the logical element from the user perspective. Step-by-Step Solution: Step 1: Recall that the value type of std::map is std::pair.Step 2: Recognise that std::pair has exactly two components, called first and second.Step 3: The first component is the key, and the second is the associated mapped value.Step 4: Option A states that there are 2 parts, a key and a mapped value, which matches this understanding.Step 5: Other options claim 1, 3, 4 or 5 parts, inventing extra components or ignoring the key, so option A is correct. Verification / Alternative check: In code, if you iterate over a std::map m, each iterator dereferences to a std::pair. You can access element.first to read the key and element.second to read or modify the value. No additional logical parts are visible to the user. This confirms that conceptually there are exactly two parts for each element in such an associative container. Why Other Options Are Wrong: Option B ignores the key, but an associative container without keys would be just a sequence container. Option C introduces an index number, which is not part of the logical element in std::map, where ordering is determined by the key, not by an index. Option D and option E describe fanciful structures that do not reflect the standard library design. Common Pitfalls: Some learners initially think of std::map as a simple dictionary of values and overlook the fact that each element is a pair. This can lead to confusion when using iterators or when interpreting type names in error messages. Remembering that each associative container element consists of a key and a mapped value will help when writing code that manipulates these structures and when answering exam questions like this one. Final Answer: 2, a key and a mapped value, for example the pair<const Key, T> stored in std::map.

Question 20

In the C++ Standard Template Library (STL), how many parameters does the basic overload of the non modifying algorithm std::mismatch typically take?

Accepted Answer

Introduction / Context: The std::mismatch algorithm in the C++ Standard Template Library compares elements from two sequences and finds the first position where they differ. Like many STL algorithms, std::mismatch has multiple overloads, but there is a basic form that takes a specific number of parameters. This question asks you to recall how many parameters the basic non modifying overload accepts. Given Data / Assumptions: We are discussing std::mismatch as defined in the <algorithm> header. The basic overload operates on two sequences using default element comparison. The question refers to the simpler form, not to additional predicate based overloads. Concept / Approach: The basic overload of std::mismatch takes three iterator parameters: first1, last1 and first2. The pair [first1, last1) specifies the first range, and first2 points to the beginning of the second range that should be compared. The algorithm advances through both sequences in parallel, comparing corresponding elements until it finds a mismatch or reaches the end of the first range. There are additional overloads that take four or more parameters, including custom predicates, but the question focuses on the simpler three parameter version. Step-by-Step Solution: Step 1: Recall the standard signature of the simplest std::mismatch overload.Step 2: That signature is roughly mismatch(InputIt1 first1, InputIt1 last1, InputIt2 first2).Step 3: This gives three parameters: first1, last1 and first2.Step 4: Option C states that the algorithm usually takes 3 parameters in the basic form.Step 5: Options A, B, D and E list incorrect counts or describe only more complex overloads, so option C is correct for the basic version. Verification / Alternative check: Documentation for std::mismatch commonly shows the first overload as mismatch(InputIt1 first1, InputIt1 last1, InputIt2 first2). Later overloads add a fourth parameter, a binary predicate, or use different iterator category requirements. Because the question explicitly mentions the non sequence modifying algorithm and does not mention predicates, it is reasonable to assume it refers to this three parameter overload. Why Other Options Are Wrong: Option A and option B would not give std::mismatch enough information to define both ranges. Option D describes an overload that includes two ranges, but that form also needs starting and ending iterators for the second range, making it more complex than the basic version. Option E exaggerates further by adding multiple ranges and predicates that are not part of the simplest interface. Common Pitfalls: It is easy to confuse the signatures of different algorithms or different overloads of the same algorithm, especially when predicates are involved. For exam questions, pay attention to whether the question mentions custom predicates or refers to the basic version that uses default comparison. In this case, the three parameter form is the correct answer. Final Answer: 3, usually first1, last1 and first2 iterators.

Technology Questions