Why is it not possible to declare a non-sealed or abstract enum, struct, or delegate?

This is a discussion on Why is it not possible to declare a non-sealed or abstract enum, struct, or delegate? within the C# Programming forums, part of the General Programming Boards category; As many of us know, the System.Type type defined in the System namespace as well as the types defined in ...

  1. #1
    Registered User
    Join Date
    Sep 2011
    Posts
    71

    Why is it not possible to declare a non-sealed or abstract enum, struct, or delegate?

    As many of us know, the System.Type type defined in the System namespace as well as the types defined in the System.Reflection namespace make it possible to easily search for abstract types of different variety of types, such as structs, enums, classes, etc.

    With that in mind, I was using reflection the other day and 'discovered' that in the framework class library there are several abstract structs. Some of them most of us have never heard of and will never be able to directly access, because they are not public. For example, System.EnterpriseServices.Thunk.IServiceCall. The name of this type gives it away as an interface, but according to reflection it is a struct, and it is also sealed, meaning that it's probably not an interface, since being sealed, unless I'm mistaken, would sort of kill the raison d’Ítre of an interface.

    Also, if you are using a .Net 3.5, you might have noticed that the type from which all enumeration types derive, System.Enum, is listed as a struct, and it clearly is abstract, since it cannot be instantiated, and not sealed, since that's the type all enumeration types derive from. As far as I know this is the only struct that is not sealed.

    To add to the confusion, in .Net 4.0 the System.Enum type is listed as an abstract class, and this can be confirmed by compiling the following code using .Net 4.0:

    Code:
                Console.WriteLine(typeof(System.Enum).IsClass);//True
                Console.WriteLine(typeof(System.Enum).IsValueType);//False
    But if the same code is compiled using .Net 3.5, then both isClass and isValueType evaluate to False, as do IsInterface and IsEnum. It clearly is not a delegate, since it does not derive from System.Delegate, but since according to the .net 3.5 documentation it is a struct, then I suppose that either that's what it is or the documentation/metadata for this type is incorrect, which might explain why reflection indicates that it is neither a value type, a class, an interface, nor a delegate. It might also explain why in both .Net 3.5 and .Net 4.0 the following expression evaluates to true:

    Code:
    Console.WriteLine(default(System.Enum) == null);//True
    On a related note, System.MulticastDelegate is listed in both .net 3.5 and 4.0 as an abstract, non-sealed delegate, which seems to make sense but makes one wonder why application code cannot declare abstract delegate types.

    And concerning abstract enums? I didn't find any!

    In conclusion, I'm not sure if I should even ask why application code can't declare abstract delegates or structs, but can someone clear up the confusion concerning the type classification of System.Enum and also help me understand why application code, unlike FCL code, cannot declare non-sealed delegate and struct types? Is there a reason for this or is it mere convention? Additionally, can someone offer some comments concerning the non-public, abstract, sealed System.EnterpriseServices.Thunk structs I mentioned above? If those types in fact are structs, are they like a kind of "static" struct? And if that's what they are, why can't the application code declare the same kind of struct?
    Last edited by y99q; 12-24-2011 at 02:46 AM.

  2. #2
    Cat
    Cat is offline
    Registered User
    Join Date
    May 2003
    Posts
    1,571
    It wouldn't really even make sense to have a non-sealed delegate - there's nothing you could do with inheritance because delegate types don't have any methods or properties.

    As to structs, value types can't inherit from each other. Imagine, for a second, that you could derive one struct from another. Say an object of struct A was 50 bytes. An object of struct B, which derived from A, was 70 bytes (the 50 + 20 more). Now, you are going to call a method that takes an A struct as a parameter. When that method compiles, how does it know where the parameter begins and ends on the stack (which requires knowing the size of the struct)? It could be either 50 or 70 depending on whether you passed the base struct or derived struct into the method.

    Remember, a parameter or local variable is really just a compiler-defined offset onto the stack (relative to the current stack pointer) - any stack variable (e.g. a value type) must have its size known at compile time, so the compiler can calculate offsets.

    Essentially, if structs could inherit from each other, they couldn't be value types because the amount of stack space they require would not be constant. (The stack space taken up by a reference itself is always constant - just the size of that reference - so reference types don't run into this issue).
    You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. how to declare an external variable of type "enum"?
    By Adam Rinkleff in forum C Programming
    Replies: 28
    Last Post: 06-23-2011, 09:52 PM
  2. How do i declare my struct for test functions?
    By lilbo4231 in forum C Programming
    Replies: 9
    Last Post: 06-22-2011, 09:45 PM
  3. Delegate Calling a method that Calls a delegate.
    By xddxogm3 in forum C# Programming
    Replies: 2
    Last Post: 05-05-2008, 12:59 AM
  4. declare and initialize struct members
    By Mr.Bit in forum C Programming
    Replies: 3
    Last Post: 11-23-2007, 10:57 AM
  5. Replies: 2
    Last Post: 05-04-2003, 05:30 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21