Irrlicht Design Problem (content coupling and encapsulation)

[nipou]

the problem here is once again, that many of those structures will be fed into the gfx APIs. So at some point we need to make a decision whether the data might meet the gfx API, or never in its whole life time. For all the latter, another container could be used. But due to reuse and simplification, an optimized algorithm should bring far better results in the end. So yes, we keep the original arrays and will work around those places where they are overused.

+----------------------------------------------+
High Level Functionality
ITriangleSelector
IrrBigArray
+----------------------------------------------+
IMesh <>---- IMeshBuffer
+----------------------------------------------+
Low Level Functionality
IrrArray
+----------------------------------------------+
Graphic Drivers
+----------------------------------------------+


New API
virtual void irr::scene::ITriangleSelector::getTriangles
(IrrBigArray<core::triangle3df> *triangles, ... );

Deprecated
virtual void irr::scene::ITriangleSelector::getTriangle
(core::triangle3df * triangles, ... );

[Simpe]

I think that it's pretty vital to keep the design of a linear array. Since a lot of Irrlicht's calculations is done by iterating through a list of objects it's sane for the sake of cache-coherency to keep lists of objects as a linear chunk of memory.

A linear array is not a list. It's a linear chunk of memory and thus it's reasonable that the base-pointer is exposed. A lot of (good) interfaces take pointer-arguments with number of objects at that location.