Всем доброго дня.
Так как все топовые производители зарелизили версии компиляторов поддерживающих c++0x, встал резонный вопрос: почему бы вместо всеобразных типов структур, не использовать тьюплы? Идея в том, чтоб не плодить сущности.
Например:

Что мы имеем в итоге: четыре разных типа, и четыре разных сущности.
Какие у такого способа плюсы - я не знаю. Минусы - очевидны. Обобщить алгоритмы работающие с этими типами можно, посредством шаблонов или адаптеров(переходников). Но смысл в этом какой? - я, честно говоря, не понимаю.

Представьте ситуацию, в которой, все эти типы были бы тьюплами:

Какие у такого способа плюсы - общность. Минусы - невозможно обращаться к членам по имени.
Если преодолеть этот минус, то по идее, должно получиться нечто удобное.

Собственно, реализовать общение к членам, пытаюсь с помощью препроцессора.
Предварительный пример:


Интересует ваше мнение.

зы
как все же правильно они называются, тьюплы или кортежи?

>как все же правильно они называются, тьюплы или кортежи?

Кортеж - это перевод тюпла на великий и могучий. К.О.

Минусы:

 - конпеляторы топовых версий - дрянь;
 - нет совметимости с си.

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

какой из них?: gcc, msvc, edg, comeau, intel?

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

а принудительное использование first и second вместо вразумительных имен никак не смущает?

Думаю, все. Топовая версия - это, считай, немного устаканенный транк. Багов обычно нет, а регрессий - море. Помните эпичный фэйл, когда гцц 4.5 и 4.6 не могли ничего заинлайнить? Так вот это только один из примеров. Если немного следить за выпусками гцц и сопутствующими обсуждениеми, видно, что на топе куча плюшек и куча регрессий, а потом в промежуточных версиях регрессии убирают.

Например гцц 4 в сравнении с гцц 3 был просто кошмаром и только к ветке 4.4 от регрессий начали избавляться и вообще вся ветка 4.4 - это по большей части багфикс с небольшими бэкпортами новых фич.

да. бывают моменты когда хочется задекларировать десятку-две структур  

azesmcar, меня не смущает, потому что называю их key и value, а структуры такие нужны обычно только в таком качестве. Второе известное мне применение - координаты, - но тут использую struct.

upd. Третьих и четвертых впрочем тоже можно придумать. Суть в том, что на моей практике обычно все сводится к ключ-значение.

Это сообщение отредактировал(а) djamshud - 15.9.2010, 16:23

ну по моему

читается намного легче, чем


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

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

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

  

по большому счету - да.


да. если использовать std::get<>() для обращения к членам.

но если свести синтаксис к:

то это не в счет  

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


У меня для Вас плохие новости.  Вот чем, пожалуй, отличаются программисты С++, так это неуёмны желанием использовать всё и вся не по назначению. Помните, у вас в руках инструмент ещё более острый, чем та самая бритва. Ну и, конечно, первый друг "творца" в создании кровавого месива - препроцессор... Я повторяюсь...

Использовать кортежи как замену классам нужно крайне осторожно. Пожалуй, однозначно не стоит делать это в Public API. Интерпретировать трудно. Как только появилась необходимость передавать/возращать кортеж, надо начинать думать о создании класса/структуры.

Для "внутреннего применения" может пригодиться. Сценарий "навскидку":

Функция возвращает не только некоторое значение, но и булеву переменную, указывающую стоит ли использовать первое значение далее в программе. При поиске, например, такое часто бывает. Чтобы не использовать передачу параметров по ссылке/указателю. Всё-таки чистые функции предпочтительнее. А городить огород с лишней структурой тут и в правду желания нет.

Это сообщение отредактировал(а) kemiisto - 15.9.2010, 16:38

так же, стоит вспомнить про std::tie(). что является огромным плюсом при работе с членами кортежей.

Добавлено @ 16:44

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

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

Кортежи использовать вместо структур глупо. Использовать вместо координат неразумно, так как читабельность падает. Для "ключ-значение" они больше подходят, но опять же, если есть лишние 10 минут, лучше накатать специальную структурку.

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

ИМХО

ок...


координаты - это просто пример. первое, тривиальное, что в голову пришло.


уже ответил -



чем лучше?


увы.
посмотрите на великолепное творение - boost.fusion. воистину великолепное  

каким образом? с помощью макросов? чем тогда тюплы от обычных структур отличаются, разве что тем, что объявляться нестандартно и опять таки затрудняют чтение. В общем я думаю так, если прибегать к каким-то нестандартным методом на то должно быть основание. Так в чем причина использования тюплов вместо структур? Что вы выигрываете? 

сущность одна - кортеж.

azesmcar, кортеж - это ж по-европейски! :)

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

Это сообщение отредактировал(а) djamshud - 15.9.2010, 20:32

да уж..и не слышал такого термина 

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



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

Я пока еще не придумал, зачем мне это нужно. Возможно, конечно, что я не понял всех прелестей этой библиотеки, но идея вектора, состоящего из данных разных типов, задаваемых на этапе компиляции, кажется мне несколько надуманной. Если мне нужен контейнер для любых данных, я использую boost::any, а если Variant, то я использую свою реализацию (а не бустовскую, непонятно зачем вообще сделанную), которая поддерживает преобразование в требуемый тип (в моем случае, требуется только совместимость его с istream/ostream).

boost.fusion - это, преимущественно, компайл-тайм библиотека(mpl). но в отличии от boost.mpl, она помогает связывать компайл-тайм код с ран-тайм кодом, и предоставляет контейнеры и алгоритмы времени компиляции.


1. этим, вы теряете всю информацию о типе. и ни о каком mpl говорить неуместно.
2. зачем вам тратить процессорное время, на каст туда-обратно. при том, что в момент компиляции, компилятор многое может сделать сам, и "разгрузить" процессор от ненужного ему занятия.


variant и any - ран-тайм классы. сплошной оверхед. именно по этой причине, в последнее время, интенсивно применяется mpl.
если не секрет, чем ваша реализация лучше boost.variant? и чем не утраивает boost.variant? просто любопытно.

Добавлено @ 00:39
тема-то не об этом...

Это сообщение отредактировал(а) boostcoder - 27.7.2011, 10:40

  У каждого класса есть сигналы/слоты. В качестве параметров они принимают разные типы (int, double, string...). Чтобы стандартизировать интерфейсы я использовал свою версию варианта. В большинстве случаев (во время работы) используется передача данных напрямую (т.е. если слот принимает int, то и отправляется ему int), но на этапе инициализации все идет через string (так как все записано в xml). Чтобы не плодить разные интерфейсы, мной было сделано именно так.

Это сообщение отредактировал(а) bsa - 16.9.2010, 11:08

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

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

решил задачу, путем написания препроцессорного метагенератора.
и так...
в нашем проекте нам потребуется файл, в котором мы будем typedef`ить наши типы. назовем его "typedefs.hpp".

в результате, препроцессор сгенерирует такой код:


использовать так:


надеюсь оцените мой труд  

зы
файлы во вложении.


Это сообщение отредактировал(а) boostcoder - 8.10.2010, 10:14

Присоединённый файл ( Кол-во скачиваний: 12 )
 metagen.tar.gz 2,11 Kb

boostcoder, не думал предложить включить это в boost? Может, тебе еще какие интересные идеи по оптимизации предложили бы?

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

зы
на днях дополню кодогенератор так, чтоб в сгенеренных типах методы name()/count()/methods() были constexpr. это позволит использовать сгенеренные типы совместно с mpl контейнерами.

a еще, имхо, неплохо было бы их вынести за пределы пользовательского (генерируемого) класса...
как впрочем и метагенериацию не мешало бы разделить на "слои".. 

не понял...
все равно ведь никто не будет копашиться в сгенерированном коде.. смысл в чем?


тоже не понял..

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

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

не знаю...стОит ли добавлять constexpr?
id - все равно enum.

т.е. такой код возможен:


добавил генерацию operator<< () в поток.


Это сообщение отредактировал(а) boostcoder - 6.5.2011, 22:33

boostcoder, думаю, если ты сможешь добиться исключения явного подключения финишного хидера, то можешь смело отправлять в буст. Даже если тебя пошлют, то дадут ряд советов, как сделать так, чтобы не послали.

1. будет удобней искать ошибку
2. большая защита коллизий
3. шаг к рантайм-типу
4. шире простор деятельности.. 
5.. 
в общем эта куча на меня производит негативное впечатление, и я много много раз подумал бы, чтоб начать использовать подобное..

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

а в бусте то оно зачем ?!

вынести лишнее в cpp..

вот первый набросок , на основе результативной структуры room_t : http://liveworkspace.org/code/853f1fea8e52...d6a735a7b46a261

а это идея!

Добавлено через 1 минуту и 31 секунду
вот только это:

я понятия не имею как сделать..ведь все генерится в одной файловой единице..

Добавлено через 3 минуты и 41 секунду
можно так: http://liveworkspace.org/code/901c72dce341...1318da49939ef96

все равно не понимаю для чего аксессоры оставлять внутри, а эти методы выносить..

а зачем все генерить в одной единице ?
почему нельзя генерить отдельно интерфейс, отдельно реализацию ?

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

пока сам не знаю..   

можно.
но в этом случае придется написать два макроса. один вписывать в .hpp файле со всеми параметрами. а второй в .cpp файле, так же, со всеми параметрами.. а если случиться несоответствие между параметрами, то понять причину ошибки будет очень не просто 

Добавлено @ 00:07
а это, как раз основная причина из-за которой недолюбливают препроцессорную кодогенерацию.

Это сообщение отредактировал(а) boostcoder - 7.5.2011, 00:08

что подразумевается под "всеми параметрами" ?

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

кстати зачем все так сложно ? 
зачем аксессоры ? зачем наследование ?

Добавлено через 4 минуты и 40 секунд
что должна уметь Ваша структура ?
1. иметь наиболее близкий к классическому интерфейсу структуры
2. уметь отобразить строковые  имена структуры и методов
3. являться/преобразоваться к tuple 
4. сериализоваться и выводиться в поток, но это avtomatizirovano na osnovanii punkta 2.. 

что еще ?

это:




угу. это все.

Добавлено через 42 секунды
ну и иметь еще уникальный id, который можно использовать в компайл-тайм.

просто придется лишние файлы делать.. 
defs.hpp
inc.hpp
src.hpp
где два последних включают defs между своих метаген инклудов
а все остальные пользуют inc.hpp

Добавлено через 4 минуты и 24 секунды
второй набросок : http://liveworkspace.org/code/bd091abb264f...a4979a83bb2d449

хм.. очень даже узабильно 

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

осталось понять для чего это нужно  

если нужна возможность разделения на интерфейс и реализацию...

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

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

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

Добавлено через 1 минуту и 35 секунд
или Вы предлагаете сначала вручную запускать препроцессор чтоб он сгенерил что нужно, а потом использовать сгенеренное как единицу трансляции?

зачем вручную ? в нужной единице трансляции будет включена typedefs как реализация, а в остальных, как интерфейс.. 

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

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

Добавлено через 1 минуту и 45 секунд
набросок 3: http://liveworkspace.org/code/c127b050f95c...83b624536fc1b6b

Добавлено через 3 минуты и 35 секунд
при втором варианте описания (см. ссылку) теряем возможность автоматического id, в полезности которого я сомневаюсь..зато развязаны руки по оформлению класса...

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


может тогда оставить генерацию как есть? ;)


неее. id - как раз нужен...

может и не нужно.. 

Добавлено @ 01:49

подумаем , как его добыть..

Добавлено @ 01:50

P.S. понимаю что id нужен, я не вижу выгоды в зависимости id от countera..

Добавлено @ 01:59
я бы наверно привел бы к такому виду :


набросок 4 : http://liveworkspace.org/code/82114ed27eeb...aa18f3339d378c0

если коллизии не сильно беспокоят, то набросок 5 : http://liveworkspace.org/code/fccd8f937463...f3458ef316c7969
вернулись к началу, но с другой стороны      
 

Это сообщение отредактировал(а) mes - 7.5.2011, 02:14

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

ну есть у меня файлик в ~4000 строк, в котором описаны все типы. да, куча. ну ничего. комментирование очень помогает  

а чем не нравится выход предложенный выше в последнем посте ?
одна лишняя строчка для енума, зато полный контроль..


P.S. struct ids можно заменить на namespace ids ..

Это сообщение отредактировал(а) mes - 7.5.2011, 09:05

а какой смысл писать руками то, что можно не писать? при учете того, что результат одинаковый.

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