search for: iterator_categori

Displaying 6 results from an estimated 6 matches for "iterator_categori".

Did you mean: iterator_category
2008 Jul 23
0
[LLVMdev] GEP::getIndexValid() with other iterators
Hi Chris, > What flavor of iterators do you want to pass in? vector or > smallvector? If so, a pointer to the first element + extents is fine. I was passing a std::vector in. And you are quite right, first element + size works like a charm. Since I am using a vector of uint64_t's instead of Value*, I did need to add an extra version of getIndexedType(), taking a uint64_t* instead
2008 Jul 23
2
[LLVMdev] GEP::getIndexValid() with other iterators
On Jul 22, 2008, at 11:54 PM, Matthijs Kooijman wrote: > Hi Chris, > > >> I'd prefer to not turn this into a template. Why not just define a >> version that takes an array of uint64_t's or something like that? > because I want to be able to pass in iterators. I could define a > version that > takes std<uint64_t>::iterators, but next thing we know, we
2007 Jul 03
0
[LLVMdev] API design
On Tuesday 03 July 2007 10:58, David Greene wrote: > > Here's a different suggestion that cloning all the code. Instead of > > doing that, why not add a new (templated) CallInst ctor, one which is > > very trivial. Then you could put the conditional code in it (to detect > > an empty range) and call into the non-inline stuff we already have. > > > > It
2007 Jul 03
4
[LLVMdev] API design
On Tuesday 03 July 2007 00:44, Chris Lattner wrote: > On Mon, 2 Jul 2007, David A. Greene wrote: > >>> - Changing the API > >>> a) Template it to take two iterators. This causes code size bloat. > > > > This seems like the right solution to me. Unless llvm is running on > > extremely limited memory embedded systems, the extra code space > >
2007 Jul 04
1
[LLVMdev] API design (and Boost and tr1)
On Monday 02 July 2007 23:24, David A. Greene wrote: > > > - Changing the API > > > a) Template it to take two iterators. This causes code size bloat. > > This seems like the right solution to me. Unless llvm is running on > extremely limited memory embedded systems, the extra code space > shouldn't be an issue. It turns out this wasn't quite a simple as
2007 Jul 03
4
[LLVMdev] API design
On Monday 02 July 2007 16:26, Chris Lattner wrote: > On Sun, 1 Jul 2007, Nick Lewycky wrote: > > I've been running LLVM with _GLIBCXX_DEBUG (extra checks) turned on to > > see what would happen, and it's been a complete disaster. Well, that's a bit harsh, isn't it? It's finding bugs, just like it's supposed to. :) I believe I've started to run into