2012-11-05 10 views
8

Uczę się teraz w C++ i słyszałem dużo o językach osadzonych skryptów. Wyobraziłem to sobie zupełnie inaczej.Dlaczego powinienem osadzić język skryptowy?

Myślałem, że napiszę wszystkie moje ciężkie funkcje wydajności w C++ i wywołać je z języka skryptowego, takich jak Lua lub Python.

Ale wygląda na to, że jest odwrotnie. -> Napisz funkcje w Lua/Pythonie i wywołaj je w kodzie C.

Jaka jest zaleta osadzania języka w C++ zamiast pisania API w C++ i wywoływania tych funkcji w innym języku?

Przykład:

// function in c++ 
int expensiveFunction(){ 
    return 1; 
} 

Następnie w Pythonie Nazwałbym tę funkcję i chciałbym mieć wydajność od C++, ale mogą dokonywać zmian w czasie wykonywania Dzięki wykonawczego interpretera Pythona.

+0

Innym powodem jest to, że możesz pozwolić użytkownikom pisać własne skrypty, aby rozszerzyć program. Tak właśnie działa Unix. –

+2

W jakim kontekście mówisz? W grach wideo silnik jest "zamknięty" w C++, ale często rzeczy kontrolowane są za pomocą języków skryptowych w celu umożliwienia modyfikacji. To samo dotyczy czegoś takiego jak serwer lub jakiekolwiek oprogramowanie, w którym chciałbyś zamknąć rdzeń, ale pozwolić na tworzenie rozszerzeń stworzonych przez użytkownika. Ale odwrotność byłaby prawdziwa w, powiedzmy, oprogramowaniu naukowym, gdzie coś takiego jak Python jest proste do napisania, ale wolne, więc podstawowe funkcje powinny być w C/Fortran. – tpg2114

+0

@ tpg2114: o to właśnie mówię. Kiedy powinienem rozważyć osadzenie języka w języku C++ zamiast pisać rdzeń w języku C++ i używać go w python/lua? Może możesz dać mi jakieś zalety/wady. –

Odpowiedz

4

W rzeczywistości wiele silników gier lubi budować interfejsy do silnika poprzez osadzanie Lua lub Pythona. Istnieją zalety:

  • Non-programmers mogą współpracować z silnikiem.
  • Nie trzeba przekompilowywać w przypadku drobnych zmian w skrypcie.
  • Błędy w skrypcie mogą nie spowodować awarii całego systemu.

C++ jest bardzo przydatny jako backend dla projektów, które wymagają elastyczności języków skryptowych, ale chcą wydajności C++. Nie słyszałem o projektach, które używają C++ jako interfejsu, z językiem skryptowym jako zapleczem.

API Style

Używamy tego stylu w oprogramowaniu mojej firmy. Udostępniamy interfejs API za pośrednictwem biblioteki DLL systemu Windows, która może być dość łatwo wywoływana przez większość języków. W szczególności obsługujemy VB i VBA. Jest to świetne, gdy backend jest spoza formantu skryptora. Trudno jednak debugować problemy wynikające z perspektywy twórcy skryptu.

Zalety

  • Strong segregowania
  • dostępne z różnych językach

Wady

  • trudne do debugowania 2 procesy

Osadzony styl

Oprogramowanie faktycznie osadza interpreter skryptów w oprogramowaniu.W ten sposób możesz udostępniać funkcje tak, jakby były funkcjami natywnymi. W tym stylu twórcy skryptów i programiści backendu są zazwyczaj w tej samej firmie. Może być również używany przez tradycyjne oprogramowanie, aby umożliwić innym rozszerzenie funkcjonalności aplikacji. Jeśli dzielą się kodem źródłowym, możesz łatwiej rozwiązywać problemy wynikające ze skryptów. Aplikacja dba również o to, kiedy i jak uruchomić swoje skrypty. Jednak, aby obsługiwać dodatkowe języki, twórca aplikacji musi osadzić innych tłumaczy.

Zalety

  • silniejsze sprzężenie
  • Łatwiejsze debugowanie jeden proces

Wady

  • Tylko dostępne za pośrednictwem zatwierdzonego języku
+1

Myślę, że większość bibliotek Pythona jest napisanych w języku C++. –

+1

To właśnie mówię. C++ świeci jako backend do innych języków. Brzmiało to jakby był ciekawy C++ używając skryptów jako zaplecza. –

+1

Przykro mi, że źle odczytałem twoją odpowiedź. Ponieważ chcę napisać prosty silnik graficzny w języku C++ i zbudować framework (w "języku skryptowym") na górze silnika. Tak więc inni mogą programować coś w python/lua, ale nadal osiągają wydajność C++. Byłem po prostu zdezorientowany, ponieważ widziałem kod, który był osadzony w C++. –

1

Skrypty są kompilowane w czasie wykonywania, podczas gdy główny język będzie kompilowany podczas kompilacji. To sprawi, że praca z dużą bazą kodu będzie stosunkowo łatwa, ponieważ nie trzeba będzie kompilować całego projektu, aby zaktualizować prosty skrypt.

+0

Dodałem przykład. Byłbym również w stanie dokonać zmian w czasie wykonywania, ale bez dodawania języka do C++. –

+0

@MaikKlein Nigdy nie widziałem, żeby ktoś dzwonił do kodu C++ z Pythona, zazwyczaj jest odwrotnie, na przykład wywołuje skrypt Lua z C++. – Rapptz

+0

Tak, chciałbym tylko wiedzieć, dlaczego? Bardziej rozsądne wydaje mi się napisanie interfejsu API w języku C++. –

1

Jednym z powodów może być użycie szkieletu C++, który przynosi swoją główną funkcję (i zmusza do użycia go jako głównej funkcji programu).

Moim zdaniem, to często zły konstrukcja ramy - nie jest to łatwe w użyciu więcej niż jednej takiej ramy w programie ...

To samo dotyczy wielu języków skryptowych w jednym programie: Tylko jeden język może zapewnić główną funkcję. Wszystkie pozostałe języki muszą być osadzone.

Uwaga: W przypadku wątków można uzyskać "wiele głównych funkcji". Cóż, niezupełnie wiele głównych funkcji. Ale wiele pętli obsługi zdarzeń.

3

Naprawdę, każde podejście działa poprawnie. Pytanie brzmi, które podejście jest bardziej odpowiednie dla konkretnego zastosowania.

Na przykład pisanie ciężkiego kodu o dużej wydajności jako rozszerzenie języka działa dobrze w aplikacjach, w których ma się wrażenie, że ktoś używa mniejszej biblioteki w języku skryptowym. Jeśli chcesz dostarczyć wydajny interfejs API do renderowania grafiki, który jest zawarty w aplikacji Pythona, jest to właściwa droga.

Z drugiej strony, jeśli masz silnik, który jest prawie w całości napisany w C++ - jak silnik gry - i chcesz zapewnić prosty sposób podłączenia do silnika gry bez potrzeby ponownej kompilacji, możesz osadzić tłumacza. Właśnie dlatego silniki geme często piszą np. AI lub behawioralne haki w języku skryptowym: zmień na przykład "czas reakcji" bota i natychmiast zobaczysz różnicę , czasami nawet bez ponownego uruchamiania gry.

Wszystko zależy od tego, która strona jest "większa", ale w obu przypadkach można podejść zarówno do Lua, jak i Pythona.

1

Raz osadziłem Pythona w kontrolerze robota. Sterownik zarządzał robotem, który obsługiwał płytki z chipem komputerowym, a także kontrolował różne inne urządzenia. Klient mógł napisać program w języku Python, który robił rzeczy takie jak nadążanie za miejscem, w którym znajdowały się wafle, otwieranie drzwi, włączanie i wyłączanie świateł, odczytywanie przełączników itp. Może też czytać instrukcje z linii szeregowej lub sieci Ethernet i tłumaczyć je na działania . Oczywiście precyzyjna kontrola robota była obsługiwana na poziomie C++, działającym w najbardziej pilnym priorytecie w systemie czasu rzeczywistego.

1

Oprócz względów, takich jak wydajność, rekompilacja, możliwość konserwacji, innym powodem jest bezpieczeństwo kodu.

Zestawione język jak C/C++ jest trudniej (nie niemożliwe), aby inni mogli znać dokładny algorytm bez kodu źródłowego, a skrypty są (podobno) łatwiej znać jego logikę, ponieważ są tam, aby skompilować przy starcie .

Powiązane problemy