[C++-sig] Re: Questions/Comments about new stuff

[David Abrahams]

From: "Dave Hawkes" <daveh at cadlink.com>


>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:04ca01c22daa$4de4dd90$6501a8c0 at boostconsulting.com...
> >
> > Well, I'm not even sure it works - witness the iterator crash I'm
seeing.
> > Certainly this seems completely broken:
> >
> >      current_object =
> >
>
python::object(handle<>(boost::python::class_<empty_class>(full_name.c_str(
> > )).object()));
> >
>
> There is a dependancy in the current code that requires the module_info
> outside of the scope of module initialization when a new class is created
> later. At the time the code was written I didn't appreciate that a class
was
> going to be dynamically created. I can fix this if you wish?

This is not a trivial problem.

> > All instances of class_<T> refer to the same object for a given T. What
> > happens when you have multiple levels of nesting (c1.c2.c3...)?
> >
>
> That's correct. The type_info should uniquely identify the c++ class
> c1::c2::c3 from c3. The assumption I make is that someone won't take a
> definition of c1:c2:c3 and define it simultaneously as both c1.c2.c3 and
c3
> in python.

You're misunderstanding the nature of the problem. Each time you mention
class_<empty_class> it accesses the very same Python object. It doesn't
matter what name you pass. I don't believe it's particularly useful to
allow nested classes to be registered before their enclosures are
registered, and I'm pretty sure it's not possible without a major
architecture change.

> >
> > > able to par it down further using the API code.
> >
> > Don't touch anything for the time being. I'm going to fix it up to show
> you
> > how it should be done. Adding stuff like this (and especially
> > init_sub_module) to the codebase, even as a temporary measure to be
> cleaned
> > up later, is really unacceptable because it means that I can't maintain
it
> > until it's cleaned up. Note that I don't even think you're able to
> maintain
> > code written in this style. If the code were less-dense, you would have
> not
> > missed "r", for example. Code has to go into the codebase with a tidy
> style
> > to start with, as much as possible.
>
> I think there's only a couple of major areas that need cleaning up.

I disagree. I've spent all morning deciphering, massageing, and debugging
this code. The iterator test is still broken, and things have become quite
tangled. Unfortunately, I can't afford to have the codebase in this
condition while you clean things up -- it impacts the other users, too. I'm
going to roll back your changes, but I hope that you'll add it again on a
branch, so that we can work together to merge it into the main trunk in a
controlled way.

-Dave