[C++-sig] Re: boost::python::range and duplicate comdat under MSVC 6
Raoul Gough
RaoulGough at yahoo.co.uk
Tue Nov 4 10:37:07 CET 2003
David Abrahams <dave at boost-consulting.com> writes:
> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
[snip]
>> In our case it's being triggered by the static member variable in
>> shared_ptr_from_python (see coverter/shared_ptr_from_python.hpp).
>> Seems pretty fatal to me, since (AFAIK) a static object is necessary
>> for the type registration scheme to work. I'm not going to bother
>> trying to fix this.
>
> We use lots of static data members, though; this isn't the only place
> we ought to be seeing a problem if that's the issue.
It seems to be dependant in some complicated way on the template
arguments. For example, the following is sufficient to demonstrate the
problem:
#include <boost/python/object/class_converters.hpp>
#include <boost/python/object/iterator.hpp>
#include <boost/python/return_value_policy.hpp>
#include <boost/python/return_by_value.hpp>
int main ()
{
namespace python = boost::python;
namespace objects = boost::python::objects;
namespace detail = boost::python::detail;
namespace converter = boost::python::converter;
typedef python::return_value_policy<python::return_by_value> policy_t;
typedef python::return_value_policy<python::return_by_value> policy_t;
typedef objects::iterator_range<policy_t, int *> iterator_t1;
typedef objects::iterator_range<policy_t, double *> iterator_t2;
detail::force_instantiate (
converter::shared_ptr_from_python<iterator_t1>::registration);
detail::force_instantiate (
converter::shared_ptr_from_python<iterator_t2>::registration);
return 0;
}
>From the assembly listing, this has the following symbol duplicated
for two slightly different procedures that are passed to _atexit. They
both do some setup before calling one of the (correctly distinguished)
static object destructors.
?registration@?$shared_ptr_from_python at U?$iterator_range at U?$
return_value_policy at Ureturn_by_value@python at boost@@$E
Only the first part of the iterator type seems to be embedded in the
mangled name (the return value policy) which obviously causes a clash
whenever two different iterators use the same policies. I guess that
reordering the template parameters to iterator_range might reduce the
likelihood of the problem occurring in practice.
>
> However, a simple transformation ought to be enough to eliminate the
> static data member, AFAICT. Do you need help working it out?
It looks to me like the static member is only useful for the
side-effects of its constructor. Is there an alternative way to
achieve this?
--
Raoul Gough.
(setq dabbrev-case-fold-search nil)
More information about the Cplusplus-sig
mailing list