Misc Interview Questions
Size of shared_ptr
The size of std::shared_ptr is typically 16 bytes or more on a 64-bit system.
The size consists of an 8-byte pointer to the object and 8+ bytes for the control block that handles reference counting.
The actual size can vary depending on the platform, architecture, and standard library implementation, so you can use sizeof to check it for your environment.
Diamond problem
The diamond problem in C++ (and other object-oriented languages that support multiple inheritance) refers to an ambiguity that arises when a class inherits from two classes that both inherit from the same base class. This situation can cause issues with inheritance and method resolution, specifically when the derived class is unsure which path to take to access the base class's methods or members.
To solve the diamond problem, C++ introduces virtual inheritance. Virtual inheritance ensures that the base class is shared between all the derived classes.
what is array decay in C++
Array decay in C++ refers to the process by which an array is automatically converted to a pointer when passed to a function. This occurs because, in most contexts, the name of an array is interpreted as a pointer to its first element, which causes the loss of the array's size and type information.
Key Points About Array Decay:
- Array to Pointer Conversion: When you pass an array to a function, it decays into a pointer to the first element of the array. This means the function only receives a pointer, and it no longer has access to the full array's size or type.
- Loss of Array Size Information: When an array decays into a pointer, the size of the array is lost. The function receiving the array will not know how many elements the array has. This is why, when passing arrays to functions, it's common to also pass the array's size as a separate argument.
To prevent problems from array decay, you can use alternatives like std::array or std::vector, which retain size information and provide safer, more flexible handling of arrays.
Key Differences Between Abstract Class and Interface
Feature | Abstract Class | Interface |
Instantiation | Cannot be instantiated directly. | Cannot be instantiated directly. |
Methods | Can have both abstract and concrete methods. | Can only have abstract methods (except default and static methods). |
Constructor | Can have constructors. | Cannot have constructors. |
Fields | Can have instance variables (fields). | Can only have public static final variables (constants). |
Inheritance | A class can extend only one abstract class. | A class can implement multiple interfaces. |
Access Modifiers | Can have any access modifiers for methods and fields. | All methods in an interface are implicitly public, and they cannot have other access modifiers. |
Default Methods | Cannot have default methods. | Can have default methods (Java 8+). |
Purpose | Used when classes share common functionality but might not have a strict contract. | Used to define a contract or capability that classes should adhere to. |
Multiple Inheritance | No multiple inheritance (one class only). | Supports multiple inheritance (a class can implement multiple interfaces). |
REST (Representational State Transfer Application Programming Interface)
Stateless means that each request from the client to the server must contain all the information the server needs to fulfill the request. The server does not store any state about the client between requests. Each request is independent.
HTTP Methods
REST APIs commonly use standard HTTP methods (also called verbs) to perform operations on resources:
GET: Retrieve data from the server. For example, GET /users might fetch all users.
POST: Create a new resource on the server. For example, POST /users might create a new user.
PUT: Update an existing resource. For example, PUT /users/123 might update the user with ID 123.
DELETE: Delete a resource. For example, DELETE /users/123 might delete the user with ID 123.
PATCH: Partially update a resource.
HTTP Status Codes
REST APIs use HTTP status codes to indicate the outcome of the request:
200 OK: The request was successful, and the server has responded with the requested data.
201 Created: The request was successful, and a new resource was created.
400 Bad Request: The server could not understand the request, often due to malformed syntax.
404 Not Found: The resource was not found.
500 Internal Server Error: The server encountered an error while processing the request.
CRUD Operations
REST APIs typically align with the CRUD operations:
Create (POST)
Read (GET)
Update (PUT or PATCH)
Delete (DELETE)
Idempotency
RESTful APIs emphasize idempotency in certain operations. This means that making multiple identical requests should have the same effect as making a single request.
For example, a GET request is idempotent because it will always return the same data.
A DELETE request is also typically idempotent, as deleting a resource multiple times will have the same result: the resource will be gone.
STUB, MOCK or FAKE
Stub: If you’re testing a service that calls an external API, and you want to simulate a successful response from that API, you’d use a stub.
Mock: If you’re testing the interaction between a service and a logging mechanism, and you want to assert that the log method was called with the correct parameters, you’d use a mock.
Fake: If you’re testing a database-driven application and don’t want to rely on a real database, you might use a fake in-memory database.
Some C++ process is running slow - how would you go about investigating
To investigate why a C++ process is running slow, you should:
- Profile the application using tools like gprof, perf, or Valgrind to find bottlenecks.
- Analyze algorithms for inefficiency and optimize them.
- Check for memory leaks or excessive memory usage using profiling tools.
- Investigate multi-threading issues (e.g., thread contention, lock contention).
- Look for disk or network I/O issues.
- Use compiler optimizations and review the code for any unnecessary copies or suboptimal code paths.
Possible Outcomes When There's a Connection Problem:
- Connection Failure: The connection cannot be established or is refused (e.g., server unreachable, port closed).
- Packet Loss: Lost packets trigger retransmissions, slowing down the connection.
- Timeouts: If acknowledgments aren't received within the timeout period, retransmissions are attempted. Multiple timeouts can lead to connection termination.
- Congestion Control: TCP reduces the transmission rate to avoid congestion, which can cause slowdowns.
- Connection Reset: A reset is initiated due to a forced termination or unexpected error.
- Half-Open Connections: Inconsistent connection states when one side terminates while the other side is unaware.
- Firewall/NAT Issues: Network security devices can block or drop TCP packets, resulting in connection issues.
Git and Github Differences:
Git | GitHub |
A version control system used to manage source code history. | A platform/hosting service built around Git to store and manage Git repositories online. |
CLI-based (command-line interface) tool. | Web-based platform with a GUI for repository management and collaboration. |
Git is used locally on your computer to track changes and manage code. | GitHub allows you to host repositories and collaborate with others remotely. |
Focuses on version control and local repository management. | Focuses on collaboration, project management, and hosting Git repositories in the cloud. |
In a typical workflow:
- Git is used to create and manage repositories on your local machine, commit changes, and track history.
- GitHub is used to store the remote version of your repositories, collaborate with others, and share code. You push and pull changes to and from GitHub using Git commands.
No comments:
Post a Comment