Hi

-
Hi,
I’m trying to solve the following problem using Generics:
I need to implement a collection (say List or DynArray) of Generic Dynamic Sub-Arrays, so that each Sub-Array can hold data of different type. Each sub-Array has the same number of items, just of different types.

This is what I try to achieve (sorry for the compact layout):

type TVertex = record VX, VY, VZ: Double; end;
type TNormal = record NX, NY, NZ: Double; end;
type TTexCoord = record U, V: Double; end;
……. Other data custom types

Type TMeshProperty = class
     FData: TArray;
     procedure AddValue(AValue: T);
……
End;

Type TMeshPropertyCollection = class
 FMeshProperties: TArray <-compiler error here, as TMeshProperty is not defined, correct, but how to solve this?
    procedure AddProperty(AProp: TMeshProperty);
End;

The TMeshPropertyCollection must be able to store TMeshProperties of any of the custom defined types. I know that I could just combine all properties intro just one type, but this is not what I’m going for. I want other users to be able to define their own (unknown to me) types and use them in the structure.
Something like this:

Var
PropCollection: TMeshPropertyCollection;

PropV: TMeshProperty;
PropT: TMeshProperty;
PropN: TMeshProperty;

And then:

PropCollection := TMeshPropertyCollection.Create;
PropV :=  TMeshProperty.Create;
PropT :=  TMeshProperty.Create;
PropN :=  TMeshProperty.Create;
PropCollection.AddProperty(PropV);  //Add this prop to the PropCollection
PropCollection.AddProperty(PropN);
PropCollection.AddProperty(PropT);

//Make Vector just creates a record of TVertex, TNormal, TTextCoord 
PropV.AddValue(MakeVector(1.0 ,1.0, 1.0));
PropN.AddValue(MakeVector(-1.0 ,1.0, 1.0));
PropV.AddValue(MakeVector(1.0 ,0.0));

Any ideas how to (elegantly) solve this?

Comments

  1. Dorin DuminicaApril 23, 2013 at 4:57 AM

    Claudiu BARSAN-PIPU I'm still uncertain as to what you're trying to achieve, I have the feeling that you're over-engineering but it could be just me...

    with interfaces, you can define the basics and then have different implementation for each "special TMeshProperty", nothing that you can't do with classes, i.e.

    TMeshPropertyBase = class
    //... special methods + virtual methods
    end;

    TMeshPropertyVertext = class(TMeshPropertyBase)
    // overwrite virtual methods as needed + define special fields/methods
    end;

    TMeshPropertyCollection = ....
    procedure AddMeshProperty(Value: TMeshPropertyBase)
    //....
    end;

    so, on second thought, maybe interfaces isn't the "way" (:

    give us a bit more insight as to what you're trying to achieve and maybe we can find an easier solution

    ReplyDelete
  2. Claudiu BARSAN-PIPUApril 23, 2013 at 5:23 AM

    What I'm going for is actually the implementation of a mesh data structure that uses synchronized property arrays (it's an implementation of the Half-Edge structure). In this context, each element of the mesh (Face, Vertex, Edge, HalfEdge) can have various properties attached to it for specific operations that will be required just for those operations (for ex. Mesh Decimation, Mesh Smoothing etc.) and therefore should not occupy memory outside these algorithms. The idea is that I cannot anticipate the required types one would have to define, and while some are basic (just an additional vector per face etc.) some can be rather complex (it all depends on the algorithm). By having synchronized properties of any (generic) type, I could simply add a new TMyComplicatedType defined outside of the API and just use it, then eliminate that particular property and so on.
    The 3D API is designed to be used by other users without them having to inherit or derive new classes, i.e. keep it simple for "them", which as you can see can make things a bit more complex for me, as far as over engineering goes :) . If you have a simpler approach in mind, I would definitely  welcome it.

    ReplyDelete
  3. Dorin DuminicaApril 23, 2013 at 5:27 AM

    In this case, I think the most straight and forward approach is to go with "base" class and inherit from that all new types, anything other than that will complicate your code base a lot -- of course, others can have different opinions (:

    from what I can see, you don't get a "get out of jail free card" from hard-casts... I would try different approaches, sketch a few prototypes and see what works best and go with it.

    ReplyDelete

Post a Comment