Question 1

Hashtable in .NET: choose the correct combined statement about its characteristics.

Accepted Answer

Introduction / Context: Understanding core collection types is crucial for writing efficient C# code. Hashtable is one of the classic non-generic collections; while generic Dictionary is preferred today, many codebases still expose Hashtable. Given Data / Assumptions: We are discussing System.Collections.Hashtable (non-generic). Focus areas: key-based access, ordering, indexing, and enumeration. Concept / Approach: Hashtable stores entries as key–value pairs and provides O(1)-average access by key. It does not guarantee any ordering of elements (neither insertion order nor sort order). It is not index-based (you do not access elements by numeric index). Iteration is provided via an enumerator that implements IDictionaryEnumerator, exposing Entry, Key, and Value of the current element. Step-by-Step Solution: Keyed nature → True: you look up by key (e.g., ht[""id""]).Ordering → False: no ordering guarantees; enumeration order is unspecified.Index-based → False: there is no positional integer index API.Enumerator → True: Hashtable’s enumerator implements IDictionaryEnumerator to yield DictionaryEntry (Key, Value).Keys/Values → Exposed on the Hashtable itself via the Keys and Values properties (collections), not only via the enumerator. Verification / Alternative check: Create a Hashtable, add elements, iterate with foreach (DictionaryEntry de in ht) to access de.Key/de.Value. Try to rely on order; results will vary. Why Other Options Are Wrong: B claims insertion order and index-based access—incorrect. C says you cannot enumerate—incorrect. D forbids heterogeneous values—Hashtable stores objects; heterogeneity is allowed. E misstates where Keys/Values live; they are properties on Hashtable. Common Pitfalls: Assuming predictable order, or thinking it behaves like a List. Prefer Dictionary in modern generic code for type safety and performance. Final Answer: Hashtable is a keyed collection; it is unordered and not index-based; its enumerator type implements IDictionaryEnumerator.

Question 2

C#.NET Stack (non-generic): is the following mixed-type Push() usage valid?  Stack st = new Stack(); st.Push("hello"); st.Push(8.2); st.Push(5); st.Push('b'); st.Push(true);

Accepted Answer

Introduction / Context: The classic System.Collections.Stack is a non-generic last-in, first-out collection that stores elements as System.Object. This permits mixing types in the same collection, which is sometimes useful and sometimes risky. Given Data / Assumptions: We are using System.Collections.Stack (non-generic), not Stack. We push strings, floating-point numbers, integers, a char, and a bool. Concept / Approach: Because the non-generic Stack stores elements as object references, any type can be pushed (value types are boxed automatically). Type safety is enforced at use-sites via casts when popping or peeking. Step-by-Step Solution: Check string → allowed (reference type).Check double/float literal → allowed (boxed value type).Check int → allowed (boxed value type).Check char literal 'b' → allowed (boxed value type).Check bool → allowed (boxed value type). Verification / Alternative check: Run-time: foreach over st will yield objects of different types. Casting back to original types works as long as you cast correctly (or check with 'is'/pattern matching) before use. Why Other Options Are Wrong: A/D assume homogeneity requirement or a special API—non-generic Stack has neither. B forbids bool—false. C confuses char vs. string; 'b' is valid for char. Common Pitfalls: Mixing types can lead to InvalidCastException when popping if you assume the wrong type. Prefer Stack for compile-time safety. Final Answer: Valid: non-generic Stack stores objects, so dissimilar elements are allowed.

Question 3

ArrayList in .NET: how do you get the current number of elements stored?

Accepted Answer

Introduction / Context: ArrayList is a resizable array in System.Collections. Knowing the difference between capacity and count is key for correct memory and performance management. Given Data / Assumptions: We are using System.Collections.ArrayList (non-generic). We want the number of elements actually contained. Concept / Approach: ArrayList exposes two size-related members: Count and Capacity. Count returns how many elements are currently stored. Capacity is the size of the internal array (allocation) and may be greater than Count. Other listed members either do not exist or are not used for this purpose. Step-by-Step Solution: Use arr.Count → returns the number of elements present.arr.Capacity → internal storage size, not the active element count.arr.GrowSize / arr.MaxIndex / arr.UpperBound → not members of ArrayList for this purpose. Verification / Alternative check: Add items and inspect Count vs. Capacity in a debugger; Count increases by one per Add, Capacity grows in steps. Why Other Options Are Wrong: They either refer to non-existent members or to Capacity, which is distinct from count. Common Pitfalls: Using Capacity to loop can lead to null entries or index errors. Always iterate up to Count. Final Answer: arr.Count

Question 4

Key-based I/O in .NET collections: which listed collections perform input/output based on a key?

Accepted Answer

Introduction / Context: Different collections provide different access semantics. Some are key-based (associative containers), while others are position-based or bit-based. Choosing the right collection is essential for clarity and performance. Given Data / Assumptions: We consider classic System.Collections types. Hashtable and SortedList are associative containers keyed by objects. Concept / Approach: Key-based collections allow storage and retrieval by key rather than by numeric index. Hashtable provides hash-based key lookup with no ordering guarantees. SortedList stores key–value pairs sorted by keys, enabling ordered iteration and binary-search-like retrieval. Step-by-Step Solution: Hashtable → key-based access (e.g., ht["id"]).SortedList → key-based access plus sorted by keys.Stack → LIFO structure, no keys, push/pop/peek operations.BitArray → compact boolean store accessed by integer index, not keys.'Map' → not a .NET Framework class name in System.Collections; the closest equivalents are Dictionary and Hashtable. Verification / Alternative check: Create a Hashtable and a SortedList and insert/retrieve items via keys; attempt the same with Stack or BitArray and observe the absence of key-based APIs. Why Other Options Are Wrong: They include non-keyed structures or non-existent types (as named). Common Pitfalls: Assuming Stack has named access or that BitArray supports keys beyond integer indices. Final Answer: Hashtable and SortedList

Question 5

Which statements about the System.Collections.Stack collection are correct?

Accepted Answer

Introduction / Context: Stack is a fundamental LIFO data structure. Understanding its operations and typical use-cases (such as expression evaluation and recursion emulation) is important for both interviews and real-world coding. Given Data / Assumptions: We discuss System.Collections.Stack (non-generic). We evaluate statements about usage pattern (LIFO vs. FIFO), iteration, type restrictions, and top access. Concept / Approach: Stack supports Push, Pop, and Peek. It is LIFO, not FIFO. Being non-generic, it stores objects and can hold mixed types. It implements IEnumerable, so you can iterate using foreach or an enumerator. Stack is commonly used in parsing and evaluating expressions (e.g., infix to postfix, postfix evaluation). Step-by-Step Solution: Expression evaluation → True; stacks are commonly used for operators/operands.Enumerator-based iteration → True; Stack implements IEnumerable.FIFO → False; Stack is LIFO.Similar types only → False; non-generic Stack can store heterogeneous objects.Peek() → True; returns the top element without removal. Verification / Alternative check: Implement a postfix evaluator using a Stack and verify Push/Pop/Peek behavior; iterate with foreach to confirm enumeration. Why Other Options Are Wrong: A omits Peek(); B asserts FIFO and homogeneity; D contradicts the false parts in A and B; E contradicts the many true aspects. Common Pitfalls: Confusing Stack (LIFO) with Queue (FIFO), and assuming non-generic collections enforce a single element type. Final Answer: It supports expression evaluation, enumerator-based iteration, and accessing the top element via Peek().

Question 6

C#.NET — ArrayList and IEnumerable/IEnumerator: identify the true statements about enumeration, thread-safety, and nested (inner) enumerator classes. Statements: 1) The ArrayList class contains a nested enumerator class that implements IEnumerator. …

Accepted Answer

Introduction / Context: In the .NET Framework, non-generic collections like ArrayList expose iteration capabilities via IEnumerable/IEnumerator. Understanding how enumerators are implemented, what nested classes can access, and what thread-safety guarantees exist helps developers avoid common bugs when iterating or modifying collections. Given Data / Assumptions: The collection under discussion is System.Collections.ArrayList (non-generic). ArrayList implements IEnumerable and returns an IEnumerator from GetEnumerator(). We are considering default behaviors without applying wrappers like ArrayList.Synchronized or external locks. Concept / Approach: ArrayList provides an enumerator implemented by a nested class (an inner type) that implements IEnumerator. In C#, a nested type has access to all members (including private) of its containing type. By default, ArrayList is not thread-safe, so simultaneous access from multiple threads requires external synchronization to be safe. Step-by-Step Solution: 1) Statement 1: True. ArrayList uses a nested enumerator that implements IEnumerator and is returned by GetEnumerator().2) Statement 2: Interpreted correctly, this is True in the sense that ArrayList is not synchronized and therefore not safe for concurrent access without locks.3) Statement 3: True. A nested class can access members of its containing class directly; passing an explicit reference is not required.4) Statement 4: False. Due to nested-type access rules, no explicit reference passing is necessary to access the outer class’s members.5) Statement 5: False. Enumerators are intended for read-only iteration; modifying the collection during enumeration invalidates the enumerator and raises an exception. Verification / Alternative check: Create an ArrayList, obtain IEnumerator via GetEnumerator(), and attempt to modify the collection during enumeration; observe InvalidOperationException. Inspect metadata (e.g., via decompilation) to see the nested enumerator type. Why Other Options Are Wrong: Options including statement 4 or 5 are incorrect because nested classes do not need an explicit reference, and enumerators should not modify the collection. Common Pitfalls: Assuming enumerators permit mutation; forgetting to synchronize or lock around shared ArrayList usage in multi-threaded code. Final Answer: 1, 2, and 3 only

Question 7

Framework Class Library (FCL) collections — pick the correct statement about performance and mutability of elements stored in collection classes.

Accepted Answer

Introduction / Context: The .NET Framework Class Library (FCL) provides rich collection classes designed for common scenarios. This question checks conceptual understanding of their goals and capabilities. Given Data / Assumptions: We are discussing the general properties of FCL collections (System.Collections and System.Collections.Generic). Statements concern mutability, transport, and performance characteristics. Concept / Approach: Collections abstract storage and access patterns and are optimized for typical operations such as adding, searching, sorting, and enumerating. They can hold references to any serializable objects for transport, support modifying elements (subject to type rules), and use well-known data structures to improve performance. Step-by-Step Solution: 1) Option A: Incorrect. Serializable elements in a collection can be transmitted over a network (e.g., via serialization or web APIs).2) Option B: Incorrect. Collections typically allow modification unless explicitly read-only wrappers are applied.3) Option C: Incorrect. Collections are designed to be widely applicable, and generics make adopting for new types straightforward.4) Option D: Incorrect. Heterogeneous collections are allowed; modification is not restricted to homogeneous element types (though generics encourage strong typing).5) Option E: Correct. FCL collections implement efficient algorithms and data structures to manage items effectively. Verification / Alternative check: Review types such as List, Dictionary, and HashSet to see algorithmic choices (dynamic arrays, hash tables, trees). Why Other Options Are Wrong: They impose artificial restrictions not inherent to FCL collections. Common Pitfalls: Confusing read-only views with fundamental collection immutability; assuming only homogeneous types are supported. Final Answer: FCL collection classes use efficient algorithms and data structures to manage items, which helps program performance.

Question 8

ArrayList capacity growth — if Capacity is 4, what is the capacity after adding the 5th element?

Accepted Answer

Introduction / Context: ArrayList grows its internal storage automatically. Understanding capacity growth helps explain amortized insertion costs. Given Data / Assumptions: Initial Capacity property is 4. A 5th element is added, exceeding current capacity. Concept / Approach: ArrayList uses a dynamic array. When capacity is exceeded, it increases capacity (commonly doubling) to accommodate additional items, reducing the frequency of reallocations. Step-by-Step Solution: Attempt to add element number 5 to capacity 4.ArrayList resizes underlying array, typically doubling from 4 to 8.Capacity becomes 8; Count becomes 5. Verification / Alternative check: Write a short program that sets Capacity to 4, adds 5 items, and prints Capacity and Count. Why Other Options Are Wrong: 4 is impossible (insufficient for 5 items); 16 and 32 are too large for a single resize; element type does not affect capacity growth. Common Pitfalls: Confusing Capacity (allocated slots) with Count (actual elements). Final Answer: 8

Question 9

System.Collections — which of the following is NOT an interface defined in this namespace?

Accepted Answer

Introduction / Context: Knowing the standard interfaces in System.Collections is essential for iteration and dictionary-like access patterns. Concept / Approach: Common interfaces include IEnumerable (sequence), IEnumerator (iterator), IComparer (ordering), IDictionaryEnumerator (dictionary enumeration). There is no standard IDictionaryComparer interface in System.Collections. Why Other Options Are Wrong: IComparer, IEnumerable, IEnumerator, and IDictionaryEnumerator are valid and widely used in the non-generic collections. Final Answer: IDictionaryComparer

Question 10

Index-based Input/Output — in which of the following .NET collections are elements accessed by index?

Accepted Answer

Introduction / Context: Different collection types expose different access patterns (index, key, FIFO, LIFO). This affects algorithm design and complexity. Concept / Approach: ArrayList and BitArray are index-based. Stack (LIFO) and Queue (FIFO) do not expose random indexers. HashTable is key-based, not index-based. Why Other Options Are Wrong: Options including Stack/Queue/HashTable imply index-based access where none exists. Final Answer: BitArray and ArrayList

Question 11

Ordered collection classes — which choices represent ordered collections in .NET?

Accepted Answer

Introduction / Context: “Ordered” refers to a deterministic iteration order defined by the data structure. Stack and Queue impose specific orders (LIFO and FIFO respectively). Concept / Approach: Stack yields elements in reverse insertion order (LIFO). Queue yields elements in insertion order (FIFO). HashTable has no guaranteed order. BitArray is index-addressable but represents bits rather than general objects; the question context typically treats Stack and Queue as the canonical ordered structures among those listed. Why Other Options Are Wrong: Map is not a standard .NET type name; HashTable has no guaranteed iteration order; “All”/“None” do not fit the behavior of Stack and Queue. Final Answer: Stack and Queue

Question 12

Hashtable — how do you check if a specific state name (key) like "Kerala" exists in the table of state→capital entries?

Accepted Answer

Introduction / Context: Hashtable stores key/value pairs. Efficient membership checks rely on keys, not values. Concept / Approach: Use ContainsKey to test the presence of a key. Use ContainsValue to search values (less efficient and not appropriate for checking key membership). Why Other Options Are Wrong: HasValue/HasKey/ContainsState are not Hashtable methods; ContainsValue checks values, not keys. Final Answer: t.ContainsKey("Kerala")

Question 13

Queue enumeration — choose the correct code to access all elements of a System.Collections.Queue instance.

Accepted Answer

Introduction / Context: All non-generic collections in System.Collections support enumeration via IEnumerable/IEnumerator. Queue is no exception. Concept / Approach: Call q.GetEnumerator() to get an IEnumerator. Iterate by calling MoveNext() and reading Current. foreach uses the same pattern behind the scenes. Why Other Options Are Wrong: Option B: GetEnumerator() returns IEnumerator, not IEnumerable. Option C: GetEnumerable() does not exist. Option D: GetEnumerator() is an instance, not static, method. Option E: foreach is supported, but explicit IEnumerator use is also valid. Final Answer: IEnumerator e = q.GetEnumerator(); while (e.MoveNext()) Console.WriteLine(e.Current);

Question 14

Stack enumeration — choose the correct code to access all elements of a System.Collections.Stack instance.

Accepted Answer

Introduction / Context: Like Queue, Stack supports enumeration through GetEnumerator(). Understanding iteration without indexing is important for LIFO containers. Concept / Approach: Call st.GetEnumerator(), loop with MoveNext(), and access Current. Alternatively, foreach (var x in st) is the idiomatic approach. Why Other Options Are Wrong: Option A: Type mismatch (GetEnumerator returns IEnumerator). Option B: GetEnumerable() does not exist. Option D: GetEnumerator is not static. Option E: Stack is not index-based. Final Answer: IEnumerator e = st.GetEnumerator(); while (e.MoveNext()) Console.WriteLine(e.Current);

Question 15

Hashtable nullability rule — can a key be null and can a value be null?

Accepted Answer

Introduction / Context: Hashtable stores key/value pairs with hashing semantics. Null handling differs for keys and values. Concept / Approach: Hashtable prohibits null keys because hashing and equality logic require a valid object reference. However, values may legitimately be null to represent “no value” while still reserving a key in the table. Why Other Options Are Wrong: Allowing a null key breaks hashing; disallowing null values is unnecessary; the comparer does not change the prohibition on null keys. Final Answer: True — a key cannot be null, but a value can be null.

Question 16

In .NET, an ArrayList is being enumerated by four threads at the same time. How many independent enumerator instances will exist concurrently for that single ArrayList object?

Accepted Answer

Introduction / Context: Understanding how enumeration works in .NET collections is essential for writing thread-aware code. Each call to GetEnumerator() on a collection such as ArrayList returns a new enumerator object that maintains its own iteration state. When multiple threads enumerate the same collection concurrently, the number of enumerators equals the number of active enumerations. Given Data / Assumptions: A single ArrayList instance exists. Exactly four threads are “working on” (i.e., enumerating with foreach/GetEnumerator) that ArrayList at the same time. No synchronization tricks or shared enumerator are being used. Concept / Approach: ArrayList implements IEnumerable and returns an IEnumerator via GetEnumerator(). Every call produces a distinct enumerator instance with its own cursor and version check. Enumerators are not thread-safe; they are lightweight objects designed to be used by a single enumeration context. Step-by-Step Solution: Each thread starts enumeration → it calls GetEnumerator() (implicitly via foreach) → returns a fresh IEnumerator.Therefore, with four simultaneous enumerations, there are four distinct IEnumerator objects.These enumerators are independent; advancing one does not advance the others. Verification / Alternative check: Create a test that calls GetEnumerator() multiple times on the same ArrayList and compare ReferenceEquals among the returned enumerators; each call yields a different object reference. Why Other Options Are Wrong: 1 or 2 or 3 assumes enumerator sharing, which does not occur automatically. “Depends on a project setting” is incorrect; enumerator creation is defined by the framework, not by IDE settings. Common Pitfalls: Mutating the collection while enumerating causes InvalidOperationException because enumerators track the collection version. Also, enumerators are not thread-safe objects; if multiple threads need to enumerate, they should each have their own enumerator or coordinate access. Final Answer: 4

Collection Classes Questions