Взаимодействие backend и frontend

Выносишь всю логику в разделяемую библиотеку и дёргаешь её API из любого main, хоть консольного, хоть ncurses, хоть GTK, хоть Qt. Или в чём вопрос?

Это я понимаю, я пробовал реализовать это. Но выходил костыль. Если можно, дайте какой-нибудь простой пример

logic.h:

#ifndef LOGIC_H
#define LOGIC_H

typedef struct
  {
	int param1,
	    param2;
  } config_t;

int  my_cool_func(config_t *conf);
void another_cool_func(int someshit);
int  awful_func_dont_call_it(char **memleak);

#endif /* LOGIC_H */

logic.c не привожу, там всё понятно.

main.c (CLI):

#include <stdlib.h>
#include <stdio.h>
…
#include "path/to/logic.h"



int main(int argc, char **argv)
  {
	config_t conf;

	/* Parse arguments */
	/* Run logic */
	return my_cool_func(&conf);
  }

main.cpp (Qt):

#include <QApplication>
…
extern "C"
  {
	#include "path/to/logic.h"
  }



int main(int argc, char **argv)
  {
	QApplication app(argc, argv);

	// Your logic

	return app.exec();
  }

Аналогично с остальными.

CMakeLists.txt (я использую CMake, но можно сделать аналогично на любой системе сборки):

cmake_minimum_required(VERSION 3.0)

project(liblogic C)
… # всякие настройки

add_library(logic SHARED logic.c)

project(logic-cli C)
…

add_executable(logic-cli main.c)
target_link_libraries(logic-cli logic)

project(logic-qt)
…

add_executable(logic-qt main.cpp)
target_link_libraries(logic-qt logic Qt5::Core Qt5::Widgets)

Как-то так. Разумеется, это всё очень упрощённо, просто чтоб показать принцип. За синтаксическую корректность не ручаюсь

Худший код-стайл, который я когда-либо видел. Какое-нибудь гну?

Если нужно подружить несколько реализаций фронтенда (ncurses/gtk/qt/cocoa/etc), для этого идеально подойдет абстрактная фабрика.

Если же нужно всего два фронтенда - консольный (классический вариант, не ncurses) и гуевый, то проще всего сделать как-то так:

$ myprogram --gui

Или так:

$ myprogram-gui $ myprogram --some-console-args

backend и frontend - разеые процессы, коммуницирующие между собой через IPC - самый гибкий вариант. Нужно только продумать интерфейсы и найти IDL из которого можно нагенерировать код занимающийся всем IPC.

http://www.faqs.org/docs/artu/ch11s07.html#id2960228

Худший

Вкусовщина. Я, например, не терплю K&R.

Какое-нибудь гну?

Вариация

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

Правильно! Перед написанием hello world необходимо пройти пятилетние курсы по архитектуре вычислительных систем, праву и металлургии и двухнедельные по современной философии.

Худший код-стайл, который я когда-либо видел

Плюсую.

Желательно так чтобы можно было писать backend на С, a frontend на С++

Почему такое ограничение? Можно зафигачить оба на плюсах и применить REST. Хотя в суть проекта я не вникал...

Спасибо, как раз сам до этого дошел. Написал калькулятор с cli и ncurses, принцип тот же, что и выше. Сразу пробовал другие способы, но выходил костыль. Уже все прояснилось, считайте тему закрытой.

и применить REST

нужно ли? :)

Зависит от задачи, опять же таки.

не знаю, но я об этом читал еще где-то в манах лет 15 назад, когда и паскаля толком не умел

Вэбня на десктопе? Фу как пошло!

15 лет назад было модно под онтопиком генерировать код из IDL? ПЛ моему тогда тупо парсили вывод программы...

Вэбня на десктопе? Фу как пошло!

Это будущее. Которое уже почти наступило.

Рест с вебом связан разве что с помощью http.

Ага и вместо ноомалного IPC поднимать вэбснрвер и городить рест на пэхапэ. А GUI писать через qwebengine... Какой-то кошмар... Брр.

Ага и вместо ноомалного IPC поднимать вэбснрвер

Чем тебе REST не нормальный IPC?

и городить рест на пэхапэ

Пиши на Rust %)

А GUI писать через qwebengine... Какой-то кошмар...

И что кошмарного? HTML + CSS - это просто еще один GUI-тулкит.

HTML + CSS - это просто еще один GUI-тулкит.

Ещё бы не требовался практически полноценный браузер для его использования.

Люди работают над этим - Sciter, Modest. Может, на основе Servo что-то будет.

Причём здесь «рест на пэхапэ». У нас был вполне себе rest на плюсах и никакой веб сервер там не нужен. Есть библиотеки с HTTP классами Не всегда они покрывают на все 100% твои требования по фичам и производительности, конечно, но тем не менее. В том проекте, мы таки отказались от библиотеки и написали свою http часть на boost asio, емнип, поскольку упёрлись в производительность библиотеки. Получалось что front и backend как бы части распределённой системы. Хочешь, на одной машине оба запускай. Хочешь - на разных.

libpcap и wireshark, tshark, tcpdump и прочие.

http - лишняя сущность. Есть сокеты, shared memory, dbus в конце концов. Вместо json'а есть куда более адекватный ptb, где хотя бы меньше бойлерплейта.

Главное что все это по-хорошему писать вообще не надо. Вон, есть тот же commonapi: https://at.projects.genivi.org/wiki/pages/viewpage.action?pageId=5472316

если есть API и «ядро» отлажено, то делаешь GUI фронтенд на Tk и не жужжишь :-) получается нативная программулина для всех популярных платформ.

так или иначе любой комм. софт это будет рест напохапе. если до релиза дойдет.

http - лишняя сущность

давайте строить API над D-Bus

Надеюсь, авторы этих предложений будут гореть в аду. Вместе с поцерингом, хартманном и сиверсом.

Тебе не кажется, что ты искажаешь мою оригинальную цитату?

Нет. Первая часть не искажена вообще, вторая отражает сущность CommonAPI - это средство построения интерфейсов, со своим IDL и кодогенератором: https://at.projects.genivi.org/wiki/pages/viewpage.action?pageId=5472316 .

В первой части варианты shared memory и sockets и _в конце концов_ dbus. CommonAPI умеет еще someip, а при желании можно написать и свой бэкэнд. Прелесть именно в кодогенерации.

https://at.projects.genivi.org/wiki/pages/viewpage.action?pageId=5472320

В первой части варианты shared memory и sockets и _в конце концов_ dbus.

А поверх сокета наверняка свой протокол. Почему он не лишняя сущность?

на десктопе? Не зависит.

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