есть такая ситуация.
существует класс 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

Ыыы... Преждевременная оптимизация - корень всех зол © Дональд Кнут.
Если нет причин беспокоиться о производительности, то беспокоиться не нужно. Если причины есть, то в первую очередь беспокоиться нужно о сложности алгоритма и, уж конечно, в последнюю очередь нужно беспокоиться о быстродействии одинаковых по асимптотической сложности конструкций.

он имел в виду писание кода с оптимизацией
а в моем случае это выбор алгоритма из подобных.

Алгоритмы то с одинаковой сложность, так что выбирать можно любой .

Alek86, 
Я привык считать, что появление необходимости в dynamic_cast свидетельствует о плохом проектировании. (Хотя, разумеется, есть исключения)
Плюс, нередко, быть "насмерть" уверенным в каких-то частях проектирования, значит связывать себе руки. Когда я говорю "тут все круто, просто долго объяснять", это значит, что я просто запарился над этим думать.... А оптимальное решение в итоге показывает, как все было не круто.   
По поводу данной задачи я подробно не вникал, ибо поздно. Но навскид приходит идея, что раз Event и Garbage получаются такими разными сущностями, то почему бы их не хранить раздельно в двух векторах? Или если, нужно сохранить их последовательность относительно друг друга, то в двух мэпах, типа std::map<int, Event> и std::map<int, Garbage>, где int - это абсолютный порядковый номер...


Это сообщение отредактировал(а) SaDFromSpb - 7.11.2007, 04:28

согласен. и более того, я ЗНАЮ, что у меня все не круто, хотя бы потому что опыта в проектировании ООП'ных приложений почти нету. Но писать огромные описания проблемы, чтоб за меня тут проектировали все полностью, не считаю нужным  я попробовал описать кусок проблемы...



они не разные сущности, так что надо вкупе



мое IMHO это изврат, намного похуже динамик каста. динамик каст хранит id класса и по нему можно, фактически, и отделять, а ты предлагаешь усложнить работу (и написание) класса Channel (контейнер) в несколько раз...

Добавлено через 3 минуты и 5 секунд
кстати, еще вопрос


я, кстати, тоже до недавнего времени так считал. и даже не помню, почему :(
ты почему так считаешь?

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

Если Garbage это частный случай Event, то ИМХО намного логичней, что-бы они имели одинаковый интерфейс (это-же всего-лишь строки телепрограммы). Но нужно заюзать полиморфизм, чтобы к примеру при выводе сообщения Garbage оно как-то выделялось, и бросало исключение, а в классе исключения может быть описана ошибка. 
То-есть я предлагаю использовать общий интерфейс для Garbage и Event, а всю дополнительную функциональность класса Garbage, вынести в класс исключения. Приемущество проявится если доля объектов класса Garbage в контейнере не велика, в этом случае исключения будут генерироваться редко, а проверять dynamic_cast - ом каждый элемент будет не нужно.

Те же 0.92. Значимой разнице попросту неоткуда взяться.

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

Хм.. Тоже верная мысль, наверное.. Тебе виднее...


Ну во-первых, потому что это когда-то говорил мудрый препод   , во-вторых, использование dynamic_cast'а свидетельствует о том, что мы пользуемся какой-то дополнительной функциональностью (RTTI, которую кстати, опциями компилятора можно отключить), чтобы получить истинный (ну или просто более "нижний") интерфейс объекта. Оправданно ли это? Динамик кастом можно пользоваться двумя способами: 1) Приведение, когда ты точно знаешь, какой это класс на самом деле. Но если ты это знаешь, то наверное можно провести такую реорганизацию, чтобы динамик каст не понадобился. 2) Попытка приведения по очереди к нескольким подкласам с отлавливанием ошибок при неправильном приведении (сам так ни разу не пробовал, но вроде можно). - Для С++ это как-то "грязно" =). Получается в некоторых местах теряется информация о типах, когда она должна быть. Почему должна? Потому что при хорошем проектировании интерфейс всегда достаточен для контекста в котором он используется, и когда получается наоборот - это, возможно, сигнал о том, что проектирование неудачано...
Как-то так.... 

А вообще демагогия это все.   


Lazin, Тоже, кстати, мысль про исключения пришла, но, как-то не стройно получается в плане логичности и понятности. И сможет ли автору помочь механизм исключений во всех случаях, где евентом оказывается гарбидж? Хотя... ему, опять же, виднее будет...



Это сообщение отредактировал(а) SaDFromSpb - 7.11.2007, 13:33

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

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

Компилятор у меня mingw32-g++ 3.4.4, выставлена оптимизация -O3.


Насколько?


Я совсем не знаю ассемблер и не знаю, как можно получить ассемблерный листинг. И не хочу знать - мне это ни капельки не интересно.

Расшифруй. Я не понимаю, чем ты мерил и что за циферки тут привёл.

соответственно

user time = 0m0.601s
system time = 0m0.178s

Можешь по-русски внятно объяснить, что ты сейчас замерил и какие результаты получил?

times определяет системное время (время работы процесса в режиме ядра: обработка прерываний, системные вызовы) и пользовательское время (время работы процесса вне режима ядра, т. е то, что нам и нужно узнать)
нам необходимо пользовательское время
оно равно в первом случае 0 минут и 0.795 секунды
во втором - 0 минут и 0.601 секунды

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


составляет чуть ли не секунду?

UnrealMan, 
нет
это совокупное время работы процесса вне режима ядра
которое включает в себя в частности время выполнения данного участка кода

И сколько же времени затрачивается на выполнение данного участка кода (а ведь именно это нас интересует, не так ли?.. вернее, даже только часть этого участка, связанная с вычислением typeid и сравнением)?

Это сообщение отредактировал(а) UnrealMan - 7.11.2007, 20:38

UnrealMan, 
какая разница?
остальной код в обоих случаях идентичен
поэтому он не влияет на общий результат
грубо говоря
B + T1 = A1
B + T2 = A2
T1 - время выполнения участка кода в первом случае
T2 - во-втором
B - время выполнения остального кода
на B можно сократить, при этом общее время уменьшится на B
т. е относительный результат будут тем же, но общее время уменьшится

Твои познания в математике просто поражают 

и в чем я не прав?
по существу можешь что-нибудь сказать?   


Это сообщение отредактировал(а) MAKCim - 7.11.2007, 22:30

Думаю, в этом:

"Остальной код" не обязан в обоих случаях выполняться одинаковое кол-во времени.

Ты издеваешься что ли?


Хорошо, скажу по существу. На современном компе typeid(С) == typeid(*a1) в среднем вычислится меньше, чем за микросекунду (результатов выполнения своего теста я ждал несколько секунд, а там по паре миллиардов итераций). Соответственно твои замеры одного-единственного вычисления (где время исчисляется миллисекундами ) не просто не точны - они вообще никак не отражают производительность typeid и виртуального вызова.

Теперь немного о математике. С каких это пор слагаемые при делении стало возможным сокращать? 


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

Ты о вычитании уравнений что-нибудь слышал .

почему нет?
times не зря возвращает системное и пользовательское время
системное время естественно различается (прерывания всегда асинхронны и недетерминированны)
а пользовательское постоянно, если в обоих случаях выполняется одинаковая последовательность действий (а она одинаковая)
только не надо говорить, что, дескать, частота ядра CPU может различается от опыта к опыту и т. д
она то может и различаться, только вот относительный результат всегда одинаков

отнюдь

см. выше

к словам не надо придираться
сокращать = не учитывать

Добавлено через 2 минуты и 50 секунд

железная логика
если бы все мерилось итерациями цикла   

UnrealMan, 
да, если уж на то пошло
давай я докажу, что результаты твоего теста нельзя принять за истину    

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

Исходя из этой фразы


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


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


В том-то и дело, что важен средний результат. Погрешность тут, конечно же, возможна, но будет в пределах 10-25 процентов.

какая погрешность?
я же доходчиво (надеюсь) объяснил, что к чему
время остального кода B постоянно и times это гарантирует если этот остальной код не меняется, а он не меняется
меняются только вот эти части

и

время их выполнения равно T1 и T2
общее время, полученное с помощью times равно A1 и A2 соответственно
чтобы получить T1 и T2 мы от A1 и A2 должны отнять B
при B -> 00, пропорции T1 / T2 и A1 / A2 не равны, но ассимптотически приближаются к 1
причем если T1 < T2, то справа, иначе - слева
но относительный результат (быстрее или медленнее) постоянен в не зависимости от B
а т. к B у нас постоянно, то и одного опыта достаточно для того, чтобы опровергнуть или доказать гипотезу

Это сообщение отредактировал(а) MAKCim - 8.11.2007, 00:32

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

И правда, какая погрешность. Система-то уравнений вообще не решаемая   archimed7592 сбил с толку 


И это B нам не известно.

Нам нужно найти T1/T2. Итак, каковы твои действия?

Добавлено @ 00:58

Так ты ещё и один опыт произвёл  Мегакруть ©

Это сообщение отредактировал(а) UnrealMan - 8.11.2007, 00:59

UnrealMan, 

B нам не нужно!!
T1 / T2 мы заменяем на A1 / A2
при B -> 00, если T1 < T2 ( => A1 < A2), результат неограниченно приближается к 1, но меньше ее
при T1 > T2 ( => A1 > A2) результат приближается к 1, но больше ее
при T1 = T2 ( => A1 = A2) результат 1
на основании одного опыта можно определить соотношение между A1 и A2
и на основании этого сделать вывод о соотношении между T1 и T2
конкретное соотношение не известно в силу неизвестности B, но относительный результат (который нам и нужен) мы получить можем
неужели не понятно?

Добавлено через 1 минуту и 45 секунд
archimed7592, 
вмешайся в спор
кто из нас (я и UnrealMan) тупит

Добавлено через 6 минут и 11 секунд

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

Наверное проще разобраться как реализован RTTI на каком либо конкретном компиляторе, как компилятор производит upcast-ы и тд, и сравнить с велосипедом в виде виртуальной ф-ии, сравнением и тд.

Ну что я могу сказать? Во-первых, конкретное соотношение было бы интересно узнать. Во-вторых, T1-T2 ты можешь найти, не так ли? И сколько там получается? Время в миллисекундах? Ты всерьёз считаешь, что вот эта несчастная строчка кода вычисляется несколько миллисекунд? Что у тебя там за комп такой?

сам считай, если хочешь
все данные я привел

  
1. Ты, я так понял, с ассемблером не знаком, так что не делай таких выводов
банальная строчка кода на ЯВУ может разворачиваться в вызов довольно сложной библиотечной процедуры
(что и делается кстати)
2. Я склонен больше доверять стандартной программе, нежели велосипеду (не в обиду сказано)

Мне этот форум нравится всё больше и больше  Вопросов больше не имею.

т. е сказать больше нечего?   
ради бога

Вопрос в том, кто определил , что он мудрый .  Поэтому, "во-первых" в расчет не принимаем


А что в стандарте где есть фразы, дискриминирующие  dynamic_cast?
Вообщем то исходя из этого, можно например отказаться от ООП вообще. Нафига нам эта приблуда торомозная. Ограничимся только процедурным программированием. 
Мое мнение, что "во-вторых" тоже выглядит неубедительно. 


Дело в том, что если заранее известен класс, то dynamic_cast тут вообще не нужен. Вполне можно обойтись static_cast  .  Так что никакой реорганизации для того, чтобы избавиться от dynamic_cast не понадобится. 



То есть исключения для Вас обязательно что-то исключительное? Пусть так. 
Нут так н делайте преобразование без возможной генерации исключений: ограничтесь преобразованием указателей.


Смысл этой фразы я не понял :(.
 Но в общем могу сказать, но накладываемые Вами ограничения приводят к  печальному результату: при практическом( не демонстрационном  ) использовании полиморфизма придется 
1)либо перенасыщать интерфейс базового класса( применительно  к к данному  примеру вынести GetTime в базовый класс ), 
2)либо создавать свой механизм опознования ( хотябы с использованием typeid, что кстати не всегда удобно или применимо ) с последующим использованием static_cast, 
3) либо просто отказаться от полиморфизма, потому как обычно в реальных  программах  одной работой со  объектами производных классов  как с базовыми  дело не заканчитвается и рано или поздно от работы с базовым объектом приходится переходить к работе с конкретным объектом конкретного класса. 

Не всё, что можно написать в программе будет хорошим ходом с точки зрения проектирования. Стандарт по языку, а не по проектированию.



typeid + static_cast == dynamic_cast.

В общем случае это совсем не одно и то же.

В общем то да, но я не часто пользовался typeid и поэтому вопрос: как решить задачу, когда надо преобразовать к не к реальному классу, а к некоемому базовому
A -> B 
   -> C
   -> D ->E
           ->J
          ->H->K
                ->...
 .            
 

Ну и  постановка:  имеется контейнер( дерево),   для  объектов A ( указателей, естественно).  Для всех объектов, которые могут представлены  как объекты класса D выполнить определенную операцию. То есть практически реализовать паттерн Visitor.

В чём разница? 0_о



Для преобразований к базовому касты не нужны вовсе...

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

можно, тока работать будет неправильно  

я знаю, просто в этой теме шла речь об эмуляции rtti средствами языка.

Но это ещё не всё. С помощью typeid можно сравнивать типы только most derived-объектов, а dynamic_cast успешно отработает и для промежуточных базовых классов:


Ещё dynamic_cast способен одним махом произвести такое преобразование:


а static_cast пришлось бы применить два раза.

Вы меня положительно за идиота держите 
Посмотрите еще раз постановку.
Есть коллекция объектов производных классов, которые выступают как указатели на базовый класс A.  Нужно выполнить определенные операции над объектами только тех классов, которые являются  производными  класса D, то есть над объектами E; J; H; K.

При использовании  dynamic_cast  это решается одной строчкой

При использовании typeid тупо просматривается примерно следущее

Может конечно можно еще как то задействовать type_info::before( const type_info &rhs ) const ,  но проще всетаки dynamic_cast.
И кстати, а разве  typeid для использования динамического типа не использует тот же  RTTI? 

оффтоп
хоть кто-то "на моей стороне"