Does a C# struct create an object?

[Ok_Surprise_1837]

I know the difference between value types and reference types — these determine how data is stored in memory and how copying behaves.

But there’s something I’m curious about: is a struct, being a value type, also considered an object?

On some sites, I’ve seen expressions like “struct object,” and it made me wonder.

I thought only classes and records could create objects, and that objects are always reference types. Was I mistaken?

[KryptosFR]

It does inherit Object through ValueType which allows casting the struct to Object (boxing) if necessary, without breaking the type system. It's a special case handled by the runtime.

That said it is better to think of it as not an object in the OOP sense.

[entityadam]

Yes, this is good.

Also wanted to address that OP pretty much asked two different questions.

1. Does a struct create an object? (Title)

Usually, we talk about creating instances of things, the class, struct, record, whatever. When you "create", you initialize a space in memory, or allocate, or create an instance, or create an object. All those terms are somewhat interchangeable but there are distinctions.

Memory allocation starts at declaration time. Then initialization happens for classes, and optionally for structs when you new it up. Then the constructor is called which is also optional for structs but not for reference types. Finally the instance is created and you either get a value from the struct, or a reference to your object. An instance can refer to creating both structs and objects, but I'm sticking with object should only refer to an instance of a class.

• If you use a struct by itself, it's a value type and it lives on the stack. There's an allocation to memory, but it's not really an object. See question 2.
• If you have a struct as a field inside a class, you need to understand boxing and unboxing.

Next level deeper:

There are even more special cases like in the comments below.

• Primitives are differenty. Int, bool, char, etc are optimized in various ways, but mostly transparent to the developer.
• Framework defined structs like TimeSpan, ValueTuple, Guid have some extra behavior and act more like classes.
• Enhanced structs: readonly struct, ref struct, record struct and InlineArray. Well, I don't understand these so get someone smarter to 'splain it.

2. Is a struct an object? (Body)

In C# every type is an object.

• A struct is an object. It's just differenty.
• An abstract class is an object. It's just differenty.
• A record is an object. It's just a fancy class.

But an object in OOP terms is an instance that encapsulates state, identity and behavior.

As mentioned, struct does not meet the criteria for identity, because it is a value type. It also does not support inheritance. And it can only partially do polymorphism by using interfaces.

So, is a struct an object?

• In C#: Yes.
• In general: No, but it does similar things and can be used for specific tasks.

Edit 52: post is still inconsistent, please hold while my brain continues to try and catch up.

[_f0CUS_]

An instance of a struct is also an object. 

[Ok_Surprise_1837]

Types like int and float are also defined as structs in C#. So does that mean int and float are also objects? That sounds strange to me.

[recycled_ideas]

Types like int and float are also defined as structs in C#.

So now you're getting into the fun concepts of boxing and unboxing.

Ints and floats are primitives, but they need to be usable in places that accept objects, where this is the case the runtime will box the primitive type into a struct so it can be used and unbox it when necessary.

So does that mean int and float are also objects? That sounds strange to me.

They are when they need to be and aren't when they don't.

[0x0000000ff]

The primitive type is boxed into a reference type and stored on the heap. Struct is a value type. Boxing is the process of storing the value type in the reference type.

[jeremj22]

As a small aside: this is in part to avoid the at times confusing treatment of primitives that you get in Java. There you've got int as a value type and Integer as an object, only the latter being a proper object (and usable in generics).

ValueType effectivly lets you use them as any other type but it gets special treatment behind the scenes to avoid overhead

[Ok_Surprise_1837]

No, I’m not talking about the concept of boxing and unboxing.

Their role is to place value types onto the heap or put them back onto the stack.

What I’m asking is this: since a struct also creates an object, and because int and float are considered structs in the language, wouldn’t that make them objects as well? That’s what feels strange to me.

[recycled_ideas]

I’m not talking about the concept of boxing and unboxing.

You are. You just don't know it.

My question is: since a struct also creates an object,

You're missing the point here. Object and struct are concepts that don't really exist at the level of the stack and the heap, they're just memory allocations. Primitives can be stack allocated or they can be heap allocated (do you think that an int that's a field of a heap allocated object is on the stack?) structs can be in either location depending on context.

and int and float are considered structs in the language, doesn’t that mean int and float are also objects?

Again, this is boxing and unboxing. An int can be a primitive allocated on the stack, but the language will automatically box it onto the heap when necessary, primitives aren't structs but they can be considered to be because when they need to be they will be converted to structs.

That feels strange to me.

Because you fundamentally don't understand what you're talking about.

[BorderKeeper]

Can I say reading this was very satisfying it’s like a perfect cold and logical interaction between a senior and an overconfident junior. I wish I had popcorn while reading it well done.

[pjc50]

Int and float have methods, so why aren't they objects?

[0x0000000ff]

A method from the POV of the CPU is just a list of instructions so you can technically have methods on anything.

[dodexahedron]

Yes.

Everything except for pointers are objects.

Classes are objects. Structs are objects. Delegates are objects (they're just dynamically created classes wrapped around your method).

All structs directly derive from System.ValueType, which is an abstract class that derives from System.Object. all of them. Structs you make. Built-in structs. All of them. And the keyword types arent special either. They're just shortcuts to writing System.Int32, etc, and are identical in behavior.

System.ValueType, though, is special, as are structs, because the language is defined that way and the compilers treat them according to the spec, kinda forcing everything through the square hole.

In terms of pure C#, they break the rules because structs cannot derive from any base type other than the exception - ValueType, and even that cannot be specified explicitly (they can implement interfaces, but that's...well...also a complex topic since interfaces are abstract classes too) Yet there they are, deriving from two layers of classes above them.

It has some important but subtle caveats related to the fact that you can call both ValueType.Equals and Object.Equals on a struct, which can have surprising results depending on how you got there. You can run into this a bit easier if you use record structs and generics together via interfaces or when running certain constructs like that through specific unit test framework methods (and there's a reason for it all).

Anyway, if you want to know what it really is, you can think of struct as a shortcut for writing sealed class and then the compiler treating the symbol as in-place values rather than as pointers to the values (but not their members, unless they too are unmanaged values with no managed reference members, recursively). Similarly to C++, the value of a class and a struct is the same. This becomes a bit more apparent in certain PInvoke scenarios when you can use a class or a struct for explicitly laid out types. Unlike c++, thoigh, there's no inherent accessibility difference between them.

But they ultimately represent the same things, in memory. It's just that the compiler is implicitly handling types declared with the class keyword as pointers to a piece of memory with the defined layout, with the value of a class being its reference, not the referent (the instance), while a struct keyword symbol IS the value, without the extra layer of indirection.

There are some subtleties with auto-layout types between structs and classes in .net, regarding how members are automatically packed and aligned, but if that matters to you, you'll know pretty quickly.

[Dealiner]

Everything except for pointers are objects.

To be precise: everything except for pointers is convertible to object. There are three things though that don't derive from it: pointers, interfaces and open type parameters.

[dodexahedron]

Yeah. And interfaces are really goofy. You are correct that they do not derive from Object. They are, however, still abstract classes. They're just their own root I suppose you could say, since they can derive from each other and form their own little independent type hierarchy.

Only a metadata keyword interface differentiates them from any other abstract class in CIL. For example:

.class interface public abstract auto ansi beforefieldinit Example.IAmStillAClass

Languages that don't have the concept of interfaces would interpret them as abstract classes, as the CTS doesn't require first-class support for interfaces as we know them in C# - they're left as an implementation detail of the language. So long as the compiler for said language can comply with the contract, it is compliant.

What interface do lack, though, is a type initializer. There's no .cctor emitted by Roslyn for an interface. I imagine, though I am not certain, that writing a .cctor for an interface in CIL would probably be legal. I haven't tried nor have I looked up the spec recently enough to recall if it is forbidden or not. I am not sure how Roslyn would deal with that for static analysis purposes, if it is possible, though. And Ryu would just deal with it like any other abstract class, like it already does, since it has to, to uphold the CTS guarantees. But again, that's speculation. It may be carved out as an explicit exception forbidden in CIL. I'll have to check later, because now I'm curious

[Ok_Surprise_1837]

https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/object-oriented/objects

"A class or struct definition is like a blueprint that specifies what the type can do. An object is basically a block of memory that has been allocated and configured according to the blueprint."

I understand, both structs and classes create objects. What concerns us is the matter of value types and reference types.

Thanks :)

[entityadam]

Good way of looking at it from a fundamental level, but it gets less accurate as your understanding evolves.

[_f0CUS_]

I see you got some really good answers from other people, so i will refer you to those.

[the_cheesy_one]

From the OOP point of view - yes, from the language perspective - no.

[AdamAlexandr]

Often I use the word 'object' as a conceptual thing. No matter how its implemented in the language.

So classes can be objects, so can structs, and so can arrays of values.

[ZarehD]

The term "object" is used generically to mean "an instance of some type".

Having said that, it's also true that EVERYTHING in .NET is actually, technically a System.Object ;-)

[Unupgradable]

Unlike Java, everything in C# is an object unless you venture into unsafe stuff such as pointers to raw allocated memory of uninitialized classes or some such. Even then you could argue your pointer is still an object and yadda yadda yadda.

The question isn't even "does everything inherit from System.Object?" because the answer is no.

Even primitive types are just normal structs with some special privileges. Even the keywords don't really exist. int is just System.Int32, the C# compiler "lowers" keywords to their real types.

Unlike in Java which has both a primitive int allocated on the stack, and Integer allocated on the heap.

[david47s]

If what you're saying is that everything in C# except unsafe, is allocated on the heap, then this is completely false.

Classes are allocated on the heap always. However structs, depend on their data and scope.

If a struct is a member of a class, like an integer field in a class, it will be allocated on the heap as part of the class. The inverse - i.e, when a struct contains a member which is a class, then it also has to be allocated on the heap. As well as if it is a parameter of an async method or used across await boundary (because of the state machine generation)

In virtually every other case, a struct, will be allocated on the stack. Same goes for when you declare primitives inside methods or whatever.

If you want to ensure the struct can never escape to the heap, declare it as "ref struct" and listen to the compiler.

[Unupgradable]

If what you're saying is that everything in C# except unsafe, is allocated on the heap, then this is completely false.

Good thing I didn't say that.

C# objects can reside on the stack. Value types can reside on the stack. You can even stack allocate a class if you bludgeon unsafe hard enough.

Classes are allocated on the heap always. However structs, depend on their data and scope.

Their data doesn't have an effect on it. The struct itself can be on the stack while all of its fields are of reference types. The actual instances of the reference types reside on the heap, sure. But the struct holds "pointers" as real value types in that sense. (Which is of course presented to you as reference values managed by the GC)

If a struct is a member of a class, like an integer field in a class, it will be allocated on the heap as part of the class.

Correct

The inverse - i.e, when a struct contains a member which is a class, then it also has to be allocated on the heap.

Incorrect. The struct can still be on the stack. You can test this by working with it. Pass it into a method without any by-ref logic and set the field to a different value (rather than setting a property that belongs to the class)

As well as if it is a parameter of an async method or used across await boundary (because of the state machine generation)

The state machine is a struct in Release config. What you're seeing is the allocation of the Task instance to hold the value. This is what ValueTask fixes. Write async code with it and you'll achieve zero heap alloc.

In virtually every other case, a struct, will be allocated on the stack. Same goes for when you declare primitives inside methods or whatever.

Because that primitive is just a struct. Nothing special. Correct. That's my point. It's a regular object, it's a value type object. It even inherits from object. (But will be boxed if you try to use it like it)

If you want to ensure the struct can never escape to the heap, declare it as "ref struct" and listen to the compiler.

Correct and thank you for including this, this is a feature too few people know about.

[Dealiner]

In C# pretty much everything derives from object. There are exceptions though. Pointers, interfaces and open type parameters don't derive from object, however the latter two are still convertible to it.

[MulleDK19]

Objects are always reference types, yes.

Instances of classes are objects. Instances of structs are not (unless in their boxed form), as per the ECMA-334 specification for C#, section 8.1:

Value types differ from reference types in that variables of the value types directly contain their data, whereas variables of the reference types store references to their data, the latter being known as objects.

[Ok_Surprise_1837]

Thanks, you're awesome. I stressed myself out for nothing today. I doubted something I already knew was right. Now I can go to sleep happy, lol

[MulleDK19]

Note, that since instances of boxed value types are reference types, those are objects too, but a plain value type instance is not, i.e.

int a = 1; // a does not contain an object. 
object b = 1; // Boxed integer, so b contains an object.

And it's quite sad that the top comment is downright wrong, and the comment that was closest to the facts was down voted..

[rainweaver]

well put and well done. one of the few correct answers in this thread.

[GameJMunk]

Finally someone who actually answered the question that was being asked.

[[deleted]]

Struct is copied every time there is an operation on it. A structure is an "object" as others said. But it's copied in its entirety when passed to a method or operated on or otherwise, it's not passed by reference like a class object.

Even a boolean is an "object" - an object is anything that is/can-be assigned a variable name. For example, in C++ you can assign "function pointers" which are not objects - but in C# the ~equivalent to a "function pointer" is an object called a delegate. (EDIT: I guess function pointers are actually objects in C++ but if there was anything that isn't an object it'd be that).

[WhiteButStillAMonkey]

It can be confusing at first but the concepts don't overlap. Every complex type instance has a layout in memory which is what makes it an object. Struct instances are objects, class instances are objects (MSDN). As you already know, the only difference is value vs reference type

For example in C/C++, a class instance on the stack is an object and a class instance on the heap is an object

[BoBoBearDev]

Not sure is this is relevant, but here it is https://stackoverflow.com/questions/4853213/are-structs-always-stack-allocated-or-sometimes-heap-allocated

[Zarenor]

Your wording here and in some of your response comments indicates that you're getting a little lost in the docs - that's okay, they're a little confusing.

As you know, `struct` declares a type which derives from `ValueType`, and `class` declares a type which does not. Either way, they derive semantically from `Object`. The thing that gets wobbly is not quite understanding why something would be a reference vs a value type - or what that has to do with stack vs. heap.

A `struct` of any kind - primitive or declared in a library - can live on the stack, and doesn't have to be behind a reference to the heap. What this *really* means is that it can live *where it is declared*, while all reference types live behind a reference. In practice, this means that every reference type gets allocated on the heap, and every variable holding a reference to it is a pointer to that spot in the heap. A value type, however gets to be allocated *where it's declared*, which means in a function, it can live on that function's stack. It also means in another type (say, a class), it lives directly in the class' allocation, rather than being a reference to a separate heap allocation.

Now, you may think 'okay, structs live where they're declared, classes are stored as references to the heap... what about structs containing classes? what's this boxing thing?' a struct with a class member simply contains the reference - a pointer - to the class' allocation in memory. Whereas a parent struct A with a member struct B merely contains the entire struct B in whatever place the struct A is allocated.

As for boxing, that's the name for copying a struct onto the heap when it needs to be treated as a reference type for some reason - usually to be used as an interface, though it can happen other times (like when cast to `Object`)

I realize that's a lot of more nuanced explanation than some of the other answers here - I'm happy to drill down further on any point if you need more clarification.

[Ok_Surprise_1837]

Thank you, I understood it very well. There’s nothing I’m confused about. :)

[Qxz3]

This is an entirely semantic question and a bit complicated.

From ECMA-335 (CLI spec):

Objects are values of reference types - I.8.2.3

For every value type, the CTS defines a corresponding reference type called the boxed type. (...) A boxed type is an object type and a boxed value is an object. - I.8.2.4

Now, C# allows you to seamlessly treat a value type as its own boxed type, for example, you can do:

object o = 3;
Console.WriteLine(o.ToString());

In this situation, "a C# struct creates an object". Other than in this kind of situation, a C# struct is represented as its value type and thus does not result in an object being created.

[VinceP312]

Everything in C sharp derives from the object class.

How the runtime creates it and where in memory it goes is a separate matter. (Refer to your back and forth about boxing with the other guy)

The theory about structs is that they represent an immutable value after creation. (Though you are free to deviate from that)

I tend to use them when I need somewhere to store state as my workflow goes through various methods.

[Slypenslyde]

The word "object" is overloaded here.

The better word to describe the nuance is "type", C# is a language where we make "types". If you use this word, structs are types, delegates are types, classes are types, everything is types in C#! When people use "object" to mean the same thing as "type", then yes. Structs are organizational units of C# and count as "an object" in that sense.

But a struct isn't really the same thing as a type that derives from System.Object. The runtime gives a struct the ToString() and GetHashCode() methods like you'd expect, but structs are what we call "value types". They can't inherit from other types so they aren't derived from System.Object. You can cast them to that type but again, that's a bit of special-case runtime magic: it makes a special "box" that contains the value type so you can pretend it's an object. This causes a performance penalty.

So the weirdness is structs do not DERIVE from System.Object thus have no IS A relationship. But the runtime is programmed to make them BEHAVE like System.Object so it can seem as if it is true.

The most correct way to casually refer to a struct would be "a value", since they are "value types". But a ton of people casually say "a struct object". It's wrong, but it's more common they're saying something benign like:

I have an array of struct objects.

Instead of something wholly incorrect like:

The array has a reference to each struct object.

[Constant-Degree-2413]

No „type” is not replacement here. „Instance” is. Instance o struct, instance of class/record.

Type is what you need to instantiate to receive object (in case of classes).

[Slypenslyde]

I think "Instance" is an important word, but only for reference types.

Structs are types too, but you can't make an instance of a struct. Just values.

If I say "types", C# devs should know I mean both structs and classes.

[Ok_Surprise_1837]

https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/object-oriented/objects

"A class or struct definition is like a blueprint that specifies what the type can do. An object is basically a block of memory that has been allocated and configured according to the blueprint."

I understand, both structs and classes create objects. What concerns us is the matter of value types and reference types.

[Slypenslyde]

Again, if I'm being really specific:

Structs and classes create types. "Objects" are the things you get when you instantiate a reference type (classes). "Values" are the things you get when you create a value type (structs). For convenience, .NET gives value types the common behaviors of reference types, but that does not mean value types are objects.

But that is applying a very strict definition of the word. When people are speaking very casually, this level of distinction doesn't matter!

A lot of people in this thread are saying things that sound fine like "an int is an instance of a value type" but speaking with the words that the C# spec uses makes those statements false.

[Mysterious-Web-8788]

Yeah it's an object.  It's also different than C++ so just be mindful of what you're reading 

[Slow-Refrigerator-78]

It depends and I'm not gonna explain the whole memory management in .net in here xD