История изменений

я к тому, что констант в программе вообще не должно быть.

Так... присвоения не нужны, константы не нужны... сразу скажи, что еще ненужно - мне чисто чтоб поржать.

тут не нужно придумывать. Всё уже придумано до нас.

Ну ладно, перефразирую: лучше б _нашел_ красивое решение без повторного присвоения

Что-то я не пойму, как твои SP освобождают память, которую выделил кто-то другой? Это же фундаментальный принцип: кто выделял память, тот и освободить должен!

Стандартным деаллокатором. Никаких подобных принципов не слышал. Может, это тоже твоя личная задумка?

А когда счётчик увеличивается? А почему счётчик не инкапсулирован в SP?

Увеличивается при создании нового SP на объект. А счетчик должен быть привязан к объекту или той области памяти, в которой он размещен, а не к указателю на нее, коих может быть много. Вот инкремент/декремент этого счетчика - да, инкапсулирован в SP.

это пример для лучшего понимания.

Вот и я привел формулы O(n) и O(log(n)) для лучшего понимания, но получил только непонимание. Если совсем на пальцах - то алгоритмы, выигрывающие по времени на больших объемах данных, как правило, проигрывают в производительности на малых входах.

я говорил про массив из 1000000, и из 1000000000. Откуда ты 20 взял?

У меня массив из максимум, 20 элементов. Если что, это идентификаторы плагинов. Их не может быть 1000000.

Факт заключается в том, что список максимов - это общий алгоритм

Еще раз: одна задача, даже такая тривиальная как поиск максимума, может иметь несколько алгоритмов. Какой из них является «общим»? И если я воспользовался не так называемым «общим», каким-нибудь другим - что в этом плохого?

Проблема в том, что возможно более правильное решение - изменять максимум не проверяя весь список, а в момент _изменения_ списка.

Вызывать мьютекс при каждом изменении, вместо того, чтобы воспользоваться тем, что уже защищает ресурс «лог»? Нет, это не есть более правильное решение.

А возможно, тебе тут надо два списка хранить - один по порядку, как уже есть, а второй по этому максимуму.

Написать кучу кода, возможно, небезглючного. Накладные расходы превысят время выполнение всей текущей операции логгирования - и все ради чего?

я к тому, что констант в программе вообще не должно быть.

Так... присвоения не нужны, константы не нужны... сразу скажи, что еще ненужно - мне чисто чтоб поржать.

тут не нужно придумывать. Всё уже придумано до нас.

Ну ладно, перефразирую: лучше б _нашел_ красивое решение без повторного присвоения

Что-то я не пойму, как твои SP освобождают память, которую выделил кто-то другой? Это же фундаментальный принцип: кто выделял память, тот и освободить должен!

Стандартным деаллокатором. Никаких подобных принципов не слышал. Может, это тоже твоя личная задумка?

А когда счётчик увеличивается? А почему счётчик не инкапсулирован в SP?

Увеличивается при создании нового SP на объект. А счетчик должен быть привязан к объекту или той области памяти, в которой он размещен, а не к указателю на нее, коих может быть много. Вот инкремент/декремент этого счетчика - да, инкапсулирован в SP.

это пример для лучшего понимания.

Вот и я привел формулы O(n) и O(log(n)) для лучшего понимания, но получил только непонимание. Если совсем на пальцах - то алгоритмы, выигрывающие по времени на больших объемах данных, как правило, проигрывают в производительности на малых входах.

я говорил про массив из 1000000, и из 1000000000. Откуда ты 20 взял?

У меня массив из максимум, 20 элементов. Если что, это идентификаторы плагинов. Их может быть 1000000.

Факт заключается в том, что список максимов - это общий алгоритм

Еще раз: одна задача, даже такая тривиальная как поиск максимума, может иметь несколько алгоритмов. Какой из них является «общим»? И если я воспользовался не так называемым «общим», каким-нибудь другим - что в этом плохого?

Проблема в том, что возможно более правильное решение - изменять максимум не проверяя весь список, а в момент _изменения_ списка.

Вызывать мьютекс при каждом изменении, вместо того, чтобы воспользоваться тем, что уже защищает ресурс «лог»? Нет, это не есть более правильное решение.

А возможно, тебе тут надо два списка хранить - один по порядку, как уже есть, а второй по этому максимуму.

Написать кучу кода, возможно, небезглючного. Накладные расходы превысят время выполнение всей текущей операции логгирования - и все ради чего?