std :: ігнорувати зі структурованими прив'язками?


88

Прелюдія:

std::tuple<int, int, int> f();
std::tuple<int, int, float, int> g();

C ++ 1z введе синтаксис для структурованих прив'язок, що дозволить писати замість

int a, b, c;
std::tie(a, b, c) = f();

щось на зразок

auto [a, b, c] = f();

Однак std::tieтакож дозволено вказати std::ignoreігнорувати певні компоненти, наприклад:

std::tie(a, b, std::ignore, c) = g();

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


2
Просто введіть там довільне ім’я.
п. 'займенники' m.

1
@nm чи не створить копія довільне ім'я?
Piotr Skotnicki

1
@Piotr std::ignoreЯ думаю, не більше копій, ніж з . Оскільки ми гарантуємо елісію копіювання, фіктивна змінна ініціалізується; за допомогою ініціалізується std::tieтимчасовий, який знаходиться в rhs присвоєння std::ignore.
j6t

1
Можна було б мати макрос, auto[IGNORE]який генерує унікальне ім'я (наприклад: з конкретним компілятором COUNTER або LINE ). Було б читається досить, і на практиці буде функціонувати як std::ignoreдля std::tie.
KABoissonneault

2
@PiotrSkotnicki Ні, єдиною копією декларації розпакування є те, що розкладається. Декларовані речі є або псевдонімами для членів / елементів цієї речі, або посиланнями, які прив'язуються до того, що getповертається.
TC

Відповіді:


62

Пропозиція структурованих прив’язок містить спеціальний розділ, що відповідає на ваше запитання ( P0144R2 ):

3.8 Чи повинен бути спосіб явного ігнорування компонентів?

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

Симетрія з std::tieрекомендувала б використовувати щось на зразок std::ignore:

tuple<T1,T2,T3> f();

auto [x, std::ignore, z] = f(); // NOT proposed: ignore second element

Однак це відчуває себе незручно.

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

Однак зверніть увагу, що робочий проект стандарту в даний час переглядається відповідними національними органами (НБ), і є коментар НБ із запитом на цю функцію ( P0488R0 , US100 ):

Декларації декомпозиції повинні забезпечувати синтаксис для відкидання деяких повернутих значень, як і std::tieвикористання std::ignore.


6
Зараз вже пізно, але я хотів би зазначити, що функція, яка відчуває себе незручно використовувати і, можливо, буде замінена в майбутньому, краще, ніж взагалі не мати можливості користуватися цією функцією , і це не схоже на тип річ, яка змусить комітет зі стандартів побажати машини часу, оскільки іншої розумної інтерпретації std::ignoreструктурованих прив’язок немає.
Daniel H

11

Чи можна буде зробити щось подібне, використовуючи новий синтаксис структурованих прив'язок?

Ні. Вам просто доведеться скласти ім’я змінної, яке не буде згадуватися пізніше.


25
який генерує невикористане попередження про змінну -Wunused-variable, яке ви можете використовувати: [[maybe_unused]] auto [ a, b, dummy ] = std::tuple(1,"2",3f);але це означає, що будь-яке з них може бути невикористаним, ви не будете знати, яке саме. зараз для цього випадку немає хорошого рішення. сподіваємось, це буде вдосконалено в c ++ 20. взято звідси: stackoverflow.com/questions/41404001/…
серін

3
"зараз немає хорошого рішення для цього випадку" : це не зовсім вірно: Ви можете просто використовувати, (void)dummy;щоб позбутися невикористаного попередження змінної, не впливаючи на інші змінні.
andreee

16
@andreee: Використання заяви просто для затихання попередження - це не те, що я назвав би "хорошим рішенням".
Нікол

"Використання заяви просто для стихання попередження ..." У нас закінчуються заяви?
AndyJost

2
@AndyJost: Ні, але у нас закінчується кількість візуального простору на екрані. Витрачати його, особливо дорогоцінний вертикальний простір, на стихання попередження не корисно.
Nicol Bolas
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.