Several attribute collections for the same simplex type, behind one container. More...

#include <AttributeCollection.hpp>

Inheritance diagram for wmtk::AttributeContainerGroup:

Public Member Functions
void	add (AbstractAttributeContainer *c)

void	move (size_t from, size_t to) override

void	resize (size_t s) override

void	clear () override

void	rollback () override

void	begin_protect () override

void	end_protect () override

Private Attributes
std::vector< AbstractAttributeContainer * >	m_children

Detailed Description

Several attribute collections for the same simplex type, behind one container.

A mesh exposes exactly one p_vertex_attrs / p_face_attrs / ... slot, so a class hierarchy that wants to split its attributes – shared fields on a base class, application-specific fields on the derived one – has nowhere to register the second collection. Point the slot at one of these instead and register both.

Splitting rather than unioning matters because an AttributeCollection<T> is a member: a derived class cannot change its type, and AttributeCollection<Derived> is not usable as an AttributeCollection<Base> (the storage is a std::vector<Derived>, so it has the wrong stride). Without this, every application pays for every other application's fields on every simplex.

The children keep their own rollback lists and are protected and rolled back independently, which is exactly right: AttributeCollection::operator[] records the rollback entry, so a write to an extras collection inside an operation is undone on failure just like a write to the shared one. Order of registration is the order of forwarding; no child observes another.

Non-owning: the collections outlive the group by being members of the same objects.