Size: a a a

2021 July 10

D

Dmitriy in pro.cxx
Гарантируется распаковка по индексу, а как он хранит внутри  - важно ли?
источник

D

Dmitriy in pro.cxx
Идея лезть во внутрянку тупла звучит паршиво
источник

K

Kelbon in pro.cxx
повторюсь, например bit cast или посылка по сети и ты ожидаешь принимая байтики, что это был tuple int,float, а там лежит float int, ну такие примеры конечно....
источник

ES

Egor Suvorov in pro.cxx
В bit_cast точно нельзя передавать tuple/pair и вообще структуры. Как минимум потому что есть padding
источник

ES

Egor Suvorov in pro.cxx
Так точно нельзя делать со стандартными. Только свои Plain Old Data с непортируемым #pragma pack(push, 1) и #pragma pack(pop) или чем-то аналогичным.
источник

K

Kelbon in pro.cxx
да, паддинг это такое, но у меня пример где это учитывается(внутренний, долгор объяснять)
источник

ES

Egor Suvorov in pro.cxx
А дальше начинается веселье, что нельзя писать int &x = foo.field;, где foo — такая упакованная структура, потому что может нарушиться требование к выравниванию ссылок на int.
источник

ES

Egor Suvorov in pro.cxx
В частности, нельзя делать swap(foo.field1, foo.field2);
источник

D

Dmitriy in pro.cxx
От тебе заняться нечем. Порядок аргументов - последняя проблема
источник

D

Dmitriy in pro.cxx
Про паддинг уже сказали :)
источник

K

Kelbon in pro.cxx
ну короче я написал реверс пак, теперь буду передавать стандартному туплу обратный пак, чтобы он делал тупл укладывающий нормально данные по порядку))), в теории можно сделать #if всякие на реализации по компиляторам или сложную (нет) проверку какую то, через тот же bit cast по типу как делают с endian, но это мои личные штуки, не продакшн не беспокойтесь....
источник

ES

Egor Suvorov in pro.cxx
В смысле не отделить? Крайний случай — это пустой пак.

Можно взять стандартную идею по построению операций со списками из лямбда-исчисления, будет так: https://godbolt.org/z/o9Gd6Wva6
Можно дальше под конкретные случаи оптимизировать. Например, выпилить apply и type_list и сделать напрямую на таплах. Но тогда может компилироваться сильно медленнее, потому что инстанцировать класс сложнее.
источник

ES

Egor Suvorov in pro.cxx
Можно сделать более приятный синтаксис, как в Boost::Hana.
источник

K

Kelbon in pro.cxx
не думал про возможность в специализации писать два пака подряд, я сделал в итоге через раскрытие последовательности интовых значений(компайл таймовой), которую самому пришлось написать, т.к. нужно было выбирать и тип и начальное значение и шаг, и брал для каждого значения элемент этого номера из пака и вставлял
источник

K

Kelbon in pro.cxx
хотя в итоге я и использовал возможность так писать в специализации...
источник

ES

Egor Suvorov in pro.cxx
make_integer_sequence добавляет немного боли, да, но тут не нужен.
источник

K

Kelbon in pro.cxx
интересно почему нельзя писать template<typename ... x, typename last>, по сути же задетектить это вполне возможно
источник

K

Kelbon in pro.cxx
типо если 1 аргумент, то last это он, если несколько то ласт это последний, а первый это остальные
источник

ES

Egor Suvorov in pro.cxx
Можно, но сложнее, чем детектить только первый. Например, надо думать, как детектить с двух концов, не надо ли разрешить какие-то перемешивания со значениями вроде <typename..., int, typename...> или <auto..., int, auto...> для каких-то случаев, а потом ещё неявные преобразования подъедут...

В общем, ограничение «пак только последний» мне нравится
источник

O

Ofee in pro.cxx
Потому что сложно и до [P2347R0] не было кому-то нужно настолько, чтобы тратить время на написание соответствующей бумаги
источник