Здравствуйте.
Хочу получить следующий код

http://liveworkspace.org/code/0abd4f6bcc30...acb606b53230b5e
ессно, это не работает.

выход, конечно, есть - сделать через switch, но хотелось бы как-нить поэлегантнее.
Есть ли вообще возможность создать одной строкой такой тип tag_t ?
Спасибо.

думаю, это единственный способ:

http://liveworkspace.org/code/61f1dbf44267...340c21c4675be47

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

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

ЭЭЭэ, ну и нафига тогда надо было весь этот паровоз городить ??? мы уже тип передали в виде e1, e3

Именно так и сделал в итоге. Думал, просто, что можно как-нибудь поэлегантнее...

e1 и e3 это не типы, это ключи.

Добавлено через 42 секунды

думаю можно. но задача не известна.

Да ты хоть как их закодируй и обзови. Суть от этого не меняется, тип передан в зашифрованном виде

Dem_max, ты под веществами?

Dem_max, снимай свой шлем хоть иногда, моцг проветривать.


Добавлено @ 15:52
Dem_max, или, возможно ты не понимаешь, почему решение со switch это грёбанный костыль, и почему ТС хотел его избежать?



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

Расскажи почему ???

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

В твоем коде добавлять столько же строчек как и в мой, чем же твой код лучше от этого стал ??

значит ты не видишь разницу.
лень объяснять. может кто-то другой объяснит.

borisbn, кстати, твою задачу можно решить более элегантно, с использованием boost.preprocessor.
наперед, предвижу что-то вроде:

т.е. этот макрос будет одновременно генерить енум-ключей с именем my_enum_name, и специализации tag_2_type<> для перечисленных типов/ключей.



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

Я тоже не вижу. В данном конкретном случае, без уточнения деталей задачи, switch проще и требует меньше кода, зачем тут городить что-то ещё непонятно.
Может кто-нибудь не поленится и объяснит?

жуть какая  

вот представь, что есть функция которую предложил 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 (в данном случае, в его придётся модифицировать)