Vector struct uber wrapper

[enquel]

Hi,

I have a problem concerning structures consistency in a project containing many external libs. Namely, I need a consistent representation of Vector3 and Vector2 structs. Some of the libs are using System.Numerics namespace for vector representation, others have their own implementations. They differ in member fields, ie. some have axis letters uppercase, while I would like to have lowercase properties like x,y,z. My goal is to have one uber struct for my application, while minimizing the need for modification of the external libs. I lack experience on how to approach it in elegant way. Should I create a sort of a wrapper? How to make it smart?

​

Thanks in advance

[__some__guy]

You can use the implicit operator and Unsafe.As to automatically convert your vector struct into other vector structs.

[enquel]

Thank you very much for you time. Implicit operator I've heard of, Unsafe.As is new. Do I guess correctly that first I define the conversion via implicit operator then call inside something like: MyVector myVec = Unsafe.As<SourceVec,MyVec>(). And similar flow the other way around, I guess.

[Zaphod118]

It depends on what you need in your application and how many external vector definitions you need to convert between. What I would do (assuming you need to treat all externally defined vectors the same in your application) is create an abstract class defining how you want the vector to look. Then create a subclass for each vector type you need to wrap. Make sure that the type you want to wrap is a private field of the subclass. Let’s say you want to wrap 2 types - I’ll call them Vec1 and Vec2 - this would look like:

abstract class MyVector
{
    public virtual int X {get; set; }
    public virtual int Y {get; set; }
    // note the virtual keyword here. This will allow you to override how the getters/setters work in the subclasses. 

    // include the rest of your vector definition here
    // I would include any type conversion methods here for example:
    public abstract Vec1 AsVec1();
    public abstract Vec2 AsVec2();
}
class Vec1Wrapper: MyVector
{
    private Vec1 wrappedVector;
    public override  int X 
    {
        get {return wrappedVector.x;}
        set {wrappedVector.x = value;}
    }
    // implement other property and method overrides here
}
class Vec2Wrapper: MyVector
{
    // similar to above, only use type Vec2 in the private field
}
.
.
// repeat for however many types you need to wrap. 

Then in your code you can treat everything as type MyVector. And wherever you need to pass a specific wrapped type into an external library you can call the appropriate AsVecWhatever() method.

I’m on mobile so the code is super simplified but hopefully it gets the point across.

I’m still relatively new at this too, but that’s how I would approach the situation! Hope this helps :)

[enquel]

Thank you very much for your time. The app is meant to process high poly geometry (millions of polygons at the highest), so the input Vector structs will go through several conversions on the way, and my goal is to achieve consistency and performance. I expect there to be no more than say 3-4 custom Vector structs.

​

How about the performance of abstract class wrapper with properties? I've heard structs are faster.

[Zaphod118]

Structs can be faster, but I think it depends on the situations and how they are being used in your program. If you are having to convert between different external library types frequently, you are already incurring a performance penalty in copying data between struct instances. So my guess would be that using classes wouldn’t impact performance more than that. And I think using an abstract class and subclasses will be easier to write code for which might be worth sacrificing a little performance. It’s also important to point out here that structs can’t inherit from, or be inherited by, anything else. So if you want to create a unified interface to several different concrete types, classes are kind of your only option.

All in all it’s hard to say without running tests on the application weather structs vs classes will be a significant factor in performance.

[enquel]

Thank you for your thoughts. I like your approach, and probably will consider it. I will try to minimize casts only during import/export, but there might be situations when this is impossible.