| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Общие вопросы > сделать strong_typedef ещё strong'ее |
| Автор: borisbn 21.11.2011, 09:14 | ||||
| Всем привет. Хотел сделать 2 типа таким образом, чтобы преобразование из одного в другой было бы невозможно, несмотря на то, что по сути эти типы одинаковые. Сделал такой код:
foo1 отрабатывает (как и должна), на foo2 ругается (как и должна). Но затем сделал так:
и это - отрабатывает (хотя мне бы хотелось, чтобы выдавалась ошибка). Эту тему - http://forum.vingrad.ru/topic-198572.html - смотрел, но, как я понял, тогда решения не нашли (кроме mpl, которую не хочется тянуть ради такой задачи) Спасибо. |
| Автор: boostcoder 21.11.2011, 09:54 | ||||
во первых - для тех кто желает ознакомиться с макросом , он определен тут: http://gitorious.org/boost/svn/blobs/master/boost/serialization/strong_typedef.hpp
в твоем примере, нежелательное поведение происходит из-за перегруженных operator type(); если их закомментировать, то все ок. пример:
http://liveworkspace.org/code/62d1803c53fc6f735125a31db9e76ecd а вот почему(и как это исправить) operator type() дает такой эффект - это нужно у более компетентных полюбопытствовать. |
| Автор: math64 21.11.2011, 10:07 | ||||
Можно так:
В случае vector (и других классов) можно так:
|
| Автор: boostcoder 21.11.2011, 10:17 |
| еще два способа: 1. закоментить operator=() для "голого" типа. 2. указать для operator=() "голого" типа спецификатор =delete. math64, ну почему вы так безобразно код пишите? или вы не рассчитываете что его читать будут? Добавлено через 4 минуты и 30 секунд странный какой-то strong typedef получается.. |
| Автор: borisbn 21.11.2011, 10:24 | ||
мдааа. похоже BOOST_STRONG_TYPEDEF не получится использовать (даже убрав оператор приведения к T), т.к. не получится использовать так
обычный typedef в этом плане предпочтительней, но он даёт привести что хочешь к чему хочешь... на ИРКе посоветовали http://www.boost.org/doc/libs/1_48_0/doc/html/boost_units.html ушёл курить юнитс'ы. Добавлено @ 10:27 math64, в Вашем примере не выдаётся ошибки, а мне нужно, чтобы выдавалась. Ведь T1 и T2 - разные типы. |
| Автор: boostcoder 21.11.2011, 11:36 | ||
я бы поступил так:
т.е. удалил бы operator=() для T Добавлено @ 11:41 какой-то конкретный шаблон? или его еще и отрыть нужно? |
| Автор: mes 21.11.2011, 13:09 |
| borisbn, если Вам нужно это для действительно для request и response, то не мучайте ни себя, ни людей, а заведите по структуре на каждый.. (или, хотя бы, от общего шаблона получайте..) не пожалаете, в отличии от того, если реализуете через тайпдеф... |
| Автор: borisbn 21.11.2011, 14:54 | ||||
при обычном typedef'е есть
вообще-то я request и response привёл как пример. ведь существует ещё множество "типов", поведение которых выглядит в точности как vector< unsigned char >, но их нельзя (по логике) присваивать друг другу... если бы typedef не давал возможности приведения (или его как-то можно было запретить), то он бы меня устраивал по-полной программе... поэтому ж и начал |
| Автор: mes 21.11.2011, 15:26 | ||
если быть точными (а значит вместо слово выглядят ставим являются), то практически нету , по крайней мере я не встречал Добавлено через 3 минуты и 26 секунд а где Выши любимые замечание по нарушению правил русского языка.. прочитал как я написал, волосы дыбом встали.. поправил Добавлено через 4 минуты и 45 секунд в С++ typedef и не является def type`ом Добавлено через 6 минут в общем для приведенного случая напрашивается максимум packet<request> и packet<response>.. |
| Автор: borisbn 21.11.2011, 16:16 | ||||
я решил, что макать гуру Си++ - себе дороже - отыграется на Си-плюс-плюсе
как это ? я пробовал
foo1 и foo2 вызываются с одним типом packet< request_t > без ошибок... |
| Автор: mes 21.11.2011, 17:33 | ||
ну это вы загнули.. |
| Автор: borisbn 21.11.2011, 18:10 | ||
| получается, что без промежуточного .v не обойтись... жаль. получается либо так
либо как Вы написали (через шаблонный packet)... склоняюсь к Вашему варианту... Всем спасибо. Закрываю. |
| Автор: mes 21.11.2011, 19:37 |
1. перегрузкой -> 2. определением полноценного интерфейса (рекомендуется) |