[Swig-devel] [ swig-Bugs-2800537 ] Member fields in a namespace result in multiple SWIG types

[SourceForge.net <no...@so...>]

Bugs item #2800537, was opened at 2009-06-03 14:22
Message generated for change (Comment added) made by wsfulton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2800537&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: lua
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Zack S. (portmanteaufu)
Assigned to: Mark Gossage (mgossage)
Summary: Member fields in a namespace result in multiple SWIG types

Initial Comment:
[This is my first bug report, so please let me know if I need to provide further clarification or additional information.]

My problem is very similar to this long-closed bug: https://sourceforge.net/tracker/index.php?func=detail&aid=782778&group_id=1645&atid=101645

I have a Lua module that I've created with a very large number of C++ classes. Some of the classes are declared within a namespace, like so:

namespace NS1 {
  class myClass {
      public:
        NS2::someDataType memberField;
  } // end myClass
} // end namespace NS1

When the C++ wrapper file is produced, it contains both a "SWIGTYPE_p_NS1__NS2__someDataType" and a "SWIGTYPE_p_NS2__someDataType". All of the wrapper functions for myClass validate their arguments expecting a SWIGTYPE_p__NS2__someDataType instead of a SWIGTYPE_p_NS1__NS2__someDataType and the program fails when I try to call them. I have manually changed the data type in a couple of areas in my generated wrapper file and can now call those functions properly.

----------------------------------------------------------------------

>Comment By: William Fulton (wsfulton)
Date: 2009-06-04 18:47

Message:
I guess this is one of those things that is clear once you know more about
SWIG. Agreed, that this could be documented better. Patches welcome :)

----------------------------------------------------------------------

Comment By: Zack S. (portmanteaufu)
Date: 2009-06-04 18:07

Message:
I determined the problem. I was assuming that SWIG worked like gcc, and
never realized that the order of %include statements mattered.

Because SWIG doesn't have to know about every single data type mentioned
in a class, when it discovers a data type it hasn't encountered before, it
simply makes a data type for it. Thus, while processing 

namespace NS1 {
class myClass {
public:
NS2::someDataType memberField;
} // end myClass
} // end namespace NS1

if it hasn't heard of NS1::NS2::someDataType yet, it doesn't know what
namespace to look for it in and creates a new swig_type_info for it.

I doubt this is still considered a bug, but perhaps someone could work the
importance of %include ordering into the SWIG documentation? I don't
believe I ever ran across anything mentioning it.

Thanks a lot to all the developers of SWIG! It's a great tool.

----------------------------------------------------------------------

Comment By: Zack S. (portmanteaufu)
Date: 2009-06-04 17:17

Message:
I'm attempting the create a minimal example of the bug, but it seems that
most of the small test cases I make work without issue.

When I run SWIG with the -debug-classes flag, the erroneous data types do
not show up in the list. That is, the list contains only the full data type
NS1::NS2::someDataType, and not the "NS2::someDataType" for which a
swig_type_info is being created in the cxx file.

----------------------------------------------------------------------

Comment By: Zack S. (portmanteaufu)
Date: 2009-06-03 15:56

Message:
I forgot to mention that this is in SWIG v1.3.39, compiled using gcc 3.4.6
and being used with Lua v5.14. I'm using Red Hat Linux.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2800537&group_id=1645