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

On Tue, Jan 8, 2013 at 4:17 PM, Sean Silva <silvas at purdue.edu>
wrote:
> On Tue, Jan 8, 2013 at 6:45 PM, Chris Lattner <clattner at apple.com>
wrote:
>> some version of GCC and later (linux folks should pick?)
>
> 4.6 is the official compiler on Ubuntu 12.04 (released 04/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. 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.)

Jeffrey

On Tue, Jan 8, 2013 at 7:26 PM, Jeffrey Yasskin <jyasskin at googlers.com>
wrote:
> 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.
Ah, I wasn't aware that it wasn't mostly stabilized. As you pointed
out, this isn't critical, so we don't need to rush it then.
> 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.)
It's not critical. That was mostly a side note about the "code
cleanup" aspect of Chris's message. It has come up during LLD
development so I though it might be worth putting out there.

-- Sean Silva

The main issue I see is for users who are stuck on ancient compilers for
historical/dependency reasons.  I know of build systems that still use
Ubuntu 8.04 and Red Hat Enterprise 4, because the effort to convert
outweighs the current benefits.

That said, I would be very much in favor of introducing C++11, provided a
compiler baseline is well established.  I agree with Sean that GCC 4.6 is
the latest we could reasonably go.


On Tue, Jan 8, 2013 at 7:37 PM, Sean Silva <silvas at purdue.edu> wrote:
> On Tue, Jan 8, 2013 at 7:26 PM, Jeffrey Yasskin <jyasskin at
googlers.com>
> wrote:
> > 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.
>
> Ah, I wasn't aware that it wasn't mostly stabilized. As you pointed
> out, this isn't critical, so we don't need to rush it then.
>
> > 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.)
>
> It's not critical. That was mostly a side note about the "code
> cleanup" aspect of Chris's message. It has come up during LLD
> development so I though it might be worth putting out there.
>
> -- Sean Silva
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130108/0edd72b6/attachment.html>

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

-Chris

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

Chris Lattner <clattner at apple.com> writes:
> 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.
That's _really_ unfortunate.  I've found range-based for gets one
thinking a different way about how to present data.  The range concept
tends to propagate and lots of potential bug sites get cleaned up.  It
can be done incrementally with no problem, but the exercise of
converting a class to provide a range interface is quite instructive.

                          -David