[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