llvm dev - Jan 2013 - [LLVMdev] Using C++'11 language features in LLVM itself

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 interact well with range-for. jyasskin,
you
>>> have some standards proposals for such a class, maybe you could try
>>> bringing that into tree?
>>
>> The C++ proposal changes rapidly. While it would be great to get usage
>> experience from LLVM in order to inform the C++ proposal, I don't
have
>> "what will eventually be in C++" to propose for LLVM. Well,
I'd expect
>> some "range<IteratorType>" template with .begin() and
.end() methods,
>> but I don't even know what name that template will have.
>>
>> I'm not sure this part of the discussion is on-topic for
Chris's
>> thread, since it's not related to a potential problem with enabling
>> C++ language features. (Not having a range type doesn't make
>> range-based for loops fail to compile on some platform, it just makes
>> them slightly less useful.)
>
> One other specific problem with this is that (I'm told) MSVC 2010
doesn't support range-based for loops.  I don't think it is reasonable
to require windows users to be on MSVC 2012.  :-(
I suspect you're right about that, but I'd appreciate if some MSVC
users would speak up here. We shouldn't hold back on using range-based
for loops if all our MSVC users are happy to move to MSVC 2012
(assuming no problems with other platforms).

>> One other specific problem with this is that (I'm told) MSVC 2010
doesn't support range-based for loops.  I don't think it is reasonable
to require windows users to be on MSVC 2012.  :-(
> I suspect you're right about that, but I'd appreciate if some MSVC
> users would speak up here. We shouldn't hold back on using range-based
> for loops if all our MSVC users are happy to move to MSVC 2012
> (assuming no problems with other platforms).
>
For our works project, we are still stuck on MSVC 2005 and MSVC 2010
(our software is a binary plugin to established products). Admittedly,
we are still sitting on LLVM 2.8 with patches from 2.9 (2.9 wouldn't
compile in MSVC 2010 for x64) . We want to move to current LLVM (not
least for the NVPTX and AMDIL targets), but have not yet had the
available man hours to do so.

Peter N

On Jan 8, 2013, at 8:09 PM, Peter Newman <peter at uformia.com>
wrote:
>>> One other specific problem with this is that (I'm told) MSVC
2010 doesn't support range-based for loops.  I don't think it is
reasonable to require windows users to be on MSVC 2012.  :-(
>> I suspect you're right about that, but I'd appreciate if some
MSVC
>> users would speak up here. We shouldn't hold back on using
range-based
>> for loops if all our MSVC users are happy to move to MSVC 2012
>> (assuming no problems with other platforms).
>> 
> For our works project, we are still stuck on MSVC 2005 and MSVC 2010
> (our software is a binary plugin to established products). Admittedly,
> we are still sitting on LLVM 2.8 with patches from 2.9 (2.9 wouldn't
> compile in MSVC 2010 for x64) . We want to move to current LLVM (not
> least for the NVPTX and AMDIL targets), but have not yet had the
> available man hours to do so.
Ok.  Unfortunately, I don't think it makes sense for the general community
to bend over backwards to support VC2005 anymore.  We're talking about LLVM
3.3 here (at the earliest), is there a strong reason you couldn't move to
VC2010 by whenever you move up to LLVM 3.3?

-Chris

> I'd appreciate if some MSVC
> users would speak up here. We shouldn't hold back on using range-based
> for loops if all our MSVC users are happy to move to MSVC 2012
> (assuming no problems with other platforms).
FWIW we're currently using 2010 but expect to move to 2012 later this year.
--paulr