BlockingQueue interface...
Oct. 30th, 2011 01:25 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
juan_gandhiОн не должен существовать! Это дебилизм.
Предположим, у вас есть класс
1. Для производителя
2. Для потребителя
И было бы идиотизмом предъявлять сразу два; вместо этого, надо иметь что-то вроде:
Очевидно, когда сказано, верно?
Только называть его надо не так; для консьюмера, что это очередь, не волнует; это просто
Что делает её блокирующей - это имплементация; но это не должно особо трахать ни ту ни другую сторону, они должны быть агностичны. Деметра, блин!
Предположим, у вас есть класс
BlockingQueueMyBestAttempt; и вам надо его показывать производителям и потребителям. Так какого, извините, хуя вы должны показывать сразу оба интерфейса? У блокирующей очереди два интерфейса.1. Для производителя
2. Для потребителя
И было бы идиотизмом предъявлять сразу два; вместо этого, надо иметь что-то вроде:
BlockingQueue.ConsumerViewBlockingQueue.ProducerViewОчевидно, когда сказано, верно?
Только называть его надо не так; для консьюмера, что это очередь, не волнует; это просто
Source, и вовсе не обязательно его использовать в блокирующем виде; а для продьюсера это Drain, и, вообще говоря, вовсе не блокирующий. Что делает её блокирующей - это имплементация; но это не должно особо трахать ни ту ни другую сторону, они должны быть агностичны. Деметра, блин!
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2011-10-30 08:32 pm (UTC)у Queue есть offer и poll, которые реализуют "неблокирующие" обращения, вроде add и remove; т.е. если add не работает (из-за ограничений по размеру, например), то и offer не работает.
далее вам нужно отличить offer от put.
no subject
Date: 2011-10-30 08:35 pm (UTC)no subject
Date: 2011-10-31 08:31 am (UTC)no subject
Date: 2011-10-30 08:36 pm (UTC)no subject
Date: 2011-10-30 09:01 pm (UTC)Странен, странен этот мир.
no subject
Date: 2011-10-30 10:27 pm (UTC)class BlockingQueue { public: class ConsumerView { public: int consumerMethod() { return parent_->consumerMethod(); } protected: friend class BlockingQueue; ConsumerView(BlockingQueue *parent): parent_(parent) { } BlockingQueue *parent_; }; ConsumerView consumerView() { return this; } BlockingQueue() { } protected: friend class ConsumerView; friend class ProducerView; int consumerMethod() { return 1; } }; int main() { BlockingQueue q; printf("%d\n", q.consumerView().consumerMethod()); }Но толку от этого нету помимо проблем. Просто в определении класса поделить методы на группы - проще и полезнее. Например так:
class BlockingQueue { public: BlockingQueue() { } // *********************** consumer methods *********************** int consumerMethod() { return 1; } // *********************** producer methods *********************** int producerMethod() { return 2; } };Другое дело, что часто хочется сделать разные группы методов доступными для разных friend-классов.
no subject
Date: 2011-11-01 06:04 am (UTC)no subject
Date: 2011-11-01 02:13 pm (UTC)no subject
Date: 2011-10-30 10:29 pm (UTC)no subject
Date: 2011-10-30 11:07 pm (UTC)no subject
Date: 2011-10-31 02:12 am (UTC)просто давать хендлеры (типа объекты функции)
продьюсеру - на "положить"
консьюмеру - на "взять"
и реально не парит никого что там за реализация внутри у этих функций
no subject
Date: 2011-10-31 03:41 am (UTC)no subject
Date: 2011-10-31 08:37 am (UTC)1. what you declare (в т.ч. множ. наследование)
2. what I need
так вот, разница между 1 и 2 в том, что what I need в точности никто не реализует (а потому не declare). Но хорошо бы иметь способ объявить, что меня интересуют объекты, реализующие вот такие и сякие методы (объявление method signature) с вот такой и сякой семантикой (документация); у кого такие методы есть - они мне подходят. В скале, например, есть такое; кажется, constructed type называется.
В таком setting не нужно, чтобы дизайнер очереди догадался раскрошить наследование на всякие мелочи с разной группировкой одних и тех же методов. Достаточно объявить в типе аргумента, какая группа методов вас интересует.
особенно интересно про блокирующее/неблокирующее
Date: 2011-10-31 03:43 am (UTC)ну обратился он к очереди а там нет ничего, что он должен делать
Re: особенно интересно про блокирующее/неблокирующее
Date: 2011-10-31 01:48 pm (UTC)no subject
Date: 2011-10-31 08:00 am (UTC)no subject
Date: 2011-10-31 01:49 pm (UTC)no subject
Date: 2011-10-31 01:52 pm (UTC)no subject
Date: 2011-11-01 03:56 am (UTC)