Здравствуйте, Тёмчик, Вы писали:
S>>Вот реально не понимаю, как паттерн Visitor поможет при работе с C API. Ладно бы еще какой-нибудь Facade был упомянут, ну или Bridge хотя бы, но Visitor... Просветите старика, плиз. Тё>Дано: одно или несколько сторонних API. Нужно: сделать бесшовную интеграцию. Передаём visitor на нужное API. Это широко используемая практика в обработке данных от пачки разных API разных версий.
При нажатии на кнопку Ok нужно вызывать somelib_data_on_ready и передать в него указатель, полученный ранее при вызове somelib_data_destroy.
Каким образом здесь применим Visitor?
S>>По поводу накладных расходов все было уже расписано ранее, перечитайте. По поводу "мутно", если вам не понятно, то речь шла про понятность политки владения сущностями в вашем подходе. В C++ сборщика мусора нет. Возвращать голые владеющие указатели так себе способ. Тё>Можете сделать умный указатель для subscription.
Этого будет мало.
Тё>Да, C++ это боль.
У вас, похоже, это была боль. Даже нет, у вас это была БОЛЬ. Причем такая, что отзывается до сих пор.
>>>> Реалтаймовые системы не на плюсах делают.
S>>Ответили за звиздеж, да. Тё>Не на плюсах.
Вот опять звиздеж. Делают. В том числе и на современных. В том числе и с использованием кусков из STL. Ничего не мешает в рилтайм-коде использовать std::find, std::accumulate, std::array и подобный код. Да даже аллоцирующие контейнеры вроде vector, map, set можно применять, если они наполняются в момент инициализации приложения.
Если где-то до сих пор в рилтайме ограничиваются C++98, то, скорее всего, из-за отсутствия сертифицированных компиляторов с поддержкой более новых стандартов.
Тё>Вот вы влезли в тему событийной модели, которой я сейчас плотно занимаюсь (использую RxJs).
Да это очевидно, что сейчас у вас с RxJs конфетно-букетный период.
Здравствуйте, Тёмчик, Вы писали:
S>>Вот в этом случае, КМК, не будет проблем с временами жизни. Пока живет хотя бы одна подписка, остается живым объект SubscriptionStorage::Internals. Следовательно, деструкторы Subscription могут спокойно вычеркивать себя из списка подписок даже если сам объект SubscriptionStorage прекратил свое существование. С другой стороны, если все объекты Subscription разрушаются до того, как умрет SubscriptionStorage, то вообще никаких проблем: ссылка на SubscriptionStorage::Internals останется только у SubscriptionStorage и этот Internals умрет сразу вслед за SubscriptionStorage.
Тё>Да просто используй std::unique_ptr с кастомным Deleter.
Здесь не нужен кастомный Deleter для unique_ptr. И вы, походу, невкурили главное: кроме unique_ptr на Subscription нужно еще и выделение отдельного объекта Internals на который все участники будут ссылаться через shared_ptr. Только при этом получается более-менее надежная и безопасная схема владения.
Здравствуйте, so5team, Вы писали:
S>>>Вот реально не понимаю, как паттерн Visitor поможет при работе с C API. Ладно бы еще какой-нибудь Facade был упомянут, ну или Bridge хотя бы, но Visitor... Просветите старика, плиз. Тё>>Дано: одно или несколько сторонних API. Нужно: сделать бесшовную интеграцию. Передаём visitor на нужное API. Это широко используемая практика в обработке данных от пачки разных API разных версий.
S>Понятнее не стало. Вот есть C API вида: S>
S>При нажатии на кнопку Ok нужно вызывать somelib_data_on_ready и передать в него указатель, полученный ранее при вызове somelib_data_destroy.
onData(char[] buffer, int offset, int length, Reader *reader) {
// ... read envelope
reader.accept(envelope)
}
S>Каким образом здесь применим Visitor?
В вашем примитивном мирке, действительно, visitor не нужен. У вас нет API
S>>>По поводу накладных расходов все было уже расписано ранее, перечитайте. По поводу "мутно", если вам не понятно, то речь шла про понятность политки владения сущностями в вашем подходе. В C++ сборщика мусора нет. Возвращать голые владеющие указатели так себе способ. Тё>>Можете сделать умный указатель для subscription.
S>Этого будет мало.
unique_ptr с кастомным deleter-м достаточно.
Тё>>Да, C++ это боль.
S>У вас, похоже, это была боль. Даже нет, у вас это была БОЛЬ. Причем такая, что отзывается до сих пор.
Когда этим занимался, было привычно. Вы просто принюхались — посмотрите на более другие языки, где простейшие вещи не требуют титанических мозгозатрат.
>>>>> Реалтаймовые системы не на плюсах делают.
S>>>Ответили за звиздеж, да. Тё>>Не на плюсах.
S>Вот опять звиздеж. Делают. В том числе и на современных. В том числе и с использованием кусков из STL. Ничего не мешает в рилтайм-коде использовать std::find, std::accumulate, std::array и подобный код. Да даже аллоцирующие контейнеры вроде vector, map, set можно применять, если они наполняются в момент инициализации приложения.
Какой толк от "аллоцирующие контейнеры вроде vector, map, set", если они не могут аллцировать в момент работы приложения?
S>Если где-то до сих пор в рилтайме ограничиваются C++98, то, скорее всего, из-за отсутствия сертифицированных компиляторов с поддержкой более новых стандартов.
Тё>>Вот вы влезли в тему событийной модели, которой я сейчас плотно занимаюсь (использую RxJs).
S>Да это очевидно, что сейчас у вас с RxJs конфетно-букетный период.
Надеюсь, в течение нескольких месяцев текущий большой проект c RxJS уйдёт в суппорт, а я займусь новым green field проектом, возможно даже на другом языке. Хотя, TypeScript мне понравился.
А Вы так и будете булькаться на уровне "аллоцирующие контейнеры вроде vector, map, set".
S>>При нажатии на кнопку Ok нужно вызывать somelib_data_on_ready и передать в него указатель, полученный ранее при вызове somelib_data_destroy.
Тё>
Тё>onData(char[] buffer, int offset, int length, Reader *reader) {
Тё> // ... read envelope
Тё> reader.accept(envelope)
Тё>}
Тё>
Что это за кусок говна, пардон май френч? И каким боком этот кусок к вопросу о применимости Visitor для работы с C API?
S>>Каким образом здесь применим Visitor? Тё>В вашем примитивном мирке, действительно, visitor не нужен. У вас нет API
Т.е. вы в очередной раз публично обосрались?
S>>Этого будет мало. Тё>unique_ptr с кастомным deleter-м достаточно.
Нет. Но, похоже, у вас недостаточно знаний и понимания предмета.
S>>У вас, похоже, это была боль. Даже нет, у вас это была БОЛЬ. Причем такая, что отзывается до сих пор. Тё>Когда этим занимался, было привычно. Вы просто принюхались — посмотрите на более другие языки, где простейшие вещи не требуют титанических мозгозатрат.
Так и в C++ не требуют. Просто к C++ нужно относиться как к C++, к Java как к Java, к JavaScript-у как к JavaScript-у. И не пытаться натягивать сову на глобус.
S>>Вот опять звиздеж. Делают. В том числе и на современных. В том числе и с использованием кусков из STL. Ничего не мешает в рилтайм-коде использовать std::find, std::accumulate, std::array и подобный код. Да даже аллоцирующие контейнеры вроде vector, map, set можно применять, если они наполняются в момент инициализации приложения. Тё>Какой толк от "аллоцирующие контейнеры вроде vector, map, set", если они не могут аллцировать в момент работы приложения?
Они хранят данные, к которым вам нужно обращаться в процессе работы, ваш К.О.
И да, в рилтайме после инициализации и входа в рилтайм режим не аллоцируют вне зависимости от ЯП (будь то С, Ada или "Си с классами").
Тё>А Вы так и будете булькаться на уровне "аллоцирующие контейнеры вроде vector, map, set".
Вы так говорите, как будто в этом есть что-то плохое. Попробуйте еще урологу или проктологу с 30 годами стажа предъявить претензию о том, что они всю жизнь в таких местах колупаются.
Здравствуйте, so5team, Вы писали:
S>С простым копированием не так все просто: RemoveOnButtonPress может вызываться не только для удаления текущего обработчика, но и для любого другого. В том числе и для тех обработчиков, до которых внутри for_each-а пока не дошли. Если for_each будет идти по временному контейнеру, то получится, что во временном контейнере останется обработчик, который уже изъят из основного. И будет вызван. Что может сильно удивить пользователя, который этот обработчик только что изъял.
Это уже совсем странный use case. Но, теоретически возможный, да.
S>Тут нужна более хитрая схема. Например, с дополнительным флагом valid/invalid для каждой подписки. Если подписка удаляется в момент публикации (т.е. внутри for_each-а), то физически она не удаляется, а флаг для нее меняется на invalid (+ еще взводится отдельный флаг, который показывает, что список подписок изменился). Перед вызовом подписчика проверяется флаг для него. Если valid, то вызывается. Если invalid, то пропускается. После выхода из for_each-а публикации проверяется общий флаг наличия изменений в списке. Если изменения есть, то идет еще один цикл с изъятием всех invalid подписок.
А можно просто сказать, что из обработчика события безопасно отписывать можно только его самого. Иначе можно получить гонку.
Или перед вызовом колбэков копировать их не в вектор, а в очередь, и при отписке вычищать колбэк и из исходного вектора и из очереди. Впрочем, это уже будет не сильно проще, чем вариант с флагами.
S>А если добавить сюда еще и возможность вызова AddOnButtonPress в момент публикации, то ситуация становится еще интереснее. И, возможно, использование std::list вместо std::vector в таких условиях более оправдано, не смотря на все недостатки std::list-а.
Тут, как раз, в схеме c копированием все хорошо.
Ну и, в схеме с флагами этот кейс тоже не сложно обработать — вместо булевского флага сделать enum, в котором будут состояния по типу Ready, Deleted, New. В случае, когда мы в процессе вызова колбэка, добавлять не с Ready, а с New, а потом все New менять на Ready после завершения вызова колбэков. Ну и, естественно, вместо for each придется использовать обычный for по индексам.
Или просто запоминать размер вектора перед вызовом первого колбэка. И ограничить цикл по колбэкам этим размером (все, что может добавиться в процессе, просто не будет вызвано).
Тё>>onData(char[] buffer, int offset, int length, Reader *reader) {
Тё>> // ... read envelope
Тё>> reader.accept(envelope)
Тё>>}
Тё>>
S>Что это за кусок говна, пардон май френч? И каким боком этот кусок к вопросу о применимости Visitor для работы с C API?
Вы безнадежны .
S>>>Каким образом здесь применим Visitor? Тё>>В вашем примитивном мирке, действительно, visitor не нужен. У вас нет API
S>Т.е. вы в очередной раз публично обосрались?
Вам из Бабруйска виднее.
S>>>Этого будет мало. Тё>>unique_ptr с кастомным deleter-м достаточно.
S>Нет. Но, похоже, у вас недостаточно знаний и понимания предмета.
Вы зачем-то пытаетесь притянуть shared_ptr. Зачем? Если вы его суете во все дыры, — это ещё не значит, что его нужно сувать во все дыры. И кроме того, даже shared_ptr можно реализовать без разделяемого счётчика на куче. Но вы же этого ничего не знаете.
S>Так и в C++ не требуют. Просто к C++ нужно относиться как к C++,
Ещё раз. Когда я писал на C++, ни у кого не было претензий к моему уровню, и максимальные баллы на тестах это подтверждали. Вы же просто сынок в сравнении с нормальным C++ м.
S>>> аллоцирующие контейнеры вроде vector, map, set можно применять, если они наполняются в момент инициализации приложения. Тё>>Какой толк от "аллоцирующие контейнеры вроде vector, map, set", если они не могут аллцировать в момент работы приложения?
S>Они хранят данные, к которым вам нужно обращаться в процессе работы, ваш К.О.
RO-данные можно загружать в удобоваримой форме. Но откуда вам знать про это- вы же ничего в структурах данных и алгоритмах не понимаете. Весь интеллект потрачен на хождение по граблям.
S>Вы так говорите, как будто в этом есть что-то плохое. Попробуйте еще урологу или проктологу с 30 годами стажа предъявить претензию о том, что они всю жизнь в таких местах колупаются.
Только вот ваш уровень можно сравнить не с проктологом, а скорей с ассенизатором.
Здравствуйте, Тёмчик, Вы писали:
Тё>Вы безнадежны .
Безнадежен тут только ты. Ты даже не попытался объяснить, каким боком приведенный кусок кода относится к поставленной задаче. И зачем в нем нужен визитор, а не просто какой-то интерфейс, выполняющий роль колбэка.
Тё>Вы зачем-то пытаетесь притянуть shared_ptr. Зачем?
Тебе вполне популярно объясняли зачем, но ты не понял. В предложенной тобой схеме каждый Subscription должен владеть списком подписок. Иначе список подписок может неожиданно помереть, а подписки об этом даже не узнают.
Тё>Если вы его суете во все дыры, — это ещё не значит, что его нужно сувать во все дыры. И кроме того, даже shared_ptr можно реализовать без разделяемого счётчика на куче. Но вы же этого ничего не знаете.
Да, несомненно, сокровенное знание про make_shared доступно только тебе. И интрузивных поинтеров никто кроме тебя в своей жизни не писал.
Тё>Ещё раз. Когда я писал на C++, ни у кого не было претензий к моему уровню, и максимальные баллы на тестах это подтверждали. Вы же просто сынок в сравнении с нормальным C++ м.
Это прекрасно. Правда, в этом свете не очень понятно, почему ты сейчас демонстрируешь крайне низкий уровень понимания C++. И практически полное отсутствие самокритики.
Тё>RO-данные можно загружать в удобоваримой форме. Но откуда вам знать про это- вы же ничего в структурах данных и алгоритмах не понимаете. Весь интеллект потрачен на хождение по костылям.
Внезапно, чаще всего эта удобоваримая форма как раз и соответствует вектору, unordered map'у или map'у, или их комбинациям. То, что ты этого не знаешь, говорит только о твоем опыте использования C++, и ни о чем больше.
Тё>Только вот ваш уровень можно сравнить не с проктологом, а скорей с ассенизатором.
Откровенное хамство никак не добавляет веса твоим словам.
Здравствуйте, Lexey, Вы писали:
L>Безнадежен тут только ты. Ты даже не попытался объяснить, каким боком приведенный кусок кода относится к поставленной задаче. И зачем в нем нужен визитор, а не просто какой-то интерфейс, выполняющий роль колбэка.
Визитор, внезапно, это колбек.
Тё>>Вы зачем-то пытаетесь притянуть shared_ptr. Зачем?
L>В предложенной тобой схеме каждый Subscription должен владеть списком подписок.
Каждая подписка должна владеть списком подписок? Ты сам-то понял, что написал?
Кто чем владеет- не обсуждалось.
Можно сделать, что если Observable удалён раньше, чем последняя подписка- отцепить его sentinel от циклического списка и оставить неотписавшихся висеть в памяти. Когда неотписавшиеся отпишутся, они себя очистят.
Тё>>Если вы его суете во все дыры, — это ещё не значит, что его нужно сувать во все дыры. И кроме того, даже shared_ptr можно реализовать без разделяемого счётчика на куче. Но вы же этого ничего не знаете.
L>Да, несомненно, сокровенное знание про make_shared доступно только тебе. И интрузивных поинтеров никто кроме тебя в своей жизни не писал.
Ещё один безграмотный. Речь про shared_ptr без разделяемого счётчика на куче.
Тё>>Ещё раз. Когда я писал на C++, ни у кого не было претензий к моему уровню, и максимальные баллы на тестах это подтверждали. Вы же просто сынок в сравнении с нормальным C++ м.
L>Это прекрасно. Правда, в этом свете не очень понятно, почему ты сейчас демонстрируешь крайне низкий уровень понимания C++. И практически полное отсутствие самокритики.
Перечисление граблей- это по-твоему понимание C++? Ну так тогда ты на 100% попадаешь под моё описание C++ ка.
Тё>>RO-данные можно загружать в удобоваримой форме. Но откуда вам знать про это- вы же ничего в структурах данных и алгоритмах не понимаете. Весь интеллект потрачен на хождение по костылям.
L> Внезапно, чаще всего эта удобоваримая форма как раз и соответствует вектору, unordered map'у или map'у, или их комбинациям. То, что ты этого не знаешь, говорит только о твоем опыте использования C++, и ни о чем больше.
Если тебе использование C++ разжижило мозг, то это твоя проблема. Ибо на массиве, r-b tree и hash map, структуры данных не заканчиваются.
L>Откровенное хамство никак не добавляет веса твоим словам.
Взаимно.
Здравствуйте, Lexey, Вы писали:
L>А можно просто сказать, что из обработчика события безопасно отписывать можно только его самого. Иначе можно получить гонку.
Есть ощущение, что автор кода пошел еще по более простому пути: тупо сказал, что внутри коллбэков изменение подписки делать нельзя!
Зато решение получилось компактным и простым, сходу видно, что с ним делать можно, а чего нет.
Тё>>>onData(char[] buffer, int offset, int length, Reader *reader) {
Тё>>> // ... read envelope
Тё>>> reader.accept(envelope)
Тё>>>}
Тё>>>
S>>Что это за кусок говна, пардон май френч? И каким боком этот кусок к вопросу о применимости Visitor для работы с C API? Тё>Вы безнадежны .
Вряд ли безнадежен тот, кто открыто говорит о непонимании.
Скорее уж тот, кто надувает щеки и не может внятно объяснить, что он имел в виду.
Тем более, что есть серьезные подозрения, что надувание щек в данном случае -- это лишь попытка замять предложение использовать Visitor там, где от него толку нет вообще.
S>>>>Каким образом здесь применим Visitor? Тё>>>В вашем примитивном мирке, действительно, visitor не нужен. У вас нет API
S>>Т.е. вы в очередной раз публично обосрались? Тё>Вам из Бабруйска виднее.
Пока что получается именно так.
Тё>Вы зачем-то пытаетесь притянуть shared_ptr. Зачем? Если вы его суете во все дыры, — это ещё не значит, что его нужно сувать во все дыры. И кроме того, даже shared_ptr можно реализовать без разделяемого счётчика на куче. Но вы же этого ничего не знаете.
А там как бы и нет разделяемого счетчика на куче.
S>>Так и в C++ не требуют. Просто к C++ нужно относиться как к C++, Тё>Ещё раз. Когда я писал на C++, ни у кого не было претензий к моему уровню, и максимальные баллы на тестах это подтверждали.
Вопрос только в том, кто был проверяющим для вашего кода. И были ли они вообще.
Тё>Вы же просто сынок в сравнении с нормальным C++ м.
Еще раз: моего кода в открытом доступе полно, эдак с пару-тройку десятков тысяч строк. Каждый может посмотреть и сделать собственные выводы.
S>>Они хранят данные, к которым вам нужно обращаться в процессе работы, ваш К.О.
Тё>RO-данные можно загружать в удобоваримой форме.
Речь не идет про RO-данные, актитесь.
Тё>Но откуда вам знать про это- вы же ничего в структурах данных и алгоритмах не понимаете.
Мне уже много годиков и работа моя заключается далеко не только (и не столько) в написании кода. Так что мне простительно.
А вот вы несете откровенную херню явно не то, что не разбираясь в предмете, но даже и близко никогда рядом не находившись, вот это доставляет.
Тё>Только вот ваш уровень можно сравнить не с проктологом, а скорей с ассенизатором.
Хоть с ассенизатором, хоть с мусорщиком, хоть с трубочистом. Тут ведь главное что? Что когда мы перестаем работать, вы сразу же оказываетесь в полном дерьме.
Здравствуйте, so5team, Вы писали:
S>Вряд ли безнадежен тот, кто открыто говорит о непонимании.
Вы напоминаете одного, даже двух коллег из exUSSR. Им 20 раз повторили, но продолжает упорно твердить "не понимаю".
S>Скорее уж тот, кто надувает щеки и не может внятно объяснить, что он имел в виду.
Это вы не можете понять.
S>Тем более, что есть серьезные подозрения, что надувание щек в данном случае -- это лишь попытка замять предложение использовать Visitor там, где от него толку нет вообще.
Вы его не умеете готовить. В общем-то, закрадываются сомнения, а что вы можете готовить.
Тё>>Вы зачем-то пытаетесь притянуть shared_ptr. Зачем? Если вы его суете во все дыры, — это ещё не значит, что его нужно сувать во все дыры. И кроме того, даже shared_ptr можно реализовать без разделяемого счётчика на куче. Но вы же этого ничего не знаете.
S>А там как бы и нет разделяемого счетчика на куче.
Уже нет? Но почему тогда вы утверждали про выделение на куче под умный указатель?
S>Вопрос только в том, кто был проверяющим для вашего кода. И были ли они вообще.
Мой код был идеален и без review
Тё>>Вы же просто сынок в сравнении с нормальным C++ м.
S>Еще раз: моего кода в открытом доступе полно, эдак с пару-тройку десятков тысяч строк. Каждый может посмотреть и сделать собственные выводы.
Мне лень ковыряться в вашем коде в открытом доступе. Несколько лет назад на рсдн была эпическая битва вас с вашей библиотекой, и оппонента с чужой библиотекой на Java. Вы тогда тоже упорно ничего не понимали и твердили про превосходство C++, в то время как та жавская библиотека использовалась в матчере на бирже, до таких требований у вас в Бобруйске не дорастут никогда.
S>>>Они хранят данные, к которым вам нужно обращаться в процессе работы, ваш К.О.
Тё>>RO-данные можно загружать в удобоваримой форме.
S>Речь не идет про RO-данные, актитесь.
У вас данные, к которым вам нужно обращаться в процессе работы, ещё и изменяются? В ядре? C аллокаторами и т.д. Да вы бредите.
Тё>>Но откуда вам знать про это- вы же ничего в структурах данных и алгоритмах не понимаете.
S>Мне уже много годиков и работа моя заключается далеко не только (и не столько) в написании кода. Так что мне простительно.
Так вы ещё и руками водитель. Вот откуда берутся неадекватные компании с C++.
S>А вот вы несете откровенную херню явно не то, что не разбираясь в предмете, но даже и близко никогда рядом не находившись, вот это доставляет.
Юноша, я кодил C++ и скрещивал с другими языками, ещё когда вы в первый класс ходили. А с событийной моделью работаю прямо сейчас. И visitor я использовал для собряжения интерфейсов и форматов при получении и конвертации данных. Поэтому я ответственно заявил — код с addButtonSubscription, deleteButtonSubscription — полное говно. Куда на какой сайт идти и что читать до просветления- указал. Хотите- просвещайтесь, не хотите- булькайтесь в своём копролите.
Тё>>Только вот ваш уровень можно сравнить не с проктологом, а скорей с ассенизатором.
S>Хоть с ассенизатором, хоть с мусорщиком, хоть с трубочистом. Тут ведь главное что? Что когда мы перестаем работать, вы сразу же оказываетесь в полном дерьме.
Вам, скинули копролит мамонта поддерживать, вы и рады.
Не всем это интересно. Кому-то интересно делать новые проекты, изучать новые технолигии, (старые) алгоритмы, и т.д.
Здравствуйте, Тёмчик, Вы писали:
S>>Скорее уж тот, кто надувает щеки и не может внятно объяснить, что он имел в виду. Тё>Это вы не можете понять.
Так вы и не пробовали объяснить. Попробуйте, попытка не пытка.
Только вот шансы, что вы вновь обосретесь, но надуете щеки и сделаете вид, что не вы, близки к 100%.
S>>Тем более, что есть серьезные подозрения, что надувание щек в данном случае -- это лишь попытка замять предложение использовать Visitor там, где от него толку нет вообще. Тё>Вы его не умеете готовить. В общем-то, закрадываются сомнения, а что вы можете готовить.
Если вы можете готовить, то что вам мешает показать вменяемый кусок кода? Задача простая, есть C API вот такого вида:
При нажатии на кнопку Ok нужно вызывать somelib_data_on_ready и передать в него указатель, полученный ранее при вызове somelib_data_create. Покажите как, по вашему мнению, здесь может быть применен Visitor.
S>>А там как бы и нет разделяемого счетчика на куче. Тё>Уже нет?
Код посмотрите, тaм все сказано.
Тё>Но почему тогда вы утверждали про выделение на куче под умный указатель?
Цитату можно?
S>>Вопрос только в том, кто был проверяющим для вашего кода. И были ли они вообще. Тё>Мой код был идеален и без review
"Ну и вы говорите, говорите" (c)
Тё>Несколько лет назад на рсдн была эпическая битва вас с вашей библиотекой, и оппонента с чужой библиотекой на Java. Вы тогда тоже упорно ничего не понимали и твердили про превосходство C++, в то время как та жавская библиотека использовалась в матчере на бирже, до таких требований у вас в Бобруйске не дорастут никогда.
Если вы не поленитесь и поднимите этот разговор, то вряд ли найдете там утверждения про превосходство C++. И да, если наша библиотека под рилтайм не заточена, то какой смысл ее сравнивать с тем, что под конкретный сценарий использования затачивалось (речь про Distruptor) мне лично непонятен.
S>>Речь не идет про RO-данные, актитесь. Тё>У вас данные, к которым вам нужно обращаться в процессе работы, ещё и изменяются?
При необходимости. Конечно же.
Тё>В ядре?
Тёмчик, мы про реальное время говорим, не про ядро. Одно к другому не относится.
Тё>C аллокаторами и т.д. Да вы бредите.
Зачем для изменения данных нужны аллокаторы?
Тё>Юноша, я кодил C++ и скрещивал с другими языками, ещё когда вы в первый класс ходили.
Тёмчик, вам же лет около 40? Не слишком ли вы молоды, чтобы незнакомых людей юношами называть?
Здравствуйте, Тёмчик, Вы писали:
Тё>Визитор, внезапно, это колбек.
Угу, только вот, внезапно, колбэк не обязан быть визитором. И никаких аргументов в пользу того, что тут нужен именно визитор, а не простой указатель на функцию или std::function, например, от тебя не наблюдается.
L>>В предложенной тобой схеме каждый Subscription должен владеть списком подписок. Тё>Каждая подписка должна владеть списком подписок? Ты сам-то понял, что написал?
Я-то прекрасно понял. Потому что решал подобные задачи на практике. А вот ты упорно не понимаешь проблему.
Тё>Кто чем владеет- не обсуждалось.
Эта тема поднималась, только ты с нее соскочил на наезды на детали реализации. Исходная схема, когда единой точкой входа и для подписок и для отписок являлся менеджер подписок, тебя не устроила. Ты вместо нее предложил схему, где отпиской управляет отдельный объект Subscription, и про менеджер после подписки можно забыть. Вот и получил необходимость поддерживать жизнь списка подписок через Subscription'ы, а не только через менеджер.
Тё>Можно сделать, что если Observable удалён раньше, чем последняя подписка- отцепить его sentinel от циклического списка и оставить неотписавшихся висеть в памяти. Когда неотписавшиеся отпишутся, они себя очистят.
Ну, то есть, мы возвращаемся к тому, что при отписке никакого сентинела может уже не быть, и это нужно учитывать. И нафига он тогда вообще нужен? Это не говоря о том, что в реальной жизни помимо списка подписок и сентинела почти наверняка нужны будут какие-то вспомогательные флаги/мьютексы/т.п.
Тё>Ещё один безграмотный. Речь про shared_ptr без разделяемого счётчика на куче.
Сам ты безграмотный. Ты можешь, наверное, написать аллокатор, который будет хранить счетчик в статической памяти, например. Или написать свой shared_ptr, который будет его хранить хрен знает где (в TLS, например). Только, это никому не нужно, ибо через make_shared счетчик спокойно аллоцируется в той же памяти, что и объект, которым владеет shared_ptr. А в случае интрузивных поинтеров счетчик просто является частью объекта.
Тё>Перечисление граблей- это по-твоему понимание C++? Ну так тогда ты на 100% попадаешь под моё описание C++ ка.
Если тебе всюду мерещатся грабли, то с этим к психиатру надо бы.
Тё>Если тебе использование C++ разжижило мозг, то это твоя проблема. Ибо на массиве, r-b tree и hash map, структуры данных не заканчиваются.
Мне оно мозг, наоборот, укрепило. Например, я не пытаюсь пихать сомнительные паттерны везде, где только можно. И не хватаюсь использовать сторонние библиотеки только потому, что они выглядят красивее, чем кастомные решения. И главное, не считаю себя умнее всех.
Что касается структур данных, то тут можно вспомнить классическое "правило" 80/20: >80% кейсов покрываются именно векторами, хеш-мапами и упорядоченными мапами.
Здравствуйте, Lexey, Вы писали:
L>Что касается структур данных, то тут можно вспомнить классическое "правило" 80/20: >80% кейсов покрываются именно векторами, хеш-мапами и упорядоченными мапами.
Здравствуйте, so5team, Вы писали:
L>>Что касается структур данных, то тут можно вспомнить классическое "правило" 80/20: >80% кейсов покрываются именно векторами, хеш-мапами и упорядоченными мапами. S>Золотые слова. Вот прям спасибо.
Кстати, добавлю — недавно понадобилось иметь std::map или std::set, который заполняются лишь однажды и потом почти никогда не модифицируются, но в котором нужно очень иногда искать по ключу, но постоянно приходится просто итерировать.
В закромах буста обнаружился flat_map и flat_set. Вот прям что надо было.
Здравствуйте, landerhigh, Вы писали:
L>Кстати, добавлю — недавно понадобилось иметь std::map или std::set, который заполняются лишь однажды и потом почти никогда не модифицируются, но в котором нужно очень иногда искать по ключу, но постоянно приходится просто итерировать.
Ага, частый юзкейс.
Положить в массив, отсортировать и std::lower_bound() на него.
Можно всё обернуть в класс и выставить удобный апи наружу.
Делается легко и непринуждённо.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Nuzhny, Вы писали:
L>>В закромах буста обнаружился flat_map и flat_set. Вот прям что надо было. N>Оно в С++20, к сожалению, они не попали.
Ну, я не бустофоб, так что проблема так себе.
Вот чему я удивился, так тому, что корутины, которые вошли в двадцатку — stackless.
Здравствуйте, Тёмчик, Вы писали:
S>>Тем более, что есть серьезные подозрения, что надувание щек в данном случае -- это лишь попытка замять предложение использовать Visitor там, где от него толку нет вообще. Тё>Вы его не умеете готовить. В общем-то, закрадываются сомнения, а что вы можете готовить.
Наверное я понял, причем здесь Visitor. Вы же кроме Visitor-а ничего-то и не знаете. А про сам Visitor, узнали всего лишь несколько лет назад: http://rsdn.org/forum/job/7263272.1
проходя собеседование в контору, в которую вас не взяли из-за проваленного тестового задания. Проваленного, скорее всего, из-за плохого владения плюсами (как выяснилось здесь: http://rsdn.org/forum/job/7262279
Да и озвученный два года назад вопрос все еще остается очень актуальным: "Как? Как можно много лет программировать на C++ и Java и узнать про Visitor только в 2016-ом?"
.
