ON_SimpleArray

I would like to ask a question about the Rhino C++ SDK.

From a historical perspective, Rhino developers implemented their own collection types and various kinds of arrays. I assume that in CAD applications—where you need to handle a large number of objects while maintaining high performance and memory safety—these design choices are especially important.

Could you explain why collections such as ON_SimpleArray were implemented instead of using the C++ standard library (for example, std::vector, std::array, std::unique_ptr, std::shared_ptr, and other modern techniques)? What aspects of building a real CAD environment might developers of simpler geometry libraries not fully understand or underestimate?

1 Like

Aside from intent (covered by Steve below), my findings are that it may provide a performance boost. The methods needed to support ON_SimpleArray are fewer and less complex than for the vector object in C++. I have tried both in my C++ code and found vector to be slower. But this result is dependent on the usage context so you need to do your own evaluation to decide which is best.

ON_SimpleArray cannot do everything that vector does. But for cases not using the more powerful features of vector, using ON_SimpleArray is like it says, its simpler which may provide a performance boost.

Regards,

Terry.

1 Like

There’s no problem using the standard library these days. ON_SimpleArray is very very similar to std::vector. We just happened to write ON_SimpleArray way way back in the past when the standard library was just starting out

Thank you for explanation, it is crazy to think you were writing such a low level code that now relies the whole Rhino SDK…

It’s actually not a very complicated data type and I’m guessing many people have written their own form of a dynamic array over the years when they first learn how to work with templates.

Fun fact, I heard somewhere that std::vector is a monstrous construct of around 4000 lines of code. I haven’t checked the standard library to confirm this though. :slight_smile:
Anyway, if that’s true, I kinda understand why one would want to implement a similar, yet code-wise leaner container, especially if you want more granular control over how the container grows, how it’s copied, etc.