AW: [C++-sig] New implementation for opaque_pointer_converter

[Gottfried.Ganssauge at HAUFE.DE]

Hi Dave,
> Von: David Abrahams [mailto:dave at boost-consulting.com]
> > I see tow ways around that.
> > The first one is fairly simple: just return Py_None from
> > opaque_pointer_converter::convert() if a NULL-pointer is to be
> >> converted.
> 
> That's what Boost.Python does when converting NULL pointer values
> to_python, because it corresponds to peoples' expectations.
After sleeping a night over it I realized that it's probably what I would
expect as well,
so I now tend to think that this implementation might be the best one.
In addition all APIs I know using opaque pointers (like fopen()) use
NULL-pointers for a failure return value so we would need some special value
anyway to check for failures.

> 
> > It's drawback was already made obvious in your test case: 
> the assertion
> > (type(getnull()) == type(get()) won't hold.
> 
> I added that assertion after trying
> 
>    assert getnull() is None
> 
> expecting it to work.  Probably it would be best to return something
> other than PyNone in this case, but it's not a big deal.
Probably not; as you already pointed out: people expect to get None for a
NULL-pointer.

...
> 
> However, I realize now that I have concerns about the current
> specialization macro:  In order for this to work cross-module you'd
> need to invoke the macro in every translation unit which uses
> conversions to- or from- the raw pointer type.
> 
> In the approach I was thinking of, we would just change type_id<T>()
> to use typeid(add_pointer<remove_reference<T>::type>::type) for _all_
> T.  We'd want some special code to strip the trailing '*' when
> printing these, and we'd need to carefully examine all of the places
> where a boost::python::type_info is constructed from a std::type_info.
I see what you mean.

Cheers,

Gottfried