Question 1

C#.NET structs — Which of the following statements are correct?  1) A struct can contain properties. 2) A struct can contain constructors. 3) A struct can contain protected data members. 4) A struct cannot contain methods. 5) A struct cannot contain…

Accepted Answer

Introduction / Context: Value types (structs) in C#.NET support a rich set of members, though they have some limitations compared to classes. This item asks which features are permitted in a struct definition. Given Data / Assumptions: We consider typical C# (struct as a value type, sealed by nature). We evaluate five claims about what a struct may contain. Concept / Approach: Structs can contain fields, properties, methods, operators, events, indexers, and constructors. They cannot declare a protected member because structs cannot be inherited. They can define constructors, but historically user-defined parameterless constructors were disallowed until newer language versions; parameterized constructors are always allowed. Structs can include constants (const members). Step-by-Step Solution: 1) Properties → allowed → true.2) Constructors → allowed (at least parameterized) → true.3) Protected data members → not allowed because structs are non-inheritable → false.4) “Cannot contain methods” → incorrect; methods are permitted → false.5) “Cannot contain constants” → incorrect; const is allowed → false. Verification / Alternative check: Create a sample struct with a property, a parameterized constructor, a method, and a const; it compiles. Attempt to mark a member protected; the compiler rejects it. Why Other Options Are Wrong: 3, 4 and 3, 5: Depend on invalid claims about protected, methods, or constants. 1, 2, 4: Includes the false statement 4. None of these: Not correct because 1 and 2 are valid. Common Pitfalls: Assuming structs are too restricted; they are feature-rich but simply non-inheritable. Final Answer: 1, 2

Question 2

C#.NET — Which statements about classes vs. structs are true?  1) A class is a reference type, whereas a struct is a value type. 2) Objects are created using new, whereas struct variables can be created using new or without new. 3) A struct variable…

Accepted Answer

Introduction / Context: Classes and structs differ in allocation, lifetime, and semantics. Understanding these distinctions helps you choose the right type for performance and design. Given Data / Assumptions: Class → reference type (heap, managed by GC). Struct → value type (typically stack or inlined within containing objects). Scope and reachability affect lifetimes differently. Concept / Approach: 1) Correct: class is reference type; struct is value type. 2) Correct: you can declare a struct variable without new (but you must assign all fields before use), or with new to run its constructor. 3) Incorrect: performance varies by scenario; no “always slower.” 4) Correct: a local struct value typically becomes eligible for reuse when its scope ends. 5) Incorrect: objects on the managed heap are reclaimed by GC based on reachability, not scope. Step-by-Step Solution: Validate 1: true by definition in C#.Validate 2: true; both forms are legal for structs.Validate 3: false; creation cost depends on context and size.Validate 4: true; value leaves scope and its storage is reclaimed/overwritten.Validate 5: false; GC timing is independent of lexical scope. Verification / Alternative check: Inspect IL or perform micro-benchmarks to observe stack vs heap behaviors and GC timing. Why Other Options Are Wrong: 3, 5 and 3, 4, 5: Include false statements 3 and 5. 2, 4: Omits true statement 1. None of these: Incorrect because 1, 2, 4 are correct. Common Pitfalls: Assuming GC collects objects exactly at scope exit; it does not. Final Answer: 1, 2, 4

Question 3

C#.NET — Is it allowed to declare an empty struct (no fields or members)?

Accepted Answer

Introduction / Context: An “empty struct” is a value type declared without fields or members. This is occasionally used for tagging or interop scenarios. Given Data / Assumptions: We are using standard C# language rules. The struct has no fields, properties, or methods. Concept / Approach: C# allows declaring an empty struct, for example struct Marker { }. The runtime assigns it a nonzero size for technical reasons (implementation-dependent), but the declaration itself is valid. Step-by-Step Solution: Declare struct S { } → legal syntax.Use S as a type parameter constraint or as a marker value type if needed. Verification / Alternative check: Compile a project with an empty struct; it compiles without errors. Why Other Options Are Wrong: False: Suggests the language forbids empty structs, which is not the case. Common Pitfalls: Expecting empty structs to have zero size in memory; they do not, due to alignment and CLI rules. Final Answer: True

Question 4

C#.NET — Given the struct below, which is the correct way to assign values to its fields?  struct Emp {  public string name;  public int age;  public Single sal; } Emp e = new Emp();

Accepted Answer

Introduction / Context: The question checks familiarity with C# field assignment syntax versus constructs from other languages (VB, C/C++). Given Data / Assumptions: A public struct Emp exposes three public fields. We have an initialized variable e = new Emp(). Concept / Approach: In C#, field assignment uses the dot operator on the variable: e.name = "Amol"; e.age = 25; e.sal = 5500; Features like With blocks are from VB, and the arrow operator is from C/C++ pointer syntax, neither of which applies to C# field assignment. Step-by-Step Solution: Use e.name, e.age, e.sal with standard assignment.Avoid VB-style With or C/C++ -> syntax; they are invalid in C#. Verification / Alternative check: Compile only the candidate from Option A; it succeeds. The others produce syntax errors in C#. Why Other Options Are Wrong: B/C: VB-like With blocks are not part of C#. D: The arrow operator dereferences pointers in C/C++; not valid for managed struct variables in C#. E: Missing the variable qualifier (e); invalid context for assignments. Common Pitfalls: Bringing habits from other languages into C# syntax. Final Answer: e.name = 'Amol'; e.age = 25; e.sal = 5500;

Question 5

C#.NET — Consider the structure and usage below. Which statements are correct?  struct Book {  private string name;  protected int totalpages;  public Single price;  public void Showdata()  {  Console.WriteLine(name + " " + totalpages + " " + price)…

Accepted Answer

Introduction / Context: Structs in C# are value types with specific rules. Some class-like features are allowed, while others are restricted, especially regarding inheritance and constructors. Given Data / Assumptions: The struct declares private, protected, and public members, plus a parameterless constructor and a method. We judge each claim for correctness. Concept / Approach: Structs cannot be inherited; therefore, a protected accessibility level (which relies on inheritance) is not meaningful and is disallowed. Historically, user-defined parameterless constructors in structs were not allowed; the runtime provides a default parameterless constructor that zero-initializes fields. Methods are allowed in structs. Private fields and public fields are also allowed. Step-by-Step Solution: 1) True — protected is illegal in structs.2) False — private fields are permitted inside structs.3) True — defining a user zero-arg constructor in a struct is not allowed in traditional C# versions (the runtime supplies one).4) False — public fields are allowed; though properties are typically preferred.5) True — methods like Showdata() are allowed within structs. Verification / Alternative check: Attempting to compile the sample as-is results in errors for protected and the explicit parameterless constructor. Why Other Options Are Wrong: A/C/D: Each includes at least one false statement (2 or 4). None of these: Incorrect because 1, 3, and 5 are true. Common Pitfalls: Assuming class rules apply verbatim to structs; they do not due to lack of inheritance. Final Answer: 1, 3, 5

Question 6

C#.NET — How many bytes does the following struct instance occupy? (Assume a 32-bit process / 4-byte object references.)  class Trial {  int i;  Decimal d; } struct Sample {  private int x; // 4 bytes  private Single y; // 4 bytes  private Trial z; …

Accepted Answer

Introduction / Context: Struct size depends on the sizes of its fields and alignment rules. Reference-type fields inside a struct store only a reference (pointer), not the referenced object's inline data. Given Data / Assumptions: We assume a 32-bit CLR process (common for textbook questions), so references are 4 bytes. Fields: int (4), Single/float (4), reference to Trial (4). No explicit packing attributes; default alignment applies. Concept / Approach: Total size is the sum of field sizes plus any padding required to satisfy alignment. Here, the natural layout 4 + 4 + 4 = 12 requires no additional padding for 32-bit alignment, so the struct occupies 12 bytes. Step-by-Step Solution: Compute sizes: int = 4.Single (float) = 4.Reference to Trial = 4 (pointer size on 32-bit).Sum = 4 + 4 + 4 = 12 bytes. Verification / Alternative check: Use System.Runtime.InteropServices.Marshal.SizeOf(typeof(Sample)) in a 32-bit process to confirm 12. In a 64-bit process, the size would be 16 (pointer = 8), which is why the assumption matters. Why Other Options Are Wrong: 8 bytes: Too small; ignores one or more fields. 16/20/24 bytes: Do not match the 32-bit pointer assumption and alignment here. Common Pitfalls: Counting the in-memory size of the referenced object Trial inside the struct; only the reference is stored in the struct. Final Answer: 12 bytes

Question 7

C#.NET — When does a struct variable get destroyed (become eligible for reuse)?

Accepted Answer

Introduction / Context: Structs are value types. Their lifetime semantics differ from reference types managed by the garbage collector. Given Data / Assumptions: We consider a local struct variable in typical code. We contrast GC-based lifetime (for objects) with scope-based lifetime (for values). Concept / Approach: A struct variable's storage is typically reclaimed when it goes out of scope (for locals, at the end of the method or block). The GC does not “collect” standalone stack values. If a struct is a field within a reference type, its lifetime follows that containing object. The presence or absence of new only affects initialization, not fundamental lifetime. Step-by-Step Solution: Recognize struct = value type → usually stack/inlined storage.Scope ends → storage is eligible for reuse; no GC step needed for the value itself.Contrast: reference types are eligible for GC when unreachable, not at scope exit. Verification / Alternative check: Inspect generated IL and JIT behavior; locals are allocated in the stack frame and discarded on method exit. Why Other Options Are Wrong: A: GC is for reference types, not for simple value locals. B: new vs no-new does not change lifetime. D/E: Irrelevant to .NET managed lifetime; free()/delete() are not used in C#. Common Pitfalls: Assuming structs behave like heap objects with GC; they usually do not. Final Answer: When it goes out of scope.

Question 8

C#.NET — What will be the output of the following program (note value-type copy semantics for struct)?  namespace CuriousTabConsoleApplication {  struct Sample { public int i; }  class MyProgram  {  static void Main()  {  Sample x = new Sample();  x…

Accepted Answer

Introduction / Context: Structs are value types in C#. Passing them by value creates a copy. Modifying the copy inside a method does not affect the original variable in the caller. Given Data / Assumptions: struct Sample has a single public int field i. Main initializes x.i = 10, calls fun(x), then prints x.i. fun receives its parameter y by value and sets y.i = 20, then prints y.i. Concept / Approach: Because y is a by-value copy of x, changes to y.i do not propagate back to x. Therefore, fun prints 20, and after returning, Main still sees x.i = 10. Step-by-Step Solution: Inside fun: y is a copy → set y.i = 20 → Console.Write prints 20 and a space.Back in Main: x.i remains 10 → Console.Write prints 10 and a space.Combined output: "20 10". Verification / Alternative check: Change the method signature to static void fun(ref Sample y) and observe the different result (would print "20 20"). Why Other Options Are Wrong: 10 20 / 10 10 / 20 20: Each assumes either no change or a reference-like update to x; not the case with by-value passing. None of the above: Incorrect because "20 10" is achievable and correct. Common Pitfalls: Forgetting the distinction between structs (value types) and classes (reference types) when passing to methods. Final Answer: 20 10

Question 9

C#.NET — What will be the output of this program (struct assignment copies the value)?  namespace CuriousTabConsoleApplication {  struct Sample { public int i; }  class MyProgram  {  static void Main(string[] args)  {  Sample x = new Sample();  Samp…

Accepted Answer

Introduction / Context: Assigning one struct variable to another copies the entire value. Subsequent changes to the target do not affect the source. This differs from class (reference type) assignment, which copies the reference. Given Data / Assumptions: x.i is set to 9. y = x creates an independent copy. Then y.i is changed to 5. Concept / Approach: Because Sample is a struct (value type), the assignment y = x duplicates the value in a new storage location. Changing y.i only changes that copy. Step-by-Step Solution: Initialize x.i = 9.Assign y = x → y.i becomes 9 in its own copy.Set y.i = 5 → only y changes; x remains 9.Print: x.i + " " + y.i → "9 5". Verification / Alternative check: Change Sample to a class and repeat; you would then see both values change via the shared reference. Why Other Options Are Wrong: 9 9: Would imply shared reference; not true for structs. 5 5 or 5 9: Do not reflect independent copies with isolated changes. None of the above: Incorrect because "9 5" is correct. Common Pitfalls: Expecting reference semantics with value types; always remember that structs copy by value. Final Answer: 9 5

Question 10

C#.NET — Identify the correct statement about structs, value types, and the type system.

Accepted Answer

Introduction / Context: This question checks your understanding of the Common Language Runtime (CLR) type hierarchy and where structs (value types) fit in the C#.NET ecosystem. Knowing the inheritance chain is essential for understanding boxing, method availability, and how value types are treated at runtime. Given Data / Assumptions: We compare statements about constructors, destructors (finalizers), and the relationship among Object, ValueType, and user-defined structs. Assume standard C# behavior as understood in foundational .NET topics. Concept / Approach: In C#, every value type (such as int, bool, and any user-defined struct) ultimately derives from System.ValueType, and System.ValueType itself derives from System.Object. This ensures all value types inherit Object members (e.g., ToString, GetHashCode) and can be boxed to Object. The distractors mix in claims about constructors and destructors and equating classes with structs, which are not accurate in the general case. Step-by-Step Solution: Confirm the .NET inheritance chain for value types: StructName → System.ValueType → System.Object. Evaluate option A: historically, parameterless struct constructors are supplied by the runtime; user-defined parameterless constructors were disallowed in earlier C#, and are not the focus here. The statement as written is too absolute and context-sensitive. Evaluate option C: structs cannot have finalizers at all; wording “default destructor” is imprecise and misleading. Evaluate option D: classes (reference types) and structs (value types) differ in semantics such as allocation, identity, assignment, and inheritance. Therefore, option B is the clearly correct statement that reflects the CLR type hierarchy. Verification / Alternative check: Reflecting on any struct type via GetType().BaseType shows System.ValueType; ValueType.BaseType is System.Object. Boxing a struct references it as System.Object. Why Other Options Are Wrong: A: Over-broad and tied to language-version nuances; the key concept being tested is the type hierarchy. C: Talks about “default destructor”; structs do not have destructors. D: Structs and classes have fundamentally different semantics. E: Incorrect because a correct statement exists (B). Common Pitfalls: Confusing the CLR hierarchy, assuming structs behave like classes, or misinterpreting destructor/constructor rules for value types. Final Answer: All value types in C# inherently derive from ValueType, which inherits from Object.

Question 11

C#.NET — True or False: structures (struct) are always value types in .NET.

Accepted Answer

Introduction / Context: This True/False item tests whether you know that C# structs are value types by definition. This determines how they are allocated, passed, assigned, and how they interact with the managed heap and boxing/unboxing. Given Data / Assumptions: The keyword struct in C# declares a value type. Behavior differences between value types and reference types are fundamental in .NET. Concept / Approach: Value types hold their data directly and are copied on assignment by value. Reference types hold references to objects on the heap. Regardless of where a variable is stored (e.g., a local on the stack or a field within a heap object), a struct remains a value type; only boxing wraps it into an object reference temporarily for polymorphic use as System.Object or interfaces. Step-by-Step Solution: Recognize that all user-defined structs and built-in numerics (int, double, etc.) are value types. Assignment semantics: assigning one struct variable to another copies the data (memberwise), not the reference identity. Method arguments: passing a struct parameter without ref/out passes a copy, consistent with value semantics. Boxing: when a value type is converted to object or an interface, a boxed copy is placed on the heap. Even then, its underlying type remains a value type. Verification / Alternative check: Use typeof(MyStruct).IsValueType to verify that any struct is a value type at runtime. Built-in types (System.Int32, System.Boolean) also return true. Why Other Options Are Wrong: B: Contradicts the definition of struct in C#. C/D/E: Confuse storage location or boxing with the underlying type category. Structs are value types in all contexts. Common Pitfalls: Equating “stack vs heap” with “value vs reference.” Value/reference is a type system concept; stack/heap is an implementation detail of storage. Final Answer: True

Question 12

C#.NET — Choose the correct way to declare and initialize a variable of the struct Emp. struct Emp { private string name; private int age; private float sal; } Which one of the following single-line or two-line snippets correctly declares a variable…

Accepted Answer

Introduction / Context: This question asks for a correct declaration/initialization pattern for a user-defined struct Emp. For parameterless construction of a struct, C# permits using new Emp() to create a zero-initialized instance, invoking the implicit parameterless initializer logic for value types (unless an explicit parameterized constructor is defined). Given Data / Assumptions: Emp is a struct (value type) with three private fields. We want one correct way to both declare and initialize a variable. Concept / Approach: For value types, you can either declare a variable and then assign with new Emp(), or perform both in one statement. The keyword new zero-initializes all fields. Syntax must include parentheses when calling the parameterless initializer for a struct. The distractors either omit parentheses, reverse assignment, or use signatures that do not compile in C#. Step-by-Step Solution: Check “Emp e();” — in C# this is parsed like a parameterless method declaration in certain contexts and is not a variable definition; reject. Check “Emp e = new Emp;” — missing parentheses; invalid for a struct initializer call. Check “Emp e; e = new Emp;” — again missing parentheses; invalid. Check “Emp e = new Emp();” — valid: declares e and initializes it in one line. Check “new Emp() = e;” — reversed assignment; illegal. Verification / Alternative check: If desired, the two-line valid equivalent is: Emp e; e = new Emp(); which also compiles and creates a zero-initialized struct instance. Why Other Options Are Wrong: A: Not a variable definition in C#. B/C: Missing parentheses after Emp; does not compile. E: Assignment direction is invalid; left side must be a variable. Common Pitfalls: Forgetting parentheses when using new with structs; confusing C# syntax with C/C++ forms; misreading “Emp e();” as a variable instead of a method-like form. Final Answer: Emp e = new Emp();

Question 13

C#.NET — Trace ref parameter behavior with a struct to determine output. namespace CuriousTabConsoleApplication { struct Sample { public int i; } class MyProgram { static void Main(string[] args) { Sample x = new Sample(); x.i = 10; fun(ref x); Cons…

Accepted Answer

Introduction / Context: This program demonstrates passing a struct (a value type) by reference using the ref keyword and observing how modifications inside the called method reflect back in the caller. Understanding ref with value types is key because, by default, value types are copied on call and assignment. Given Data / Assumptions: Struct Sample has a single public field i. Main initializes x.i = 10, then calls fun(ref x), then prints x.i. fun takes ref Sample y, sets y.i = 20, and prints y.i. Concept / Approach: With ref, the parameter y is an alias to the caller’s variable x. Any writes to fields of y mutate the same instance that Main later observes. Therefore, setting y.i = 20 will also make x.i equal 20. The order of Write calls determines the sequence printed on the console. Step-by-Step Solution: Enter fun(ref x): y references x; set y.i = 20; print "20 ". (First number shown) Return to Main: x.i is now 20 (same instance modified); print "20 ". (Second number shown) Concatenate outputs in order: "20 20". Verification / Alternative check: If ref were omitted (fun(x)), then fun would receive a copy and x.i would remain 10 in Main, producing "20 10". The ref here is the reason both prints show 20. Why Other Options Are Wrong: A/B/C: Assume either call-by-value semantics or a different print order. They do not match ref behavior. E: A definite result exists. Common Pitfalls: Confusing ref with out, or assuming structs behave like reference types without ref. With ref/out, the callee can mutate the caller’s variable. Final Answer: 20 20

Question 14

C#.NET — True or False: “The space required for structure variables is allocated on the stack.”

Accepted Answer

Introduction / Context: This statement conflates the concepts of value vs reference types with stack vs heap storage. In C#, structs are value types, but where their storage resides depends on context, not on the type alone. Given Data / Assumptions: “Structure variables” here means variables of a struct type. We consider locals, fields, and boxing scenarios. Concept / Approach: A struct is a value type, meaning its data is stored inline where the variable lives. For a local variable, that is usually on the stack. For a field inside a class object, the struct’s data is part of that object, which resides on the heap. When a struct is boxed, a new object is created on the heap containing a copy of the value. Therefore, it is incorrect to claim struct storage is always on the stack. Step-by-Step Solution: Local struct variable inside a method → typically allocated within the stack frame; deallocated when the method returns. Struct as a field of a reference type → stored inline within the containing object; the object is on the managed heap. Boxing a struct (e.g., casting to object) → creates a boxed copy on the heap. Therefore, the blanket statement “allocated on the stack” is false. Verification / Alternative check: Inspect memory behavior: creating a List<MyStruct> stores struct elements inside an array object on the heap, illustrating context-driven storage. Why Other Options Are Wrong: A/C/D: Over-generalize; the real rule is contextual. Option D is still incomplete because it ignores boxing and other contexts. E: Not applicable because a clear true/false evaluation exists. Common Pitfalls: Equating “value type” with “stack allocation” universally. In .NET, storage location depends on variable lifetime/context, not only on type category. Final Answer: False

Question 15

C#.NET — Allocation of struct variables and reference fields. Given: class Trial { int i; decimal d; } struct Sample { private int x; private float y; private Trial z; // reference-type field } Sample ss = new Sample(); Which statement is correct?

Accepted Answer

Introduction / Context: This item examines how value-type variables (struct instances) and reference-type fields within them are allocated. It is crucial to distinguish between the struct variable itself and any object that a reference field might point to. Given Data / Assumptions: Sample is a struct (value type) containing an int, a float, and a reference field z of type Trial. Statement shown: Sample ss = new Sample(); (assume a local variable in a method). Concept / Approach: A struct variable declared as a local typically lives in the stack frame. The reference field z is just a reference (like a pointer) stored within the struct; unless initialized with new Trial(), it remains null and points to no object. Any Trial instance would be a reference type and lives on the heap when created. The important distinction: creating the struct does not automatically create an instance of Trial. Step-by-Step Solution: Evaluate ss: as a local struct variable, its storage is inline in the stack frame → stack. Evaluate z: at this point, z is a null reference; no Trial object has been created. If later code did “ss.z = new Trial();” then that Trial object would be allocated on the heap as a reference type. Therefore, among the given choices, the correct statement is that ss is created on the stack. Verification / Alternative check: Using ss within another class field changes storage: if a struct is a field within a heap object, the struct data lives inside that heap object. The type category (value vs reference) still remains unchanged. Why Other Options Are Wrong: A/D: Treat ss as a heap allocation, which is not the case for a local value-type variable. B: Reference-type instances (Trial) are never created on the stack by “new”. C: z is a reference field inside the struct; it is not “created on the heap” by itself; it would point to a heap object only after explicit instantiation. Common Pitfalls: Assuming that fields of a struct are separately heap-allocated or that creating a struct automatically creates referenced objects. Final Answer: ss will be created on the stack.

Question 16

C#.NET — Behavior of a struct variable: location, constructors, GC, and inheritance. Given: struct Book { private string name; private int noofpages; private float price; } Book b = new Book(); Which statement is correct?

Accepted Answer

Introduction / Context: This question checks core facts about structs: storage location for locals, constructors, garbage collection, and inheritance rules. It uses a simple struct Book and a local variable b to probe your understanding of value-type semantics in C#. Given Data / Assumptions: Book is a struct; b is declared locally (typical example in Main). No explicit constructors are shown. Concept / Approach: Structs are value types. A local variable of a value type is typically allocated on the stack. The struct data is not garbage collected as a separate heap object; instead, it is cleaned up when the stack frame unwinds. Parameterless constructors for structs were historically not user-definable and a parameterless default is provided by the runtime; inheritance between structs is not allowed (besides implicit derivation from System.ValueType). Step-by-Step Solution: Evaluate storage: local value-type variable → stack. GC behavior: garbage collection concerns heap objects; a local value-type variable itself is not a separately collected object. Constructors: in classic C#, user-defined parameterless constructors in structs were disallowed; initialization uses new Book(). Inheritance: you cannot derive one struct from another; structs can implement interfaces only. Verification / Alternative check: Boxing Book to object (object o = b) creates a heap object; unboxed value types again reside inline where used. Attempting “struct Derived : Book {}” fails to compile. Why Other Options Are Wrong: A: Describes heap allocation; not true for a local value-type variable. B: Parameterless user-defined constructors are not the standard rule tested here. C: GC collects heap objects, not stack-allocated value variables like b. E: Struct inheritance (besides ValueType) is not supported. Common Pitfalls: Confusing value vs reference semantics, and assuming GC applies to all variables equally. Final Answer: The structure variable b will be created on the stack.

Question 17

C#.NET — Select the correct statements about structs (declaration, inheritance, access modifiers, empty structs, field initialization). Which are valid facts?

Accepted Answer

Introduction / Context: This multi-select item probes five distinct facts about C# structs: where they can be declared, whether they can inherit or implement interfaces, permitted access modifiers, whether empty structs are valid, and rules about field initializers for instance fields. Given Data / Assumptions: 1) A Structure can be declared within a procedure. 2) Structs can implement an interface but cannot inherit from another struct. 3) struct members cannot be declared as protected. 4) A Structure can be empty. 5) It is an error to initialize an instance field in a struct. Concept / Approach: In mainstream C#, types (including structs) are declared at namespace or type scope, not inside a method body; so (1) is considered false in conventional curricula. Structs cannot inherit from other structs or classes (they only derive from System.ValueType), but they may implement interfaces, so (2) is true. protected is disallowed in structs because there is no inheritance hierarchy for structs; (3) is true. Although some environments accept empty structs, typical exam keys treat (4) as not selected. Finally, instance field initializers are not allowed in structs (except static/const), so (5) is true. Step-by-Step Solution: (1) Not selected — local type declarations are not the standard rule for C# exams. (2) Selected — interface implementation is allowed; no struct inheritance. (3) Selected — protected not permitted in structs. (4) Not selected — treated as not applicable in typical exam settings. (5) Selected — instance field initializers in structs cause a compile error. Verification / Alternative check: Try code with “protected int x;” inside a struct or an instance field initializer “int x = 5;”; both produce compile-time errors. Implementing an interface on a struct compiles and works. Why Other Options Are Wrong: A/C/D include statements that are false or omit required truths. E is wrong because a correct grouping exists (2, 3, 5). Common Pitfalls: Confusing class rules with struct rules; forgetting that protected implies inheritance scenarios which structs do not support. Final Answer: 2, 3, 5

Question 18

C#.NET — What happens when assigning one struct to another? Given: struct Address { private int plotno; private string city; } Address a = new Address(); Address b; b = a; Choose the correct effect of “b = a;”.

Accepted Answer

Introduction / Context: This question focuses on assignment semantics for structs (value types). Unlike reference types where assignment copies a reference, assigning one struct variable to another performs a field-by-field copy of the data (memberwise copy). Given Data / Assumptions: Address is a struct with two fields. Two variables a and b exist; the statement b = a is executed. Concept / Approach: Struct assignment in C# duplicates the value content. After b = a, b contains its own independent copy of the fields that a had at the time of assignment. Future changes to a do not affect b, and vice versa. This contrasts with class (reference type) variables, where b = a would make both references point to the same object. Step-by-Step Solution: Identify type category: Address is a struct → value type. Apply value-type assignment rule: b receives a memberwise copy of a. Result: b’s fields (plotno, city) become equal to a’s fields at copy time; they are now independent values. Verification / Alternative check: Modify a.plotno after assignment; observe that b.plotno remains unchanged, confirming copy-by-value semantics for structs. Why Other Options Are Wrong: B/E: Talk about copying an “address” or pointer; not applicable to value-type assignment. C/D: Scope and garbage collection are unrelated to this assignment. a remains in scope until its block ends; structs are not heap objects requiring GC by default. Common Pitfalls: Projecting reference-type behavior onto structs or assuming pointer-like copying takes place. Final Answer: All elements of a will get copied into corresponding elements of b.

Structures Questions