Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / C++ Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3 4 5 6      [все]
 Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
Сокет юникс, protobuff, qRPC?
Ось линуксоподобная.

Сообщение было отредактировано: 23 апр 20, 17:25
23 апр 20, 17:26    [22121611]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 50033

shmem

Posted via ActualForum NNTP Server 1.5

23 апр 20, 17:40    [22121618]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
Dimitry Sibiryakov,

Боюсь слишком низкий уровень.
Все писать надо, семафоры, проверялки что там что то появилось для события. Сериализацию.
23 апр 20, 18:22    [22121633]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 50033

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

Posted via ActualForum NNTP Server 1.5

23 апр 20, 18:37    [22121646]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
Dima T
Member

Откуда:
Сообщений: 14743
ZeroMQ
23 апр 20, 19:23    [22121668]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
Dimitry Sibiryakov,
Не решил. Обсуждаем плюсы минусы
23 апр 20, 19:52    [22121681]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
PetroNotC Sharp
Сокет юникс, protobuff, qRPC?
Ось линуксоподобная.


protobuf здесь выпадает из списка. Он вобщем не относится к интеракции процессов.
Это просто протокол сериализации как и Avro/Apache Thrift. И его можно юзать и для
файлов и для сетей.
23 апр 20, 19:56    [22121683]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
Про D-Bus еще можно почитать. Вот щас в Ubuntu используется.

Вообще думаю надо пойти еще и от языка разработки и платформы. Если Qt - то будет одно.
Если Java то будет еще штук 20 как.

ZeroMq удобен когда 1 процесс должен за секунду передать тыщу мегабайт в другой
процесс и тот другой должен так-же быстро это схавать. Если таких требований нет
- то лучше наверное брать что-то высокоуровневое. Или просто то что удобно программировать.
Без амбиций.
23 апр 20, 20:00    [22121687]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
ъъъъъ
Member

Откуда:
Сообщений: 685
Dima T
ZeroMQ

!!! :)
...
Я без зазрения совести пихаю ZMQ во все дыры, пока - полет нормальный.
Правда, я остановился на версии 4.2 (кажется), которую все еще под WinXP можно.
Очень классная транспортная основа, поверх неё легко наращивать прикладное "мясо". Легко расширяется и вбок и вглубь. Не завязан ни на какие-либо брокеры, особенности операционок, не требует инсталляции, надежность, понятные исходники. Почти нет разницы при организации разных уровней (межнитевое, межпроцессное, межкомпьютерное) взаимодействий.
Отличная документация, мощное комьюнити, бесплатно.

Из недостатков: если пытаться использовать сокеты ZMQ "привычным" ("а вот в <Berkeley Sockets>||<Windows Sockets>,...") образом - получится фигня, наблюдал не раз. Т.е., чтение документации должно предшествовать.
23 апр 20, 23:35    [22121770]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
Автору я предлагаю написать 2 превед-медвед-мира на D-Bus, ZeroMQ.

И просто посмотреть где оно практически будет удобно. И прикинуть цену внесения изменений.
24 апр 20, 10:19    [22121882]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
mayton
PetroNotC Sharp
Сокет юникс, protobuff, qRPC?
Ось линуксоподобная.


protobuf здесь выпадает из списка. Он вобщем не относится к интеракции процессов.
Это просто протокол сериализации как и Avro/Apache Thrift. И его можно юзать и для
файлов и для сетей.

Да. Прочитал.
А там даже никаких вкусностей сверху нету?
У gRPC такая же картина? Не в курсе?
24 апр 20, 13:29    [22122041]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
Я протобуф использовал косвенно. Как часть проекта Apache-ORC. И там протобуф использовался
просто для хранения длинных последовательностей вещественных и целых чисел в файлах.
+Еще были опции сжатия. Но они скорее всего шли от Apache-ORC.
24 апр 20, 13:31    [22122048]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
C gRPC не работал.
24 апр 20, 13:32    [22122050]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
mayton
Автору я предлагаю написать 2 превед-медвед-мира на D-Bus, ZeroMQ.

И просто посмотреть где оно практически будет удобно. И прикинуть цену внесения изменений.
как раз собираюсь.
Подскажи, ожидать API при общении с модулями как в шарпе или java
servis.getUser()
То есть построить семантику методы тут реально?
24 апр 20, 13:35    [22122055]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
Не понял суть вопроса. На примере лучше.
24 апр 20, 13:43    [22122062]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
mayton,
Суть построения API в java и тут совершенно противоположная.
Тут шлем структуры с командами по одному и тому же методу.
По крайней мере в протобафе.
А в java или API google есть список методов с комментами.
Как сделать api на 50 методов.
В соап там прокси класс генерится с этими методами.

Сообщение было отредактировано: 24 апр 20, 13:53
24 апр 20, 13:53    [22122076]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
mayton
Не понял суть вопроса. На примере лучше.

servis.getUser()
Сериализовать тут что?
24 апр 20, 13:57    [22122080]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
Вряд-ли я тебе отвечу на этот вопрос сразу. Ты начни делать HelloWorld - и по мере поступления
информации - будем смотреть где API удобнее.

Про сериализацию - непонятно. Можно ответить и да и нет. Смотря какие фреймворки и протоколы связи.
24 апр 20, 14:00    [22122084]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
mayton,
ОК. Попозже.
Протобаф - передача структур и классов в другой процесс. А мне метод с именем вызввть надо.
24 апр 20, 14:13    [22122101]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
mayton
Ты начни делать HelloWorld - и по мере поступления
информации - будем смотреть где API удобнее.

народ.
Подскажите как сделать бинарники в протобаф либе для студии в винде.
Я директиву make вообще не знаю.
Вот инструкция
https://github.com/protocolbuffers/protobuf/blob/master/src/README.md
автор
To build protobuf from source, the following tools are needed:

autoconf
automake
libtool
make
g++
unzip

Но тут меня напугало, что делать в винде? Если ничего этого нет?
И make я в жизни не запускал.
Что делать?
С чего начать?
21 май 20, 17:43    [22137213]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
Вот тут пишут что есть уже скомпилированные бинарники.
Но опять же, внутри архивов их не нашел
https://github.com/protocolbuffers/protobuf/releases/
21 май 20, 17:47    [22137217]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
ХЗ. Но там дальше по тексту они дают более конкретную ссылку на CMake + VisualStudio

https://github.com/protocolbuffers/protobuf/blob/master/cmake/README.md
21 май 20, 17:52    [22137222]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
mayton
ХЗ. Но там дальше по тексту они дают более конкретную ссылку на CMake + VisualStudio

https://github.com/protocolbuffers/protobuf/blob/master/cmake/README.md

OK
CMake на компе не было - поставил.
Делаю дальше
21 май 20, 17:58    [22137226]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
c:\Path\to\cmake\build\release>cmake -G "NMake Makefiles" ^
Продолжить? -DCMAKE_BUILD_TYPE=Release ^
Продолжить? -DCMAKE_INSTALL_PREFIX=../../../../install ^
Продолжить? ../..
CMake Error: The source directory "C:/Path/to/cmake" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.
- Как убрать вопрос Продолжить?
- путь добавлять в CMakeLists.txt?
21 май 20, 18:09    [22137234]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
PetroNotC Sharp
- путь добавлять в CMakeLists.txt?

по данному вопросу не тот путь был
c:\Path\to\cmake\build\release>cd c:\Path\to\protobuf\cmake\build\release

c:\Path\to\protobuf\cmake\build\release>cmake -G "NMake Makefiles" ^
Продолжить? -DCMAKE_BUILD_TYPE=Release ^
Продолжить? -DCMAKE_INSTALL_PREFIX=../../../../install ^
Продолжить? ../..
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:20 (project):
The CMAKE_C_COMPILER:

cl

is not a full path and was not found in the PATH.

To use the NMake generator with Visual C++, cmake must be run from a shell
that can use the compiler cl from the command line. This environment is
unable to invoke the cl compiler. To fix this problem, run cmake from the
Visual Studio Command Prompt (vcvarsall.bat).

Tell CMake where to find the compiler by setting either the environment
variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
the compiler, or to the compiler name if it is in the PATH.


CMake Error at CMakeLists.txt:20 (project):
The CMAKE_CXX_COMPILER:

cl

is not a full path and was not found in the PATH.

To use the NMake generator with Visual C++, cmake must be run from a shell
that can use the compiler cl from the command line. This environment is
unable to invoke the cl compiler. To fix this problem, run cmake from the
Visual Studio Command Prompt (vcvarsall.bat).

Tell CMake where to find the compiler by setting either the environment
variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
to the compiler, or to the compiler name if it is in the PATH.


-- Configuring incomplete, errors occurred!
See also "C:/Path/to/protobuf/cmake/build/release/CMakeFiles/CMakeOutput.log".
See also "C:/Path/to/protobuf/cmake/build/release/CMakeFiles/CMakeError.log".
21 май 20, 18:25    [22137243]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 50033

PetroNotC Sharp
cl

is not a full path and was not found in the PATH.

Может, его нужно запускать из студийного шелла, который устанавливает все нужные
переменные окружения?.. Кстати, там может внезапно обнаружиться и CMаke, уже установленный
вместе со студией.

Posted via ActualForum NNTP Server 1.5

21 май 20, 18:34    [22137246]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
Я когда еще на винде сидел - все С++ каноничные вещи проверял сначала на виртуалке VBox под Linux.

Там обычно все "изкаробки" работает. А потом когда освоил что к чему переносил в винду.
21 май 20, 18:37    [22137247]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
Dimitry Sibiryakov,
уже успел проверить немного эту идею.
Но там вроде круче.
С 17ой студии вообще самому не надо запускать CMake
https://docs.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio?view=vs-2019
если я правильно понял.
Пробую апдейт студии
21 май 20, 18:43    [22137253]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
mayton
Там обычно все "изкаробки" работает.

винда и линукс слишком больная разница. Чтобы по шагам переносить.
21 май 20, 18:44    [22137255]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 50033

PetroNotC Sharp
С 17ой студии вообще самому не надо запускать CMake

Они просто включили CMake в состав студии.

Posted via ActualForum NNTP Server 1.5

21 май 20, 18:49    [22137260]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
Да но этож мать ево Protobuf. Цитирую

language-neutral, platform-neutral, extensible mechanism for serializing structured data


Тоесть должен летать. Везде.
21 май 20, 18:49    [22137262]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
Dimitry Sibiryakov
PetroNotC Sharp
С 17ой студии вообще самому не надо запускать CMake

Они просто включили CMake в состав студии.

ну это как раз на MS похоже - никаких копаний в файлах. Всё в IDE
21 май 20, 18:55    [22137269]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
mayton
Тоесть должен летать. Везде.

сборка без ide для меня темный лес.
Привычка.
21 май 20, 18:56    [22137270]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
PetroNotC Sharp
Dimitry Sibiryakov
пропущено...

Они просто включили CMake в состав студии.

ну это как раз на MS похоже - никаких копаний в файлах. Всё в IDE

У меня знакомец прямо из Студии приложения запускает в Линукс на виртуалке. Если я правильно его понял.
21 май 20, 19:16    [22137279]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
petrav,
Если кроме него это никто не умеет, ценность этого сразу падает.

"Сложнее всего в мире достигнуть простоты — это крайняя граница опыта и последнее усилие гения". © George Sand.
21 май 20, 19:49    [22137298]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
petrav,
У нас типа Git стоит.
Написал что то в винде. Протестил то что виндовое.
Потом отправил одной командой в хрранилище.
В линуксе получил и работай точно также.
Все равно есть места где директивы компилятору для кого участок кода.
Без этого не получается.
21 май 20, 20:05    [22137306]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
Вот так счас делается бинарник CMake через студию.
Появилось понятие Проект CMake.
https://docs.microsoft.com/ru-ru/cpp/build/get-started-linux-cmake?view=vs-2019
21 май 20, 23:25    [22137387]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
PetroNotC Sharp
Вот так счас делается бинарник CMake через студию.
Появилось понятие Проект CMake.
https://docs.microsoft.com/ru-ru/cpp/build/get-started-linux-cmake?view=vs-2019

Ну, собственно, мой знакомый примерно это и сделал. Он в Студии создал отдельную конфигурацию сборки для Linux. Прикрутил туда clang, какой-то из вариантов make. Запуск прямо из Студии в виртуалке с Линукс и удалённый отладчик.

Повторюсь, если я правильно понял.
21 май 20, 23:55    [22137397]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 10171
mayton
language-neutral, platform-neutral, extensible mechanism for serializing structured data
Тоесть должен летать. Везде.
Это для (уже готовой) реализации. Тоже самое можно сказать и про целую пачку прикладных интернет-протоколов.
Далее. Даже если у вас есть "platform neutral" исходные тексты, то это не отменяет суровой привязки к процессу сборки на всех этапах. А "platform-neutral toolchain" ещё не завезли. И, вроде как, даже не планируют.

Сообщение было отредактировано: 22 май 20, 09:12
22 май 20, 09:13    [22137468]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
Ну хотя-бы декларированы намерения.
22 май 20, 10:16    [22137509]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
PetroNotC Sharp, а ты пробовал уже свои месседжи описать на этом птичьем языке?

https://developers.google.com/protocol-buffers/docs/cpptutorial
22 май 20, 10:55    [22137545]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
mayton
PetroNotC Sharp, а ты пробовал уже свои месседжи описать на этом птичьем языке?
https://developers.google.com/protocol-buffers/docs/cpptutorial

дак это сишный язык))
На одном конце профиля - структуры. Мы их кидаем на другой конец провода.
Всё банально.
22 май 20, 11:02    [22137550]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
petrav
PetroNotC Sharp
Вот так счас делается бинарник CMake через студию.
Появилось понятие Проект CMake.
https://docs.microsoft.com/ru-ru/cpp/build/get-started-linux-cmake?view=vs-2019

Ну, собственно, мой знакомый примерно это и сделал. Он в Студии создал отдельную конфигурацию сборки для Linux. Прикрутил туда clang, какой-то из вариантов make. Запуск прямо из Студии в виртуалке с Линукс и удалённый отладчик.

Повторюсь, если я правильно понял.

возможно.
Просто это имхо дичайший оверхед.
Мне всего нужен батник в винде чтобы всё скомпилировалось.
Пришлось ставить CMake в Program Files и ....хорошо что студия взяла это всё Г...требуху к себе.
Но ещё я не понял, поддерживают ли формат студия<--> Make File все проекты на гитхабе.
22 май 20, 11:05    [22137552]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
mayton
PetroNotC Sharp, а ты пробовал уже свои месседжи описать на этом птичьем языке?

https://developers.google.com/protocol-buffers/docs/cpptutorial

с другой стороны я выше жаловался, что мне структуры не нужны. Мне
22122055
22 май 20, 11:07    [22137555]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
crutchmaster
Member

Откуда: оттуда.
Сообщений: 1114
mayton
Про D-Bus еще можно почитать

Не надо dbus. Тогда уж rabbitmq/kafka.
22 май 20, 11:07    [22137556]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
PetroNotC Sharp
mayton
PetroNotC Sharp, а ты пробовал уже свои месседжи описать на этом птичьем языке?
https://developers.google.com/protocol-buffers/docs/cpptutorial

дак это сишный язык))
На одном конце профиля - структуры. Мы их кидаем на другой конец провода.
Всё банально.

Я знаю что банально. Опубликой что-нибудь.
22 май 20, 11:08    [22137557]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
mayton
Я знаю что банально. Опубликой что-нибудь.

Обязательно. Я ещё не скомпилил))))
Линкер ругается.
В процессе.
22 май 20, 11:10    [22137559]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
PetroNotC Sharp
mayton
PetroNotC Sharp, а ты пробовал уже свои месседжи описать на этом птичьем языке?

https://developers.google.com/protocol-buffers/docs/cpptutorial

с другой стороны я выше жаловался, что мне структуры не нужны. Мне
22122055

А зачем ты учишься собирать protobuf если тебе нужен удалённый вызов методов, как я понял?
22 май 20, 11:25    [22137569]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
petrav,
мне вообще нужны просто бинарники для винды от него
22 май 20, 11:26    [22137572]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
petrav,
Я делаю Hello World
protobuff --> qRPC
потом возможно ZeroMQ.
Ты про него что там есть вызов методов?
22 май 20, 11:28    [22137575]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
PetroNotC Sharp

потом возможно ZeroMQ.
Ты про него что там есть вызов методов?

Я просто пробежался по описанию protobuf, почитал твои посты и задал вопрос.

А ты не интересовался Inter-Process Communication in Qt? Вон они пишут, что к D-Bus прикрутили систему слоты-сигналы. Ты же на Qt программируешь?
22 май 20, 11:43    [22137584]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
petrav,
Я тоже чисто прочитал что в Qt сигналы меж процессов не работают.
22 май 20, 11:45    [22137586]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
PetroNotC Sharp
petrav,
Я тоже чисто прочитал что в Qt сигналы меж процессов не работают.

А я по документации и примерам (D-Bus Chat Example) вижу что работают. Я правда не уверен, что это будет работать под Win. Но у меня собралось, запустилось и написало, что не может подключиться к сессии D-Bus.

org::example::chat *iface;
iface = new org::example::chat(QString(), QString(), QDBusConnection::sessionBus(), this);
QDBusConnection::sessionBus().connect(QString(), QString(), "org.example.chat", "message", this, SLOT(messageSlot(QString,QString)));
connect(iface, SIGNAL(action(QString,QString)), this, SLOT(actionSlot(QString,QString)));

Может я что-то не понимаю...
22 май 20, 12:08    [22137601]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
petrav,
ну, если не трудно то сделайте демку. Я не такой уж спец.
- два Qt приложения Сервер и клиент
- запускаем рядом в разных процессах
- в окошке клиента вводим 1234 и в окошке сервера это появилось.
А потом я попробую.
22 май 20, 12:18    [22137606]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
PetroNotC Sharp
petrav,
ну, если не трудно то сделайте демку. Я не такой уж спец.
- два Qt приложения Сервер и клиент
- запускаем рядом в разных процессах
- в окошке клиента вводим 1234 и в окошке сервера это появилось.
А потом я попробую.

Зайди в папку аля "Examples\Qt-5.10.1\dbus\". Там есть сэмпл "chat" и даже файл .pro есть, xml описание протокола.

DBUS_ADAPTORS += org.example.chat.xml
DBUS_INTERFACES += org.example.chat.xml
22 май 20, 12:25    [22137615]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
petrav
"Examples\Qt-5.10.1\dbus\"
OK
Счас, добью protobuf и посмотрю. Спс.
22 май 20, 12:29    [22137620]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
PetroNotC Sharp
Вот так счас делается бинарник CMake через студию.
Появилось понятие Проект CMake.
https://docs.microsoft.com/ru-ru/cpp/build/get-started-linux-cmake?view=vs-2019

вроде работает.
Нужно правой кнопой на проекте и buid - libprotobuf.lib = появится в Users....
............
Но при переключении конфига exe с release на debug ошибка:
Error	LNK2038	mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in project-name.obj	project-name	D:\project-name\libprotobuf.lib(common.cc.obj)	1
Либу я сделал одну в режиме release и прописал в проект exe тоже одну.
Если я не отлаживаю либу а отлаживаю экзешник это правильно?
22 май 20, 16:49    [22137810]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
PetroNotC Sharp

Либу я сделал одну в режиме release и прописал в проект exe тоже одну.
Если я не отлаживаю либу а отлаживаю экзешник это правильно?

Конечно. Но я бы всё же разобрался что там происходит с макросом '_ITERATOR_DEBUG_LEVEL'. Это не сложно.
22 май 20, 18:18    [22137850]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
c Protobuf демкой вопрос решён - работает.

/*********.proto*****************************
syntax = "proto2";
package pack.my;
message Person{
  string name = 1;
}
**************************************/
#define WIN32_LEAN_AND_MEAN

#include "stdafx.h"
#include <iostream>
#include <fstream>
#include <string>
#include <winsock2.h>
#include <windows.h>
#include <ws2tcpip.h>
#include <conio.h>
#include "addressbook.pb.h"
#include "addressbook.pb.cc"

#pragma comment (lib, "WS2_32.lib")
#pragma comment (lib, "Mswsock.lib")
#pragma comment (lib, "AdvApi32.lib")

using namespace std;
using namespace pack::my;

void savePerson(const char* fname, const Person& person) {
	fstream out(fname, ios::out | ios::trunc | ios::binary);
	if (!person.SerializeToOstream(&out))
		throw runtime_error("savePerson() failed");
}

void loadPerson(const char* fname, Person& person) {
	fstream in(fname, ios::in | ios::binary);
	if (!person.ParseFromIstream(&in))
		throw runtime_error("loadPerson() failed");
}

int main(int argc, char* argv[]) {
	GOOGLE_PROTOBUF_VERIFY_VERSION;

	Person person;
	person.set_name("aaa");
	cout << "Saving Person..." << endl;
	savePerson("12345678.dat", person);

	cout << "Loading Person..." << endl;
	Person person2;
	loadPerson("12345678.dat", person2);
	cout << "----> PRINT Person class: " << person2.name() << endl;
	cout << endl;
	// Optional:  Delete all global objects allocated by libprotobuf.
	google::protobuf::ShutdownProtobufLibrary();

	return 0;
}
22 май 20, 23:20    [22137998]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
PetroNotC Sharp,

Если по некоему каналу данных будут в произвольном порядке передаваться структуры Person, Cat, Dog. Эта проблема решена в protobuf?
22 май 20, 23:30    [22138003]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
petrav,
Мне стыдно за либу но там нифига нет кроме сериализации.
То есть как из строки сделать классы там живые ...в оперативке.
ParseFromIstream(...
Всё
То есть ваш вопрос решается не в либе а в любом коде сервера.
Если передача асинхронно, то будет беспорядочно.
Если синхронна, то будем ждать ответа или освобождения канала.
Имхо

Сообщение было отредактировано: 22 май 20, 23:50
22 май 20, 23:46    [22138009]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
petrav,
ну вот, я собираюсь qRPC либу посмотреть.
Говорят она в яндекс маркете)
Дак вот там генерируетя как синхронный так и асинхронный сервер-клиент.
Как раз ваш вопрос.
https://habr.com/ru/company/yandex/blog/484068/
автор
Еще одна фича gRPC — клиент и сервер генерируются при помощи proto-компилятора и gRPC-плагина на основе proto-описания. Есть возможность в моменте, когда пишется код, выбрать какой клиент будет использоваться. То есть выбрать асинхронный или синхронный клиент, в зависимости от того, какого рода код вы пишите.
23 май 20, 00:08    [22138014]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
PetroNotC Sharp
petrav,
Мне стыдно за либу но там нифига нет кроме сериализации.
То есть как из строки сделать классы там живые ...в оперативке.

(Развёл руками)

Protobuf — это гугловская разработка? Через год они похоронят этот проект. У Гугла традиция убивать проекты. Что-то новое изобретут. У них есть деньги на переписывание своих проектов на другие либы. Есть ли эти деньги у тебя? Поэтому я и предлагаю что-то более стабильное: D-Bus + Qt. Но это, я опасаюсь, под Win будет сложно запустить. Но под Linux работать будет, слоты-сигналы.
23 май 20, 00:14    [22138017]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
petrav,
Дык у тебя исходники. Хоть вечно работай.
Таки же как и DBus.
Только боюсь там транспорт писать надо. Опять просто расшаривает данные на 2 процесса. Я посмотрю позже.
Ну а бросает разработчиков не гугл а MS.
Вспомни COM, Сильверлайт, веб сервер единственный.
23 май 20, 09:02    [22138066]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
PetroNotC Sharp
petrav,
Дык у тебя исходники. Хоть вечно работай.

Ты считаешь, что сможешь саппортить разработку Гугла? Это хорошо, что ты так считаешь, смелость и безбашенность города берёт.

PetroNotC Sharp
Таки же как и DBus.
Только боюсь там транспорт писать надо. Опять просто расшаривает данные на 2 процесса. Я посмотрю позже.

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

PetroNotC Sharp
Ну а бросает разработчиков не гугл а MS.
Вспомни COM, Сильверлайт, веб сервер единственный.

Ещё OLE и DDE. А они что IIS убили? Что-то сомневаюсь.
23 май 20, 10:01    [22138070]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
Алексей Роза
Member

Откуда: РФ
Сообщений: 196
petrav
А они что IIS убили? Что-то сомневаюсь.

Nginx всех убил.
Apache по инерции плывёт, но тонет каждый год.
а IIS даже не пытается всплывать.
2017

Сообщение было отредактировано: 23 май 20, 10:05
23 май 20, 10:04    [22138071]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
Алексей Роза
petrav
А они что IIS убили? Что-то сомневаюсь.

Nginx всех убил.
Apache по инерции плывёт, но тонет каждый год.
а IIS даже не пытается всплывать.
2017
нет
ASP Net core полностью без обратной совместимости.
Все проекты надо переписать с нуля.
Ну а там первый кроссплатформенный веб сервер kestrel.
MS поняло что упустило линукс
23 май 20, 10:09    [22138073]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
petrav,
Что значит саппортить?
По русски это сопровождать?
Откройте выше ссылку. Там 3 файла cpp.
Любой заказчик лучше это возьмет чем наколенное поделие.
А либа 1 и либа 2 чем не равны?
23 май 20, 10:12    [22138074]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
Алексей Роза
Member

Откуда: РФ
Сообщений: 196
PetroNotC Sharp
Алексей Роза
пропущено...

Nginx всех убил.
Apache по инерции плывёт, но тонет каждый год.
а IIS даже не пытается всплывать.
2017
нет
ASP Net core полностью без обратной совместимости.
Все проекты надо переписать с нуля.
Ну а там первый кроссплатформенный веб сервер kestrel.
MS поняло что упустило линукс



зы: на ютубе, кстати, про protobuf много
слишком много для такой простой технологии, где "только сериализация"...
23 май 20, 12:01    [22138090]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
Алексей Роза,
"слишком много" это не инженерный термин. Перефразируйте свою мысль.
23 май 20, 12:50    [22138106]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 50033

Алексей Роза
на ютубе, кстати, про protobuf много
слишком много для такой простой технологии, где "только сериализация"...

Ты ещё с порно сравни...

Posted via ActualForum NNTP Server 1.5

23 май 20, 13:33    [22138123]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
PetroNotC Sharp

А либа 1 и либа 2 чем не равны?

Тем что Qt у тебя уже есть, а добавляя ещё одну библиотеку — ты добавляешь новую зависимость.
23 май 20, 13:45    [22138130]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
petrav,
Согласен. Если функционал требуемый одинаков в обоих, то D-Bus выигрывает.
Но решают что брать как и у тебя наверху.
Я готовлю аналитическую записку по вариантам А, Б, С.
Эта тема обзорная. По всему что есть межпроцессного.
Дойду и до D-Bus.
23 май 20, 14:22    [22138144]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
ъъъъъ
Member

Откуда:
Сообщений: 685
petrav
Ты считаешь, что сможешь саппортить разработку Гугла? Это хорошо, что ты так считаешь, смелость и безбашенность города берёт.

Там нечего саппортить, протобуф - это идея. Масса самопальных реализаций для языков, не поддерживаемых гуглом.
23 май 20, 18:22    [22138251]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
petrav
PetroNotC Sharp

А либа 1 и либа 2 чем не равны?

Тем что Qt у тебя уже есть, а добавляя ещё одну библиотеку — ты добавляешь новую зависимость.

Ну и что?
23 май 20, 18:25    [22138255]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
mayton
petrav
пропущено...

Тем что Qt у тебя уже есть, а добавляя ещё одну библиотеку — ты добавляешь новую зависимость.

Ну и что?

Да ничего, нормально всё. Добавляйте. Только не понятно зачем задавать бессмысленные вопросы? Или вам снова процитировать разработчика PVS Studio?
23 май 20, 18:32    [22138258]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
petrav
mayton
пропущено...

Ну и что?

Да ничего, нормально всё. Добавляйте. Только не понятно зачем задавать бессмысленные вопросы? Или вам снова процитировать разработчика PVS Studio?

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

Если из принципа не подключать зависимости к коду (дескыть я и сам напишу) - то такой путь
предполагает что ты напишешь сам вообще все. И драйвер к БД. И рендерер 3Д графики.
Можно и Буст написать.

Вобщем граница здесь - зыбкая. Я не осуждаю. Не хотите - не используйте. Но эволюционный
процесс - предполагает предпочтение повторного использования изобретению.
23 май 20, 18:40    [22138261]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 50033

mayton
Если ты нашел что-то и оно решает твою задачу в разумные сроки - это успех.

А если нашёл что-то, что решает не совсем твою задачу или не совсем её решает? Вот как у
топикстартера, например.

Posted via ActualForum NNTP Server 1.5

23 май 20, 18:43    [22138263]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
Protobuf - все решит.
23 май 20, 18:48    [22138265]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 50033

А если решит не всё, надо найти ещё одну библиотеку, которая в сочетании с ним решит
недостающее. Это Ява-ой-вэй.

Posted via ActualForum NNTP Server 1.5

23 май 20, 18:50    [22138266]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
mayton
petrav
пропущено...

Да ничего, нормально всё. Добавляйте. Только не понятно зачем задавать бессмысленные вопросы? Или вам снова процитировать разработчика PVS Studio?

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

Если из принципа не подключать зависимости к коду (дескыть я и сам напишу) - то такой путь
предполагает что ты напишешь сам вообще все. И драйвер к БД. И рендерер 3Д графики.
Можно и Буст написать.

Я где-то призывал не использовать сторонние библиотеки? Да ерунда, не было такого. Вы манипулируете.

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

Нет, эволюция как раз и есть квинтэссенция изобретения.
23 май 20, 18:50    [22138267]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
Dimitry Sibiryakov

А если решит не всё, надо найти ещё одну библиотеку, которая в сочетании с ним решит
недостающее. Это Ява-ой-вэй.

На этом форуме явно не хватает функции лайков. :) Лайк!
23 май 20, 18:53    [22138269]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
petrav
Нет, эволюция как раз и есть квинтэссенция изобретения.

Давай отвлечемся. Как ты думаешь? Зачем было созданое "наследование" как один из пунктов идеологии ООП?
23 май 20, 18:53    [22138270]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
petrav

Я где-то призывал не использовать сторонние библиотеки? Да ерунда, не было такого. Вы манипулируете.

Тогда прошу прощения. Это направление дискуссии закрыто.
23 май 20, 18:54    [22138271]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
ъъъъъ
Member

Откуда:
Сообщений: 685
petrav
Я где-то призывал не использовать сторонние библиотеки?

Только те, которые Гугл "тянет"?
23 май 20, 18:58    [22138273]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
mayton
petrav
Нет, эволюция как раз и есть квинтэссенция изобретения.

Давай отвлечемся. Как ты думаешь? Зачем было созданое "наследование" как один из пунктов идеологии ООП?

Я, конечно, готов обсуждать банальные вещи, потому что часто нам вещь кажется банальной. Но на практике она оказывается очень сложной, хотя и выгладят простой с первого взгляда. Но в таком случае и вопрос должен намекать на какие-то неординарные моменты. А ваш вопрос банален. Не вижу смысла на него отвечать по сути.
23 май 20, 19:04    [22138279]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
"стакан полу налитый или полупустой"? )))
Я выше про функционал говорил к такому примеру.
Если потребуется отправить команду - метод по IP на другую машину то qRPC решит задачу.
А DBus не решит.
Это как пример функционала.
Надо это или нет решает руководство.
23 май 20, 19:04    [22138281]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
PetroNotC Sharp
"стакан полу налитый или полупустой"? )))
Я выше про функционал говорил к такому примеру.
Если потребуется отправить команду - метод по IP на другую машину то qRPC решит задачу.
А DBus не решит.
Это как пример функционала.
Надо это или нет решает руководство.


Тут еще тонкий момент. Есть взаимодействие типа посылка месседжей (MQ). И есть - вызов методов (RPC).
Они похожи но первый асинхронный и практически без обратной связи. Тоесть контролируется просто
факт доставки хотя-бы одному потребителю. Работает очень быстро. А что дальше с сообщением
случилось на прикладном уровне? Обработано оно или у тебя был division by zero... ХЗ. Это уже
не задачи MQ. Это уже прикладной слой.

И второе взаимодействие - дёрнул метод (RPC) и получил код ошибки. Работает
медленно. Но надежно. Каждая интеракция между процессами имеет фиксацию.
Ты точно знаешь что получил ответ.

ZeroMQ, DBus - это про первое. Это стрим месседжей.

Любая библиотечка Rest/SOAP/Http - это второе.

И protoBuf - это ни первое и не второе а просто протокол сериализации-десериализации объекта в БЛОБ.
Причем такой блоб которому пофиг на разрядность int, и пофиг на порядок байтов в слове (BigEndian).
И более того. ProtoBuf может подружить между собой например C++/JavaScript и все остальное.

Мы используем протобуф не напрямую а косвенно как Apache-ORC - формат документа для биг-дата
где десятки терабайт таблиц упаковываются в такие-себе Vertical Arrays. И со сжатием ZLib/Snappy
уже поверх данных и завернутых в proto.

А какие усилия сишник потратит для поддержки вот такой кросс-платформенности на основе структур
struct? Я не знаю. Опять-же чтоб прочувствовать преимущества прото-буф - надо чтобы оба процесса
были на разных архитектурах.

А если у тебя процессы - гомогенные (оба под Win32 и одной разрядности) то наверное протобуф
тебе и не нужен.
23 май 20, 19:54    [22138298]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
petrav
mayton
пропущено...

Давай отвлечемся. Как ты думаешь? Зачем было созданое "наследование" как один из пунктов идеологии ООП?

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


С тобой иногда бывает так сложно говорить. Вот ты сказал первый свою банальность дескыть:

>> Тем что Qt у тебя уже есть, а добавляя ещё одну библиотеку — ты добавляешь новую зависимость.

Это - банальность. Знаешь я не помню в каком бизнес-сегменте ты работешь. Кажется что-то с авиацией
или АСУТП. Но мне кажется что у тебя есть определённая проф-деформация.

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

У тебя есть элемент предвзятости. Ты сослался на PVS-Studio? Ты что? Cотрудник этой организации?
Зачем вообще нам в дискуссию затаскивать это? Неужели у нас нет аргументов кроме какого-то кастомного
приложения которое создавалось чтоб стыдливо закрыть дефекты 40 летней эволюции кодирования на С++?

Сообщение было отредактировано: 23 май 20, 20:27
23 май 20, 20:00    [22138301]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
mayton
Есть взаимодействие типа посылка месседжей (MQ).

конечно, в данном топике message-oriented middleware мы не рассматриваем.
Все просто - getName() из другого процесса\демона
23 май 20, 20:09    [22138310]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
mayton

А какие усилия сишник потратит для поддержки вот такой кросс-платформенности на основе структур
struct? Я не знаю. Опять-же чтоб прочувствовать преимущества прото-буф - надо чтобы оба процесса
были на разных архитектурах.

На самом деле обмен структурами Human, Car, Dog... причём в произвольном порядке в канале данных. Это весит, ну максимум 500 строчек кода. С проверкой контрольной суммы, с анализом возможных шумов в канале данных. Причём взаимодействие на разных архитектурах.
23 май 20, 20:33    [22138315]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
petrav
Это весит, ну максимум 500 строчек кода.

какого уровня программиста и сколько будет в баксах потеря компании если там баги?
Вот пример на java простейшего сервера для школы.
Они есть готовые
---------
import java.io.DataInputStream;
import java.io.DataOutputStream;
import java.io.IOException;
import java.net.ServerSocket;
import java.net.Socket;

public class TestAsServer {

/**
 * 
 * @param args
 * @throws InterruptedException
 */
    public static void main(String[] args) throws InterruptedException {
//  стартуем сервер на порту 3345

        try (ServerSocket server= new ServerSocket(3345)){
// становимся в ожидание подключения к сокету под именем - "client" на серверной стороне                                
                Socket client = server.accept();

// после хэндшейкинга сервер ассоциирует подключающегося клиента с этим сокетом-соединением             
                System.out.print("Connection accepted.");

// инициируем каналы для  общения в сокете, для сервера     

// канал записи в сокет
                DataOutputStream out = new DataOutputStream(client.getOutputStream());
                System.out.println("DataOutputStream  created");

                // канал чтения из сокета
                DataInputStream in = new DataInputStream(client.getInputStream());
                System.out.println("DataInputStream created");

// начинаем диалог с подключенным клиентом в цикле, пока сокет не закрыт                
                while(!client.isClosed()){

                System.out.println("Server reading from channel");

// сервер ждёт в канале чтения (inputstream) получения данных клиента               
                String entry = in.readUTF();

// после получения данных считывает их              
                System.out.println("READ from client message - "+entry);

// и выводит в консоль              
                System.out.println("Server try writing to channel");

// инициализация проверки условия продолжения работы с клиентом по этому сокету по кодовому слову       - quit  
                if(entry.equalsIgnoreCase("quit")){
                    System.out.println("Client initialize connections suicide ...");
                    out.writeUTF("Server reply - "+entry + " - OK");    
                            out.flush();
                    Thread.sleep(3000);
                    break;
                }

// если условие окончания работы не верно - продолжаем работу - отправляем эхо-ответ  обратно клиенту               
                out.writeUTF("Server reply - "+entry + " - OK");                
                System.out.println("Server Wrote message to client.");

// освобождаем буфер сетевых сообщений (по умолчанию сообщение не сразу отправляется в сеть, а сначала накапливается в специальном буфере сообщений, размер которого определяется конкретными настройками в системе, а метод  - flush() отправляет сообщение не дожидаясь наполнения буфера согласно настройкам системы             
                out.flush();    

                }

// если условие выхода - верно выключаем соединения             
                System.out.println("Client disconnected");
                System.out.println("Closing connections & channels.");

                // закрываем сначала каналы сокета !
                in.close();
                out.close();

                // потом закрываем сам сокет общения на стороне сервера!
                client.close();

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

                System.out.println("Closing connections & channels - DONE.");
            } catch (IOException e) {
                e.printStackTrace();
        }
    }
}
23 май 20, 20:41    [22138319]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
petrav,
а шумы в канале откуда?
23 май 20, 20:43    [22138321]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
mayton
petrav
пропущено...

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

С тобой иногда бывает так сложно говорить.

У всех свои недостатки, я прошу прощения.

mayton
Вот ты сказал первый свою банальность дескыть:

>> Тем что Qt у тебя уже есть, а добавляя ещё одну библиотеку — ты добавляешь новую зависимость.

Это - банальность.

Конечно, это банальность. Но я не задавал банальных вопросов. А вы, mayton, задали именно что банальные вопросы. При этом вы высококвалифицированный программмист.

mayton
Знаешь я не помню в каком бизнес-сегменте ты работешь. Кажется что-то с авиацией
или АСУТП.

Нет.

mayton
Но мне кажется что у тебя есть определённая проф-деформация.

Конечно, как и у вас.

mayton
Я всегда старался из себя эту деформацию изгонять. Смотреть на мир широко отрытыми глазами
и не позволять предвзятости брать верх.

Это пример для подражания.

mayton
У тебя есть элемент предвзятости. Ты сослался на PVS-Studio? Ты что? Cотрудник этой организации?

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

mayton
Зачем вообще нам в дискуссию затаскивать это? Неужели у нас нет аргументов кроме какого-то кастомного
приложения которое создавалось чтоб стыдливо закрыть дефекты 40 летней эволюции кодирования на С++?

?! Хватит говорить ерунду.
23 май 20, 21:00    [22138322]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
Нет. Сокет-сервер - это слишком примитивно. Автору нужен API для
синхронных интеракций. Например на базе Http.

Давайте на верхнем архитектурном уровне
нарисуем этот API как абстракции. А потом имплементируем.

interface IPetroServer {
        
}

Почему я хочу именно в таком виде. Чтобы отвязаться от всяких Human, Car, Doc
и от разговоров ниочем.
23 май 20, 21:04    [22138324]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
petrav, давай возьмем паузу на недельку. Просто мы напрягаем
общество банальностями и перебранкой.
23 май 20, 21:07    [22138327]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
ъъъъъ
Member

Откуда:
Сообщений: 685
mayton
Автору нужен API для
синхронных интеракций. Например на базе Http.

Например, ZeroMQ с парой штатный zmq сокетов req-rep.
23 май 20, 21:09    [22138328]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
ъъъъъ
Member

Откуда:
Сообщений: 685
ъъъъъ
mayton
Автору нужен API для
синхронных интеракций. Например на базе Http.

Например, ZeroMQ с парой штатных zmq сокетов req-rep.
23 май 20, 21:09    [22138329]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
ъъъъъ,
ну дак, для кругозора и альтернативы надо ещё знать одну - две либы.
Чтобы выбирать то было из чего.
23 май 20, 21:23    [22138334]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
ъъъъъ
Member

Откуда:
Сообщений: 685
PetroNotC Sharp,

это же прикольно.
23 май 20, 21:42    [22138341]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
ъъъъъ,
прикольно в ПТ
23 май 20, 21:47    [22138348]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
PetroNotC Sharp
petrav
Это весит, ну максимум 500 строчек кода.

какого уровня программиста и сколько будет в баксах потеря компании если там баги?

Обмен через сокеты (или любой другой канал данных) любыми структурами в любой последовательности реализуется средним программистом за пару недель. 1-3-ри дня на разработку. И две недели на тестирование на фоне другой работы. Там просто... очень просто. Без багов.
23 май 20, 22:03    [22138351]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
petrav,
угу.
И в каждой фирме сидит прогер и пилит через сокеты)))
Неужели сериализацию тоже? )))
А асинхронность могём?
Этот прогер только потоки неделю отлаживать будет.
23 май 20, 22:11    [22138354]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
petrav,
в принципе, одному прогеру дали интерфейс и он пошёл писать БЛ (бизнес-логику).
mayton
interface IPetroServer {
        
}

ну а ваш прогер пусть пилит транспорт. Будет два прогера. Системщик и Разработчик ИС.
23 май 20, 22:14    [22138356]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
Да. Это разумное разделение архитектуры на слои. Но мой поинт
был в том чтобы создать УСЛОВИЯ сравнения между собой
zmq req-rep, HTTP(Rest/GraphQL), SOAP, gRPC.

Единый интерфейс - это что-то вроде общего знаменателя. Или правил судейства.
Сами посудите если я нарисую интерфейс
interface IPetroServer {
   void method1(string arg1);      
}


то мы мысленно упрощаем себе постановку. И нам уже не нужны сложные
протоколы сериализации объектов. А если так

interface IPetroServer {
   CarResult method1(const Car &car);      
}


То это кардинально переворачивает постановку. Нам уже нужны способы
как сериализовать сложный объект Car и уже здесь как раз выходит на сцену
XML, JSON, eBML, ProtoBuf, Apache Avro, Thrift. (из этого списка я юзал все
пожалуй кроме последнего).

А если нужна сложная модель данных - или само-документрированность
то лучше SOAP или GraphQL.
23 май 20, 22:38    [22138365]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
Алексей Роза
Member

Откуда: РФ
Сообщений: 196
PetroNotC Sharp
Вот пример на java простейшего сервера для школы.

голосую за вылизанную либу протобафов.
23 май 20, 22:40    [22138366]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
mayton
То это кардинально переворачивает постановку.
где?
Я выше писал что нужно getName()
23 май 20, 22:57    [22138373]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
Как-то настолько у тебя всё легко что я ищу подвох.
Получается что ты так долго сетапишь удалённое взаимодействие
только для того чтобы ... взять name() ?

Оно-же string возвращает?

А другие методы у тебя будут?
23 май 20, 23:06    [22138376]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
PetroNotC Sharp
Error	LNK2038	mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in project-name.obj	project-name	D:\project-name\libprotobuf.lib(common.cc.obj)	1

так что делать с этой ошибкой?
Вставил отладочную lib в проект release.
При компиляции эта ошибка.
Релизной либы нету.
23 май 20, 23:13    [22138380]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
mayton
Как-то настолько у тебя всё легко что я ищу подвох.
я люблю простоту

mayton
Получается что ты так долго сетапишь удалённое взаимодействие
только для того чтобы ... взять name() ?

не было удаленного особо

mayton
Оно-же string возвращает?

и что?
Надо std:string\QString?

mayton
А другие методы у тебя будут?

Выше писал 100 - 200 методов
23 май 20, 23:15    [22138381]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
PetroNotC Sharp

Выше писал 100 - 200 методов

Опиши что будет у тебя в этих методах. Только строки или будешь
гонять сложные объекты.

Без бизнесовых имен разумеется.
23 май 20, 23:17    [22138382]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
mayton
PetroNotC Sharp

Выше писал 100 - 200 методов

Опиши что будет у тебя в этих методах. Только строки или будешь
гонять сложные объекты.

Без бизнесовых имен разумеется.

Меня другое интересует. 200 методов — это нормально?
23 май 20, 23:52    [22138386]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
Ну... чисто с человеческой точки зрения наверное тяжело
разбирать такой API. Если побить его на 7 пакетов (по 30 методов)
в каждом то уже как-то легче.

Я думаю что есть какой-то признак как можно побить.
24 май 20, 00:07    [22138389]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
mayton
Ну... чисто с человеческой точки зрения наверное тяжело
разбирать такой API. Если побить его на 7 пакетов (по 30 методов)
в каждом то уже как-то легче.

Может и не то что бы тяжело, а просто гавнокодинг? 200 методов...

А вы, давеча, рассказывали про бизнесовый объект с 1000-й полей данных.
24 май 20, 00:15    [22138391]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
Так то - другое. Никто конечно Java-класс с 1000 полями не создает.
Но таблица в бигдате реально существует. И есть отдельно спека
которая такой описывает.

А если надо с энтитей поработать то на нее смотрят сквозь призму
какого-то интерфеса. Например если это Organization то у нее есть
к примеру штук 20 базовых свойств. Вот с ними и работают.
Если нужны там квартальные отчоты по организации то можно
посмотреть через другой.
24 май 20, 00:27    [22138395]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
Алексей Роза
Member

Откуда: РФ
Сообщений: 196
Core Guidelines настаивает, что в классе должен быть минимум методов...
автор
# C.4: Make a function a member ONLY if it needs direct access to the representation of a class.
Меньшее связывание, чем с функциями-членами, меньшее количество функций, которые могут вызвать проблемы при изменении состояния объекта, уменьшает количество функций, которые необходимо изменить после изменения представления.


Сообщение было отредактировано: 24 май 20, 07:35
24 май 20, 07:35    [22138417]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
mayton,
200 методов? Ну наверно преувеличил.
Это как бд выбирают.
Нужно 500 мегов, а ТЗ пишут на 5 гигов)))
Что в методах?
Простые типы или классы?
Постараемся простые.
Классы сложнее версионность поддерживать.
Да и основа REST.
24 май 20, 09:51    [22138432]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
Алексей Роза,
Не в классе 200 методов, а на ИС 200 методов.
А в ИС может быть 200 классов.
Вот и выходит по одному на класс.
Class ракета.run
Class пиво.run
Class юзверь.run
24 май 20, 09:55    [22138433]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
Ты же не сразу сделаешь 200 методов.

Будет какой-то итеративный процесс.

Побьешь на несколько ендпоинтов. В процессе.
24 май 20, 09:56    [22138434]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
PetroNotC Sharp
PetroNotC Sharp
Error	LNK2038	mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in project-name.obj	project-name	D:\project-name\libprotobuf.lib(common.cc.obj)	1

так что делать с этой ошибкой?
Вставил отладочную lib в проект release.
При компиляции эта ошибка.
Релизной либы нету.

Щаз тупо дам поиск по строке во всех иходниках в тотал коммандере.
Буду искать макрос.

Сообщение было отредактировано: 24 май 20, 09:59
24 май 20, 09:58    [22138435]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
mayton,
Конечно.
Счас вообще один метод тестирую.
С одним protobuf неудобно.
Нужно придумать структуру и там поля
Имя метода
Возврат
Тип возврата
Параметер1, парам2,
Тип парам1, тип парам2,
....
24 май 20, 10:00    [22138437]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
PetroNotC Sharp
Щаз тупо дам поиск по строке во всех иходниках в тотал коммандере.

поиск дал строку только в *.obj и двоичных файлах(
24 май 20, 10:51    [22138444]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
PetroNotC Sharp
PetroNotC Sharp
Щаз тупо дам поиск по строке во всех иходниках в тотал коммандере.

поиск дал строку только в *.obj и двоичных файлах(

В исходниках библиотеки искал? Что в аля Microsoft.Cpp.Win32.user?
24 май 20, 11:00    [22138445]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
PetroNotC Sharp
mayton,
Конечно.
Счас вообще один метод тестирую.
С одним protobuf неудобно.
Нужно придумать структуру и там поля
Имя метода
Возврат
Тип возврата
Параметер1, парам2,
Тип парам1, тип парам2,
....

Посмотри еще для комплекта Apache Thrift https://thrift.apache.org/

Как альтернатива protobuf. И я тоже для себя посмотрю.
24 май 20, 11:07    [22138448]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
petrav
В исходниках библиотеки искал?
проекта.
Уже нашел что в студии можно поставить
_HAS_ITERATOR_DEBUGGING = 0; _ITERATOR_DEBUG_LEVEL = 0;
но не работает
petrav
Что в аля Microsoft.Cpp.Win32.user?

где смотреть?
24 май 20, 11:07    [22138449]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
mayton
Thrift
он на очереди после того что смотрю.
Как то староват показался.
24 май 20, 11:08    [22138450]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
PetroNotC Sharp,

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

В свойствах "Отладка" проекта "В", "Свойства конфигурации" → "C/С++ → ", "Предпроцессор", добавьте следующее в определения препроцессора:

_HAS_ITERATOR_DEBUGGING = 0; _ITERATOR_DEBUG_LEVEL = 0;

Восстановите проект B в Debug, затем создайте проект A в Release и он должен правильно установить ссылку.

не понял выделенное.
24 май 20, 11:10    [22138452]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
PetroNotC Sharp
mayton
Thrift
он на очереди после того что смотрю.
Как то староват показался.

А в чем старость?
24 май 20, 11:13    [22138453]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
mayton
А в чем старость?
цитируемость в интернете
24 май 20, 11:20    [22138454]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
PetroNotC Sharp
mayton
А в чем старость?
цитируемость в интернете

Ну ассемблер тоже слабо цитируют. Хотя мы часто тут его косвенно обсуждаем.
24 май 20, 11:22    [22138455]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
mayton,
"обсуждаем но не применяем". Обсуждайте.
24 май 20, 11:25    [22138458]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
PetroNotC Sharp
petrav
В исходниках библиотеки искал?
проекта.
Уже нашел что в студии можно поставить
_HAS_ITERATOR_DEBUGGING = 0; _ITERATOR_DEBUG_LEVEL = 0;
но не работает
petrav
Что в аля Microsoft.Cpp.Win32.user?

где смотреть?

В Студии меню View -> Property Manager.

_ITERATOR_DEBUG_LEVEL для Дебаг == 2. Для Релиз == 0. По умолчанию. Не очень понятно, что у тебя происходит. Такое впечатление, что ты пытаешься собрать Дебаг, но собираешь Релиз.
24 май 20, 11:37    [22138460]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
Почему-же? Ассемблер - это вообще главный ударный аргумент в вопросах перформанса
компилляторов старого типа C/C++. Тех которые сразу на выходе выдают x86/x86_64.

Про Java - тоже самое. И Елизаров и Шипилев приводят фрагменты ассемблера чтоб
показать что где и как мы схитрили и сделали какой финт ушами.

Сообщение было отредактировано: 24 май 20, 11:37
24 май 20, 11:39    [22138463]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
petrav,
типа
+
Картинка с другого сайта.
24 май 20, 11:39    [22138464]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
mayton,
Я люблю мейнстрим в IT.
Этим всё сказано.
24 май 20, 11:40    [22138465]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
petrav
В Студии меню View -> Property Manager.

Там нужно выбрать текущий режим запуска и в результате выходим на
Проект - ПКМ (правая кнопа мыши) - Properties - C++ - Preprocessor - Definition
Далее?
24 май 20, 11:44    [22138466]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
PetroNotC Sharp
petrav,
типа
<Скриншот>

У тебя itkvnl-<бла-бла-бла>.obj собран в Дебаг, а Source.obj собран в Релиз. И ты их пытаешься слинковать. Что-то накосячено в проекте.
24 май 20, 11:53    [22138469]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
petrav,
далее там. Второй день ошибка.
22138471
24 май 20, 11:56    [22138472]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
PetroNotC Sharp, ты закинь этот макет в github и мы быстрее пофиксим.
24 май 20, 12:01    [22138476]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
mayton
PetroNotC Sharp, ты закинь этот макет в github и мы быстрее пофиксим.

это на второй день без решения)). Всё по плану.
24 май 20, 12:04    [22138480]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
хммм....
Интересная либа есть в qRPC
+
/*	$NetBSD: getaddrinfo.c,v 1.82 2006/03/25 12:09:40 rpaulo Exp $	*/
/*	$KAME: getaddrinfo.c,v 1.29 2000/08/31 17:26:57 itojun Exp $	*/
/*
 * Copyright (C) 1995, 1996, 1997, and 1998 WIDE Project.
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 * 3. Neither the name of the project nor the names of its contributors
 *    may be used to endorse or promote products derived from this software
 *    without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 *
 */

/*
 * This is an adaptation of Android's implementation of RFC 6724
 * (in Android's getaddrinfo.c). It has some cosmetic differences
 * from Android's getaddrinfo.c, but Android's getaddrinfo.c was
 * used as a guide or example of a way to implement the RFC 6724 spec when
 * this was written.
 */

#include "address_sorting_internal.h"

#include <errno.h>
#include <inttypes.h>
#include <limits.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>

// Scope values increase with increase in scope.
static const int kIPv6AddrScopeLinkLocal = 1;
static const int kIPv6AddrScopeSiteLocal = 2;
static const int kIPv6AddrScopeGlobal = 3;

static address_sorting_source_addr_factory* g_current_source_addr_factory =
    NULL;

static bool address_sorting_get_source_addr(const address_sorting_address* dest,
                                            address_sorting_address* source) {
  return g_current_source_addr_factory->vtable->get_source_addr(
      g_current_source_addr_factory, dest, source);
}
 

для того чтобы отправлять сообщения не по IP а по именам компа в сети:
address_sorting
Android's implementation of RFC 6724
24 май 20, 13:43    [22138513]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
И что здесь интересного?
24 май 20, 14:05    [22138528]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
mayton,
методы вызывать можно не по IP. Доп функционал.
24 май 20, 14:14    [22138534]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
PetroNotC Sharp
mayton,
методы вызывать можно не по IP. Доп функционал.

А что ты такого пишешь что тебе нужна библиотека ITK ? Просто интересно.
24 май 20, 14:16    [22138535]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
Да так себе. Если это - коробочный DNS - так это должно работать всегда
в любой нормальной сети. У меня вот в домашней я только осилил
поддерживать /etc/hosts.
24 май 20, 14:18    [22138536]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3 4 5 6      [все]
Все форумы / C++ Ответить