вот представь, что есть функция которую предложил Dem_max. в этой функции наверняка происходит не просто вывод значения, а наверняка, это значение еще как-то используется. т.е. эта функция - реализация чего-то.
в один прекрасный день, ты решил добавить в твою систему кастов, новый тип. ты 1)декларишь енум, 2)лезешь изменять реализацию. против первого я ничего не имею против потому, что декларации/тайпдефы/форварды - это все свойственно плюсам потому, что на основании деклараций компилятор производит специализации одного и того же кода, за тебя.
и представь switch, в который ты лезешь и начинаешь добавлять новый case с оглядкой на то, чтоб случайно его не продублировать и на то, чтоб присвоить ему корректное значение. и это хорошо что с++ статически типизируемый, ошибки ты получишь на стадии компиляции. основные два аргумента: 1)ты не будешь каждый раз при добавлении нового case, писать его секцию руками - ты ее скопипастишь. 2)эта функция может находится где-то в дебрях проекта, в которые никто уже годы не лез. а если проект состоит из подпроектов, и эта функция реализована в одном из подпроектов, то тебе придется пересобирать подпроект, ведь предложенная функция не шаблонная.

а теперь сравни с тем, как все описанное будет происходить при использовании моего примера. комментарии, полагаю, излишни.

Скажу короко - есть задачи где это нужно.
(ну хотя бы потому, что свитч занимает процессорное время. Решение-же бусткодера, выполняется в момент компиляции.
в реал-тайме там просто ничего не делается. Есть и другие случаи, где это просто необходимо.

До тех пор пока эта функция не вызывается в цикле миллионы раз -- это чистой воды premature optimization. switch достаточно легковесно реализуется на уровне инструкций. 

Но в некоторых задачах это действительно может быть необходимо.




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

Пускай автор решает, соответственно его задаче, которую мы не знаем.

Это сообщение отредактировал(а) W4FhLF - 21.10.2012, 21:18

я не буду писать реализацию. функция-то шаблонная.

Вообще, имхо, в чистом виде нельзя. Язык со статической типизацией, этим все сказано.

Если tag известен на момент компиляции, то foo нужно делать шаблонной.
Что и предложил бусткодер.  

Если же tag неизвестен на момент компиляции (а это собственно и есть динамический тип в чистом виде.), то остается только свитч.

напр:


Eстественно свитч может быть замаскирован под какой-нибудь другой набор операторов.
факт остается фактом. В точке A, невозможно просто написать тип вроде такого:
typedef tag_2_type<tag>::type tag_t;
tag_t value = *( (tag_t*)p );

все вышесказанное, конечно-же имхо.

Ок, если автору нужна простая шаблонная функция странно, что он её сразу не написал. 

volatile правильно заметил, что там, где речь заходит о динамической типизации всё сводится к пресловутому switch рано или поздно.

я единственный кто читал топик и код ТС`а ?


ниразу.
то, что пытается реализовать ТС - не динамическая типизация.
и то что пытается реализовать ТС, запросто реализуется более безопасными, расширяемыми и гибкими способами. и никакого switch.


Это сообщение отредактировал(а) boostcoder - 21.10.2012, 21:56

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

Если судить чисто по примеру то там вообще сам тип известен, и прямолинейное решение лежит на поверхности.
  
Но ясно что borisbn, не стал бы такие дурацкие вопросы задавать. и на основе этого, уже делаем дальнейшие предположения.
Тип, понятно что неизвестен. А известен какой-то тег (код типа), в соответствии с которым нужно восстановить тип.
Но насколько хорошо известен этот тег - неясно.

Вариант 1.
Есть некий тег (код типа), известный на момент компиляции.
В этом случае можно решать разными путями. Я бы безусловно выбрал темплейтный вариант. а ля boostcoder.
(это отнюдь не premature optimization, это идеология. Все что можно сделать в компайл тайме, там и нужно делать.)

Вариант 2.
Есть некий тег (код типа), НЕ известный на момент компиляции.
В этом случае имхо, только свитч, в том или ином виде. Конечно, он может быть довольно сильно завуалирован.
Точнее скажем так: какие-то движения по выбору пути в ран-тайме предпринять придется, по любасу.

boostcoder
Ну как будто в шаблоне ты не будешь копипастить, копипастом пользоваться опасно, у же не раз тут человек из PVR-Studio  приводил примеры и предупреждал.

Ого сколько я пропустил...Сорри, сейчас с телефона смотрю. Как доберусь до десктопа обязательно отпишусь

В общем, задача следующая: имеется сериализованные бинарные данные примерно в таком формате

В данном конкретном случае мне нужно просто распечатать назначение параметра (тут всё просто - берётся по таблице из 256 строк... или map - не важно) и собственно само значение параметра. Вот тут и загвоздка. Не то, чтобы непонятно как делать (решение на поверхности), сколько хотелось обойтись без свитча, но, судя по всему, не получится. В итоге сделал и с шаблонной функцией и со свитчем:


Спасибо всем, кто ответил.

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

Это сообщение отредактировал(а) borisbn - 22.10.2012, 08:40

Dem_max, в моем случае, копипастить буду не я, копипастить будет компилятор.

borisbn, да, если значение это чисто рантаймовская величина, то либо switch, либо map.

Если число различных типов параметров фиксировано - можно использовать паттерн Visitor (в данном случае, в его придётся модифицировать)