views:

132

answers:

1

SWIG graciously provides the swig_type() function to get a string representation of the data type of a passed userdata object. However, in the case of member fields, SWIG and Lua consider those to be simple "number" items and so prints only "number" instead of the data type's name.

e.g.

typedef num_years int;

class Person
{
    public:
           Person * spouse;
           num_years   age;
};

in C++ would result in:

Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio

> p = MyModule.Person();
> print(swig_type(p.spouse));
Person *
> print(swig_type(p.age));
number

Is there some back-door route I could take to determine member fields' data types? I see that the get and set functions have the correct string representation of the number fields when validating arguments.

Thanks for any assistance!

+2  A: 

SWIG-wrapped C++ objects are Lua userdata objects conforming to a particular set of rules. swig_type() works by peering into those userdata objects and retrieving the type name information that SWIG stored there. But age is represented directly, so there's no type name field to look up, so swig_type() can't do its magic. You can get what you want by making num_years an opaque class type that wraps an int (and which maybe defines some implicit conversions for ease of use in C++), but that's a lot of work to go to for a dubious reward.

The get and set functions work by an entirely different mechanism; they have the correct signature because SWIG stores it in the generated wrapper at compile time, copying from the interface file.

David Seiler