[prev in list] [next in list] [prev in thread] [next in thread]
List: kdevelop-devel
Subject: Re: policy on c++11 in source code
From: "henry7638 () gmail ! com" <hank () millerfarm ! com>
Date: 2011-10-21 8:35:21
Message-ID: 3b4cb7fd-8da1-44b8-ab70-13e4b5c4f1ba () email ! android ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Milian Wolff <mail@milianw.de> wrote:
> Four years is a bit much. Maybe if we'd use all of C++11 but imo noone
> suggests that. Rather it's about cherry-picking nice features that are
> available already and work well and improve productivity. >
>
> Anyhow, I also think that a year will at least be required. Or well,
> we'll
> have to wait until the BSD guys have ditched the outdated GCC in favor
> of a
> current CLang ;-)
>
If we intend to wait until all the world is ready for C++11, then 4 years is \
optimistic. Not only does Clang need to become ready, but also we need to wait for \
the current releases to become non-supported. BSD supports current ports running a \
couple versions back.
However we do not have to wait. FreeBSD has support for installing latter versions of \
gcc. Default is /usr/bin/gcc. We can use /usr/local/bin/gcc47, it just needs to \
explicate that we need this. If we find a subset of C++11 that is already supported \
(something the gcc 4.5, clang 2.9, visual studio 2010, etc), documenting the minimum \
required compiler is the minimum required.
Ideally someone would write a cmake macro to require some minimum compiler based on \
features, that would modify the current macro to keep looking if the default compiler \
isn't enough. Then add some analysis tools (krazy?) To give warnings if someone \
introduces code that isn't in the allowed subset.
The above would help all C++ projects, so feel free to suggest the idea to someone \
outside kdevelop who might better know how to pull it off.
I think the above is the right focus for efforts to get C++11 used for now. I don't \
know how to find the right subset. Compilers may have something checked off as \
working, but they missed some obscure case. Compilers are known to have released \
support before the standard, only to have the standard be different. Both situations \
to watch for.
( what follows are BSD related, and not really related to the important part of the \
discussion. Feel free to stop reading here)
As for clang, FreeBSD already boots when compiled with it, and 15000 ports compile as \
well, but that leaves several thousand that don't: some assume gcc, some hit clang \
bugs. Unknown if there are random breakages in any of the ports that compile. These \
are being worked on.
I don't know what the other BSDs are doing. OpenBSD is looking at pcc as their \
compiler, and then all C++ would come from a user installed compiler not the base \
system. NetBSD needs support for targets that are not in LLVM. Both of the above have \
seen some effort into using Clang though,and might switch directions.
Clang will probably take the longest to get full C++11 support since they have more \
serious known bugs to fix before adding more features. However the supported parts \
are useful.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
[Attachment #5 (text/html)]
<br>
<br>
Milian Wolff <mail@milianw.de> wrote:<br>
<br>
>Four years is a bit much. Maybe if we'd use all of C++11 but imo noone <br>
>suggests that. Rather it's about cherry-picking nice features that are <br>
>available already and work well and improve productivity. ><br>
><br>
>Anyhow, I also think that a year will at least be required. Or well,<br>
>we'll <br>
>have to wait until the BSD guys have ditched the outdated GCC in favor<br>
>of a <br>
>current CLang ;-)<br>
><br>
<br>
If we intend to wait until all the world is ready for C++11, then 4 years is \
optimistic. Not only does Clang need to become ready, but also we need to wait for \
the current releases to become non-supported. BSD supports current ports running a \
couple versions back.<br> <br>
However we do not have to wait. FreeBSD has support for installing latter versions \
of gcc. Default is /usr/bin/gcc. We can use /usr/local/bin/gcc47, it just needs to \
explicate that we need this. If we find a subset of C++11 that is already supported \
(something the gcc 4.5, clang 2.9, visual studio 2010, etc), documenting the minimum \
required compiler is the minimum required.<br> <br>
Ideally someone would write a cmake macro to require some minimum compiler based on \
features, that would modify the current macro to keep looking if the default compiler \
isn't enough. Then add some analysis tools (krazy?) To give warnings if someone \
introduces code that isn't in the allowed subset. <br> <br>
The above would help all C++ projects, so feel free to suggest the idea to someone \
outside kdevelop who might better know how to pull it off. <br> <br>
I think the above is the right focus for efforts to get C++11 used for now. I \
don't know how to find the right subset. Compilers may have something checked \
off as working, but they missed some obscure case. Compilers are known to have \
released support before the standard, only to have the standard be different. Both \
situations to watch for.<br> <br>
( what follows are BSD related, and not really related to the important part of the \
discussion. Feel free to stop reading here)<br> <br>
As for clang, FreeBSD already boots when compiled with it, and 15000 ports compile as \
well, but that leaves several thousand that don't: some assume gcc, some hit \
clang bugs. Unknown if there are random breakages in any of the ports that compile. \
These are being worked on. <br> <br>
I don't know what the other BSDs are doing. OpenBSD is looking at pcc as their \
compiler, and then all C++ would come from a user installed compiler not the base \
system. NetBSD needs support for targets that are not in LLVM. Both of the above \
have seen some effort into using Clang though,and might switch directions. <br> <br>
Clang will probably take the longest to get full C++11 support since they have more \
serious known bugs to fix before adding more features. However the supported parts \
are useful.<br>
-- <br>
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic