Implementation Question: Does EdgeHolder need to hold a _pointer_ to an EdgeSegment _only_ because EdgeSegment is actually a pointer to one of the three derivitave types??

[gabe-lee]

CONTEXT: I am writing an implementation of this library translated into Zig (as part of my own library ecosystem, full credit given in source for the original here).

Zig does not have inheritance or virtual class members, so I elected to make each of the 3 EdgeSegment sub-types (linear, quadratic, cubic) a tagged union member field of a single concrete EdgeSegment class since the difference in object size is negligible.

However, while translating the original C++ code, I ran into the strange case of EdgeHolder doing nothing more than holding a pointer to the real edge segment. After some thought I figured this made sense for C++ because of inheritance, but I also did not know for certain if there was some sort of algorithmic reason to have it hold a reference to the edge segment and not the edge segment itself.

After translating thousands of lines of code from a language I am not very familiar with into more than 3k lines of Zig, it is hard to keep track of all the steps in the full process, so I thought I'd just go to the source themself.

My main, concrete question is: Is it ever possible (assuming proper operation) for an EdgeHolder to hold a pointer to the real EdgeSegment, that another separate EdgeHolder also holds a pointer to?

If not, I can safely remove this level of indirection from my Zig code and reduce the number of allocations performed. Conversely, if this is the case, this may be an avenue to improve the C++ codebase as well if reducing the need to allocate EdgeSegments on the heap is worth the tradeoff of needing to access the point array using a switch statement on some sort of 'type' field on the EdgeSegment.

[Chlumsky]

Yes, EdgeHolder needs to hold a pointer only because there are 3 possible segment classes. An EdgeHolder cannot hold a pointer to the same edge as another EdgeHolder. It is essentially a unique_ptr which also allows copying by performing a deep copy. Yes, it could be replaced by a union of the three types. (At one point I benchmarked this optimization and the performance difference was too small to justify breaking API compatibility since EdgeHolder is publicly exposed to users of MSDFgen as a library.)

[gabe-lee]

Awesome, thanks, and I would like to thank you for your work in this field!