search for: foo_begin

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

.../2012), which is the 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. jyass...

...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 w...

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...

...39;s getting 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...

...ears desktop support 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 w...

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_al...