Don't populate the typenames array for each and every created object and don't search it when deleting every object, this is O(N) in number of classes and is completely impractical for any big library where N can easily be several thousands. Use destructor function which will correctly destroy the object instead. Also don't store each created objects in the global registry, there doesn't seem to be any point in it. And, in fact, don't bother with the typenames at all, just use another pseudo-virtual function for checking whether a class inherits from a class with the given name. There is unfortunately one problem with the new approach: it doesn't work when the same C++ type is wrapped under different names as this results in multiple specializations of SWIG_derives_from<> for this type. But this is a relatively rare situation (but which does arise in template_default2 unit test, which had to be disabled) and could be fixed in the future by completely resolving the type, including the default template parameters values, and checking if SWIG_derives_from had been already specialized for it. In the meanwhile, this regression is not a big deal compared to the advantages of the new approach. |
||
|---|---|---|
| .. | ||
| allegrocl.cxx | ||
| allocate.cxx | ||
| browser.cxx | ||
| c.cxx | ||
| cffi.cxx | ||
| chicken.cxx | ||
| clisp.cxx | ||
| contract.cxx | ||
| csharp.cxx | ||
| d.cxx | ||
| directors.cxx | ||
| emit.cxx | ||
| go.cxx | ||
| guile.cxx | ||
| interface.cxx | ||
| java.cxx | ||
| javascript.cxx | ||
| lang.cxx | ||
| lua.cxx | ||
| main.cxx | ||
| modula3.cxx | ||
| module.cxx | ||
| mzscheme.cxx | ||
| nested.cxx | ||
| ocaml.cxx | ||
| octave.cxx | ||
| overload.cxx | ||
| perl5.cxx | ||
| php.cxx | ||
| pike.cxx | ||
| python.cxx | ||
| r.cxx | ||
| README | ||
| ruby.cxx | ||
| s-exp.cxx | ||
| scilab.cxx | ||
| swigmain.cxx | ||
| swigmod.h | ||
| tcl8.cxx | ||
| typepass.cxx | ||
| uffi.cxx | ||
| utils.cxx | ||
| xml.cxx | ||
06/25/2002 This directory contains all of the SWIG language modules. Many of these modules contain code that dates back to SWIG1.0. The module API has changed a lot in the development releases so this is fairly messy. We're working on cleaning it up, but you'll have to bear with us until it's done. -- Dave