[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-cpp-sig
Subject:    Re: [C++-sig] [Boost.Python v3] Features and Scope
From:       Hans Meine <hans_meine () gmx ! net>
Date:       2011-08-30 8:26:49
Message-ID: 201108301026.49897.hans_meine () gmx ! net
[Download RAW message or body]

Am Dienstag, 30. August 2011, 08:42:53 schrieb Jim Bosch:
> I don't see how having a global registry makes things any worse from an
> ODR perspective.  It seems like it's mostly just the same "where do
> templates get instantiated" problem that compilers and linkers always
> have to deal with.

There is a big difference in the case that two separate extensions (want to) 
use different converters, though.

> In other words, instantiating something like:
> 
> class_< std::vector<int> >
> 
> in two shared libraries doesn't seem any different from instantiating
> something like:
> 
> std::vector<int>
> 
> in two shared libraries, and we basically always have to leave it up to
> the compiler/linker to solve the latter.

Here you assume that class_< std::vector<int> >(…) will generate the same code 
in both cases.  For std::vector<int>, this holds, but for
class_< std::vector<int> >(…), the (…) part—which you left out—is crucial.

In practice, it happened to me with two extensions which did not even agree on 
the /type/ of converter (class_ vs. rvalue) for the same class 
(vigra::TinyVector, a small fixed-size vector).

Although it would be nice to fix/allow this (local registries, which can still 
be imported/reused as a dependency), it /may/ be an even better fix to change 
the extensions and make them agree on the "optimal" converter.  (The obvious 
problem is of course the definition of "optimal" which may be different 
depending on the application.)  The problem with this is the very reason for 
the variety of std::vector converters out there (e.g. focusing on conversion 
to native Python types, conversion speed, or in-place 
writability/modifications).

HTH,
  Hans
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

[prev in list] [next in list] [prev in thread] [next in thread]