есть такая ситуация.
существует класс Channel, который получается путем разбора строк файла.
у него есть Name и список Event'ов (так называется программа или фильм)

файл должен иметь примерно такой вид:



но, поскольку файл пишется человеком, то возможны опечатки и какая-то строка не будет подходить под общий вид Event'а, и поэтому будет считаться мусором (Garbage). Но и мусор мне также нужно хранить, чтобы человек его мог исправить.

Иерархия у меня такова:



для того, чтобы вывести Channel в виде строки я использую полиморфизм и вызываю функцию

для каждого элемента контейнера по очереди

но если мне нужно в классе Channel повызывать функцию, к примеру

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

Ну вот и сам вопрос - заблуждаюсь ли я где-то здесь? 


ЗЫ Если чето неясно, уточню. К функциям не придираться, в реальности они чуть более оптимизированны.

Очень точная фраза :\. 

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

постараюсь поточнее:


если кому не жалко времени - как нужно сделать лучше (проще)?

Alek86, 
в IPart описать метод, который возвращает уникальное число, идентифицирующее класс объекта
в Channel вызывать его и сравнивать результат с числом, идентифицирующим нужный класс
думаю, будет эффективнее

Ты так и не объяснил, зачем тебе нужен dynamic_cast 


Если имеется в виду имитация RTTI посредством виртуальных вызовов, то добиться таким трюком прироста производительности можно разве что при кривом компиле, который неэффективно реализует RTTI  Например, на MinGW я разницы не заметил (правда, сравнивал не с dynamic_cast, а с typeid).

обоснуй
GCC, к примеру, генерирует вот такой код (для вызова виртуального метода)

код крайне эффективный на самом деле
RTTI можно реализовать быстрее?
соглашусь, если приведешь описание реализации в каком-нибудь компиляторе

Это сообщение отредактировал(а) MAKCim - 6.11.2007, 12:24

чтобы циклом пройтись по контейнеру и преобразовать IPart в Event, чтобы вызвать Event::GetTime




то есть, на моем месте примерно такой бы "проект" у проги и был? ведь, ка я понял, суть такая же, как и у динамик каста....

Я не вижу никаких преград для эффективной реализации оператора typeid, работу которого предполагается имитировать с помощью виртуальных вызовов.


Чем строить голые теории, лучше просто замерить время, затрачиваемое на сравнение по typeid и на сравнение по id, возвращённому виртуальной функцией.

Вот грубый замер:


У меня выводится 0.92 


Это сообщение отредактировал(а) UnrealMan - 6.11.2007, 21:10

Ыыы, Alek86, ты в теме в которой грозишься создать другую тему предупреждай, если создаёшь .


Один фиг, что dynamic_cast, что это число . Только dynamic_cast будет работать стабильно а возвратить число можно "забыть"(или ещё как-нибудь закосячить) .


По теме:
1. возвращать "плохое" время в случае, если это мусор.
2. добавить возможность(если её нет) редактирования(исправления ошибок) не только мусора, но и нормальных событий(человек может написать нормально оформленный файл, но ошибиться в имени фильма, к примеру).

Тогда надобность в интерфейсе и, соответственно, в dynamic_cast'ах исчезнет.

Добавлено через 2 минуты и 6 секунд
К слову, мне сейчас много приходится работать с интерфейсами, но dynamic_cast'ами не пользуюсь, ибо, либо интерфейс включает в себя всё необходимое для взаимодействия с объектом, либо нужны разные интерфейсы/сущности(либо интерфейсы не нужны вообще).

звыняюсь, забылся

дело-то все в том, что эти классы нужны в 2х случаях:

1. показывать ошибки человеку. Для этого надло преобразовывать в строку и кидать в ричэдит

2.
 а) проверять "логику". к примеру, отсортировать события по времени 
 б) преобразовывать то, что он начепятал, в нужный мне формат (бинарный файл)
для этого нужно манипулировать std::string'ами и byte'ами

имхо, самое "естесственное" решение тут - это чтобы 1 класс (Event) хранил в себе данные, а имел 2 интерфейса для отображения в этих 2х случаях...

может, ты подскажешь, как в этом нетрудном примере (3 класса) ты бы спроектировал прогу? хоть на пальцах, чтоб я понял, ато 

уж очень обтекаемо ((

bool hasMistake();


При сортировке выкидывать те которые has mistake.


Очень даже вписывается в предыдущие два пункта.



Вопрос дня: а зачем нужны аж два интерфейса? Предполагаются другие реализации этого класса?



Опа а 3 класса откуда взялось? 

Короче говоря, попробуй описать логику более полно, но не особо вдаваяся в ненужные подробности. Думаю ответ до тебя дойдёт сам собой, но, если не осенит, то мы обязательно тебе подскажем .

боюсь, сильно это долго... ((
сама эта вещь (распознание телепрограммы) большая, и я привел мелкий ее кусок для примера.

к примеру


не выйдет, так как пользователю инфа выдается в ричэдите, где ошибки выделены красным. а само событие "в реале" состоит их времени и имени, причем в запись времени также может вкрасться ошибка ("25:34")тогда красным выделится только "25". и так далее. то есть нужно из класса получать строку и какую-то структуру с указанием, в каких местах в этой строке ошибки, а не просто "ошибка есть".



не в том дело. дело в том, что в реале и сам Channel является релизацией интерфейса IPart, поскольку есть еще и список каналов 






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

А нельзя сразу вытягивать отформатированную строку(с указаниями ошибок, если нужно)?



Нее, что-то тут не ладно... Ты не по тому признаку обобщал .


Дам последнее напутствие.

В том виде в каком это у тебя есть сейчас(все являются наследниками IPart) - это паттерн Композиция(если немного видоизменить). По сути, к нему можно очень просто прикрутить Визитора, но там как-раз таки dynamic_cast'ы повсюду .

В общем, решай сам. Либо у тебя будут перенасыщенные интерфейсы, либо тебе придётся применять dynamic_cast, либо тебе придётся перепроектировать.


зы. Неужели так много телепрограмм, что падает производительность из-за применения shared_ptr/dynamic_cast? 0_o

UnrealMan, 
а если упростить код?

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


потому я и "закрыл" тему, поскольку хрен я смогу объяснить что именно по тому признаку, что нужно  слишком много для этого рассказывать, а смысла в этом мало. главное, что убедился, что ничего криминального в проекте нету
так что спасибо всем за ответы

Это сообщение отредактировал(а) Alek86 - 7.11.2007, 00:03