I am building an editor of sorts, which means my mesh geometry can change. Certain parts of my application will want to be notified when a mesh's geometry changes. So I added a "GeometryChanged" event to my mesh class. The problem is that several of my Mesh API functions can raise the GeometryChanged event, and often these calls will be made sequentially. Here is a simple example:

mesh.AddVertices(...);

mesh.AddIndices(...);

mesh.Indices[3] = 2;

Each of these changes the geometry of the mesh, and would trigger 3 "GeometryChanged" events. If the event handlers were heavy duty this would be pretty wasteful. One solution I am considering is to wrap changes between a BeginGeometryChange()/EndGeometryChange pair, and only Begin/EndGeometryChange would raise events.

This would work and is relatively easy to integrate, but I am wondering if there is a more elegant solution. I find this somewhat inelegant because of the extra API calls to Begin/EndGeometryChange that the client must manually remember to call. I can of course add debug asserts to make sure they are properly called, but still.

There is nothing wrong or inelegant with your idea to begin/end a series of events. This is called “batching” and is the normal way to go about this. It is also heavily used in undo/redo systems, especially related to typing events.

L. Spiro

class Mesh
{
	 friend class MeshModifier;
private:
	 void begin_modifications();
	 void end_modifications();

	 void add_vertices_impl();
	 void add_indices_impl();
};

class MeshModifier
{
	 Mesh &mMesh;
public:
	 MeshModifier(Mesh &mesh) : mMesh(mesh) {mMesh.begin_modifications();}
	 ~MeshModifier() {mMesh.end_modifications();}

	 void add_vertices();
	 void add_indices();
};