Che senso ha progettare le API Lua C?

Question

Che senso ha progettare le API Lua C?

#1 da (7 voti)
#2 da (5 voti)

3

Sono un novizio di Lua . Dopo aver studiato alcuni esempi di Lua C APIs , sono un po 'confuso.

Riesco a vedere che Lua C API viene utilizzato per l'elaborazione degli script Lua :

......
lua_State *L = luaL_newstate();
luaL_openlibs(L);
luaL_loadfile(L, argv[1]);
lua_call(L, 0, 0);
lua_close(L);
......

O chiamando una funzione Lua da C code:

/* calling f("hello", 4.5) */
lua_getglobal(L, "f");
lua_pushstring(L, "hello");
lua_pushnumber(L, 4.5);
lua_call(L, 2, 1);

Quindi qual è il punto di progettazione di Lua C APIs ? Se solo fai queste funzioni, penso che chiamare il programma lua sia sufficiente, non è necessario usare Lua C APIs .

c lua

posta Nan Xiao 15.06.2015 - 11:14

fonte

2 risposte

7

Lua non è solo - e non principalmente - un programma interprete standalone ( /usr/bin/lua sul mio desktop Linux / Debian) del linguaggio di scripting Lua, ma Lua è principalmente una libreria a embed un interprete in (esistente) applicazioni (ad esempio luatex sta incorporando Lua in tex ).

Questo è il punto di forza di Lua, per essere embeddable nella tua applicazione. Lua è stata originariamente progettata per questo scopo. Quindi hai qualche applicazione esistente e puoi (senza troppi sforzi) incorporare l'interprete Lua library all'interno della tua applicazione per abilitare alcune parti di esso a essere programmabili da Lua.

Questo è spiegato nel capitolo §24 - Una panoramica dell'API C , che inizia con:

Lua is an embedded language. That means that Lua is not a stand-alone package, but a library that can be linked with other applications so as to incorporate Lua facilities into these applications.

You may be wondering: If Lua is not a stand-alone program, how come we have been using Lua stand alone through the whole book? The solution to this puzzle is the Lua interpreter (the executable lua). This interpreter is a tiny application (with less than five hundred lines of code) that uses the Lua library to implement the stand-alone interpreter. This program handles the interface with the user, taking her files and strings to feed them to the Lua library, which does the bulk of the work (such as actually running Lua code).

This ability to be used as a library to extend an application is what makes Lua an extension language. At the same time, a program that uses Lua can register new functions in the Lua environment; such functions are implemented in C (or another language) and can add facilities that cannot be written directly in Lua. This is what makes Lua an extensible language.

These two views of Lua (as an extension language and as an extensible language) correspond to two kinds of interaction between C and Lua. In the first kind, C has the control and Lua is the library. The C code in this kind of interaction is what we call application code. In the second kind, Lua has the control and C is the library. Here, the C code is called library code. Both application code and library code use the same API to communicate with Lua, the so called C API.

In questo caso devi legare (cioè avvolgere) alcune delle tue routine come funzioni primitive chiamate dagli script Lua, e devi anche essere in grado di eseguire Lua (ad es. interpretando qualche codice o script).

Quindi il punto di progettazione di alcune API Lua C è di essere in grado di usare Lua per scrivere applicazioni o software esistenti (e non principalmente per estendere un interprete Lua standalone con qualcos'altro, anche se ciò è possibile tramite plugin caricati in < a href="http://www.lua.org/source/5.3/loadlib.c.html"> loadlib.c , che viene chiamato da require ...)

Nota anche che incorporare un interprete all'interno della tua applicazione è una decisione di progettazione di software architettonica molto strong (che IMHO dovresti fare molto presto).

risposta data 15.06.2015 - 12:08

fonte

Leggi altre domande sui tag c lua

Un modulo è autorizzato a formulare assunzioni implicite? Perché così tante lingue limitano le stringhe letterali a una singola riga sorgente? [chiuso]

score 5 · Accepted Answer

Ci sono molte situazioni in cui chiamare le funzioni Lua da un programma scritto in un'altra lingua è meglio che chiamare uno script Lua.

Quando distribuisci un programma che fa cose utili, è più facile collegare la parte pertinente della libreria Lua e fare cose all'interno del tuo programma piuttosto che raggruppare l'intero sistema Lua e installarlo per ogni utente del tuo programma. Non tutti vogliono quel tanto di codice in più, alcuni utenti avranno già installato Lua, devi tenere la Lua dell'utente separata dal tuo Lua in bundle, ecc.
Raggruppare l'intera lingua può richiedere molto spazio. Il collegamento solo di alcune funzioni può rendere il pacchetto risultante del programma molto più piccolo.
È più efficiente non creare un nuovo processo ogni volta che si desidera utilizzare la funzionalità implementata in Lua. Se questo è più volte al secondo, la velocità sarà considerevole.
Il passaggio di dati a un nuovo processo e la ricezione di dati di ritorno sono complicati; devi configurare la comunicazione tra processi tramite memoria condivisa, pipe, porte o qualcosa di simile, o analizzare lo STDOUT del programma esterno. Funziona bene per valori piccoli, ma non per il lat tutto per dati strutturati di grandi dimensioni.

Nota che non tutti questi motivi si applicano sempre. Esistono molti casi d'uso in cui nessuno si applica e il bundling del linguaggio di scripting è in realtà la soluzione migliore. Ma ci sono certamente altri casi in cui il raggruppamento sarebbe eccessivo, ed è per questo che esiste l'API programmatica.