Re: boost::shared_ptr<T> and Gtk::TreeModelColumn<T>

["Murray Cumming" <murrayc murrayc com>]

> On Mon, 2006-09-18 at 23:08 +0200, Murray Cumming wrote:
>> On Mon, 2006-09-18 at 16:26 -0400, Paul Davis wrote:
>> > any opinions on the best way to have:
>> >
>> > 	Gtk::TreeModelColumn<boost::shared_ptr<T> >
>> >
>> > at the moment, g++ appears to pick the void* partial specialization of
>> > TreeModelColumn,
>>
>> Are you sure that there is void* partial specialization? What exactly
>> does it look like?
>
> well, gdb let me know that this was going on, and the stack trace showed
> we were in Value<void*> ... not really a partial specialization.

Ah, I think the experts call that a "template instantiation". Still it's
odd, though I imagine that it might be a compiler optimisation.

>> >  which leads to problems later (glib complains that the
>> > object is not actually a G_TYPE_POINTER etc). i have considered
>> > implementing another partial specialization, but I am not sure it will
>> > solve the issue. any thoughts?
>>
>> It works for RefPtr and for other random types. TreeModelColumn should
>> generate a custom gtype (via Glib::Value) to identify the type inside
>> TreeView so you shouldn't get that warning theoretically.
>>
>> A little test case might help us figure it out. You could try it with
>> just a shared_ptr<int>, for instance.
>
> i did that. it compiles but does not run. changing the shared_ptr<int>
> back to just int corrects all issues. the behaviour is different than i
> previously described, probably or possibly because of different versions
> of gtkmm. i tried this code with 2.8 and got lots of errors of the form:
>
>     unable to set property `text' of type `gchar array' from value of
>     type 'glibmm__CustomBoxed_N5boost10shared_ptrIiEE'

Noting that you told us in a subsequent email to ignore the attached case:

If this problem still exists, it might be helpful to show us a test case
that demonstrates it. I can't promise to investigate it immediately, but
someone else might, and I'd get around to it eventually.


Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com