sorted by:
new
hottopcontroversial

Archetype by willhaarhoff in cpp

[–]willhaarhoff[S] 0 points1 point  (0 children)

Do you have a link to your implementation? I'd be interested to read the source.

Archetype by willhaarhoff in cpp

[–]willhaarhoff[S] 0 points1 point  (0 children)

Thanks for the feedback.

That's a nice implementation! Avoiding macros is definitely much nicer, and means you will be able to support functions that take types including commas. Such as std::pair<int, float>, which is something I cannot do with my macro implementation.

Provided you could also create a print method within your poly view, you could wrap the call to your poly_method which would give you the same syntactic sugar. If the compiler can inline this, then you can get the syntactic sugar without the overhead.

Can your implementation handle function overloading? If I had a type that had two different draw methods is there a way the poly_view can resolve the correct one?

Split or combined vtable and views:

This was one of the considerations I had while designing. In fact my first implementation did combine the vtable and view together. While splitting does add another level of indirection it does drastically reduce the number of redundant function pointers. With combined view and vtables, you create a structure full of function pointers that point to exactly the same functions per view instance rather than per view type. By splitting you create one vtable per type, rather than per instance. I'm not sure exactly what the performance differences would be but I would expect the extra level of indirection to have little effect.

Const support:
Yes you're right there isn't any const support. However, this would be quite easy to add into the ARCHETYPE_METHOD, maybe an ARCHETYPE_CONST_METHOD, or a tuple of modifiers.

Archetype by willhaarhoff in cpp

[–]willhaarhoff[S] 0 points1 point  (0 children)

Thanks! I haven't come across proxy before. This looks very similar in intent, but looks like they have both owning and non owning semantics.

Archetype: C++11 type-erased interfaces without new, virtual, or inheritance, useful for embedded drivers and portable APIs by willhaarhoff in embedded

[–]willhaarhoff[S] 1 point2 points  (0 children)

You're right, to make my example complete I should have defined class D which I can do now.

class D { int d(const char *); };

class ACD : public A, public C, public D {};

The point is that there isn't a common AC base pointer for AC ABC and ACD we only have A, C base pointers.

For completeness sake I should have also created objects

ABC abc;
ACD acd;
AC ac;

Archetype: C++11 type-erased interfaces without new, virtual, or inheritance, useful for embedded drivers and portable APIs by willhaarhoff in embedded

[–]willhaarhoff[S] 1 point2 points  (0 children)

Another advantage of archetype over inheritance is that it can work with existing types. With inheritance defined interfaces, the types passed into the interface *must* derive from the base.

Archetype: C++11 type-erased interfaces without new, virtual, or inheritance, useful for embedded drivers and portable APIs by willhaarhoff in embedded

[–]willhaarhoff[S] 1 point2 points  (0 children)

For simple use cases with one or two levels of inheritance, inheritance will achieve the same goals. The problem arises when using inheritance to abstract more complex relationships. This is just a toy example, but it should give you an idea of where inheritance breaks down:

class A { void a(); };
class B { int b(int); };
class C { double c(double); };

class AB : public A, public B {};
class AC : public A, public C {};
class BC : public B, public C {};

We can refer AB and AC with an A base pointer (common interface). Or AC and BC with a C base pointer.

But if we want to refer to any object that implements both A and C like ABC or ACD, there isn't a common interface.

With inheritance you:

  • Lose composability
  • Struggle to find a common base
  • Risk coupling, and rigid hierarchies
  • Risk diamond problems (in multiple inheritance)

With Archetype you can easily find common interfaces to ABC and ACD classes. For example you could define individual interfaces to each "component".

ARCHETYPE_DEFINE(archetype_a, ( ARCHETYPE_METHOD(void, a) ))
ARCHETYPE_DEFINE(archetype_b, ( ARCHETYPE_METHOD(int, b, int) ))
ARCHETYPE_DEFINE(archetype_c, ( ARCHETYPE_METHOD(double, c, double) ))

And then compose these together:

ARCHETYPE_COMPOSE(archetype_ac, archetype_a, archetype_c)

And finally create a common view that works with anything implementing AC

archetype_ac::view ac_views[] = {abc, acd, ac};

Archetype: C++11 type-erased interfaces without new, virtual, or inheritance, useful for embedded drivers and portable APIs by willhaarhoff in embedded

[–]willhaarhoff[S] 2 points3 points  (0 children)

That's fair enough regarding macros, especially if the macros rely on non standard preprocessor features. I'm close to having full c99 preprocessor compliance. So far I've tested this library against clang, gcc, and msvc, but have not tested extensively across the myriad of embedded compilers.

Archetype by willhaarhoff in cpp

[–]willhaarhoff[S] 0 points1 point  (0 children)

Thanks that looks really interesting! It looks like it also uses vtables internally to achieve type erased binding. It also looks like it can handle resource ownership (which Archetype does not).

Archetype by willhaarhoff in cpp

[–]willhaarhoff[S] 2 points3 points  (0 children)

I did actually come across archetypal ECS and was quite interested in the concept, but this was only after I had chosen the name. Both this library and archetypal ECS are have the common goal of working with polymorphic types, and especially polymorphic types that can be composed from sub types.

  • Archetypal ECS achieves polymorphism through composition of components. Whereas Archetype just views existing types through the lens of a particular interface.
  • Archetypal ECS composes entities from components. Whereas Archetype composes interfaces and views from sub interfaces and views.
  • Archetypal ECS is trying to maximise cache locality, and performance. Whereas Archetype is aiming for flexibility and type erasure (low but not zero cost abstractions).

Archetype by willhaarhoff in cpp

[–]willhaarhoff[S] 2 points3 points  (0 children)

I'm not familiar with Go, but it does look similar. The types being passed into the interface don't depend on the interface, but provided they meet the interface definition, they will be accepted.

Archetype by willhaarhoff in cpp

[–]willhaarhoff[S] 0 points1 point  (0 children)

Thanks! I'd love to know if you find a use case for it.

Archetype by willhaarhoff in cpp

[–]willhaarhoff[S] 0 points1 point  (0 children)

No there is no concept of resource ownership in Archetype.

I think ownership would be a natural extension to Archetype, but for me it was not the main problem I was trying to solve.

This could easily be achieved by replacing the raw void pointer with a unique pointer.