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

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

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

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