Чому використання кортежів у С ++ не зустрічається частіше?

Чому, схоже, ніхто не використовує кортежі в C ++, ні бібліотеку Boost Tuple, ні стандартну бібліотеку для TR1? Я прочитав багато C ++-коду, і дуже рідко я бачу використання кортежів, але я часто бачу багато місць, де кортежі вирішують багато проблем (як правило, повертають декілька значень з функцій).

Кортежі дозволяють робити всілякі класні речі, як це:

tie(a,b) = make_tuple(b,a); //swap a and b

Це, звичайно, краще, ніж це:

temp=a;
a=b;
b=temp;

Звичайно, ви завжди могли це зробити:

swap(a,b);

Але що робити, якщо ви хочете повернути три значення? Зробити це можна за допомогою кортежів:

tie(a,b,c) = make_tuple(b,c,a);

Кортежі також значно полегшують повернення декількох змінних з функції, що, ймовірно, є набагато більш поширеним випадком, ніж значення підміни. Використання посилань для повернення значень, звичайно, не дуже елегантне.

Чи є якісь недоліки кортежів, про які я не думаю? Якщо ні, то чому їх рідко використовують? Вони повільніші? Або просто люди не звикли до них? Чи корисно використовувати кортежі?

Тому що це ще не стандарт. Все, що є нестандартним, має набагато більшу перешкоду. Pieces of Boost стали популярними, тому що програмісти вимагали їх. (hash_map стрибає на розум). Але хоча кортеж зручний, люди не так перемагають і чітко виграють.

Цинічна відповідь полягає в тому, що багато людей програмують на C ++, але не розуміють та / або використовують функціонування вищого рівня. Іноді це відбувається тому, що їх не дозволяють, але багато хто просто не намагаються (або навіть розуміють).

Як приклад, що не підсилює: скільки людей використовують функціонал, знайдений у <algorithm> ?

Іншими словами, багато програмістів на C ++ є просто програмістами C, що використовують компілятори C ++, а можливо, std::vectorі std::list. Це одна з причин, чому використання boost::tupleне є більш поширеним.

Синтаксис кортежу C ++ може бути трохи більш багатослівним, ніж хотіли б більшість людей.

Поміркуйте:

typedef boost::tuple<MyClass1,MyClass2,MyClass3> MyTuple;

Тож, якщо ви хочете широко використовувати кортежі, ви або отримуєте кортежі typedefs скрізь, або всюди отримуєте дратівливі назви довгих типів. Мені подобаються кортежі. Я використовую їх при необхідності. Але, як правило, це обмежується кількома ситуаціями, наприклад, N-елементним індексом або при використанні мультимап для прив'язки пар ітераторів діапазону. І це, як правило, в дуже обмеженому масштабі.

Це все дуже некрасиво і хитро виглядає в порівнянні з чимось на кшталт Haskell або Python. Коли C ++ 0x потрапить сюди, і ми отримаємо "авто" ключові слова, кортежі почнуть виглядати набагато привабливіше.

Корисність кортежів обернено пропорційна кількості натискань клавіш, необхідних для їх оголошення, упаковки та розпакування.

Для мене це звичка, руки вниз: кортежі не вирішують жодних нових проблем для мене, лише декілька я вже впораюся. Поміняти значення все ще відчувається легше старомодним способом - і, що ще важливіше, я дійсно не замислююся над тим, як поміняти "краще". Це досить добре, як є.

Особисто я не думаю, що кортежі є чудовим рішенням для повернення кількох значень - це звучить як робота для structs.

Але що робити, якщо ви хочете повернути три значення?

swap(a,b);
swap(b,c);  // I knew those permutation theory lectures would come in handy.

ОК, тож із значеннями 4 і т.д., з часом n-кортеж стає меншим кодом, ніж n-1 свопів. І за допомогою заміну за замовчуванням це робить 6 завдань замість 4, які ви мали б, якби ви реалізували шаблон три циклу самостійно, хоча, сподіваюся, компілятор вирішить це для простих типів.

Ви можете придумати сценарії, коли свопи є нелегкими або недоречними, наприклад:

tie(a,b,c) = make_tuple(b*c,a*c,a*b);

трохи незручно розпакувати.

Справа, однак, є відомі способи вирішення найпоширеніших ситуацій, для яких кортежі корисні, і, отже, немає великої терміновості братися за кортежі. Якщо нічого іншого, я не впевнений, що:

tie(a,b,c) = make_tuple(b,c,a);

не робить 6 копій, що робить його абсолютно непридатним для деяких типів (колекції є найбільш очевидними). Не соромтеся переконувати мене, що кортежі - це гарна ідея для "великих" типів, кажучи, що це не так :-)

Для повернення декількох значень кортежі ідеальні, якщо значення несумісних типів, але деяким людям вони не подобаються, якщо можливо, що абонент може отримати їх у неправильному порядку. Деяким людям взагалі не подобається кілька повернених значень і не хочуть заохочувати їх використання, полегшуючи їх. Деякі люди просто віддають перевагу названим структурам для параметрів входу та виходу, і, ймовірно, не вдалося переконати бейсбольною битою використовувати кортежі. Без обліку смаку.

Як зазначали багато людей, кортежі просто не такі корисні, як інші функції.

1. Перемикачі та обертові трюки - це лише пристосування. Вони вкрай плутають тих, хто їх раніше не бачив, і оскільки це майже всі, ці трюки - це лише погана практика інженерного програмного забезпечення.

2. Повернення декількох значень за допомогою кортежів набагато менше самодокументування, ніж альтернативи - повернення названих типів або використання названих посилань. Без цього самодокументування легко переплутати порядок повернених значень, якщо вони взаємно конвертуються і не будуть будь-якими мудрішими.

Не кожен може використовувати прискорення, і TR1 поки що не доступний у широкому масштабі.

При використанні C ++ у вбудованих системах втягування бібліотек Boost стає складнішим. Вони з'єднуються один з одним, тому розмір бібліотеки зростає. Ви повертаєте структури даних або використовуєте параметр передачі замість кортежів. При поверненні кортежів у Python структура даних знаходиться в порядку та типі повернених значень, просто не явні.

Ви їх рідко бачите, тому що добре розроблений код їх зазвичай не потребує - в дикій природі не так багато випадків, коли використання анонімної структури перевершує використання іменного. Оскільки весь кортеж справді являє собою анонімну структуру, більшість кодерів у більшості ситуацій просто йдуть із реальною справою.

Скажімо, у нас є функція "f", де повернення кортежу може мати сенс. Як правило, такі функції зазвичай досить складні, що можуть вийти з ладу.

Якщо "f" CAN не вдається, вам потрібен стан повернення - зрештою, ви не хочете, щоб абоненти повинні перевіряти кожен параметр, щоб виявити збій. "f", ймовірно, вписується в шаблон:

struct ReturnInts ( int y,z; }
bool f(int x, ReturnInts& vals);

int x = 0;
ReturnInts vals;
if(!f(x, vals)) {
    ..report error..
    ..error handling/return...
}

Це не дуже, але подивіться, наскільки потворна альтернатива. Зауважте, що мені все ще потрібно значення статусу, але код не є більш читабельним і не коротшим. Це, мабуть, і повільніше, оскільки я маю на себе вартість 1 примірника з кортежем.

std::tuple<int, int, bool> f(int x);
int x = 0;
std::tuple<int, int, bool> result = f(x); // or "auto result = f(x)"
if(!result.get<2>()) {
    ... report error, error handling ...
}

Інший, істотний мінус тут прихований - з "ReturnInts" я можу додати повернення al "f", змінивши "ReturnInts" БЕЗ ЗМІНИ "F" INTERFACE. Рішення кортежу не пропонує тієї критичної характеристики, що робить його неповноцінною відповіддю на будь-який код бібліотеки.

Безумовно, кортежі можуть бути корисними, але, як згадувалося, є трохи накладних витрат і перешкода або два, через які вам доведеться перестрибнути, перш ніж навіть реально їх використовувати.

Якщо у вашій програмі послідовно знаходяться місця, де вам потрібно повернути кілька значень або поміняти кілька значень, можливо, варто пройти маршрут кортежу, але в іншому випадку іноді просто простіше робити речі класичним способом.

Взагалі кажучи, не у всіх уже встановлено Boost, і я, звичайно, не переживаю труднощів з його завантаженням і налаштуванням каталогів, що включають, для роботи з ним лише для його функцій. Я думаю, ви побачите, що люди, які вже використовують Boost, швидше знайдуть кортежі у своїх програмах, ніж користувачі, що не підсилюють Boost, і мігранти з інших мов (Python приходить на думку) швидше просто засмучуються відсутністю кортежів в C ++, ніж вивчити способи додавання кортежної підтримки.

Оскільки сховище даних std::tupleмає найгірші характеристики як a, так structі масиву; весь доступ базується на n-й позиції, але не можна переходити через atuple допомогою afor циклу.

Отже, якщо елементи в tupleпонятійному понятті є масивом, я буду використовувати масив, і якщо елементи не є концептуально масивом, структура (яка назвала елементи) є більш ретельною. ( a.lastnameє більш пояснювальним, ніжstd::get<1>(a) ).

Це залишає перетворення, про яке йдеться в ОП, як єдиний життєздатний приклад для кортежів.

У мене є відчуття, що багато хто використовує Boost.Any і Boost.Variant (з деякою технікою) замість Boost.Tuple.