antox,

Не надо никаких хаков, указателей и других извратов. Объявить локальную переменную S:string и передавать туда.
За указатели в таких местах - гнать из професии.

wadman,

если про меня, то опыт паскаль / дельфи > 35 лет.
Я не про указатели вообще, сам их очень даже использую там, где они к месту.
А тут явный изврат только для того, чтобы показать что они знают, как это делается.
Такие эмоции, потому что не далее как вчера помогал вычищать подобное говно менее опытному коллеге,
который с этим корячился несколько часов с кодом, в которым тоже были когда то созданы проблемы на ровном месте.

wadman,

Рабочий пример уже был в исходном сообщении, вторым по счету, я на это и указал.
Да, это называется локальная переменная. В вызывающей фунции.
Н.Вирт "Язык паскаль".
Я такое изучал в 9 классе в 1984 году,
а в ответах на исходное пошел какой-то трэш про то что нужно учить указатели и хаки, за которые в рабочем коде надо пороть.

А за что мы боролись?
За сокращение длины кода? В результате нагородили забор из указателей вместо объявления одной однобуквенной переменной.
Это твой пример элементарный, а в рабочем коде таких параметров будет скорее всего несколько, и все это будет нечитаемо +
при может измениться число параметров, а вариант с указателем уже будет указывать на другу переменную, скомпеидится, а потом будет падать, причем это место может сразу не обнаружиться. Это как раз тот вариант конструкций, про который в С говорят "выстрел в ногу"

Не понимаю чем плохо заполнить значения рекордов в паре строчек перед вызовом функции.
Все понятно и читаемо. А так все в одной строке - макаронине, при рефакторинге и сравнении версий изменений боль при
разборе какой параметр на каком месте и не перепутали ли порядок.

Я предпочитаю именно этот способ.
Преимущества:
1. Очень часто набор параметров передается по цепочке методов. В моем проекте например, добавление нового параметра в цепочку вызовов могло повлечь изменения в сотнях виртуальных методов, в десятках модулей. Никому этим заниматься не хотелось, поэтому у разработчиков при необходимости был соблазн использовать нехорощие костыли, типа передачи через глобальную переменную, или использование какого-нибудь малоиспользуемого параметра в разных контекстах для разных параметров, с надеждой , что они не пересекутся.
В варианте с записью просто добавляем новое поле, заполняем где надо и вот оно уже везде в цепочке.
2. При наличии большого числа параметров в вызове при рефакторинге легко запутаться в порядке параметров, особенно если они однотипные, и как я уже писал. в сотнях методов, и набор и порядок параметров может быть разный, с каждым разбираться.
3. Скорость. запись почти всегда передается по ссылке как const или var.

Что будет много объявлений записей проблем не вижу, если нормально продумать, можно использовать одно объявление для нескольких схожих контекстов, не страшно если есть лишние поля, на скорость не влияет.

Неистово плюсую

Fr0sT-Brutal,

Да, вторая конструкция выглядит лучше, и согласен, если она предшествует вызову, а не находится внутри него, тогда она не противоречит тому о чем написал.
Еще лучше было бы, если бы ее можно было убрать в секцию объявления переменных, а не кода.
Я для такой инициализации обычно использую псевдоконструктор записи. Но там проблемка если параметров больше 2-4 - как я писал - с количеством параметров уже в конструкторе

В чем проблема объявить record? при необходимости можно использовать и вложенные.

Не нужны для этого случая кортежи, поверь. потом будут лишние сложности в поддержке кода.
Нужен максимально строгий контроль компилятором типа параметров.
Вот тут предложили типа кортежа в ParamUtils. Я сам баловался таким псевдообобщением лет 20 назад, потом все это оказалось пшиком.
Но там это было более оправдано, потому что объекты протаскивались через COM объкектную модель, а там добавить параметр в устоявшийся код на 2 порядка сложней, чем добавить параметр в рекорд.

Конечно, передавать record между EXE в DLL не годится. Мне часто приходится передавать данные и между двумя exe.
Мое решение на это случай - одинаковый record ( или объекты) на стороне EXE в DLL, при передаче он сериализуется в строку, например через JSON.
Обращение внутри каждого модуля к типизированным полям рекорда. Добавление параметра делается в 1 месте, где описан рекорд и его сериализация. Ваш ParamsUtils тоже можно использовать для сериалзициии, но для этого, как я понимаю, кода будет не меньше чем c JSON, но с JSON стандартней и быстрее. И можно передавать сколь угодно сложные структуры.
Мой подход частично взят с идей Remoting SDK (старой версии, без RTTI)
https://www.remotingsdk.com/ro/default.aspx.

antox,

Между DLL и приложением обмениваюсь через небольшой надор экспортированных фуккий.
Даныне передаются в виде пакетов конада (это имя метода) + параметры.
Это все упаковывается по спецификации JSON RPC.
https://ru.wikipedia.org/wiki/JSON-RPC

Между приложениями, в т.ч. по сети, такие же пакеты JSON + бинарные блоки ходят через транспорт ZeroMQ
https://zeromq.org
Архитектура используется разнае, и клиент - сервер, и точка - точка

wadman,

Я и имел в виду под локальной эту r объявленную внутри блока.

Не надо тут ничего обобщать через дженерики. Сделай простые типизированные рекорды.
Я за дженерики и очень даже использую. Но тут они не нужны.