И не подумаю спорить, однозначно так тут и говорить не о чем, но как по мне это имеет смысл существует ситуации когда определенные логические ветки ичпользуються ну уж крайне редко, вот если говорить о реальном коде то есть как минимум одно место в моем коде сейчас где я бы это приминил, я занимаюсь 3d печатью, и одна из задач которую стоит оптимизировать это разрезать треугольник на слои, так вот почти всегда в разрезе 2 точки, но существуют крайне редкие случаи когда слой попадает на вершину треугольника, и есть отдельная ветка которая описывает поведение в этом случае, она за сесию может и не вызваться не разу или вызоветься 5-6 раз против милионов вызовов когда в разрезе 2 точки, в таком случае, то почему бы и не пометить ветку как редко используемую и не дать компилятору возможность ее оптимизировать, хотя откровенно говоря для меня загадка в чем заключаетьсч оптимизация, и в чем это дает выигрыш)

Добрый вечер. Упрощенно имеется следующий код:

void send(const Type & type, Message && msg)
{
    send_impl(type, std::move(msg));
}
void send_impl(const Type & type, Message && msg)
{
    //...
}

После msg идет еще 1-3 параметра в зависимости от перегрузки.

Возникла необходимость помимо type (std::string) передавать также tags (std::set) и meta (std::map<string, string>), при этом хотелось бы не портить текущий интерфейс и также отдавать все одним аргументом.
Из этого родилось следующее:
https://codeshare.io/2pdJz9

Вопросы вот какие:
1. Можно ли как-то более явно показать, какие параметры ожидаются в тупле, вроде std::tuple<Type &, Tags &, Meta &> с сохранением преимуществ forward_as_tuple?
2. Можно ли как-то передать эту туплю в send_impl без темлейтов и распаковки, если send_impl лежит в .cpp файлике
3. Может я вообще не туда воюю и есть другой более адекватный подход?

П.С. Сделать еще несколько перегрузок, которые принимают теги и мету я как бы и могу, но хочется дать возможность отдавать только тип/только теги/только мету/мету и теги
С учетом того, что в методе send кроме приведенных в примере параметров есть еще, а также уже есть несколько перегрузок, мне кажется такой подход только раздует код и на местах вызова это будет кошмар.
П.П.С. Делать структурку и класть в нее перед передачей не хочется, ибо копии довольно дорогие и это хайлоад.

1) Можно через специализацию проверить корректность набора параметров в паке. Я написал с использованием C++20 исключительно для демонстрации идеи, он довольно легко переписывается для совместимости с более старыми стандартами

@Indev29, немного обновил пример с демонстрацией. Пользователь может вызвать send с использованием forward_as_tuple только если tuple содержит корректную последовательность типов. Для простоты примера я изменил код так, что возможны висячие ссылки внутри send_impl, если это нежелательное поведение — стоит в is_valid_arg_sequence_helper_v потребовать соответствие точному ссылочному типу и не вызывать его через remove_cvref

Я немного не понял, в каком случае будут висячие ссылки?

Со стороны send_impl мы могли бы ожидать, что наши параметры — не временные объекты и сохранить куда-нибудь ссылку во вне. В случае, требуй мы точного типа, пользователь был бы вынужден не передавать временные объекты. Но, кажется, этому подвержен и оригинальный код, так что полагаю, мой пример корректен

Да, ваш пример корректен, в оригинальном коде это сделано осознанно. Считаем, что на вопрос с проверкой tuple ответ получен :)

Касательно второго вопроса — мне не понятна цель, реализация send_impl может лежать в cpp файле, поскольку это не шаблонная функция

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

Я всё ещё не понял, в чём именно проблема текущего кода — наличие функции-враппера send и желание её логику перенести непосредственно в send_impl?

Нет, просто три аргумента в send_impl смущают, если бы туда прямо tuple уходило, было бы, ну, целостнее, что ли

Вопрос появился такой - а можно ли некий файл(исполняемый) загрузить в память некоего процесса(из этого процесса) кодом и задать права страницам на исполнение и сделать грубо говоря jmp? Сразу говорю - процесс мой, так что не ради хакинга

Ну, во-первых, мне не понятна эта проблема. И уж если хочется сгруппировать аргументы по смыслу, std::tuple здесь — худший кандидат, во-вторых, можно объявить в качестве аргумента конкретное инстанцирование std::tuple, это не потребует делать функцию шаблонной

Ну, во-первых, мне не понятна эта проблема. И уж если хочется сгруппировать аргументы по смыслу, std::tuple здесь — худший кандидат, во-вторых, можно объявить в качестве аргумента конкретное инстанцирование std::tuple, это не потребует делать функцию шаблонной

Вообще, как бы вы сделали передачу аргументов таким образом?
Или скорее передавали бы как три отдельных аргумента и не стали заморачиваться?)