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

[Dave Hawkes]

----- Original Message -----
From: "David Abrahams" <david.abrahams at rcn.com>
To: <c++-sig at python.org>
Cc: "Dave Hawkes" <daveh at cadlink.com>
Sent: Wednesday, July 17, 2002 1:32 PM
Subject: Re: [C++-sig] Re: Questions/Comments about new stuff


> was
> > going to be dynamically created. I can fix this if you wish?
>
> This is not a trivial problem.
>
It shouldn't be too much of a problem as it doesn't actually need access at
this point. In fact changing the class_ constructors as mentioned in a
recent post will be the easiest way of fixing the 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.
>
That's how it's meant to work! The part your missing is that when the real
c++ class is defined the the empty class is ripped out and replaced with it.
What this means is that all undefined classes are the same empty place
holder until the real class is registered.

> >
> > 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.
>
The iterator is easily fixed. I think the major problem is that I should of
perhaps provided more details about how it works before posting the code so
that you would have more confidence in it.

Dave Hawkes