Byłem zakochany w programowaniu opartym na komponentach (czy to z COM, innym systemem, czy po prostu używając paradygmatu w prostym C++). To wymaga trochę przyzwyczajenia się, jeśli jest się zwykle przyzwyczajonym do "tradycyjnego" modelu OOP, ale zdecydowanie warto. Dzięki temu mój kod jest łatwiejszy w utrzymaniu i łatwiejszy w rozbudowie.Wieloplatformowa alternatywa dla COM
Projekt, nad którym obecnie pracuję, korzysta z paradygmatu, ale nie ma ustawionego systemu. Jednak naprawdę chciałbym znaleźć jakiś system, którego mógłbym użyć z następującymi wymaganiami. Przejście z tego, co mam teraz do nowego systemu, zajęłoby trochę czasu, ale później zaoszczędziłbym wielokrotność tego czasu.
Wymagania:
- Cross-platform
- Szybka
- dobrze współpracuje z C++
- Obsługuje Krzyż proces marshalling
Pozwól mi rozwinąć te wymogi:
Wieloplatformowe
Zasadniczo potrzebuję go do pracy na systemach Windows i Mac. Linux byłby miły, ale nie jest w żaden sposób niezbędny. Poza tym naprawdę musi spełniać inne wymagania dla wszystkich platform. Jest COM dla Maca, który byłby idealny, ale nie obsługuje wymagania 4. Dodatkowo musi obsługiwać zarówno GCC, jak i MSVC.
Szybka
To gdzie CORBA niestety traci, mimo że spełnia trzy inne wymagania. Wywołania metod w procesie muszą być tak szybkie, jak to możliwe (najlepiej, jak COM), ponieważ niektóre z procedur mogą być również wywoływane z przerwania audio.
Działa dobrze z C++
... Chyba ten jest w większości oczywiste. Nie mam nic przeciwko temu, aby nie używać klas C++ do implementowania komponentów, ale z pewnością byłaby pomocna, a alternatywa musi być nadal łatwa w użyciu, szczególnie, że ostatecznie zamierzam udostępnić interfejs API dla rozszerzeń zewnętrznych.
Obsługuje Krzyż proces rozrządowych
Mam tu na myśli przynajmniej mogąc szeregować połączenia. Jeśli odbywa się to za pomocą kodu wygenerowanego z IDL, to jest to dla mnie całkowicie w porządku, a także nie mam nic przeciwko implementacji komunikacji między procesami.
COM byłby świetny, ale nie spełnia wymagań 1 w pełni. CORBA również byłaby świetna, ale nie spełnia wymagań 2 (nawet przy najszybszym ORB). XPCOM może nie spełniać wymagań 2 i nie działa z MSVC, więc nie spełnia wymagań 1.
Wszelkie pomysły, co jeszcze tam jest? Moim następnym krokiem byłoby przetasowanie własnego przy pomocy protobufów lub czegoś podobnego, ale oczywiście chciałbym tego uniknąć.
Aktualizacja
Aby opracować - przerwanie dźwięku w tym kontekście może być tak niskie, jak 2-3ms. Ten czas nie jest nawet w pełni dostępny dla mnie, ponieważ inne komponenty muszą być przetwarzane w tym czasie, a moje oprogramowanie samo owija inny program, który musi zostać przetworzony w tym czasie. Dlatego zarówno procesowe, jak i międzysektorowe procesy muszą być niezwykle szybkie.
XPCOM powinien współpracować z MSVC, AFAIK. Ponadto, jeśli nie, nie możesz po prostu użyć MinGW? – Zifre
Mogę używać MinGW, ale dla jednego, mój cały toolchain jest zintegrowany z MSVC, a jednocześnie mogę zintegrować MinGW do tego również, nie mogę użyć wspaniałego debuggera w MSVC. – arke
Myślę, że jeśli to zbudujesz, zarobisz dużo pieniędzy. W procesie, poza procesem, PC, Mac, Linux, płonący szybko. Dużo pieniędzy. :) –