What's the advantage of an "accessor"?

inline void    lock (CVertexBufferReadWrite &accessor, uint first=0, uint last=0);

this is one of the method in class CVertexBuffer, my question is why use parameter "accessor", what's the advantage behind? As I think, use a member to refer to the driver, and use the driver->lock() is more readable.

My thought is like following:

class CVertexBuffer 
{
public:

inline void lock (uint first = 0, uint last = 0);

private:

IDriver *_driver;

}

CVertexBuffer::lock(uint first, uint last)
{

_driver->lock (first, last);

}

Replies (1)

RE: What's the advantage of an "accessor"? - Added by sfb over 7 years ago

sambsp,

This is actually probably not as simple as you think it is. Since NeL was intended on being multi-threaded the "accessor" terminology is used throughout its threading utilities in NLMISC. While this isn't strictly an accessor in the same fashion as one of the threading accessors it aims to offer a similar functionality but does so for portions of the vertex buffer. For example when you suggest using a lock method on IDriver the driver does not know which vertex buffer you are locking a portion of a buffer from. In order to implement this the way you suggest we would have to change that method call to:

1IDriver::lock(CVertexBuffer *buffer, uint32 first, uint32 last);

and call it like:

1_driver->lock(this, first, last);

On top of that the CVertexBufferRead and CVertexBufferReadWrite "accessors" provide utility methods for manipulating the vertices in the locked buffer directly - independent of the actual vertex buffer. By manipulating CVertexBuffer directly you risk colliding into another thread. This way, accessing the member through the CVertexBufferReadWrite_ class you can manipulate the buffer safely and since the core CVertexBuffer class has your set of vertices flagged as locked you do not have to worry about the source being changed until you unlock the accessor.

Thanks,
sfb
/s

(1-1/1)