Всем доброго дня.
Так как все топовые производители зарелизили версии компиляторов поддерживающих 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. воистину великолепное  

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

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