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

[Dave Hawkes]

"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?


> 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.

>
> > 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.
Unfortunately the init_sub_module and class_context stuff was written before
the API code, I knew these could probably be simplified when that was
completed.

Dave Hawkes