A container that accumulates its elements metrics

I'm looking into a solution of building containers which track stored size of their elements in addition to basic functions.
So far I didn't saw a solution which doesn't create a huge amount of boilerplate code of each invalidating member of container. This also assumes that stored elements cannot change size after being stored.

Unless standard containers have some feature that allows to inject such behaviour. The following example should be working one, albeit abridged for brevity. The declarations used are:

typedef uint8_t   Byte;
typedef Byte  PacketId;
template <class T>
struct CollectionTraits {
typedef T			  collection_type;
typedef typename collection_type::value_type   value_type;
typedef typename collection_type::size_type    size_type;
typedef typename collection_type::iterator     iterator;
typedef typename collection_type::reference    reference;
typedef typename collection_type::const_iterator   const_iterator;
const_iterator begin() const { return _collection.begin(); }
const_iterator end() const  { return _collection.end(); }
iterator begin() { return _collection.begin(); }
iterator end()   { return _collection.end(); }
size_type size() const { return _collection.size(); }
protected:
T				 _collection;
};
struct Packet : CollectionTraits<std::vector<Byte>>
{   
PacketId			  id;
};

The container itself:

struct  PacketList :  CollectionTraits<std::deque<Packet>>
{
public:
typedef Packet::size_type			  data_size;
void	 clear() { _collection.clear(); _total_size = 0; }
data_size total_size() const  { return _total_size; }
void push_back(const Packet& v) { 
_collection.push_back(v); 
_add(v);
}
void push_back(const Packet&& v) { 
_collection.push_back(std::move(v)); 
_add(v);
}
void push_front(const Packet& v) { 
_collection.push_front(v); 
_add(v);
}
void push_front(const Packet&& v) { 
_collection.push_front(std::move(v)); 
_add(v);
}
void pop_back() {
_remove(_collection.back());
_collection.pop_back(); 
}
void erase(const_iterator first, const_iterator last) {
for(auto it = first; it != last; ++it) _remove(*it);
_collection.erase(first, last);
}    
PacketList() : _total_size(0) {}
PacketList(const PacketList& other) : _total_size(other._total_size) {}
private:
void _add(const Packet& v)	  { _total_size += v.size(); }
void _remove(const Packet& v)  { _total_size -= v.size(); }
data_size 			_total_size;
};

The interface in result should similar to a standard container. Is there a way to avoid this amount of repeated code? Is there some standard solution for this problem?

No, the std containers are code generators that build a few data structures that are about as fast as if you hand-coded them in C.

They don't have arbitrary hooks in them. If you want to build something more complex, you have to wrap them and write it yourself.

Unless you need your size-maintaining data to be as generic as a standard container and used in as many situations, you don't actually need to be a standard container. Standard containers are written to be used in a myriad of different situations; your specific application almost certainly won't be using your data in as many ways as standard containers are engineered to be used in.

Mimicing the entire standard container API is probably over-engineering.

As people have noted, maintaining this kind of invariant over the entire standard container API is challenging. Your code doesn't do it in a number of ways.

1. It exposes mutable references to the contained data, which could invalidate your invariants.
2. It exposes inheritance from the standard container publicly, which permits bypassing your API replacements completely either intentionally or by accident.
3. It replaces only a subset of APIs (push but not emplace, insert, maybe even splice, various erase overloads) that mutate the container.

The normal way to do this kind of thing is to store a container within some API, and don't expose its existence (it is an implementation detail). Provide only non-mutating iteration at best, and maybe not even that.

If you restrict the operations performed sufficiently to those you actually need, you can keep the boilerplate down.