Question 1

Instance fields, instance methods, and accessibility in C# — consider the code and choose the correct statements.  namespace CuriousTabConsoleApplication {  class Sample  {  public int index;  public int[] arr = new int[10];  public void fun(int i, …

Accepted Answer

Introduction / Context: This scenario distinguishes between instance members and static members in C#. It also touches on accessibility of fields and arrays declared as public. Given Data / Assumptions: index is a public instance field. arr is a public instance array field of length 10. fun(int i, int val) is an instance method (non-static) that writes into the array. Concept / Approach: Instance members must be accessed through an instance (object). Static members are accessed via the type name. Public accessibility allows direct access, but that does not change instance vs. static binding rules. Step-by-Step Solution: Statement 1) is false: s.index = 20 is valid because index is public (no error).Statement 2) is true: s.fun(1, 5) correctly assigns arr[1] = 5 on the same instance.Statement 3) is false: Sample.fun(1, 5) attempts to call an instance method as if it were static; it will not compile and therefore cannot set anything.Statement 4) is true: the call cannot work since fun() is not static.Statement 5) ('arr cannot be public') is false: arrays can be public fields, though encapsulation best practices discourage it. Verification / Alternative check: Attempt to compile Sample.fun(1, 5); the compiler reports that an object reference is required for the non-static field, method, or property. Why Other Options Are Wrong: They include false statements (1, 3, 5) or omit the valid statement 2. Common Pitfalls: Confusing 'public' with 'static'; public only controls accessibility, not whether a member belongs to the instance or the type. Final Answer: 2) The call s.fun(1, 5) will work correctly. 4) The call Sample.fun(1, 5) cannot work since fun() is not static.

Question 2

C#.NET — Default accessibility of class members and intra-class access rules. Which of the following statements are correct?  Data members of a class are by default public.  Data members of a class are by default private.  Member functions (methods)…

Accepted Answer

Introduction / Context: This question checks your understanding of C#.NET's default accessibility for class members (fields and methods) and how access modifiers behave within the same class. Many beginners assume methods default to public, but in C# the default for class members is private unless specified. Given Data / Assumptions: We are considering class members declared without any explicit access modifier. We are dealing with top-level classes in C# (not nested types with different rules). Concept / Approach: In C#, members of a class (fields, methods, properties) default to private. Access modifiers govern visibility outside the class, but inside the same class, all members can call each other regardless of each one’s modifier. Thus a private method can invoke a public method of the same class (and vice versa). Step-by-Step Solution: Evaluate (1): False. Class fields are not public by default; they are private.Evaluate (2): True. Data members default to private.Evaluate (3): False. Methods are also private by default.Evaluate (4): True. Within a class, any member can access any other member because access checks are about outside visibility.Evaluate (5): True. Member functions default to private if no modifier is given. Verification / Alternative check: Create a class with a field int x; and method void M() { } without modifiers and inspect with IntelliSense or compile-time visibility—both are private. Why Other Options Are Wrong: Any option including (1) or (3) is incorrect because they claim a default of public, which is not how C# works. Common Pitfalls: Transferring assumptions from languages where defaults differ; forgetting that properties and methods also default to private in classes. Final Answer: 2, 4, 5

Question 3

Programming paradigms — pick the correct statement. Which statement is accurate about Object-Oriented Programming (OOP), structured programming, and C#.NET?

Accepted Answer

Introduction / Context: This conceptual question distinguishes procedural/structured programming from Object-Oriented Programming (OOP), and clarifies how C#.NET is positioned in these paradigms. Given Data / Assumptions: Structured programming uses sequence/selection/iteration to organize code. Procedural programming focuses on procedures (functions) operating on data. OOP organizes code around data (objects) and the operations that act on that data (methods). Concept / Approach: OOP emphasizes encapsulation of both state (data) and behavior (methods). A hallmark summary is that OOP gives equal importance to data and the operations that manipulate it, unlike purely procedural approaches which prioritize procedures. Step-by-Step Solution: Check (a): Misleading. Structured programming is generally considered a subset/discipline within procedural programming; saying they are simply “different” is not precise for this context.Check (b): Describes procedural decomposition, not OOP; so incorrect for OOP.Check (c): Classes/objects are pillars of OOP, not structured programming; incorrect.Check (d): Correct — OOP balances data and methods via encapsulation.Check (e): C# is an object-oriented language (though it supports structured constructs); labeling it purely “structured” is inaccurate. Verification / Alternative check: Look at C# designs: classes, inheritance, interfaces, and encapsulation demonstrate OOP characteristics. Why Other Options Are Wrong: (a) oversimplifies relationships; (b) is procedural; (c) misattributes OOP concepts; (e) mislabels C#’s paradigm. Common Pitfalls: Confusing “structured” with “object-oriented”; many modern languages support both structured control flow and OOP. Final Answer: Object-Oriented Programming paradigm gives equal importance to data and the procedures that work on the data.

Question 4

C#.NET value types, new, and ToString(): analyze this snippet. int i; int j = new int(); i = 10; j = 20; string str; str = i.ToString(); str = j.ToString(); Which statement best describes this code?

Accepted Answer

Introduction / Context: This question evaluates understanding of value types, initialization, and method availability in C#. It specifically probes whether new can be used with value types, and whether methods like ToString() are available on them. Given Data / Assumptions: int is a value type (System.Int32). new int() zero-initializes an int value. ToString() is defined for all types via System.Object and overridden by System.Int32. Concept / Approach: Using new with a value type creates a zero-initialized value of that type (it does not allocate on the heap by itself in local scope). Value types still have methods (because they are structs that ultimately derive from System.ValueType and System.Object). Step-by-Step Solution: new int() is valid and yields 0 initially; here it is then assigned 20.i and j are local variables; storage is typically on the stack for locals (implementation detail). Both are value types.ToString() calls on i and j are valid and return string representations of the numbers. Verification / Alternative check: Compile and run; it succeeds and str will become "10" then "20". Why Other Options Are Wrong: (b) is false: new can be used with value types. (c) is false: value types expose methods. (d) and (e) mischaracterize allocation; locals of value types are not heap objects simply because of new. Common Pitfalls: Equating “primitive” with “no methods” (not true in C#), and assuming new always implies heap allocation for locals. Final Answer: This is a perfectly workable code snippet.

Question 5

C#.NET — Does the this reference exist for instance (non-static) method calls?

Accepted Answer

Introduction / Context: The keyword this refers to the current instance in an instance (non-static) method. Understanding when this exists is crucial to reasoning about members and overload resolution. Given Data / Assumptions: “Non-shared” means non-static (instance) in C# terminology. Static (shared) methods do not have an instance and thus no this. Concept / Approach: When an instance method is invoked, the runtime passes a hidden reference to the target object as this, enabling access to instance fields, properties, and other methods. Step-by-Step Solution: Call an instance method: obj.Member(). A hidden argument is the reference to obj, available inside as this.In static methods, no this is available because there is no specific instance bound. Verification / Alternative check: Inside a static method, referencing this produces a compile-time error; inside an instance method, this compiles and works. Why Other Options Are Wrong: False would contradict the C# object model for instance methods. Common Pitfalls: Confusing static context (no this) with instance context (has this). Final Answer: True

Question 6

C#.NET — Understanding this and instance identity in method calls. Consider: namespace CuriousTabConsoleApplication { class Sample { int i, j; public void SetData(int ii, int jj) { this.i = ii; this.j = jj; } } class MyProgram { static void Main(str…

Accepted Answer

Introduction / Context: This item examines how the this reference represents the current instance and how parameter names can shadow field names. It also clarifies that you can use this explicitly to disambiguate fields from parameters. Given Data / Assumptions: Two instances: s1 and s2. SetData uses parameters ii and jj and writes to fields i and j via this. We corrected a missing semicolon to make the sample valid. Concept / Approach: this always refers to the instance on which the method is invoked. For s1.SetData(...), this is s1; for s2.SetData(...), this is s2. You do not pass this explicitly; the compiler and runtime supply it automatically. Step-by-Step Solution: Option (a): False — explicitly using this is allowed and common when disambiguating.Option (b): False — here parameters (ii, jj) differ from fields (i, j); this is not strictly required (i = ii; j = jj; also works), but using this is clear.Option (c): False — you never pass this manually in C# instance calls.Option (d): False — methods don’t “collect” this explicitly; it is implicit.Option (e): True — on s1 call, this is s1; on s2 call, this is s2. Verification / Alternative check: Log ReferenceEquals(this, s1) inside the first call and ReferenceEquals(this, s2) in the second; they evaluate to true respectively. Why Other Options Are Wrong: They misunderstand the role and lifetime of this or imply manual passing which C# does not require. Common Pitfalls: Thinking this must be passed or that it is constant across calls. It always points to the current receiver. Final Answer: Contents of this will be different during each call to SetData().

Question 7

C#.NET — Identify valid ways to create an object of class Sample. Consider the following possibilities:  Sample s = new Sample();  Sample s;  Sample s; s = new Sample();  s = new Sample(); Which options correctly create an object?

Accepted Answer

Introduction / Context: Creating objects in C#.NET requires instantiation with new. This problem distinguishes between merely declaring a reference and actually creating an instance. Given Data / Assumptions: Sample is a reference type (class). We compare declaration vs instantiation. Concept / Approach: A declaration like Sample s; creates only a reference variable (initialized to null if it is a field, uninitialized if local). An object is created only when new Sample() is executed. You can create and assign in one step or two steps. Step-by-Step Solution: (1) Valid: both declares and instantiates.(2) Only declares a reference; no object created.(3) Valid: declare first, then instantiate and assign.(4) Invalid alone: s must be declared before assignment. Verification / Alternative check: Attempt to access s after (2) without instantiation raises NullReferenceException if used; after (1) or (3) you have a real object. Why Other Options Are Wrong: They include cases that do not create an object or that use an undeclared identifier. Common Pitfalls: Assuming declaration implies construction; in C# these are distinct steps (though they can be combined). Final Answer: 1, 3

Question 8

C#.NET — Access modifiers and member access within a class. Given: class Sample { private int i; public float j; private void DisplayData() { Console.WriteLine(i + " " + j); } public void ShowData() { Console.WriteLine(i + " " + j); } } Which statem…

Accepted Answer

Introduction / Context: This problem verifies understanding of access modifiers and intra-class accessibility in C#. It checks whether private and public members can coexist and whether methods can access fields with different access levels. Given Data / Assumptions: Field i is private; field j is public. DisplayData() is private; ShowData() is public. Concept / Approach: Inside the same class, all members (regardless of their own access modifier) can access each other. Access modifiers only restrict visibility from outside the class (or from derived classes/assemblies depending on modifier), not within it. Step-by-Step Solution: Private field i and public field j are both legal.A private method DisplayData() is legal and can access both i and j.A public method ShowData() is legal and can also access both i and j.Therefore, the class compiles and runs without errors. Verification / Alternative check: Instantiate Sample and call ShowData(); you will see output containing both i (default 0) and j (default 0) unless set elsewhere. Why Other Options Are Wrong: (a) and (b) are false restrictions; (c) and (d) misinterpret intra-class access rules. Common Pitfalls: Believing a private method cannot access public members, or vice versa. Inside a class, access is unrestricted among members. Final Answer: There is no error in this class.

Question 9

C#.NET — Objects, instance data, and shared behavior: choose the correct statements about a user-defined class Sample. Statements:  All objects of Sample will always have exactly the same data.  Objects of Sample may have the same or different data.…

Accepted Answer

Introduction / Context: This question targets the fundamentals of object instances in C#. Objects have state (fields) and behavior (methods). States vary per instance; behavior is defined once in the type and is callable on each instance. Given Data / Assumptions: Sample is a class (reference type). We distinguish per-object state from class-defined behavior. Concept / Approach: Each object holds its own copy of instance fields, so two objects can hold different values. Methods are defined on the type and are invoked with a this reference; conceptually each object “has” those behaviors, though the implementation is a single method body shared by all instances. Step-by-Step Solution: (1) False — objects can have different field values.(2) True — they may be same or different depending on assignments.(3) False — not controlled by IDE settings.(4) True — conceptually, every object exposes instance behavior and owns its own data.(5) Implementation detail: yes, method code is shared, but the better paired truth here is (2) and (4) as per conceptual MCQ framing. Verification / Alternative check: Create two Sample objects, set different field values; methods act on each object’s this. Why Other Options Are Wrong: (1) and (3) are plainly incorrect; (5) alone without (2) omits the crucial property of per-object data. Common Pitfalls: Confusing the single method implementation with per-object behavior; the important takeaway is that objects don’t share instance data. Final Answer: 2, 4

Question 10

C#.NET — What actually happens in: sample c; c = new sample(); Choose the correct interpretation.

Accepted Answer

Introduction / Context: This examines reference vs object allocation in C#. For classes (reference types), variables hold references; the new operator allocates an instance (object) on the managed heap. Given Data / Assumptions: sample is a class type. c is a local variable (stored as a reference). Concept / Approach: In c = new sample(); the expression new sample() creates a new object; the object itself does not have an identifier (name) — only the reference variable c has a name. Hence it is sometimes described as creating a “nameless” object and storing its reference in c. The object lives on the managed heap; c is a reference (typically on the stack if local). Step-by-Step Solution: Declaration: sample c; → declares a reference variable c.Instantiation: new sample(); → allocates a new object on the heap.Assignment: c = (that object reference). Verification / Alternative check: Printing ReferenceEquals(c, null) after assignment returns false; GC can collect the object if no references remain. Why Other Options Are Wrong: (a) implies the object gets the name sample; in fact, sample is the type name, not the object name. (c) and (e) are wrong because class objects are allocated on the managed heap in C#. Common Pitfalls: Thinking objects of reference types can be stack-allocated by size or that the object itself has an identifier beyond its reference(s). Final Answer: 2, 4

Question 11

C#.NET — Trace the output of this instance-method call. namespace CuriousTabConsoleApplication { class Sample { int i; float j; public void SetData(int i, float j) { this.i = i; this.j = j; } public void Display() { Console.WriteLine(i + " " + j); }…

Accepted Answer

Introduction / Context: This question reinforces understanding of instance fields, the this reference, and default numeric formatting when writing to the console in C#. Given Data / Assumptions: Fields: int i; float j; SetData assigns i = 36, j = 5.4f via this. Display prints i and j separated by a space. Concept / Approach: After SetData, the object s1 holds i = 36 and j = 5.4. Console.WriteLine concatenates numeric to string via ToString(); float.ToString() with default format usually prints a minimal precise representation like 5.4 (culture permitting), not 5.400000. Step-by-Step Solution: Call s1.SetData(36, 5.4f) → fields set.Call s1.Display() → writes i + " " + j → "36 5.4". Verification / Alternative check: Run the exact code in a default console app; you will see 36 5.4. If you require fixed decimals, you would use j.ToString("F6"). Why Other Options Are Wrong: (a) prints defaults which do not apply after SetData. (c) shows six decimals which is not the default. (d) truncates the float which doesn’t happen automatically. Common Pitfalls: Assuming float prints with six decimals by default (that is a formatting choice, not the default behavior). Final Answer: 36 5.4

Question 12

Fundamentals of classes and objects in C#.NET: which statement is correct?  Consider how classes (reference types) and their objects are created and stored in memory in C#. Choose the most accurate statement about classes/objects and their allocatio…

Accepted Answer

Introduction / Context: This question checks core understanding of how C#.NET treats classes (reference types) and where their instances are allocated. In .NET, class instances are created with new and live on the managed heap, where the garbage collector tracks them. Distinguishing heap vs. stack, and reference vs. value types, is essential for performance, lifetime, and semantics. Given Data / Assumptions: A “class” in C# is a reference type. Objects created from classes are allocated on the managed heap. The stack typically holds local variables, parameters, and references (not the object's data for class instances). Concept / Approach: When you write MyClass obj = new MyClass(); the variable obj (a reference) may be stored on the stack (if local), but the object data resides on the heap. This applies regardless of the object’s size. Value types (e.g., int, struct) can be stored inline (e.g., on the stack for locals), but classes do not behave that way. Therefore, any statement implying class objects live on the stack is incorrect. Step-by-Step Solution: Evaluate A: “Class is a value type.” → False; class is a reference type.Evaluate B: “Objects … created on the stack.” → False for class objects; they are heap-allocated.Evaluate C: “Objects of smaller size are created on the heap.” → True; in fact, all class objects are heap-allocated; saying “smaller … are on the heap” is still correct.Evaluate D: “Smaller objects on the stack can be named.” → False for class objects; naming refers to variable identifiers, not where the object lives.Evaluate E: “Objects are always nameless.” → Misleading/false; variables reference them and can be named; objects themselves need not have names, but the claim is not a correct statement about allocation. Verification / Alternative check: Inspect IL or use a memory profiler: class instances are heap objects and collected by the GC. Local references are small handles pointing to heap instances. Why Other Options Are Wrong: They either misclassify types (A), confuse stack with heap (B, D), or make a vague generalization (E) not tied to C# allocation rules. Common Pitfalls: Assuming object size changes allocation location; confusing variable (reference) location with object data location. Final Answer: Objects of smaller size are created on the heap.

Question 13

C#.NET object creation semantics: given  class Student s1, s2; // Student is a user-defined class s1 = new Student(); s2 = new Student();  Which statement best describes what is true about s1 and s2 and the created objects?

Accepted Answer

Introduction / Context: The snippet creates two separate instances of the class Student. Understanding what variables s1 and s2 hold, how objects are allocated, and what default state two new instances have is central to object-oriented programming in C#. Given Data / Assumptions: s1 and s2 are variables of reference type Student. Each call to new Student() constructs a fresh object on the managed heap. No fields are explicitly assigned after construction. Concept / Approach: Each new Student() call returns a reference to a distinct object. If the default constructor does not set different values, both newly created objects will start with the same default field values (e.g., 0, null, false), hence the contents (field values) match initially, though the references (addresses) differ. Step-by-Step Solution: s1 and s2 are distinct references → s1 != s2.s1 and s2 each point to a separate Student object.With no custom initialization differences, the objects’ fields hold identical default values → “contents … exactly same.” Verification / Alternative check: Print ReferenceEquals(s1, s2) → false. Compare default field values on both instances → equal (unless randomized initialization is coded). Why Other Options Are Wrong: A: “Contents of s1 and s2” may be read as the references themselves (addresses), which are not the same. B: Class objects are allocated on the heap, not the stack. D: The CLR does not guarantee adjacency of object allocations. E: .NET uses garbage collection; delete() is not used. Common Pitfalls: Confusing variable identity (reference) with object state; assuming deterministic adjacency of allocations; thinking manual deletion is required in .NET. Final Answer: Contents of the two objects created will be exactly same.

Question 14

Core facts about classes and objects in C#: select the correct statements.  1) Instance members of a class can be accessed only through an object of that class. 2) A class can contain only instance data and instance member functions. 3) All objects …

Accepted Answer

Introduction / Context: This item checks basic OO knowledge in C#. It tests how instance members are accessed, what a class can contain, object layout, access modifiers, and the conceptual role of a class. Given Data / Assumptions: Standard C# semantics for instance vs. static members. Typical class instances have fixed layout determined by the class definition. “Friend” corresponds to VB’s keyword (internal in C#), but the option's phrasing is ambiguous. Concept / Approach: (1) True: Outside the class, you access instance members via an instance reference; inside, you use this (still an object). (2) False: classes can also have static members. (3) True: instances of the same class share the same layout, so each object of that class occupies the same number of bytes (ignoring runtime headers and GC internals which are uniform). (4) As written, “Friend functions” is a VB term; in C#, the equivalent is internal. The statement is not accurate in C# context. (5) True: class as blueprint/template is a standard definition. Step-by-Step Solution: Select 1, 3, and 5.Exclude 2 and 4 based on the reasons above. Verification / Alternative check: Review the C# language specification for member access and type members; instance size comes from the class’s field composition. Why Other Options Are Wrong: They include statement 2 or 4 which are not correct as stated. Common Pitfalls: Confusing C# keywords with VB’s; forgetting that static members exist and are not tied to instances. Final Answer: 1, 3, 5

Question 15

The this reference in C#: which statements are correct?  1) this can be modified inside an instance member. 2) Static functions never receive this. 3) Instance member functions always receive this. 4) this continues to exist after control returns fr…

Accepted Answer

Introduction / Context: The implicit parameter this is fundamental to how instance methods operate on the current object in C#. Understanding when it exists and how it is passed helps avoid confusion between instance and static semantics. Given Data / Assumptions: We consider ordinary classes (not ref structs with in-parameters). Normal C# calling conventions apply. Concept / Approach: Instance methods receive an implicit this reference to the current object. Static methods are not tied to an instance, so no this is involved. The caller does not pass this explicitly; it is supplied by the compiler. The this reference is not a persistent entity that “continues to exist” after the call—it is just a parameter within the call frame. You cannot “reassign” this. Step-by-Step Solution: (1) False: this cannot be reassigned.(2) True: static methods have no this.(3) True: all instance methods receive this.(4) False: this is not something that persists beyond the method invocation context.(5) True: the compiler passes it implicitly when you call an instance method. Verification / Alternative check: Inspect IL of a simple instance vs. static method; the instance method has an implicit first parameter (this). Why Other Options Are Wrong: They rely on (1) or (4), which are misconceptions about mutability and lifetime of this. Common Pitfalls: Thinking this is like a global variable or reassignable pointer; confusing instance calls with static calls. Final Answer: 2, 3, 5

Question 16

Predict the output (parameter shadowing):  namespace CuriousTabConsoleApplication {  class Sample  {  int i;  Single j;  public void SetData(int i, Single j)  {  i = i;  j = j;  }  public void Display()  {  Console.WriteLine(i + " " + j);  }  }  cla…

Accepted Answer

Introduction / Context: This program demonstrates parameter shadowing of instance fields by method parameters with identical names. Without qualifying with this, assignments affect only parameters, not fields, leading to unchanged instance state. Given Data / Assumptions: Fields: i (int), j (Single) default to 0. Method parameters: int i, Single j shadow the fields. SetData assigns i = i and j = j without this. Concept / Approach: Inside SetData, the identifiers i and j refer to the parameters, not the fields. Therefore, i = i and j = j are self-assignments on the parameters. To assign to fields, you must write this.i = i; and this.j = j; Step-by-Step Solution: Initial field values: i = 0, j = 0.0f.Call SetData(10, 5.4f) → parameters receive values 10 and 5.4f.Assignments affect parameters only; fields remain 0 and 0.0f.Display prints the fields → “0 0”. Verification / Alternative check: Modify SetData to use this.i and this.j, re-run, and observe “10 5.4”. Why Other Options Are Wrong: They assume the fields changed, which they did not due to shadowing. Common Pitfalls: Naming parameters the same as fields without using this; misunderstanding variable scope. Final Answer: 0 0

Classes and Objects Questions