А именно:
+ [B|P]FIFO;
+ HTB;
+ RED;
+ WRED (a.k.a. `gred` в Linux/TC и нашем CLI);
+ SFQ.
Два замечания:
1. Вместо GRED и RED теперь WRED и RED: RED — как был, так и есть, а
WRED — специальный узел, который несёт глобальные настройки GRED, но
параметры RED на VQ задаются через подключение дочерних узлов RED.
2. Параметры RED для SFQ также были оптимизированы: в узле SFQ их не
будет, но зато к SFQ можно подключить один дочерний узел. Если
подключить туда RED, то настройки RED будут применяться для per-flow
RED дисциплины SFQ.
Примеров итератора с доступом на чтение я много оставил, а пример
модификации дерева только один. И тот я сразу забыл перевести на
итераторы (range-based for loop).
Т.к. проход теперь не по вектору (он давал экземпляр умного указателя),
а по обычному указателю (собственному прокси, если точнее), то узел
разрушался уже в процессе его отключения от дерева. Добавил удержание
ссылки в сам `unlinkParent()` (ну, нам действительно может быть нужно
только безвозвратное удаление поддерева) и пример в `main.cpp` расширил
и прокомментировал.
Решил обойтись простым ~~советским~~ статическим методом:
template <typename T>
class FabricMixin {
public:
template <typename... Args>
static std::shared_ptr<T> create(Args&&... args) {
return std::shared_ptr<T>(new T(std::forward<Args>(args)...));
}
};
Ну ладно, он не так просто выглядит на первый взгляд. Но, по сути, всё,
что он делает: параметризует метод типом возвращаемого указателя, и
передаёт все аргументы как есть в конструктор заданного типа. Решил
сделать так, чтобы не копипастить тело конструктора. Ну, вдруг я,
например, трассировку туда добавить захочу. Правда, есть недостаток у
такого решения:
class SimpleNode : ...,
public FabricMixin<SimpleNode> {
friend class FabricMixin<SimpleNode>;
Не очень удобное подключение: а) нужно внести по крайней мере две
строчки; б) автоматически самого себя параметром шаблона передавать
нельзя.
Вносить этот метод в `BaseNode` (или около) не хотел, чтобы не
пробрасывать оконечный тип по всей иерархии. Да и от указанных выше
проблем он не избавляет. Зато можно будет относительно безболезненно
выпилить этот класс, если ему подвернётся достойная замена.
Т.к. в основном меня либо интересует создание/удаление объектов, либо
нет. Смысла объединять это логи с другими логами объектов каждой
подсистемы я не вижу.
Сергей Маринкевич
grayhook