|
Boost Users : |
From: Bill Buklis (boostuser_at_[hidden])
Date: 2007-08-02 20:43:49
> -----Original Message-----
> From: boost-users-bounces_at_[hidden] [mailto:boost-users-
> bounces_at_[hidden]] On Behalf Of Filip Konvicka
> Sent: Thursday, August 02, 2007 6:44 PM
> To: boost-users_at_[hidden]
> Subject: Re: [Boost-users] Visual Studio 2005 ptr_list visualizer?
>
> Hi Bill,
>
> (please don't top post, thanks!)
> > I have written visualizers for the other pointer containers, but realize
> > that I had forgotten about ptr_list. I previously posted the visualizer
> code
> > for ptr_vector, ptr_map, ptr_multimap, ptr_set, ptr_multiset, and also
> > array. If you don't have it I can easily post it again.
> >
> Thanks for sharing your work! Once the wiki + repository are ready,
> people will hopefully find things more easily.
> > I took a quick stab at ptr_list, but I think I may have run into a
> > limitation (or bug) in the visualizer. It's not letting me cast the
> final
> > expression to the templated parameter. I tried it with a direct cast and
> > that worked, but it seems to lose the template information in the
> resulting
> > expression.
> >
> > The problem is in the expression ($T1*)$e._Myval. It seems that $T1 (the
> > template parameter) is not valid at this point. If, for example the list
> is
> > defined as ptr_list<int>, then the expression (int*)$e._Myval will work,
> but
> > obviously we can't hard code that here. Any one have any ideas here?
> >
> Yes, this is a bit tricky... the problem is not $T1 being invalid in the
> context, it rather is in how pattern matching works. I suspect that the
> rule pattern matching is string-based. In this case, it is useful to
> look (via a watch) at the exact type being matched. In the case of
> ptr_list<int>, it is
>
> boost::ptr_list<int,boost::heap_clone_allocator,std::allocator<void *>
> >
>
> which apparently matches your filter
>
> boost::ptr_list<*>
>
> since you see some effects in the watch window. Hence $T1 =
> "int,boost::heap_clone_allocator,std::allocator<void *>", which does not
> make sense after substitution. So, to fix your rule, it suffices to
> rewrite the pattern as
>
> boost::ptr_list<*,*,*>
>
> (in fact, boost::ptr_list<*,*> would work as well, justifying my above
> guess...but it is clearly not as clean).
>
> Cheers,
> Filip
>
You're right. That fixed it. I should've realized. I actually had that in my
ptr_vector implementation - at least defined as ptr_vector<*,*>. Yes,
ptr_list<*,*> works as well. By the way, it turns out that the iterators
were already done. They use the same ones that ptr_vector used, so they were
working already.
I just realized that the visualizers I posted previously are all for boost
version 1.33. It's quite possible that they will fully apply to v1.34.
Though there may be an issue with ptr_map and ptr_multimap given that the
usage has changed.
I'm not in a position where I can switch over to 1.34 just yet. Can you give
that one a try and see how it fares?
I'm guessing that not using <*,*,*> instead of just <*,*> would fail if
using a custom allocator, right? I haven't the need for that yet, but it
sounds like a good reason to adjust everything to match.
Updated visualizer:
;---------------------------------------------------------------------------
; boost::ptr_list
;---------------------------------------------------------------------------
boost::ptr_list<*,*,*>{
children
(
#list
(
head : ($c.c_._Myhead->_Next),
size : $c.c_._Mysize,
next : _Next
) : ($T1*)$e._Myval
)
preview
(
#(
"[",
$e._Mysize,
"](",
#list
(
head : $c.c_._Myhead->_Next,
size : $c.c_._Mysize,
next : _Next
) : ($T1*)$e._Myval,
")"
)
)
}
-- Bill --
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net