[LLVMdev] Using C++'11 language features in LLVM itself
Justin Holewinski
justin.holewinski at gmail.com
Mon Jan 14 10:40:06 PST 2013
On Mon, Jan 14, 2013 at 1:31 PM, Matthieu Monrocq <
matthieu.monrocq at gmail.com> wrote:
>
>
> On Sun, Jan 13, 2013 at 9:59 PM, Sean Silva <silvas at purdue.edu> wrote:
>
>> On Sun, Jan 13, 2013 at 2:10 PM, Matthieu Monrocq
>> <matthieu.monrocq at gmail.com> wrote:
>> > gcc 4.5, MSVC 10, clang 3.1
>> > - decltype v1.0 [1] + late specified return type
>> > - lambda v1.0 [2]
>> > - local types as template arguments
>> > - r-value 2.0 [3]
>> > - static_assert
>> > - built-in type traits
>>
>> This isn't very encouraging. Anecdotally from what I've seen in LLD
>> (whose C++11 feature use is bounded only by MSVC 2012), the features
>> that get the most mileage by a large margin are `auto`, range-for, and
>> `nullptr`, along with library offerings like unique_ptr<>. Just based
>> on that, the churn and overhead of imposing new build requirements
>> doesn't seem worth it at the moment.
>>
>> -- Sean Silva
>>
>
> Actually, MSVC 10 supports auto as proposed in n1984, which did not yet
> removed "auto" as a storage specifier. This is not too surprising since
> auto and decltype go hand in hand functionality wise and I am sorry I
> missed it.
>
> Therefore, given the list above, the gcc 4.5, MSVC 10 combination provides
> both "auto/decltype" and sufficient r-value support for unique_ptr<> (which
> is part of the built-in type traits part I believe). range-for and nullptr
> are unfortunately not supported with those.
IMO, "auto" alone is enough to make many of LLVM's for loops much more
readable.
>
>
> -- Matthieu
>
> _______________________________________________
> 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/20130114/4a19d962/attachment.html>
More information about the llvm-dev
mailing list