2

Lua に問題があり、正しい方向に進んでいるかどうかわかりません。C++ には、リソース マネージャーにパラメーターを渡すために使用する辞書があります。この辞書は、ハッシュと文字列のマップに非常に似ています。

Lua ではこれらのリソースにアクセスしたいので、ハッシュの表現が必要です。また、ハッシュは一意である必要があり、テーブル内のインデックスとして使用されます。私たちのハッシュ関数は 64 ビットで、私は 32 ビット環境 (PS3) で作業しています。

C++ 私はそのようなものを持っています:

paramMap.insert(std::make_pair(hash64("vehicleId"), std::string("004")));
resourceManager.createResource(ResourceType("Car"), paramMap);

Lua では、これらのリソースを使用して、他のユーザーデータのファクトリを作成します。私は次のようなことをします：

function findBike(carId)
   bikeParam = { vehicleId = carId }
   return ResourceManager.findResource('car', bikeParam)
end

したがって、パラメータは Lua によって作成される場合もあれば、C++ によって作成される場合もあります。myhashkey ('vehicleId')はテーブルのインデックスであるため、一意である必要があります。uint64_t を実装するために lightuserdata を使用しましたが、32 ビット環境にいるため、単純int64にポインターに格納することはできません。:(

プログラムで使用されるすべてを格納するテーブルを作成しint64、参照をユーザーデータに保存する必要があります。

void pushUInt64(lua_State *L, GEM::GUInt64 v)
{
  Int64Ref::Handle handle = Int64Ref::getInstance().allocateSlot(v);
  lua_pushlightuserdata(L, reinterpret_cast<void*>(handle));
  luaL_setmetatable(L, s_UInt64LuaName);
}

ただし、ユーザーデータがガベージ コレクションされることはありません。その後、int64 が解放されることはなく、テーブルは永遠に大きくなります。また、lightuserdata はメタデータへの参照を保持しないため、他の light userdata と干渉します。実装を確認すると、L->G_->mt_[2] にメタデータ テーブルが追加されています。それをやって

a = createLightUserDataType1()
b = createLightUserDataType2()
a:someFunction()

のメタテーブルを使用しますb。

メタテーブルが型にバインドされていると思いました。現在の実装 lightuserdata の使用例は非常に限られているため、かなり混乱しています。

Python では、型が辞書のインデックスとして使用されるたびに呼び出されるハッシュメタ関数があります。似たようなことをすることは可能ですか？

私の英語でごめんなさい、私はイタリア出身です。:-/

4

0 に答える 0