腳本和主機應用程序之間的責任

我一直在試圖決定如何將Lua嵌入到我的應用程序中以用於腳本和擴展目的。我有一個類處理具有類似於Lua表的結構的對象。（特別是boost::any的散列圖） Lua腳本將與這些對象及其散列映射進行交互。腳本和主機應用程序之間的責任

我越來越清楚，我可以在Lua中編寫整個或大部分這個類（並從C中訪問它），但我不確定這樣做的後果，特別是關於創建許多表來表示哈希映射。得出這個結論的原因是我想在這些C對象中存儲來自Lua的高級結構，但這樣做每次將表存儲到C對象中或從其中檢索時都需要顯式表序列化。從理論上講，這種方法可以提供更少的內存使用量，以平衡每次訪問的更高延遲。

這種情況下可能的行動方案及其優缺點是什麼？

來源

2011-07-04 Ryan Stein

使用Lua vs當前實現的優點是什麼？「存儲來自Lua的高級結構」是什麼意思？ – kikito

將表原樣從Lua存儲到C中，最有可能表示數組，並且在極少數情況下表示哈希映射。目前，存儲任何微不足道的POD類型都很簡單，比如Lua的編號，布爾值，零，字符串。正如我前面所說的那樣，存儲非平凡的數據類型（比如表）需要C和C的顯式序列化。與當前實現相比，使用Lua的好處是大多數這些操作都是內部的; Lua會在運行時處理所有變量的存儲。唯一需要顯式表序列化的是C需要一個。 –

我最終決定定居在編程我的大部分應用程序的Lua使用LuaJIT，對於許多原因，其中包括：

我試圖實現通過C/C++是已經有Lua，哈希表和metafacilities具體，我基本上重新發明輪子。
我做了一些簡單的基準測試，發現大多數我的腳本總是會結束反彈調用ç和回的Lua非常頻繁，我可以通過保持限制了運行時的焦點優化掉了很多本到Lua通過利用字節碼編譯器。
從我有限的經驗和研究對周圍即時編譯，LuaJIT（2.0.0-beta8）主題證明是我在這一點上需要相當足夠快，很可能接近C++水平類似數據結構的內存使用情況。
LuaJIT也可以很好地作爲香草替代品Lua，並且易於構建;我所要做的就是鏈接到它的庫來啓動它並運行。

我覺得我做這個失去的「超級用戶」控制多一點我的項目，但我認爲這是由於我缺乏經驗和Lua的對我的知識的複雜性C++。

來源

2011-09-22 01:37:04

如果我已經正確地理解了你的問題，你只是想使用Lua來避免序列化數據（我假設文件和文件）。如果是這種情況，你可以使用Lua，但對我來說似乎有點矯枉過正。回答最後一個問題，Lua會比本地C佔用更多的內存，並且運行速度會更慢（Lua VM比本地C慢，即使只使用C來操作從Lua跳轉到C也是如此）。反之亦然將會以大量推入和彈出Lua棧的形式受到懲罰）。

如果你想有一個更容易的時間序列化，可能會更好地使用一個庫直接序列化/從C。例如，json。

來源

2011-07-05 06:58:37 kikito

重申一遍，我最初想做的事情是讓C語言中的數據由Lua中的腳本，函數和所有腳本操縱。難題在於我希望在C中平坦地存儲（序列化）表，而不用在Lua註冊表中的某處引用它們等。這讓我懷疑在Lua本身寫這個課是否會更好。這裏沒有文件序列化，但我知道json對此很有幫助。我做了一些簡單的內存基準，用於創建幾十萬張表，這讓我相信Lua的表格可能有點臃腫。 –

腳本和主機應用程序之間的責任

回答

相關問題