Displaying 5 results from an estimated 5 matches for "insn_end".
2004 Apr 23
2
[LLVMdev] subtle problem with inst_iterator
...gt; The reason why we have it return pointers right now is to populate
> worklists, which allows us to do:
>
> std::set<Instruction*> WorkList(inst_begin(F), inst_end(F));
Maybe this can be rewritten like;
std::set<Instruction*> WorkList;
std::transform(insn_begin(F), insn_end(F),
inserter(WorkList, WorkList.begin(), take_address);
given proper definition of take_addres. Or maybe manual initialization will
okay.
So, if you think making inst_iterator's operator* return reference to
instruction is better than making it return reference to pointer, I can take
a...
2004 Apr 23
0
[LLVMdev] subtle problem with inst_iterator
...ointers right now is to populate
> > worklists, which allows us to do:
> >
> > std::set<Instruction*> WorkList(inst_begin(F), inst_end(F));
>
> Maybe this can be rewritten like;
>
> std::set<Instruction*> WorkList;
> std::transform(insn_begin(F), insn_end(F),
> inserter(WorkList, WorkList.begin(), take_address);
>
> given proper definition of take_addres. Or maybe manual initialization will
> okay.
>
> So, if you think making inst_iterator's operator* return reference to
> instruction is better than making it return referen...
2004 Apr 23
0
[LLVMdev] subtle problem with inst_iterator
On Fri, 23 Apr 2004, Vladimir Prus wrote:
> and since result of *it is considered to be rvalue it can't be accepted by
> this operator. The complete discussion is in
>
> http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1385.htm
>
> I'd suggest to apply the following patch which makes operator* return
> reference to pointer. It makes my code compile and the rest
2004 Apr 27
2
[LLVMdev] subtle problem with inst_iterator
...t; > worklists, which allows us to do:
> > >
> > > std::set<Instruction*> WorkList(inst_begin(F), inst_end(F));
> >
> > Maybe this can be rewritten like;
> >
> > std::set<Instruction*> WorkList;
> > std::transform(insn_begin(F), insn_end(F),
> > inserter(WorkList, WorkList.begin(), take_address);
> >
> > given proper definition of take_addres. Or maybe manual initialization
> > will okay.
> >
> > So, if you think making inst_iterator's operator* return reference to
> > instruction is b...
2004 Apr 23
2
[LLVMdev] subtle problem with inst_iterator
Hello, I think there's a rather subtle problem with the inst_iterator. It
declares its iterator category as std::bidirectional_iterator_tag but C++
standard requirements for forward iterator (which are included in
requirements for bidirection iterator), say that the type of expression
*r;
should be T&, where 'r' is the iterator and T is its value type. The
inst_iterator,