> The changes that you've made all sound very reasonable. Using std::map for
> the function lookup is definitely better than the linear search, but you still have
> a binary search and log-complexity. Also, does it mean that you need a C++
> compiler if you wrap C code?

Yes it would. Is that a problem? i.e. do other languages support C only?
We could fall back to your previous code for C.

The way I started out with the module was that the wrapper would be plain C if the wrapped code is plain C. I think that would be a good principle, even though I myself is really only interested in wrapping C++ code. For the Octave module, that wasn't really an issue since Octave's API is C++ meaning that you need a C++ compiler anyway for the wrapper. Maybe William has some opinion on this?

> It should be relatively easy to get constant
> complexity (trivially by changing std::map to std::unordered_map and requiring
> C++11, but I think there are better ways).
We could, but low priority I think/

I can fix this so that you get constant complexity without involving any C++. It's really easy.

> > - somewhat annoying is that if I use a function that returns 1 argument, I have
> > to specify an explicit output argument. For instance
> > "a.size()" returns nothing, while "tmp=a.size()" is ok. This is because of the
> trick
> > you use with varargout of course, but I don't know how to solve this (i.e. how
> to
> > detect a void function vs one that returns an argument).
> About functions returning one argument, what you really want is that the
> generated wrapper has 1 output argument even though nargout is 0. That's
> how I solved it for the getters. Not sure how to "mark" what functions to behave
> like this.

Right. I have no idea. Possibly with a custom typemap... can a typemap check if a function doesn't return anything (i.e. void f())?

Yeah, something like this. But remember that the MATLAB function might have return value(s) even if the C/C++ function doesn't. 

> > - I have no idea how to get indexing for containers to work. Octave used
> > __paren__ and __paren_assign__ but Matlab uses subsref and subsasgn, and
> > warns that overloading these is very tricky to get right...
> >
> > - related to the above is that your SwigRef class defines subsref in terms of
> > getitem and getitemcurl, but where are those supposed to come from?
> I realized that if I overloaded "subsref"/"subsasgn", it conflicts with other
> things, like calling wrapped functions. So I had "subsref"/"subsasgn" fallback to
> the built-in behavior when the length of the index is longer than one. That is, it
> will catch stuff like "my_instance.foo" and "my_instance(4) and
> "my_instance{2,3}", but not "my_instance.foo(4)". With the switch I added, I
> guess swig_parsref and swig_cursref will work like getitem and getitemcurl,
> respectively. It won't cover all cases - for example you would need to modify
> the switch to handle cases such as "my_instance.foo(4).bar" or
> "my_instance.foo(4).bar(5)". I hope I make myself more or less understood.

Not sure... getitem would have to be implemented elsewhere?

Basically, __getitem__ in Python corresponds to "swig_parsref". I will have a look again to see if it can update it so that it becomes an exact match.
I am currently trying to understand the way the mex function can return a proper matlab-proxy class. It works for the constructors (probably because of the swigcreate trick?) but not always for other functions. Any light you could shed on that would be great.

Do you have an example snippet?