2008-09-19 6 views
12

Utilisez-vous Luabind, toLua ++ ou une autre bibliothèque (si oui, laquelle) ou pas du tout?Comment coller le code Lua en C++?

Pour chaque approche, quels sont les avantages et les inconvénients?

+0

upps ... corrigé :) – steffenj

+0

Il y a eu une discussion sur ce sujet [ici] (http://stackoverflow.com/questions/63784/implementing-scripts-in-c-app#63865). – Mark

Répondre

4

Pour répondre à ma propre question en partie:

Luabind: une fois que vous savez comment lier les méthodes et les classes via cette syntaxe de modèle maladroit, il est assez simple et facile d'ajouter de nouvelles liaisons. Cependant, luabind a un impact significatif sur les performances et ne devrait pas être utilisé pour des applications en temps réel. Environ 5 à 20 fois plus de temps système que les fonctions C qui manipulent directement la pile.

1

Je n'utilise aucune bibliothèque. J'ai utilisé SWIG pour exposer une bibliothèque C il y a quelque temps, mais il y avait trop de surcharge, et j'ai arrêté de l'utiliser.

Les avantages sont une meilleure performance et plus de contrôle, mais cela prend plus de temps pour écrire.

1

Utilisez l'API Lua brute pour vos fixations - et gardez-les simples. Inspirez-vous de l'API elle-même (bibliothèque AUX) et des bibliothèques des auteurs Lua. Avec un peu de pratique, l'API brute est la meilleure option - une flexibilité maximale et un minimum de temps système inutiles. Vous avez ce que vous voulez et pas plus, comme vous le souhaitez.

Si vous devez lier de grandes bibliothèques tierces, utilisez des générateurs automatiques tels que tolua, tolua ++ (ou même lancez le vôtre pour le cas spécifique). Cela vous libérerait du travail manuel.

Je ne recommanderais pas d'utiliser Luabind. En ce moment, le développement est bloqué (mais commence à revenir à la vie), et si vous rencontrez un cas de coin, vous pouvez être seul. De plus, Luabind utilise intensément la métaprogrammation de modèles. Cela peut (et ne peut pas) être inacceptable, selon le point de vue.

+0

Mis à part les personnes qui pourraient utiliser des compilateurs qui ne peuvent pas supporter le TMP, je ne vois pas pourquoi cela serait inacceptable.En ce qui concerne le développement, il y en a (j'ai récemment apporté une amélioration/correction), et la plupart du temps je ne trouve pas qu'il manque quelque chose de trop important. Ce n'est pas * très * actif, cependant, c'est vrai. –

5

Je ne peux pas vraiment être d'accord avec le vote 'roll your own', relier les types de base et les fonctions C statiques à Lua est trivial, oui, mais l'image change dès que vous commencez à utiliser des tables et méta-tables; les choses se compliquent très rapidement. LuaBind semble faire le travail, mais j'ai un problème philosophique avec elle. Pour moi, il semble que si vos types sont déjà compliqués, le fait que Luabind soit fortement structuré ne va pas rendre votre code plus facile à suivre, comme l'a dit un de mes amis: "Vous aurez besoin de Herb Shutter pour comprendre les messages de compilation" . De plus, cela dépend de Boost, plus les temps de compilation obtiennent un coup sérieux, etc.

Après avoir essayé quelques fixations, Tolua ++ semble le meilleur. Tolua ne semble pas être très en développement, alors que Tolua ++ semble bien fonctionner (plus la moitié des tutoriels 'Tolua' sont en fait des tutoriels 'Tolua ++', croyez-moi sur ce point :) Tolua génère le bon choses, la source peut être modifiée et il semble traiter des cas compliqués (comme des modèles, des syndicats, des structures sans nom, etc, etc)

Le plus gros problème avec Tolua ++ semble être le manque de tutoriels appropriés, prédéfinis Visual Les projets de studio, ou le fait que la ligne de commande est un peu difficile à suivre (vous chemin/fichiers ne peut pas avoir des espaces blancs - dans Windows au moins - et ainsi de suite) Pourtant, pour moi c'est le gagnant.