Здравствуйте, so5team, Вы писали:

Тё>>

Тё>>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 годами стажа предъявить претензию о том, что они всю жизнь в таких местах колупаются.
Только вот ваш уровень можно сравнить не с проктологом, а скорей с ассенизатором.