actual_weeb_tm
actual_weeb_tm
CC#
Created by actual_weeb_tm on 12/18/2024 in #help
Boxing
All I know about SIMD is that it's supposed to be better when parallel processing large datasets which is what I'll end up doing lol
64 replies
CC#
Created by actual_weeb_tm on 12/18/2024 in #help
Boxing
yes, I think they should be faster and if they're not it's easy enough to swap them out for another implementation
64 replies
CC#
Created by actual_weeb_tm on 12/18/2024 in #help
Boxing
public Segment(T position)
public Segment(T position)
64 replies
CC#
Created by actual_weeb_tm on 12/18/2024 in #help
Boxing
So basically just using it as a constraint. I think I can include a factory method that instantiates this with the proper implementation of the interface. It's a bit of a roundabout way to do it but this allows me to use the built in optimised Vector2 and Vector3 while still allowing my own less optimised VectorN for higher dimensions Should save on performance in the end
64 replies
CC#
Created by actual_weeb_tm on 12/18/2024 in #help
Boxing
Yeah but I'm passing T directly, so it should be fine, As in, the next class up in the hierarchy is
Segment<T> where T: IVector<T>
Segment<T> where T: IVector<T>
64 replies
CC#
Created by actual_weeb_tm on 12/18/2024 in #help
Boxing
Well for my specific case I now have an IVector<T> where T: struct, IVector<T> Which should keep the IVector<Foo> unboxed.
64 replies
CC#
Created by actual_weeb_tm on 12/18/2024 in #help
Boxing
means I can still write a factory method that returns an IBar which in turn implements a specific IFoo<something> Bit of a roundabout way to do it but it should work
64 replies
CC#
Created by actual_weeb_tm on 12/18/2024 in #help
Boxing
Right, I think I get it, thanks.
64 replies
CC#
Created by actual_weeb_tm on 12/18/2024 in #help
Boxing
Right yeah okay, I got it
64 replies
CC#
Created by actual_weeb_tm on 12/18/2024 in #help
Boxing
From what I've read it seems an IFoo<T> will still be kept unboxed, is that not correct?
64 replies
CC#
Created by actual_weeb_tm on 12/18/2024 in #help
Boxing
Yeah I'm looking to do this with structs though, which preferably I'd keep, but it seems there's no way to abstract away the generic T, apart from writing a factory method, I suppose
64 replies
CC#
Created by actual_weeb_tm on 12/18/2024 in #help
Boxing
More or less, what I want to do is implement a class that works with both a generic and non-generic interface and a property that implements another generic interface, but still avoid boxing of the struct.
64 replies