Здравствуйте, adontz, Вы писали:
A>Здравствуйте, adontz, Вы писали:
A>Беру решение g_i A>Всем спасибо. A>rebind тоже рабочее решение, но выглядит страшно
Здравствуйте, g_i, Вы писали:
A>>Пишу дерево распределение памяти в котором должно регулироваться policy классом. g_i>А можно полюбопытствовать, почему менеджеру памяти нужен все же именно узел — почему входящим типом не обойтись не обойтись?
Ну узлы-то разные бывают. Ведь надо выделять память не только под 3 указателя, но и под дополнительные данные. А они кстати тоже разные. Если их ещё как-то можно охаректеризовать парой {data, key} то ничего конкретного об этих data и key сказать уже нельзя.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, g_i, Вы писали:
A>>>Пишу дерево распределение памяти в котором должно регулироваться policy классом. g_i>>А можно полюбопытствовать, почему менеджеру памяти нужен все же именно узел — почему входящим типом не обойтись не обойтись?
A>Ну узлы-то разные бывают. Ведь надо выделять память не только под 3 указателя, но и под дополнительные данные. А они кстати тоже разные. Если их ещё как-то можно охаректеризовать парой {data, key} то ничего конкретного об этих data и key сказать уже нельзя.
Вот тут немножко непонятно, как менеджер разберется, что с этими данными делать (ввиду того, что "ничего конкретного об этих data и key сказать уже нельзя"). Чтобы принять решение об определенных действиях над данными объекта Node (учитывая конструктивные особенности этого объекта), он должен, наверное, иметь специализацию для конкретного класса Node — полученной на лету реализацией шаблонного класса, вроде, не обойтись?
Здравствуйте, g_i, Вы писали:
g_i>Вот тут немножко непонятно, как менеджер разберется, что с этими данными делать (ввиду того, что "ничего конкретного об этих data и key сказать уже нельзя"). Чтобы принять решение об определенных действиях над данными объекта Node (учитывая конструктивные особенности этого объекта), он должен, наверное, иметь специализацию для конкретного класса Node — полученной на лету реализацией шаблонного класса, вроде, не обойтись?
А менеджер делать ничего и не должен, он должен только выделять и освобождать память под эти данные. Причём есть две операции выделения: под новый элемент и под копию уже существующего элемента.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, g_i, Вы писали:
g_i>>Вот тут немножко непонятно, как менеджер разберется, что с этими данными делать (ввиду того, что "ничего конкретного об этих data и key сказать уже нельзя"). Чтобы принять решение об определенных действиях над данными объекта Node (учитывая конструктивные особенности этого объекта), он должен, наверное, иметь специализацию для конкретного класса Node — полученной на лету реализацией шаблонного класса, вроде, не обойтись?
A>А менеджер делать ничего и не должен, он должен только выделять и освобождать память под эти данные. Причём есть две операции выделения: под новый элемент и под копию уже существующего элемента.
Вообще, вопрос интересный, и дискуссию можно было бы продолжить. Но тема начинает потихоньку расползаться, а еще и работать надо.. В общем, удачи.
Здравствуйте, g_i, Вы писали:
g_i>Вообще, вопрос интересный, и дискуссию можно было бы продолжить. Но тема начинает потихоньку расползаться, а еще и работать надо.. В общем, удачи.
У нас ещё будет такая возможность Некоторая часть кода скорее всего будет выставлена в форуме Исходники