Is a struct within a class bad?

very silly question. if i have class A, and within it i have a struct, then create an instance of that struct from class B, does this create an instance of class A somehow. like am i negating the benifit of the struct not needing garbage collection like a class does?

 

This would be a microoptimization at best given the best practices for structs in general. That said, if you plan on accessing a struct from another class, why not just make that struct independent of the class in the first place? This is less an optimization issue and more a code management one.

 

These are called "nested types" and creating an instance of a nested type does not create the outer-type. Though unless you have a reason to nest the type/struct then why even embed it within a particular Class? Structs can be put into a namespace directly just like Classes can be. Sometimes nested types are useful but it's not bad to nest types. It's just not good to nest them for no reason.

Also, technically the assumption that a struct will never need garbage collection is wrong. The misconception that structs are "stack types" and classes are "heap types" in .NET/C# is wrong. Eric Lippert, one of the original designers of the C# language, wrote a blog about this once https://learn.microsoft.com/en-us/a...he-stack-is-an-implementation-detail-part-one

Most importantly:

So structs should be chosen for the purpose of being a value-type and less so because they have the potential to sometimes be allocated on the stack because sometimes they aren't in many cases as Eric points out. Unless you have a good reason to truly need stack allocation of memory based on profiled data indicating so then you're probably fine to ignore this difference and focus more on value-type vs reference semantics and which is more useful for the Type imo.

 

No, it is not bad.

Garbage Collection is not a benefit, it is a thing that will add more work to the garbage collector, which can cause your FPS to drop at random times. However, you shouldn't try to avoid garbage allocation at all costs.

 

You don't create instances of structs. They're just "there", like integers. Suppose Cat is a class (Vector3 is a struct) and you have this class:

Code (CSharp):

1. class CCC {
2.   int x,y; // 2 ints
3.   Vector3 v; // 3 ints
4.   Cat cat; // 1 reference, currently null
5. }

When you create a new instance of CCC, like with

CCC c = new AAA();

the 3 integers for v are auto-created right there. All you can ever do is change the values (to compare,

Cat cat

is a class, so you need to use

new

to create one, and can chance

cat

to point to different Cat instances).

The thing that confuses people is how you can do

v=new Vector3();

. That looks like creating a new instance, right? But it's not. All it does is take the 3 v-slots than you already have, and copy in 0's. The

new

is there because C# requires it, but it does nothing. The idea is, most people don't even know what structs are. They would get confused when it's

c = new Cat()

but just

v=Vector3()

. So instead they confuse people like you with a fake

new

for structs.

 

Short answer is no. After compilation the struct and the class will be entirely separate things. There is no runtime difference between a nested struct and a struct in a namespace.

Nesting a struct is mostly optimising for programmers. When we nest a struct, we are telling everyone that this struct is designed to be used within a certain class, and not anywhere else. Its similar to how we use access modifiers like public and private. They don't change how things work once the program is compiled. But they do give programmers solid hints about how to use things.

 

Most often a private struct used only inside the class makes most sense. But there is nothing wrong with nested types (class, struct or record)

 

Have certainly used nested structs as detailed input or output containers for example. Instead of a method that takes 10 arguments, use a struct to store them in a more expressive way and pass that struct to the method.
Since those containers only make sense when you are simultaneously using the surrounding class, they are nested.

Nested classes that hold a state of there own, I'd personally tend to avoid. Rather use a namespace in that case.

 

I feel that very often this is focusing on the details and missing the point, though. A great deal of the time, when someone talks about "allocating on the stack" what they really mean is "not making a huge number of small objects which the GC will have to track and clean up". And in plenty of the cases raised as counter-arguments to this (e.g. an int in a class) that is achieved, even if the explanation given is incorrect.

That aside, I completely agree that you shouldn't worry about optimising garbage until it's actually a problem which you can measure. Unless you're measuring it you're guessing, and until you have a really solid mental model of all of the complexities involved those guesses could well make things worse rather than better.

 

I wish graphics programming's culture was like regular programming's culture, going thorough and in depth about even the minor issues.