search for: foo_end

On Mar 2, 2014, at 10:47 PM, Chandler Carruth <chandlerc at google.com> wrote: >> I'm not aware of the prior art or standards are here, but I think that a global reverse() adapter is the way to go. Likewise, we should have a standard "enumerate()" adaptor like python. >> >> I definitely prefer the global adaptor pattern. As for prior art, I had played with

...he latest Long Term Support release (which come out every 2 years, with 3 years desktop support and 5 years server support), so I wouldn't push farther than that on Linux for the time being. Another thing to bring up is that we have a lot of classes which have method pairs `foo_begin()` and `foo_end()` (e.g. `Function::arg_{begin,end}()`). These don't play nice with range-for loops (we are already seeing this come up in LLD). We probably should adopt some lightweight "range" class and a naming convention (`foo_all()`?) that will interact well with range-for. jyasskin, you have so...

...ase (which come out every 2 years, > with 3 years desktop support and 5 years server support), so I > wouldn't push farther than that on Linux for the time being. > > > > Another thing to bring up is that we have a lot of classes which have > method pairs `foo_begin()` and `foo_end()` (e.g. > `Function::arg_{begin,end}()`). These don't play nice with range-for > loops (we are already seeing this come up in LLD). We probably should > adopt some lightweight "range" class and a naming convention > (`foo_all()`?) that will interact well with range-for. j...

I flipped the build systems to use C++11 today by default. Nothing seems to have broken, folks seem happy, and the bots are making good progress. I plan to slowly remove support for building in C++98 mode over the weekend and watch the bots to see if there are any that were forcing things in the other direction. If all goes well, its open season. I've got a bunch of the basic cleanup

On Jan 8, 2013, at 4:26 PM, Jeffrey Yasskin <jyasskin at googlers.com> wrote: >> Another thing to bring up is that we have a lot of classes which have >> method pairs `foo_begin()` and `foo_end()` (e.g. >> `Function::arg_{begin,end}()`). These don't play nice with range-for >> loops (we are already seeing this come up in LLD). We probably should >> adopt some lightweight "range" class and a naming convention >> (`foo_all()`?) that will interact well w...

...the range though, just like Function::getArgumentList() returns the argument list. > For example, you might iterate over operands, and assign through the iterator to mutate them. > > Really, these operate as range-views over some sequence. It seems particularly easy to teach foo_begin(), foo_end() -> foos() as well. That's a very objective-c thing to do :-), they use the pattern foo() and setFoo() for the getter and setter, respectively (and the naming is baked into the property model). I don't feel strongly against it, but we pretty consistently use the Java style 'get...

...unction say foo(), and am using a function call to foo(); before and after the hot spots in the code to act as a marker for me in the assembly code. I then would like to use the SCC call graph pass in the code and only extract the signature features for blocks which come between two foo_start() and foo_end() function calls. Can anyone please comment on how I can implement this, I am relatively new to llvm, but Im guessing if I need generate a pass which can show me the whole CFG in a stack and then do analysis of different blocks. Maybe inherit a pass from SCCCallgraphPass and BlockGraphPass? Thank...

...rt and 5 years server support), so I > wouldn't push farther than that on Linux for the time being. Does 4.6 work sufficiently for C++11? I haven't used it in quite a while. > Another thing to bring up is that we have a lot of classes which have > method pairs `foo_begin()` and `foo_end()` (e.g. > `Function::arg_{begin,end}()`). These don't play nice with range-for > loops (we are already seeing this come up in LLD). We probably should > adopt some lightweight "range" class and a naming convention > (`foo_all()`?) that will interact well with range-for. j...

It's seems like a quiet and peaceful day, lets stir things up a bit :) How crazy would it be for us to start using basic C++'11 language features (but not C++'11 library features) in LLVM: things like auto, rvalue-refs, lambdas, etc? I think that we can keep things well defined with a few simple requirements: language features must be supported by MSVC 2010 and later, some version of

On Tue, Jan 8, 2013 at 6:23 PM, Chris Lattner <clattner at apple.com> wrote: > On Jan 8, 2013, at 4:26 PM, Jeffrey Yasskin <jyasskin at googlers.com> wrote: >>> Another thing to bring up is that we have a lot of classes which have >>> method pairs `foo_begin()` and `foo_end()` (e.g. >>> `Function::arg_{begin,end}()`). These don't play nice with range-for >>> loops (we are already seeing this come up in LLD). We probably should >>> adopt some lightweight "range" class and a naming convention >>> (`foo_all()`?) that will...