Question 1

C#.NET — Trace static vs instance calls and method overloading to predict console output. Program: namespace CuriousTabConsoleApplication { class Sample { public static void fun1() { Console.WriteLine("CuriousTab1 method"); } public void fun2() { fu…

Accepted Answer

Introduction / Context: This item checks understanding of static vs instance method calls and overload resolution, along with the exact order of outputs as control flows across fun1, fun2(), and fun2(int). The answer options use abbreviated labels ("Tab1"/"Tab2"). Given Data / Assumptions: fun1() is static and writes a “Tab1 method” line. fun2() calls fun1() then writes “Tab2 method”. fun2(int) writes the integer, then calls fun2(). Main calls Sample.fun1() then s.fun2(123). Concept / Approach: Follow the sequence: a static call, then an overload that prints and invokes the parameterless overload, which in turn invokes the static method and prints again. Keep line order exact. Step-by-Step Solution: Main → Sample.fun1() prints “Tab1 method”. Main → s.fun2(123) prints “123”. fun2(int) → fun2() → calls fun1() again, printing “Tab1 method”. fun2() then prints “Tab2 method”. Verification / Alternative check: Replace WriteLine calls with numbered markers to confirm the order: 1 (Tab1), 2 (123), 3 (Tab1), 4 (Tab2). Why Other Options Are Wrong: B omits the second “Tab1 method”. C/D/E rearrange or omit required lines. Common Pitfalls: Forgetting that fun2(int) delegates to fun2(), which again calls fun1() before writing “Tab2 method”. Final Answer: Tab1 method → 123 → Tab1 method → Tab2 method

Question 2

C#.NET — Static constructor vs static method: determine the order of outputs. Program: namespace CuriousTabConsoleApplication { class Sample { static Sample() { Console.Write("Sample class "); } public static void CuriousTab1() { Console.Write("Curi…

Accepted Answer

Introduction / Context: This question examines when the static constructor runs relative to the first access to a type, compared to the invocation of a static method, and how that affects the order of outputs on the console. Given Data / Assumptions: The class Sample defines a static constructor and a static method CuriousTab1(). Main calls Sample.CuriousTab1(). Both outputs are written with Console.Write (no newline), so the order is visible in a single line. Concept / Approach: In C#, the static constructor executes automatically once, before the first use of the type (first access to any static member). Therefore, referencing Sample.CuriousTab1 triggers the static constructor first, then the static method body runs. Step-by-Step Solution: First type access: before calling CuriousTab1(), the runtime runs static Sample(), writing "Sample class ". Then the static method executes, writing "CuriousTab1 method ". The combined output (ignoring spacing differences in the answer set) corresponds to “Sample class Tab1 method”. Verification / Alternative check: Add another call to Sample.CuriousTab1(); you will see the static constructor does not repeat, confirming it runs only once per AppDomain. Why Other Options Are Wrong: B/C miss one of the two required prints. D reverses the order (incorrect for static constructor semantics). E duplicates the static constructor (it runs only once). Common Pitfalls: Thinking static constructors run at compile time or on every static call; in reality they run once, just before first use of the type. Final Answer: Sample class Tab1 method

Question 3

C#.NET — Can you prevent outside code from creating an instance by using (or controlling) the parameterless constructor?  Give the precise rule used in C# object-oriented design.

Accepted Answer

Introduction / Context: Many C#.NET design scenarios require controlling who can create objects. A common pattern is to restrict or disable public instantiation to enforce factory patterns, singletons, or utility-only classes. The question asks whether this is possible via the parameterless (zero-argument) constructor. Given Data / Assumptions: Class has (or could have) a parameterless constructor. Goal: prevent external code from directly calling new and creating an instance. We are working within standard C# language rules. Concept / Approach: In C#, access modifiers control visibility. A parameterless constructor declared private (or internal) prevents outside callers from instantiating the class directly. Additional design options include marking the class static (which forbids instance construction entirely) or exposing only factory methods while making constructors non-public. Step-by-Step Solution: 1) If you declare private Sample(), code outside the type cannot call new Sample().2) Provide static factory methods (for example, Sample Create(...)) if controlled creation is needed.3) For utility-only types, use static class; this removes all instance constructors and instance members.4) Optionally combine with sealed to prevent subclass creation paths. Verification / Alternative check: Attempt to instantiate from another class with a private parameterless constructor will produce a compile-time error, confirming prevention of external creation. Why Other Options Are Wrong: No: Incorrect because access modifiers on constructors explicitly control instantiation rights. Common Pitfalls: Assuming a public parameterless constructor is required by the runtime. It is not; you can omit it or make it non-public based on design needs. Final Answer: Yes

Question 4

C#.NET constructors — Choose the correct definitions so that both of the following lines compile and create objects:  Sample s1 = new Sample(); Sample s2 = new Sample(9, 5.6f);

Accepted Answer

Introduction / Context: Overloaded constructors allow different initialization paths. Here, code demonstrates constructing Sample both with no arguments and with two arguments. We must pick the constructor declarations that satisfy both calls. Given Data / Assumptions: Two object creations: parameterless and (int, Single). C# syntax and types apply; Single is the same as float. Concept / Approach: To compile both statements, the class must provide: (1) a parameterless constructor, and (2) a constructor that accepts int and Single. Any option that omits either will fail one of the creations. Step-by-Step Solution: Check option A: Defines both Sample() and Sample(int, Single) — satisfies both calls.Option B: Uses a non-C# syntax (Optional keyword is VB-like) — invalid.Option C: Only two-arg constructor present — the new Sample() call fails.Options D/E: Not constructor definitions; they are variable statements. Verification / Alternative check: Compiling with only option A present succeeds for both lines. Removing either constructor causes an overload resolution error. Why Other Options Are Wrong: B: Not valid C# constructor syntax. C: Missing parameterless constructor. D/E: Not constructors at all. Common Pitfalls: Confusing VB optional parameter syntax with C# or forgetting that parameterless creation needs an explicit Sample() if any other constructor is declared. Final Answer: public Sample() { ... } and public Sample(int, Single) { ... }

Question 5

C#.NET — For the class below, which object-creation statements will compile?  class Sample {  int i;  Single j;  double k;  public Sample(int ii, Single jj, double kk)  {  i = ii;  j = jj;  k = kk;  } }

Accepted Answer

Introduction / Context: Constructor overload resolution in C# requires a call signature that exactly matches an available constructor's parameter list. The class provides exactly one constructor taking three parameters: int, Single (float), and double. Given Data / Assumptions: Only constructor is Sample(int, Single, double). No parameterless or 1–2 parameter overloads exist. Concept / Approach: Validate each object creation against the available signature. Literal 1.2f is a float, matching Single. A bare 2.4 is a double by default, matching the third parameter. Step-by-Step Solution: Option A: Needs parameterless constructor — not available.Option B: Needs a one-arg int constructor — not available.Option C: Two-arg call — not available.Option D: Three-arg call with types (int, float, double) — matches declared constructor.Option E: Invalid syntax — commas without arguments are illegal. Verification / Alternative check: Compiling with only the given constructor confirms that only the three-parameter call succeeds. Why Other Options Are Wrong: A/B/C: Missing matching constructor overloads. E: Syntax error. Common Pitfalls: Writing 1.2 without f produces a double, not a float; here we correctly used 1.2f for the Single parameter. Final Answer: Sample s3 = new Sample(10, 1.2f, 2.4);

Question 6

C#.NET — Which statement about constructors is correct?

Accepted Answer

Introduction / Context: Understanding default constructor generation and constructor rules is fundamental in C#. When you omit constructors, the compiler may synthesize one for you. When you define any constructor, this behavior changes. Given Data / Assumptions: Focus is on parameterless constructors and special cases like static constructors and optional parameters. Concept / Approach: If a class declares no instance constructors at all, the C# compiler provides a public parameterless constructor. However, as soon as you declare at least one instance constructor, the compiler does not generate another parameterless one automatically. Static constructors are parameterless by definition and cannot use optional parameters. Optional parameters are allowed on overloaded instance constructors. Step-by-Step Solution: Evaluate A: False — once you provide any constructor, no implicit parameterless constructor is generated.Evaluate B: False — static constructors cannot have parameters (optional or otherwise).Evaluate C: False — overloaded constructors may use optional parameters.Evaluate D: True — with no constructors declared, a default parameterless one is provided. Verification / Alternative check: Compile minimal classes with and without explicit constructors to observe presence or absence of a parameterless constructor. Why Other Options Are Wrong: A: Contradicts the C# rule for default constructor synthesis. B: Violates the definition of static constructors. C: Optional parameters are legal on instance constructors. Common Pitfalls: Expecting the compiler to always generate a parameterless constructor even after custom constructors are added. Final Answer: If we do not provide a constructor, the compiler provides a zero-argument constructor.

Question 7

C#.NET — Is it possible to explicitly invoke the Garbage Collector (GC)?

Accepted Answer

Introduction / Context: The .NET runtime manages memory automatically via a garbage collector. Developers sometimes wonder whether they can force a collection for testing or diagnostics, and what the implications are. Given Data / Assumptions: We are considering explicit APIs versus automatic behavior. We focus on what is possible, not necessarily recommended. Concept / Approach: .NET exposes APIs such as GC.Collect(), GC.GetTotalMemory(...), and GC.WaitForPendingFinalizers(). Calling GC.Collect() requests that the runtime perform a collection across generations, though the GC retains ultimate control. Explicit collection is generally discouraged in production because it can hurt performance and disrupt generational heuristics. Step-by-Step Solution: 1) Recognize that GC.Collect() exists and is callable.2) Understand that it is a request; timing and exact impact are runtime-managed.3) Prefer letting the GC run automatically unless you have a measured scenario (e.g., large object graph release before going idle). Verification / Alternative check: Create a small test harness, allocate objects, call GC.Collect(), and observe memory/free lists via diagnostic tools. Why Other Options Are Wrong: No: Incorrect — the API is present and callable. Common Pitfalls: Misusing explicit collections can increase pause times and degrade throughput; rely on profiling before forcing collections. Final Answer: Yes

Question 8

C#.NET — For methods to be considered overloaded, which aspects must differ? (Select the correct set.)  Consider: Type of arguments; Return type of methods; Number of arguments; Names of methods; Order of arguments.

Accepted Answer

Introduction / Context: Method overloading in C# permits multiple methods with the same name as long as their signatures are distinguishable by the compiler. Knowing what elements constitute the signature avoids ambiguity errors. Given Data / Assumptions: Signature elements include parameter types, count, and order. Return type is not part of the signature for overload resolution. Name must be the same for overloading to occur. Concept / Approach: Two methods are valid overloads when they share the same name but differ by parameter type lists. Differences can arise from type changes, the number of parameters, or their order (when it affects the type sequence). The return type alone cannot distinguish overloads. Step-by-Step Solution: 1) Type of arguments — yes, part of signature.2) Return type — no, not considered for overload resolution.3) Number of arguments — yes, different arity is valid.4) Names of methods — overloading requires the same name, so name differences are not overloading.5) Order of arguments — yes, because it changes the parameter type sequence. Verification / Alternative check: Try compiling pairs that only differ by return type (will fail) versus pairs that differ by parameter lists (will succeed). Why Other Options Are Wrong: A (2,4): Both items do not define overloading. B (3,5): Missing the crucial type dimension (1). D (3,4,5): Includes name changes, which are not overloading. Common Pitfalls: Assuming return type overloading is allowed; it is not in C#. Final Answer: 1, 3, 5

Question 9

C#.NET — Which statements about static methods are correct?

Accepted Answer

Introduction / Context: Static members belong to the type itself rather than to any particular instance. Understanding how to call them and what they can access is a core C# concept. Given Data / Assumptions: We distinguish invocation style and data access rules. We focus on standard C# semantics without unsafe tricks. Concept / Approach: Static methods are called on the type (for example, Math.Abs(…)), not on an instance. A static method cannot access instance fields or properties directly because it lacks a this reference. Static methods are defined within class (or struct) scope just like instance methods. Step-by-Step Solution: Evaluate A: False — static calls do not require (and should not use) an instance.Evaluate B: False — static methods cannot access instance data without an explicit instance reference passed in or obtained elsewhere.Evaluate C: False — static methods are members of a class; they are not “outside” the class.Evaluate D: True — the idiomatic and correct invocation is via the class: TypeName.StaticMethod(). Verification / Alternative check: Attempt to reference an instance field from a static method; the compiler flags an error due to missing instance context. Why Other Options Are Wrong: A: Confuses static with instance invocation. B: Violates access rules for static versus instance context. C: Misstates the scope where static members live. Common Pitfalls: Creating an instance only to call a static method — unnecessary and misleading. Final Answer: Static functions are invoked using class.

Question 10

C#.NET — Analyze static vs instance access in the following code and select the correct statement(s):  class Sample {  static int i;  int j;  public void proc1()  {  i = 11;  j = 22;  }  public static void proc2()  {  i = 1;  j = 2;  }  static Sampl…

Accepted Answer

Introduction / Context: This snippet contrasts instance and static contexts. The class defines a static field i and an instance field j, plus an instance method, a static method, and a static constructor. We must reason about which assignments are legal. Given Data / Assumptions: proc1() is an instance method: it has access to both static and instance members. proc2() is static: it has no implicit instance (this), so it cannot refer to instance fields. Static constructors exist in C# and are parameterless; they run once per type. Concept / Approach: An instance method may freely access static and instance members. A static method may access only static members unless given an explicit instance. Static constructors can access only static members. Step-by-Step Solution: A: False — proc1() can assign to static i.B: True — proc1() can set both i and j.C: False — proc2() cannot reference instance field j without an instance.D: False — static constructors are legal in C#.E: False — same reason as C; proc2() can set i but not j. Verification / Alternative check: Compiling this code will produce errors at the references to j in proc2() and in the static constructor. Why Other Options Are Wrong: A/C/E: Misstate static versus instance access rules. D: Misrepresents C# support for static constructors. Common Pitfalls: Attempting to set instance fields in static contexts or forgetting static constructors cannot reference instance state. Final Answer: proc1() can initialize i as well as j.

Question 11

C#.NET — Which statement is correct regarding constructors and destructors?

Accepted Answer

Introduction / Context: Constructors initialize objects and can enforce design constraints. Destructors (finalizers) in C# are limited and differ from C++ semantics. This question asks you to identify the accurate statement among common misconceptions. Given Data / Assumptions: We consider standard C# behavior (no unsafe or special tooling). “Limit instantiation” includes patterns like private constructors and factory methods. Concept / Approach: Constructors can assign default values to fields and may be made private to restrict creation (e.g., singleton, factory-only). C# does not auto-generate copy constructors; developers can write a constructor that copies fields, but it is not provided by the language automatically. Destructors (finalizers) apply only to classes and there can be at most one per class (no parameters, non-overloadable). Step-by-Step Solution: Option A: True — constructors both initialize and can restrict via access modifiers.Option B: False — no automatic copy constructor exists in C#.Option C: False — structures (value types) cannot have destructors.Option D: False — a class may define at most one destructor (finalizer) with fixed signature. Verification / Alternative check: Inspect C# specification on constructors and finalizers; attempt to add multiple destructors or a struct destructor to observe compiler errors. Why Other Options Are Wrong: B: Confuses C# with C++ semantics. C: Structs cannot declare destructors. D: Only one destructor allowed and it has no parameters. Common Pitfalls: Assuming finalizers behave like C++ destructors or that copy constructors are auto-generated in C#. Final Answer: A constructor can be used to set default values and limit instantiation.

Question 12

C#.NET overloading — What is wrong with the following code and which statement is correct?  namespace CuriousTabConsoleApplication {  class Sample  {  public int func()  {  return 1;  }  public Single func()  {  return 2.4f;  }  }  class Program  { …

Accepted Answer

Introduction / Context: In C#, method overloading is based on the method signature, which includes the method name and parameter list, but excludes the return type. This example attempts to define two methods that differ only by return type. Given Data / Assumptions: Both methods are named func and take no parameters. One returns int and the other returns Single. Main attempts to call both. Concept / Approach: Because the parameter lists are identical (empty) and names are the same, the two declarations collide. The compiler cannot choose an overload based solely on the expected return type at a call site; therefore, this code does not compile. Legal overloading would require distinct parameter lists. Step-by-Step Solution: 1) Compare signatures: name + parameters are identical — not allowed.2) Observe that return type is ignored for overload resolution.3) Conclude that the code is a compile-time error; neither call is valid as written. Verification / Alternative check: Attempting to compile yields a method with the same name and signature error. Changing one method to func(int x) or similar resolves it. Why Other Options Are Wrong: A: Incorrect — this is not valid overloading. B: Incorrect — functions can be overloaded; the rule applies equally to methods with return values. D/E: These presume the program compiles; it does not in this form. Common Pitfalls: Thinking the compiler can pick an overload from the assignment target's type; C# does not allow overloading by return type alone. Final Answer: Return type cannot be used to distinguish overloaded methods; the code does not compile.

Question 13

C#.NET — Which statement about constructors is correct?

Accepted Answer

Introduction / Context: Constructors in C#.NET initialize objects and set up type-level state. In addition to ordinary instance constructors, the language also supports a special kind called a static constructor, which runs once per type to initialize static members. Given Data / Assumptions: The question compares several claims about what constructors can and cannot do. We must choose the single correct statement among common misconceptions. Concept / Approach: There are two broad constructor categories in C#: instance constructors (can be overloaded, can be private/protected/internal/public) and static constructors (no parameters, no access modifiers, run automatically once, and initialize static data). An instance constructor executes with an implicit this reference and can read/write both instance and static members. Static constructors have no this and can touch only static state. Step-by-Step Solution: Check A: False — instance constructors may be private (singletons/factory patterns).Check B: False — constructors can be overloaded by parameter lists.Check C: True — static constructors are valid and common for type initialization.Check D: False — instance constructors can access static data.Check E: False — instance constructors do receive this; it refers to the object under construction. Verification / Alternative check: Compile a class with a private constructor (compiles) and with multiple overloads (compiles). Add a static constructor to set static fields (compiles and runs once at first use). Why Other Options Are Wrong: A: Private constructors are legal and commonly used. B: Overloading is fully supported. D: Instance constructors can set static fields. E: this exists in instance constructors; only static constructors lack it. Common Pitfalls: Confusing static constructors (type initialization) with instance constructors (object initialization). Final Answer: A constructor can be a static constructor.

Question 14

C#.NET — Can a static method access instance data directly?

Accepted Answer

Introduction / Context: Understanding the difference between static and instance context is essential in C#. Static methods belong to the type itself, whereas instance members belong to specific objects. Given Data / Assumptions: Static methods do not have an implicit this. Instance fields/properties require an instance to reference. Concept / Approach: A static method cannot directly access instance data because it lacks a particular object. It may only reach instance data if an instance reference is provided as a parameter or obtained in some other explicit way. Step-by-Step Solution: 1) Static method context → no this.2) Instance field requires object reference.3) Therefore, direct access is not allowed; only static members are accessible without an instance. Verification / Alternative check: Try compiling a static method that reads an instance field without an instance; the compiler errors. Why Other Options Are Wrong: Yes: Would require an implicit instance, which static methods do not have. Common Pitfalls: Calling a static method through a variable of the class type and assuming that gives it instance access — it does not. Final Answer: No

Question 15

C#.NET — During the lifetime of a single object, how many times can its constructor run?

Accepted Answer

Introduction / Context: A constructor initializes a new object immediately after memory is allocated. The semantics guarantee predictable, one-time setup for that instance. Given Data / Assumptions: An object is created with new, which allocates memory and then calls the constructor. We are talking about one specific instance's lifetime. Concept / Approach: The constructor executes exactly once per instance, at construction time. You cannot re-run the constructor on an already created object. Re-initialization requires a separate method or creating a new instance. Step-by-Step Solution: Allocation → constructor runs exactly once → object becomes usable.There is no supported way to re-invoke the constructor on the same instance. Verification / Alternative check: Experiment by trying to call the constructor like an ordinary method on an existing instance; this is not allowed. Why Other Options Are Wrong: A/D/E: Misunderstand life-cycle; constructor is not a repeatable routine on the same object. C: No such project setting changes constructor semantics. Common Pitfalls: Assuming a constructor can serve as a reset method; write an explicit Reset() if needed. Final Answer: Only once.

Question 16

C#.NET — Identify the correct statements about constructors:

Accepted Answer

Introduction / Context: Constructors define how objects are initialized. Several myths persist about their capabilities and responsibilities. Given Data / Assumptions: We evaluate five claims, selecting the set that is fully correct. Concept / Approach: In C#, a constructor's name matches the class name, it does not return a value (no return type), and it is not called like a normal method by user code; rather, it runs automatically during new or is chained via this(...) / base(...). Memory allocation is performed by the runtime before the constructor runs; the constructor initializes the already allocated object. Step-by-Step Solution: Statement 1: False — constructors can be overloaded.Statement 2: True — name equals class name.Statement 3: True — invoked by construction/chaining, not as an ordinary call.Statement 4: True — constructors have no return type.Statement 5: False — allocation precedes constructor execution; constructors do not allocate. Verification / Alternative check: Check the C# spec and observe that adding different parameter lists is legal and that constructors have no return type. Why Other Options Are Wrong: A/C/D: Each includes at least one false statement (1 or 5). E: Not applicable because there is a correct set (2, 3, 4). Common Pitfalls: Attributing memory allocation to constructors rather than to the runtime allocator. Final Answer: 2, 3, 4

Question 17

C#.NET — Which statement about the garbage collector (GC) is correct?

Accepted Answer

Introduction / Context: The .NET GC manages each process's managed heap, automatically reclaiming memory for objects that are no longer reachable. Understanding its scope and triggers is key to writing efficient managed code. Given Data / Assumptions: We are discussing GC behavior at the process level. Reachability, not reference count, determines collection. Concept / Approach: Each managed process hosts its own garbage collector instance responsible for that process's heaps. Objects are eligible for collection when they are unreachable (no live roots). The GC runs automatically based on allocation pressure and heuristics; manual invocation via GC.Collect() is possible but usually discouraged. Step-by-Step Solution: A: Correct — GC scope is per managed process/app domain runtime environment.B: Incorrect — there is no single global GC for all processes.C: Incorrect — reachability matters, not the number of references; a single live reference keeps the object alive.D: Incorrect — GC does not require manual runs after IDE operations. Verification / Alternative check: Review runtime architecture: each process's CLR hosts GC and heaps; task manager shows independent processes with independent heaps. Why Other Options Are Wrong: B: Contradicts process isolation. C: Confuses reference counting with tracing GC. D: Unrelated to application lifecycle. Common Pitfalls: Assuming GC uses reference counting like COM; .NET uses tracing and generations. Final Answer: There is one garbage collector per program (managed process).

Question 18

C#.NET — Which statements about static methods are correct?

Accepted Answer

Introduction / Context: Static members are associated with the type, not any particular object instance. This affects what they can access and how they are invoked. Given Data / Assumptions: We assess five statements about accessibility and invocation. Concept / Approach: A static method lacks a this reference; therefore, it cannot touch instance fields or call instance methods unless given an explicit instance. Conversely, instance methods run with this and can freely call static methods or read static fields. Static data is zero-initialized by the runtime, so explicit initialization is not strictly necessary. Step-by-Step Solution: 1) True — only static data is directly available to static methods.2) True — cannot call instance methods without an instance.3) False — static fields have default initialization; explicit initialization is optional.4) True — instance methods can access static members.5) False — no this in static methods. Verification / Alternative check: Compile code that references instance members from a static method; you will get compile-time errors unless you use an instance variable. Why Other Options Are Wrong: B/C/D: Each includes at least one false item (3 or 5). E: Not applicable; there is a correct set (1, 2, 4). Common Pitfalls: Believing static members must be explicitly initialized; the CLR provides default values. Final Answer: 1, 2, 4

Constructors Questions