Концепция передачи параметров в виде строки

Какие другие способы можете предложить (вызов разных функций через один интерфейс)

Я могу предложить так не делать.

а как лучше? То, какая конкретно функция должна быть вызвана, известно только на этапе выполнения программы

Нужно сделать это нормальным интерфейсом с нормальными функциями и нормальными параметрами.

Как, например? См. update

Что за упорин. Rest придумали вместо soap. Или о чем ты.

Если действительно нужно - делай, я разрешаю. Потом можно будет легко добавить скриптинг, например, к твоему поделию.

Если нужна именно альтернатива строкам - ну посмотри как ioctl сделаны - передаёшь номер функции и сцылку на структуру с параметрами (или объект, если прям плюсплюсно хочется).

Если действительно нужно - делай, я разрешаю

спасибо. Не то, чтобы прям очень-очень, просто решили, что парсинг параметров должен делать тот, для кого эти параметры предназначены, а не вызывающая функция, логично?

За ioctl спасибо, гляну

Update: глянул.

«Долгое время операции ioctl() были основной техникой выполнения нестандартных действий над устройством (и не только в операционной системе Linux, но и в других, например, в той же MS Windows). Но операции ioctl() являются опасными: при их выполнении отклоняется контроль типизации параметров, и в качестве параметра может быть передана любая структура. Если в коде реализующей части вызова ioctl() (модуле ядра) не реализован тщательнейший контроль данных, переданных в вызов, то некоторые параметры могут вызывать тяжелые ошибки в коде ядра, вплоть до его разрушения. Серьёзной альтернативой управляющих операций ioctl() является чтение/запись информации через псевдоимена файловой системы /proc и /sys»

Серебряной пули нет...

Можно передавать вектор строк, можно передавать словарь, ещё есть всякие any-типы. Если части программы вообще не должны быть связаны, то типы, наверное, лишнее, но использовать контейнер может быть проще, если данные всегда являются набором значений. Ещё можно глянуть на реализацию сигналов-слотов, где передают вектор указателей на void, которые по назначению кастуются (но тут надо чтобы типы всегда были согласованы между сторонами).

Есть проект (не важно, на каком языке)

А какой язык всё-таки? В python есть удобный сахар для передачи поизвольных параметров через словарь, не нужно заниматься ручным парсингом.

def func(**kwargs):                                                             
    for k, v in kwargs.items():                                                 
        print('{}: {}'.format(k, v))                                            
                                                                                
func(a = 1, b = 2)

a: 1
b: 2

Речь о c++. Собственно, идея с передачей в виде строки возникла благодаря питону :)

Ну и такая концепция кажется логичной: парсинг параметров должен делать тот, для кого эти параметры предназначены, а не вызывающая функция

Ещё можно глянуть на реализацию сигналов-слотов, где передают вектор указателей на void, которые по назначению кастуются (но тут надо чтобы типы всегда были согласованы между сторонами).

А если скастовать void не туда, то произойдёт Segmentation fault, правильно я понимаю?

Вот ты распарсил строку «param=val» в param и val, а дальше что?

if(param == "foo") {x.foo = val;}
else if(param == "bar") {x.bar = val;}
//ещё 1000 таких же строк

Неужели так? Рефлексии то нет

Именно так. Парсить её в любом случае надо, вопрос — в какой части программы? А какая альтернатива?

Тут проблема даже не написать эти 1000 строк кода, а постоянно поддерживать их в актуальном состоянии при изменении кодовой базы.

А какая альтернатива?

В качестве альтернативы можно взять другой язык для твоего менеджера вызовов call_function(Функция1, "строка с параметрами"). Сами функции пускай остаются в C++ — это не проблема. Биндинги генерируются автоматически, а всю работу по разбору будет делать интерпретатор скриптового языка.

Если такой вариант приемлем, то могу набросать минимальный рабочий пример на Python & C++.

Если такой вариант приемлем, то могу набросать минимальный рабочий пример на Python & C++.

да не, спасибо, такую штуку я и сам использую в другом проекте.

Как по мне, полагая идея с любой точки зрения.

пологая? А какая крутая?

А если скастовать void не туда, то произойдёт Segmentation fault, правильно я понимаю?

Если повезёт, то да. Если не повезёт, то тихо будет сделано что-то не то. В том же Qt это надёжно работает, потому что код для вызова и обработки генерируется автоматически.

Другие способы: DCE, CORBA, DDE, OLE, OLE2, COM/DCOM, RMI/JRMP, RMI/IIOP, D-Bus, XML-RPC, SOAP, WSDL, REST.

насколько мне известно, большая часть этих «способов» предназначена для межпроцессного взаимодействия, не?

а в этом вашем бусте разве нет какой-нибудь реализации интерфейса Callable? я к тому, что это довольно непростая вещь и велосипедить свое какой смысл?

я не знаю, буст не мой, я с ним не работал :)

Вдогонку к идее про ioctl: передавай указатель на какой-нибудь пустой базовый класс ArgsObject, а дальше dynamic_cast’ом приводи к типу структуры с аргументами к конкретному методу. Если тебе действительно нужно мультиплексировать несколько методов в один. Но звучит как какое-то переусложнение.

Ты описываешь задачу так, как будто эти два модуля у тебя совсем друг про друга не знают. А если так, то можно уж и пойти до конца, заюзав RPC, и считать их разными процессами: какая разница, в одном они адресном пространстве или нет. Но никто тебе не скажет точно, пока ты не расскажешь исходную задачу. А до тех пор мы обречены решать X-Y проблему.

https://github.com/sergey-shambir/bind-command

https://www.youtube.com/watch?v=fs6KV9iNi_U

Паттерн «стратегия» может быть просто интерфейсом — набором функций объеденным в структуру. В нужный момент выбираем нужную функцию.

Ты что-то делаешь не так.

набор параметров для конкретного вызываемого метода может сильно разниться.

Набор параметров известен на момент компиляции? Если да, то можно просто вызывать функцию - обычную или виртуальную.

Если нет - приведи пример реального кейса когда такое возможно. Ведь если программа не знает на момент компиляции сколько параметров у вызываемой функции, сколько параметров она будет передавать при вызове этой функции? Приведи кейс, уверен что он решается либо с помощью массивов, либо с помощью опциональных параметров (ну, почти), либо variadic functions.

На самом деле задача передачи «всех параметров в виде строки» существует, и успешно решается стандартными способами (я потом скажу какими, многое тебе уже описали). Но она не для того кейса что ты описал.

Серьёзной альтернативой управляющих операций ioctl() является чтение/запись информации через псевдоимена файловой системы /proc и /sys

Олег Цилюрик

http://psihomed.com/grafomaniya/

ох...шь open/close делать и разбираться куда чего писать, при том что проблема

не реализован тщательнейший контроль данных

никуда не денется.

https://github.com/torvalds/linux/blob/master/Documentation/ABI/obsolete/sysf...

This ABI is deprecated and will be removed after 2020. It is

replaced with the GPIO character device.

разработчики чета не в восторге от такой «альтернативы»

Если ты в значениях не экранируешь переводы строки, у тебя баг.

any/variant/...

разработчики чета не в восторге от такой «альтернативы»

Были бы не в восторге - выпилили бы весь sysfs. А тут тупо у говнокодеров разбери-пи тормозил.

gRPC ищешь ты.

Что-то мне кажется ты пытаешься сделать единообразными совершенно разные по сути вещи. А это плевок в сторону ООП. Глянь сторону Питона или чего-то подобного.

gRPC ищешь ты.

нет, но спасибо за годную инфу :)

Если ты в значениях не экранируешь переводы строки, у тебя баг.

параметры пишутся тоже программой (совсем другой), так что баги тут не должно быть

Набор параметров известен на момент компиляции? Если да, то можно просто вызывать функцию - обычную или виртуальную.

известен, но некоторые из них опциональные (могут быть не заданы)

На самом деле задача передачи «всех параметров в виде строки» существует, и успешно решается стандартными способами (я потом скажу какими, многое тебе уже описали).

скажи сейчас :) Вызов различных функций хочется реализовать через единый «универсальный» интерфейс

Это общая проблема при форматировании. Если в сообщении может использоваться любой байт 0-255, то какой бы не был выбран разделитель, будет пересечение с данными. Поэтому, например, в url в параметрах символ & нужно кодировать особо.

Можно упороться и воспользоваться protobuf :)

Функция всегда принимает только один аргумент — Message определенного типа. Это тип можно выводить шаблоном и динамически парсить в него text/json-представление этого message.

известен, но некоторые из них опциональные (могут быть не заданы)

В C++ опциональные аргументы можно передавать несколькими способами. Я бы рекомендовал обратить внимание на два:
1. Уникальность функции определяется не только ее именем, но и количеством аргументов. То есть ты можешь задавать разную имплементацию в зависимости от количества аргументов.
2. Параметрам функции можно задать дефолтные значения.

#include <iostream>

void fn(std::string str, int i=0)
{
        std::cout << "called fn('" << str << "', " << i << ")" << std::endl;
}

void fn()
{
        std::cout << "called fn()" << std::endl;
}

int main()
{
        fn("test", 5);
        fn("test");
        fn();

        return 0;
}

$ g++ test.cpp && ./a.out
called fn('test', 5)                                                                                                                                                             
called fn('test', 0)
called fn()

скажи сейчас :) Вызов различных функций хочется реализовать через единый «универсальный» интерфейс

Давай сначала решим вопрос передачи произвольных наборов данных.

То, что тебе нужно, называется сериализация. Дальше нужно выбрать формат/протокол. Сейчас популярен JSON. Раньше был XML. Есть другие, например Google Protocol Buffers. Как видишь, уже давно есть множество реализаций сериализации/десериализации под типовые форматы. Ссылки на примеры я дал, но лучше погуглить побольше по ключевым словам, например, C++ object serialization json. Валидаторы также имеются, например для JSON.

Что до интерфейса - я так и не понял архитектуру.

Если это микросервисы, то, например, REST может быть вариантом. Но у REST свои недостатки; например, тот, что заточен под работу с объектами - создание, модификация, и т. п., а если нужно что-то шире, то приходится извращаться. Если у тебя произвольные функции, то гугли на тему RPC; вариантов много.
Посмотри вот это

Ключевое: и для вызова методов на другом компоненте, и для сериализации данных уже давно есть готовые библиотеки, и свой велосипед писать не нужно.

Но если у тебя весь проект компилится как единое целое, то, повторюсь, вызов функций лучше делать средствами C++ как я описал в начале поста.

А сколько всего у тебя этих разных параметров? 10-20?

D-Bus, XML-RPC, SOAP, WSDL, REST.

Но ведь в основе всех этих технологий стоит передача всех параметров в виде одной строки, которая парсится на вызываемой стороне.

В чем принципиальное отличие от того, что есть у ТС?

Именно так. Парсить её в любом случае надо, вопрос — в какой части программы?

В парсере. </thread>

А сколько всего у тебя этих разных параметров? 10-20?

пока до 10, но одна функция может принимать массив произвольной длины, например

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

Что до интерфейса - я так и не понял архитектуру.

Грубо говоря так, как описано в ОП: условно есть программа, которая считывает скриптовый файл и вызывает написанные в этом файле функции с передачей им параметров, которые считываются из этого же файла. Реализация этих функций сделано в виде виртуального класса, где виртуальная функция «call_function» принимает, условно говоря, одну строку со списком параметров, которую парсит внутри себя конкретная реализация этой функции.

Передавать параметры в виде JSON, XML или ini (как у меня сейчас) — не принципиально, но спасибо за советы :)

я знал, что хорошие мысли приходят не только мне в голову... :D

а чем тебя обычный стек не устраивает? я когда-то писала скриптовый интерпретатор. через стек передавать параметры удобно и это стандартное решение в таких вызовах.

Видимо, тем, что я не очень представляю, как это сделать :)

ну, почитай теорию, что ли :) тебе всё равно придётся обрабатывать всякие там циклы, переходы при выполнении кода внутри скриптов, возврат из функций. а это всё делается через стек.

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