Функции с переменным числом аргументов: va_arg vs void*

Не сомневаюсь, но при выборе языка удобство для меня - это не самый главный пункт ;)

Удобство ещё в том, что если нужно в а-ля Си коде можно использовать: std, …

Вообще сам не использую, так как разработал (и пополняю) своё API, которое весьма удобно.

В целом конечно - «на вкус и цвет, товарищей нет».

Пошучу

Как говорил кирпич подойдя к краю крыши другому кирпичу - «Главное, чтобы человек попался хороший».

Без сомнения, ты решишь эту задачу с помощью C. И второй вариант безусловно рабочий. Всё дело в том, что будет потом. Насколько это будет читабельно, развиваемо, тестируемо. Вот тут возникают вопросы. И другой язык тут более предпочтителен. При строгой типизации уже при компиляции ты найдешь ошибку, которую в C не нашел бы и она бы выскочила на проде. При явном использовании типов явно видно как добавлять новые типы, при использовании полиморфизма не придется делать страшный switch () из приведения от (void*). Ладно, простите за офтоп.

struct args3 s;
s.a = 1;
s.b = 2;
call_by_index(3, &s);

Я думал в си уже завезли эту херню с фигурными скобками дли инициализации структур.

я определю список id и соответствующие данные, которые будут передаваться через указатель

Ну так не поступай как писатели printf (хотя там тоже много чего в оправдание можно сказать).

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

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

В целом конечно - «на вкус и цвет, товарищей нет».

Немного офтопа.

А чем использование C++ в качестве а-ля Си плохо?

Например. перевёл freetype и SDL на C++ и всё ok!

Я знаю содердимое для конкретного id, но я не могу заранее предусмотреть id для всех возможных случаев. Именно в этом вся суть. Если бы я заранее мог знать все возможные варианты, то я бы сделал бы обычный api.

В теле своей функции ты перечисляешь все ID. Или switch/case, или if - else if - else if. Не суть.

А значит ты предусмотрел абсолютно все ID. В теле своей функции, а не навызывающей стороне. В чём разница?

С точки зрения сишки — ерунда — ты. ТС правильные вопросы задает, чтобы не напортачить.

это зависит от флага/стандарта с которым ты собираешь проект.

Значит надо с правильным стандартом собирать и проблем нет.

Даже в этом случае имеется куча подводных камней в реализации. Увы!

Ну так не поступай как писатели printf (хотя там тоже много чего в оправдание можно сказать).

Пошучу

Разработчики printf наверное не знают иных способов.

С использованием метаданных printf более ээфективен и универсален.

Для run-time такой подход - «шик, блеск, красота».

А поди загляни в реализацию ngx_printf и спрячь этот пафос поглубже ))

А поди загляни в реализацию ngx_printf и спрячь этот пафос поглубже ))

Смотрел конечно.
Пафоса нет.
Не знают.
Впрочем лишний раз посмотрю исходники (ранее не знали).

Потому анонимус, если ничего дельного не выдает, идет в жопу. Ну, выдай что-то красивое и по делу — ты же можешь.

Возможно, я немного неточно выразился в шапке, давай попробую поточнее.

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

Представим, что есть 2 сервиса. Один - локальный проигрыватель музыки, второй удалённый, который отвечает за освещение. У каждого из них есть заголовочник со своим набором id и описанием того, что вместе с этим id передаётся (и передаётся ли вообще). Очевидно, что эти наборы будут полностью отличаться друг от друга, т.к. выполняют абсолютно разные задачи.

Допустим, я сделаю так, как ты решил - пропишу все id и структуры в заголовочнике механизма rpc. Что дальше? А дальше появляется условный вася пупкин и говорит: я хочу сделать автозапуск автомобиля, стоящего во дворе, и управление воротами, как мне это сделать через твой rpc? На что я справедливо развожу руками.

Теперь, когда я расписал всё более подробно, спрошу: почему бы мне не поступить так, как писатели printf, если я не знаю в данный момент список того, что будет передаваться при вызове, но об этом будет известно при использовании этого api?

В чём разница?

В том, что я пишу независимый механизм, который ничего не знает о вызывающей и вызымаемой сторонах. Его задача - доставить вызов и данные от одного процесса другому. Список аргументов известен лишь при использовании.

Автор хочет protobuf на C написать. Ну наверно это возможно, вроде даже есть биндинги для C.

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

Ты пытаешься переложить личную головную боль на прослойку. Нет — прослоек, которые решат все твои бизнес-задачи — не существует. Тебе придется писать их самому. По каждому кейсу, раз уж ты сам сказал, что «развожу руками».

В любом случае тебе придется реализовывать каждый вид обрабатываемого сообщения — тебе от этого не уйти.

Автор пока даже не понимает зачем и куда. Вот это мы и обсуждаем.

Тут ты никак не уйдешь от реализации «появляется условный вася пупкин и говорит: я хочу сделать автозапуск автомобиля, стоящего во дворе, и управление воротами».

Ты пытаешься переложить личную головную боль на прослойку

Нет, я пытаюсь переложить всю головную боль на того, кто будет использовать этот механизм. Ибо это в его задачу будет входить определение всех аргументов, которые передаются при конкретном id и написание обёрток при желании. Если это будет вася пупкин с его воротами и автозапуском, то он сам решит, какие id передаёт и принимает его код и какие аргументы при этом используются. Я-то каким боком тут?

А, ну тогда лепи void и не парься.

Но я так и не понял, при чем тут твоя базовая функция, которая там что-то исполняет?

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

Если это голосование, то я за вариант 2. Понятнее, что будет происходить, есть надежда, что будет легче отловить испорченную память при ошибках в интерпретации аргументов.

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

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

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

Представим, что есть 2 сервиса. Один - локальный проигрыватель музыки, второй удалённый, который отвечает за освещение. У каждого из них есть заголовочник со своим набором id и описанием того, что вместе с этим id передаётся (и передаётся ли вообще). Очевидно, что эти наборы будут полностью отличаться друг от друга, т.к. выполняют абсолютно разные задачи.

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

В таком случае, если не планируется передавать миллионы событий в секунду, то собственный ASCII-протокол или даже JSON видятся уже не самым худшим решением