Я не пойму - Вы делаете очередь для какого-то частного случая, или - в библиотеку для использования потом где угодно? :-)
Если для частного, на хрена вообще тратить время на приоритет, если он сейчас не нужен? Вы сначала заделали что-то про запас, возможно потеряли эффективность и усложнили имплементацию - без немедленной нужды. А сами говорите об экономии времени.
Если для общего, то почему Вы так смело расчитываете, сколько в этой очереди будет сообщений? И токуда известно, насколько этот сбереженный час важен? Может, мы ее потом вставим в навигацию самолета, где от кучи датчиков будет нестись хренова туча информации и она захлебенется на ту самую долю секунды?
И что за идея (высказанная там, наверху) - диктовать клиенту своего кода дизайн через интерфейс? Вы же не настаиваете, чтобы класс vector имел функцию "internalMutexLock()", чтобы напомнить разработчику, что иногда и запереть неплохо?
Кстати, каким образом "В случае, когда у меня высокоприоритетных обьектов существенно меньше, чем низкоприоритетных, время их вставки в очередь будет не O(logN), а O(K), где K - количество высокоприоритетных обьектов"? Что там внутре?
В любом случае - суть моих возражений в том, что FIFO и очередь с приоритетом - это разные вещи. Это не есть плохая и хорошая имплементации одной вещи. И использовать одну, где нужна другая - "про запас" странно.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2003-05-29 03:25 pm (UTC)Я не пойму - Вы делаете очередь для какого-то частного случая, или - в библиотеку для использования потом где угодно? :-)
Если для частного, на хрена вообще тратить время на приоритет, если он сейчас не нужен? Вы сначала заделали что-то про запас, возможно потеряли эффективность и усложнили имплементацию - без немедленной нужды. А сами говорите об экономии времени.
Если для общего, то почему Вы так смело расчитываете, сколько в этой очереди будет сообщений? И токуда известно, насколько этот сбереженный час важен? Может, мы ее потом вставим в навигацию самолета, где от кучи датчиков будет нестись хренова туча информации и она захлебенется на ту самую долю секунды?
И что за идея (высказанная там, наверху) - диктовать клиенту своего кода дизайн через интерфейс? Вы же не настаиваете, чтобы класс vector имел функцию "internalMutexLock()", чтобы напомнить разработчику, что иногда и запереть неплохо?
Кстати, каким образом "В случае, когда у меня высокоприоритетных обьектов существенно меньше, чем низкоприоритетных, время их вставки в очередь будет не O(logN), а O(K), где K - количество высокоприоритетных обьектов"? Что там внутре?
В любом случае - суть моих возражений в том, что FIFO и очередь с приоритетом - это разные вещи. Это не есть плохая и хорошая имплементации одной вещи. И использовать одну, где нужна другая - "про запас" странно.