"Lijun Qin" <qinlj@[...].com>  writes:

>  Hi, all:
> 
>  I have found a method to do this, by register a convert function:
> 
>  inline void* convert_to_cstring_from_unicode(PyObject* obj)
>  {
>      if (!PyUnicode_Check(obj)) return 0;
>      PyObject* str = PyUnicode_AsEncodedString(obj, "mbcs", NULL);
>       if (!str) throw_error_already_set();
> 
>       //We must release the str before we return to python, gard here
>       static leak_gard _gard;
> 
>       unicode_str_map[obj] = str;
>       return PyString_AsString(str);
>  }
> 
>  converter::registry::insert(convert_to_cstring_from_unicode,
>  type_id<char>());
> 
>  But the problem is that the PyString object must be freed when the
>  call is completed, I currently do this by applying a custom call
>  policy to the methods using 'const char*' type of parameters, but if
>  there were reclusive

"recursive", I think.

>  calls into the same fuction, it'll much complex.
> 
>  In this procedure, I found that if we can apply the call policies
>  before the argument conversion procedure and in the context of the
>  call policy object (a call policy object is always attached with a
>  method, right?)

Right.

>  the problem will be solved much easier and safer. We'll be able to
>  replace the PyUnicode object with a PyString object (in Windows
>  platform, always MBCS encoding), maybe save the original args tuple
>  in the call policy object

This is the key thing which I had forgotten: call policies can have
state.  You can keep a stack (linked list) of "original args tuples"
in the call policy in order to deal with recursion.

>  then convert the args to C++ (it'll success because the arg is a
>  PyString) and call the C++ function, when postcall(args, result)
>  called, we can just release the newly allocated args tuple, replace
>  it with the original one. This will give us more control on how the
>  args be processed.

Yes, that sounds brilliant!  So this approach does not use the
convert_to_cstring_from_unicode converter, correct?

I think it has inspired me, also, to consider expanding the conversion
interface.  I was looking for a way for converters to maintain state
(e.g. to be able to keep a PyString alive during the conversion, or to
be able to fabricate a vector<int>  from a Python list and then write
the modified elements of the vector back into the list after the call)
without incurring the cost of a polymorphic postcall operation for
each converter in a function call.  One possibility might be to define
an abstract postcall object, and pass a pointer to a chain of those,
which lives in the call policy, to all converters during function
calls.  Any converter which needed to maintain state could add a
postcall object to the chain.  That would essentially reduce the
postcall check to a single step for N arguments, in the usual case
that there were no postcall operations.  In non-function contexts,
such as

     char const* p = extract<char*> (s);

the pointer to the postcall chain would be NULL, so any converters
which required a postcall chain could simply report "no match".


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com


_______________________________________________
C++-sig mailing list
C++-sig@[...].org
http://mail.python.org/mailman/listinfo/c++-sig