[C++-sig] Re: map key

[David Abrahams]

"Mike Rovner" <mike at bindkey.com> writes:

> "David Abrahams" <dave at boost-consulting.com> wrote in message
> news:usmvrh0l3.fsf at boost-consulting.com...
>> "Mike Rovner" <mike at bindkey.com> writes:
>>
>> <snip>
>>
>> Mike, lots of mailers don't respond well to indentation with tabs.
>
> I'm sorry for the formatting. There was no tabs but something strange
> happened with pasting from VC7.
>
>> There is no function returning const Key* being invoked, but I see
>> what you mean.  The problem occurs where you try to convert a ``const
>> Key*'' to a Python object.
>
> That's correct.
>
>> > Can I specify return_internal_reference when constructing keys list?
>>
>> Hum, that's an interesting question.  I guess you'd like each of the
>> items in the keys list to keep the map object alive so that they will
>> remain valid.  You could use t.append(ptr(it->second)), which would
>> build an object around the pointer and stick it in the list, but that
>> would not have the desired lifetime-management properties.
>
> It is working, but I still don't understand it. ;)
> I have a map<const Key*, Value>, so map<>::iterator it->first shall
> return const Key* or at least const Key* const&. So we already have a
> pointer,
> why we need a ptr() call around it?

Because, in general, building a Python object around a pointer
(instead of a copy of the pointee) is unsafe, we don't do it by
default.  You have to ask for it explicitly.  Of course
return_internal_reference makes it safe, but it's not known that
you're using it at that point in the code.

> I'd like to have a lifetime-management, but I'm still shallow on it.
> I don't need to keep a map, because map keys are pointers to an object
> elsewhere 

Oh, good point. return_internal_reference is ineffectual here.

> and manupulating them can be a potential disaster but I'm limited by
> existing library I'm wrapping. :(

You can only do what you can do.

> But while it's great at hand-maid keys() and items() lists, there's
> still a problem with iterator<map<const Key*, Value> >(). Obviosly
> it doesn't know about ptr().

I think it doesn't know about std::pair<const Key*,Value>, which is
the iterator's value type ;-)

A Python map's iterator just iterates the keys, so you might need to
build the iterator by hand if you want it to do the same thing.

>> One approach would be to wrap a function which could convert
>> the pointer with the lifetime management you want:
>
> I have a host object Host which holds all Keys and cleaning them on
> desruction.  Host can return const Key* and I'd like to keep that
> (wrapped) host instead.

Fine; I think you can figure out how to make that work, yes?

>> I think that would solve it.
>
> Thanks a lot, Dave. BPL already saved us a week debugging and more
> is on the way.

That's great!  I'm curious, though: how can you tell it saved you a
week?

>> Mike, I think this would make a really good tutorial case study for
>> the Boost.Python documentation.  Is there any way I could persuade
>> you to write it up so that others can benefit?
>
> (side note) I'm constantly adding some stuff from that list to the wiki.
> OK, if you think I can do it, I can do it. :)

I have complete faith!

> You mean that http://www.boost.org/libs/python/doc/tutorial/index.html
> tutorial?

No, I think we'll probably build up a bunch of these case studies, and
they would just weigh down the tutorial.

> I need a few lines guidelines like a few questions that my future
> text will answer and I'll go for it.

Sorry, I don't understand what it is you need to know.  Just let me
know; I really appreciate your willingness to contribute!

-- 
                       David Abrahams
   dave at boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution