hamarb123
Odd behaviour copying structs
if anything, I'd argue that interfaces are more prone to it (with good reason generally) - e.g., look at
IList<T>, it has 3 other interfaces that you need to do too.
with base classes, I find you generally will just write the base class inheriting from object with all the common functionality & abstract methods needed, and then write the derived classes directly from the base class58 replies
Odd behaviour copying structs
but tbh, I wouldn't pick one based solely on whether it disallows multiple "inheritance" or not - I would pick whatever is most logical based on what features you need, based on the performance, etc., and then just not do multiple inheritance if you don't want it
58 replies
Odd behaviour copying structs
the difference between interfaces and base types is that you can implement an interface at any point, whereas base types explicitly limit you to only 1 base type (and hence force a simpler "inheritance" graph) - there are other differences too, such as base types being able to store fields if you need that - and base types generally being faster - but you generally select based on what functionality you will actually require - if you only ever plan to have entities that don't inherit from some other random class, then a base class is probably a better choice than an interface - if you will need an entity that inherits from some other type, you can either achieve that by using a wrapper or by making it an interface instead - if you were going to make them structs and never box them, then you'd obviously want to use an interface & pass them around by a constrained generic
58 replies
Odd behaviour copying structs
there's 2 reasons to use interfaces generally - one reason to use an interface is because you want complex "inheritance" graphs - if you want a simple graph, then using inheritance is effectively a simpler form of achieving that and it limits you to simple graphs - the other reason to use an interface is if you want to expose common functionality to a generic parameter, where T is the actual type implementing it, which you're not doing clearly as you're just boxing it
58 replies
Odd behaviour copying structs
I said that one was for making a shallow copy of a boxed struct - if you want to do a shallow copy of a class, you can just call MemberwiseClone (as I also mentioned lol) - you can just expose this as a public API in a base class if you just want to write it once
58 replies
Odd behaviour copying structs
it's not necessarily needed - you could have a collection for each type
if you do need them all in the 1 collection, then the easiest solution is probably to just use a class instead of boxing, since that way you make sure there's only the 1 allocation for the 1 thing & it makes it more clear that you're intentionally doing it by reference, otherwise there are more complex solutions available to avoid boxing:
- you could store all the data inline (assuming it's unmanaged, otherwise it will be more difficult), along with some sort of type id (& size, if size varies between types & you don't just want to pad) - this is the basic idea behind a lot of the solutions to avoid boxing for this
- instead of storing inline, you could store the data in another memory location if you wanted and manage that memory (you will still probably have to do some memory management for the inline approach, but probably not as much, but this has other benefits like making it more easy to tightly pack)
- instead of storing a type id & doing switch statement on it, you could store some sort of pointer/object, that you have 1 of per type, which exposes the interface in a way that explicitly takes the memory to operate on as a parameter, so that way you can still call methods on it fully generically, but with the benefit of no allocations
- etc.
58 replies
Odd behaviour copying structs
it's not that complicated to see when you're boxing - whenever you convert a struct or a generic of a struct type to
object, ValueType, an interface it implements, it boxes - or if you call a method that is from a base type that you didn't override like ToString(), or a default interface method implementation that you didn't override, on a struct58 replies