Re: Re: Compiler version
On Thursday 28 June 2012 00:27:08 Ivan Cukic wrote: > > Can you explain why you need a more modern version, I see a good analysis > > of what the current situation regarding compiler availability but i fail > > to see why we need a newer compiler. > > For me, the main reasons for this request are: > - lambdas (gcc 4.5) > - variadic templates (4.3 / 4.4) > - auto (4.4) > - nullptr (4.6) > - =default, =delete (4.4) > - explicit override (4.7) > - unique/shared_ptr (?? works in 4.5) > > nullptr and override are really useful while developing, even as enabled-if- > possible - so I can live without hard-requiring them (macro-based switch), > but lambdas are not so easily replaceable while making the life much easier > and a lot of methods shorter :) how would nullptr be useful with a macro-based switch? I actually want to do a sed s/NULL/nullptr/g on the complete code base. And I hope everyone can understand that :-) Other features I really want to make use of is auto and lambdas. I think both will help to increase the readability and maintainability of the code base. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: Re: Compiler version
On Thursday 28 June 2012 00:55:15 Ivan Cukic wrote: > Workspace applications (kwin, activity manager, and more) are not meant for > /strange/ platforms like windows/mac, so they should belong to the later > category. What about freebsd? Personally I am not willing to support that platform anymore if it would mean that we have to restrict ourself to an outdated gcc version. Reasons why in general I would find it acceptable to drop support for non-linux in KWin are outlined in a recent discussion on plasma mailing list [1]. @Raphael any idea about that? Cheers Martin Gräßlin [1] http://mail.kde.org/pipermail/plasma-devel/2012-June/019955.html signature.asc Description: This is a digitally signed message part.
Re: Compiler version
> how would nullptr be useful with a macro-based switch? I actually want to do > a sed s/NULL/nullptr/g on the complete code base. And I hope everyone can > understand that :-) Well, nullptr is a compile time check, right (like explicit override)? So, you compile your code with a compiler that supports it, making your code safe in that aspect, while someone could still compile the code with an older compiler. It doesn't help in the cases where there is an ambigous resolution int vs ptr, but it can be done if needed. [1] > What about freebsd? Personally I am not willing to support that platform > anymore if it would mean that we have to restrict ourself to an outdated gcc They are moving towards clang 3.1 for FreeBSD 10. So, I don't see them as a problem in this case - they should become compliant in the version that will ship 4.10. http://lists.freebsd.org/pipermail/freebsd-stable/2012-May/067486.html Cheerio, Ivan [1] http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/nullptr -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun
Re: Compiler version
On quinta-feira, 28 de junho de 2012 10.14.03, Ivan Cukic wrote: > Well, nullptr is a compile time check, right (like explicit override)? So, > you compile your code with a compiler that supports it, making your code > safe in that aspect, while someone could still compile the code with an > older compiler. Qt 5 has Q_NULLPTR that expands to nullptr on C++11 and 0 otherwise. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Compiler version
Il 27/06/2012 23:41, Martin Gräßlin ha scritto: On Wednesday 27 June 2012 23:28:30 Ivan Čukić wrote: Hi all, I've tested the waters some time ago [1] what would people say if we started asking for more modern compilers. I've stated there I'll start the discussion on k-c-d once we branch out 4.9, so I'm doing as promised. The post was only about kactivities, but the same could be applied to more stuff. Thanks for bringing up the issue, I actually intended to write a similar mail tomorrow to request that applications are allowed to require compilers supporting C++11 features. actually for stability and feature related to c++11 gcc-4.7 is nearly the minimum, but in my experience gcc-4.7 is still a bit rough so +1 for gcc-4.6 So +1 for a minimum requirement of gcc 4.6 or clang 3.1 diff between http://gcc.gnu.org/gcc-4.6/cxx0x_status.html and http://gcc.gnu.org/gcc-4.7/cxx0x_status.html --- cxx0x-gcc-46.txt2012-06-28 14:33:15.058728078 +0200 +++ cxx0x-gcc-47.txt2012-06-28 14:33:16.198733511 +0200 @@ -1,27 +1,27 @@ - Status of Experimental C++0x Support in GCC 4.6 + Status of Experimental C++11 Support in GCC 4.7 - GCC provides experimental support for the upcoming ISO C++ - standard, C++0x. This support can be enabled with the -std=c++0x - or -std=gnu++0x compiler options; the former disables GNU - extensions. + GCC provides experimental support for the 2011 ISO C++ standard. + This support can be enabled with the -std=c++11 or -std=gnu++11 + compiler options; the former disables GNU extensions. - GCC's C++0x mode tracks the C++0x working paper drafts produced - by the ISO C++ committee, available on the ISO C++ committee's + GCC's C++11 mode implements much of the C++11 standard produced + by the ISO C++ committee. The standard is available from various + national standards bodies; working papers from before the + release of the standard are available on the ISO C++ committee's web site at [1]http://www.open-std.org/jtc1/sc22/wg21/. Since - this standard is still being extended and modified, the feature - set provided by the experimental C++0x mode may vary greatly - from one GCC version to another. No attempts will be made to - preserve backward compatibility with C++0x features whose - semantics have changed during the course of C++0x - standardization. + this standard has only recently been completed, the feature set + provided by the experimental C++11 mode may vary greatly from + one GCC version to another. No attempts will be made to preserve + backward compatibility with C++11 features whose semantics have + changed during the course of C++11 standardization. - The following table lists which C++0x features are supported in - this release of GCC. For more information about C++0x support in - GCC, please see the [2]C++0x in GCC project page. + The following table lists which C++11 features are supported in + this release of GCC. For more information about C++11 support in + GCC, please see the [2]C++11 in GCC project page. +--+ |Language Feature | Proposal | Available in | - | | |GCC 4.6?| + | | |GCC 4.7?| |-+---+| | Rvalue references | [3]N2118 | Yes | |-+---+| @@ -30,7 +30,7 @@ | Initialization of class objects | [5]N1610 | Yes | | by rvalues | || |-+---+| - | Non-static data member | [6]N2756 | No | + | Non-static data member | [6]N2756 | Yes | | initializers| || |-+---+| | Variadic templates | [7]N2242 | Yes | @@ -52,7 +52,7 @@ | New function declarator | [14]N2541 | Yes | | syntax | || |-+---+| - | New wording for C++0x lambdas | [15]N2927 | Yes | + | New wording for C++11 lambdas | [15]N2927 | Yes | |-+---+| | Declared type of an expression | [16]N2343 | Yes | |-+---+| @@ -64,7 +64,7 @@ | Solving the SFINAE problem for | [19]DR339 | Yes | | expressions | || |-+---+| - | Template aliases| [20]N2258 | No
Re: Compiler version
On quinta-feira, 28 de junho de 2012 14.38.37, viv...@gmail.com wrote: > actually for stability and feature related to c++11 gcc-4.7 is nearly > the minimum, but in my experience gcc-4.7 is still a bit rough so +1 for > gcc-4.6 That's nonsense. C++11 support in GCC 4.5 and 4.6 is just fine. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Compiler version
Am Donnerstag, 28. Juni 2012, 10:20:42 schrieb Thiago Macieira: > On quinta-feira, 28 de junho de 2012 10.14.03, Ivan Cukic wrote: > > Well, nullptr is a compile time check, right (like explicit override)? So, > > you compile your code with a compiler that supports it, making your code > > safe in that aspect, while someone could still compile the code with an > > older compiler. > > Qt 5 has Q_NULLPTR that expands to nullptr on C++11 and 0 otherwise. Is there any chance that these macros will find their way into Qt4? I don't mean that they should be used by Qt itself everywhere (or at all), but providing them would allow an easy forward-compatible way of introducing this stuff. That may not really help for KDE (or we need to require 4.8.3 or need to ship them ourself) but for other stuff out there this would be an improvement that you basically get for free. Eike signature.asc Description: This is a digitally signed message part.
Re: Compiler version
On Thu, Jun 28, 2012 at 1:09 PM, Rolf Eike Beer wrote: > Am Donnerstag, 28. Juni 2012, 10:20:42 schrieb Thiago Macieira: >> On quinta-feira, 28 de junho de 2012 10.14.03, Ivan Cukic wrote: >> > Well, nullptr is a compile time check, right (like explicit override)? So, >> > you compile your code with a compiler that supports it, making your code >> > safe in that aspect, while someone could still compile the code with an >> > older compiler. >> >> Qt 5 has Q_NULLPTR that expands to nullptr on C++11 and 0 otherwise. > > Is there any chance that these macros will find their way into Qt4? I don't > mean that they should be used by Qt itself everywhere (or at all), but > providing them would allow an easy forward-compatible way of introducing this > stuff. That may not really help for KDE (or we need to require 4.8.3 or need > to > ship them ourself) but for other stuff out there this would be an improvement > that you basically get for free. > > Eike That'd be hard, since there's no Qt 4.9 planned, but a simple macro that won't break stuff can be made on KDE api to define Q_NULLPTR ( implications? ) when it's doesn't exists. Thiago, on C++ 0 and (void*) 0 are the same thing? I know that on C they aren't, and I didn't found the information easily on the web. Tomaz
Re: Compiler version
Martin Gräßlin writes: > What about freebsd? Personally I am not willing to support that platform > anymore if it would mean that we have to restrict ourself to an outdated gcc > version. Reasons why in general I would find it acceptable to drop support for > non-linux in KWin are outlined in a recent discussion on plasma mailing list > [1]. > > @Raphael any idea about that? In the future, the idea is to use clang instead of gcc by default, but I wouldn't count on that for this decision: there's still work to do, and even when a new FreeBSD comes out with clang as the default compiler we'll still have to support a few older releases with gcc 4.2 anyway. That said, it wouldn't really be a problem if a newer gcc was required; we do have many different gcc release series in the ports system (including 4.7.x and 4.8 snapshots) and in the end users will simply have to use them to build KDE instead. As for the Plasma post, there's ongoing work towards having recent X.org releases, as well as improving support for KMS and things like that (AFAICT the NVidia binary blog probably already works fine, and I am using KMS with an Intel graphics card myself with Mesa 7.11.2, with updates on the way). The KMS code might not apply to all supported FreeBSD versions, but this is something that will be automatically solved with time -- other than that, I don't really know what difference it all would make for KWin and workspace in general (I'm not subscribed to plasma-devel, but I can do that or you guys can CC me if you prefer to continue this part of the discussion elsewhere).
Re: Compiler version
On quinta-feira, 28 de junho de 2012 13.37.14, Tomaz Canabrava wrote: > Thiago, on C++ 0 and (void*) 0 are the same thing? I know that on C > they aren't, and I didn't found the information easily on the web. No, they are not. In C++, 0 can be cast to any pointer, but so can 0L and false. However, (void*)0 is a null of type void* and that cannot be cast to any pointer type except for void *. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Compiler version
On quinta-feira, 28 de junho de 2012 18.09.22, Rolf Eike Beer wrote: > Am Donnerstag, 28. Juni 2012, 10:20:42 schrieb Thiago Macieira: > > On quinta-feira, 28 de junho de 2012 10.14.03, Ivan Cukic wrote: > > > Well, nullptr is a compile time check, right (like explicit override)? > > > So, > > > you compile your code with a compiler that supports it, making your > > > code > > > safe in that aspect, while someone could still compile the code with an > > > older compiler. > > > > Qt 5 has Q_NULLPTR that expands to nullptr on C++11 and 0 otherwise. > > Is there any chance that these macros will find their way into Qt4? I don't > mean that they should be used by Qt itself everywhere (or at all), but > providing them would allow an easy forward-compatible way of introducing > this stuff. That may not really help for KDE (or we need to require 4.8.3 > or need to ship them ourself) but for other stuff out there this would be > an improvement that you basically get for free. There's no plan in backporting features. But you can take Qt 5's qcompilerdetection.h's bottom part about C++11. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Review Request: Remove image/x-wmf and image/x-xfig from image thumbnailer's supported mimetypes
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105371/#review15238
---
Ship it!
Makes sense, kill them and backport as much as you want
- Albert Astals Cid
On June 28, 2012, 5:39 a.m., Friedrich W. H. Kossebau wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105371/
> ---
>
> (Updated June 28, 2012, 5:39 a.m.)
>
>
> Review request for KDE Runtime.
>
>
> Description
> ---
>
> The declared-as-supported mimetypes of the image thumbnailer are quite broad,
> assuming a lot of QImageIOPlugin existing and installed. But at least for
> x-fig and wmf there are no such plugins known, by what I can tell. So the
> claim of support is wrong.
>
> Worse: There is no safe way to install an own, better thumbnailer, that one
> would be only chosen by pure luck. Reason is that the thumbnail creation
> invoking code just greps the first in the list of found thumbnail plugins,
> see the code in kde-runtime/kioslave/thumbnail/thumbnail.cpp:
>
> QString ThumbnailProtocol::pluginForMimeType(const QString& mimeType) {
> KService::List offers = KMimeTypeTrader::self()->query( mimeType,
> QLatin1String("ThumbCreator"));
> if (!offers.isEmpty()) {
> KService::Ptr serv;
> serv = offers.first();
> return serv->library();
> }
> [...]
>
> E.g. trying to install an own xfig thumbnailer failed for me.
>
> While changing the above code to use KMimeTypeTrader::preferredService(...)
> surely might be also good to do, I have no idea about the impact.
> For now I just would like to have those two wrong claims removed.
>
> Okay to backport to 4.9 (and 4.8)?
>
>
> Diffs
> -
>
> kioslave/thumbnail/imagethumbnail.desktop 53c9a33
>
> Diff: http://git.reviewboard.kde.org/r/105371/diff/
>
>
> Testing
> ---
>
>
> Thanks,
>
> Friedrich W. H. Kossebau
>
>
Re: Review Request: Remove image/x-wmf and image/x-xfig from image thumbnailer's supported mimetypes
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105371/#review15240
---
This review has been submitted with commit
2e094436a6cf05d21223c19d234ef1b2db2c by Friedrich W. H. Kossebau to branch
master.
- Commit Hook
On June 28, 2012, 5:39 a.m., Friedrich W. H. Kossebau wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105371/
> ---
>
> (Updated June 28, 2012, 5:39 a.m.)
>
>
> Review request for KDE Runtime.
>
>
> Description
> ---
>
> The declared-as-supported mimetypes of the image thumbnailer are quite broad,
> assuming a lot of QImageIOPlugin existing and installed. But at least for
> x-fig and wmf there are no such plugins known, by what I can tell. So the
> claim of support is wrong.
>
> Worse: There is no safe way to install an own, better thumbnailer, that one
> would be only chosen by pure luck. Reason is that the thumbnail creation
> invoking code just greps the first in the list of found thumbnail plugins,
> see the code in kde-runtime/kioslave/thumbnail/thumbnail.cpp:
>
> QString ThumbnailProtocol::pluginForMimeType(const QString& mimeType) {
> KService::List offers = KMimeTypeTrader::self()->query( mimeType,
> QLatin1String("ThumbCreator"));
> if (!offers.isEmpty()) {
> KService::Ptr serv;
> serv = offers.first();
> return serv->library();
> }
> [...]
>
> E.g. trying to install an own xfig thumbnailer failed for me.
>
> While changing the above code to use KMimeTypeTrader::preferredService(...)
> surely might be also good to do, I have no idea about the impact.
> For now I just would like to have those two wrong claims removed.
>
> Okay to backport to 4.9 (and 4.8)?
>
>
> Diffs
> -
>
> kioslave/thumbnail/imagethumbnail.desktop 53c9a33
>
> Diff: http://git.reviewboard.kde.org/r/105371/diff/
>
>
> Testing
> ---
>
>
> Thanks,
>
> Friedrich W. H. Kossebau
>
>
Re: Review Request: Remove image/x-wmf and image/x-xfig from image thumbnailer's supported mimetypes
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105371/#review15241
---
This review has been submitted with commit
9145b51c1cc4e9ecd273e8eb41de1bbcdd607e35 by Friedrich W. H. Kossebau to branch
KDE/4.8.
- Commit Hook
On June 28, 2012, 5:39 a.m., Friedrich W. H. Kossebau wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105371/
> ---
>
> (Updated June 28, 2012, 5:39 a.m.)
>
>
> Review request for KDE Runtime.
>
>
> Description
> ---
>
> The declared-as-supported mimetypes of the image thumbnailer are quite broad,
> assuming a lot of QImageIOPlugin existing and installed. But at least for
> x-fig and wmf there are no such plugins known, by what I can tell. So the
> claim of support is wrong.
>
> Worse: There is no safe way to install an own, better thumbnailer, that one
> would be only chosen by pure luck. Reason is that the thumbnail creation
> invoking code just greps the first in the list of found thumbnail plugins,
> see the code in kde-runtime/kioslave/thumbnail/thumbnail.cpp:
>
> QString ThumbnailProtocol::pluginForMimeType(const QString& mimeType) {
> KService::List offers = KMimeTypeTrader::self()->query( mimeType,
> QLatin1String("ThumbCreator"));
> if (!offers.isEmpty()) {
> KService::Ptr serv;
> serv = offers.first();
> return serv->library();
> }
> [...]
>
> E.g. trying to install an own xfig thumbnailer failed for me.
>
> While changing the above code to use KMimeTypeTrader::preferredService(...)
> surely might be also good to do, I have no idea about the impact.
> For now I just would like to have those two wrong claims removed.
>
> Okay to backport to 4.9 (and 4.8)?
>
>
> Diffs
> -
>
> kioslave/thumbnail/imagethumbnail.desktop 53c9a33
>
> Diff: http://git.reviewboard.kde.org/r/105371/diff/
>
>
> Testing
> ---
>
>
> Thanks,
>
> Friedrich W. H. Kossebau
>
>
Re: Review Request: Remove image/x-wmf and image/x-xfig from image thumbnailer's supported mimetypes
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105371/#review15242
---
This review has been submitted with commit
d93ac7d8f56568ce11bcf0dccd2a98cc009f96b2 by Friedrich W. H. Kossebau to branch
KDE/4.9.
- Commit Hook
On June 28, 2012, 5:39 a.m., Friedrich W. H. Kossebau wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105371/
> ---
>
> (Updated June 28, 2012, 5:39 a.m.)
>
>
> Review request for KDE Runtime.
>
>
> Description
> ---
>
> The declared-as-supported mimetypes of the image thumbnailer are quite broad,
> assuming a lot of QImageIOPlugin existing and installed. But at least for
> x-fig and wmf there are no such plugins known, by what I can tell. So the
> claim of support is wrong.
>
> Worse: There is no safe way to install an own, better thumbnailer, that one
> would be only chosen by pure luck. Reason is that the thumbnail creation
> invoking code just greps the first in the list of found thumbnail plugins,
> see the code in kde-runtime/kioslave/thumbnail/thumbnail.cpp:
>
> QString ThumbnailProtocol::pluginForMimeType(const QString& mimeType) {
> KService::List offers = KMimeTypeTrader::self()->query( mimeType,
> QLatin1String("ThumbCreator"));
> if (!offers.isEmpty()) {
> KService::Ptr serv;
> serv = offers.first();
> return serv->library();
> }
> [...]
>
> E.g. trying to install an own xfig thumbnailer failed for me.
>
> While changing the above code to use KMimeTypeTrader::preferredService(...)
> surely might be also good to do, I have no idea about the impact.
> For now I just would like to have those two wrong claims removed.
>
> Okay to backport to 4.9 (and 4.8)?
>
>
> Diffs
> -
>
> kioslave/thumbnail/imagethumbnail.desktop 53c9a33
>
> Diff: http://git.reviewboard.kde.org/r/105371/diff/
>
>
> Testing
> ---
>
>
> Thanks,
>
> Friedrich W. H. Kossebau
>
>
Re: Compiler version
Il 28/06/2012 16:31, Thiago Macieira ha scritto:
On quinta-feira, 28 de junho de 2012 14.38.37, viv...@gmail.com wrote:
actually for stability and feature related to c++11 gcc-4.7 is nearly
the minimum, but in my experience gcc-4.7 is still a bit rough so +1 for
gcc-4.6
That's nonsense. C++11 support in GCC 4.5 and 4.6 is just fine.
Thiago you work to qt5 which include the c++11 stuff, so probably you
know better than rumors around, must admit that I've spoken by those
rather than an extended experience in the field.
What made me think the rumors were true is:
a) many programs which support to be compiled with c++11 syntax require
gcc-4.7
b) that the resolved/fixed bug list is rather long:
A search for resolved/fixed bugs with 'C++0x' or 'C++11' in the summary
580 bugs found [1]
the same search with gcc-4.7.{0,1,2} as "known to fail" is much shorter:
22 bugs found [2]
feature wise instead the increment in 4.7 seem to be short (there was a
diff in the first mail):
Non-static data member
New wording for C++11 lambdas
Template aliases
Delegating constructors
User-defined literals
Extended friend declarations
Explicit virtual overrides
[1]
http://gcc.gnu.org/bugzilla/buglist.cgi?order=Bug%20Number&short_desc=C%2B%2B0x%20C%2B%2B11&resolution=FIXED&cf_known_to_fail_type=anywords&cf_known_to_work_type=allwords&query_format=advanced&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&short_desc_type=anywordssubstr&product=gcc
[2]
http://gcc.gnu.org/bugzilla/buglist.cgi?order=Bug%20Number&short_desc=C%2B%2B0x%20C%2B%2B11&resolution=FIXED&cf_known_to_fail_type=anywords&cf_known_to_work_type=allwords&query_format=advanced&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&short_desc_type=anywordssubstr&product=gcc&cf_known_to_fail=4.7.0&cf_known_to_fail=4.7.1&cf_known_to_fail=4.7.2
Re: Compiler version
On quinta-feira, 28 de junho de 2012 18.53.03, viv...@gmail.com wrote: > Il 28/06/2012 16:31, Thiago Macieira ha scritto: > > On quinta-feira, 28 de junho de 2012 14.38.37, viv...@gmail.com wrote: > >> actually for stability and feature related to c++11 gcc-4.7 is nearly > >> the minimum, but in my experience gcc-4.7 is still a bit rough so +1 for > >> gcc-4.6 > > > > That's nonsense. C++11 support in GCC 4.5 and 4.6 is just fine. > > Thiago you work to qt5 which include the c++11 stuff, so probably you > know better than rumors around, must admit that I've spoken by those > rather than an extended experience in the field. We may not be talking about the same thing. > What made me think the rumors were true is: > a) many programs which support to be compiled with c++11 syntax require > gcc-4.7 It depends on which C++11 feature you're using. Qt has an #define for each of them so you can know if the compiler supports such a feature. Qt does not require C++11 and will not for many years. What's more, any program requiring full and unrestricted C++11 support will be extremely niche and not very popular until at least 2014. For those of us living in the real world, we have to accept that C++11 support is limited and therefore limit what we use of it. That being the case, GCC 4.5 and 4.6 are more than enough. > b) that the resolved/fixed bug list is rather long: I used GCC 4.5 and 4.6 each for a year and I don't remember any serious bugs with them. There was one bug I reported (I think it was 4.5), which wasn't promptly fixed because it was in C++11 and that was experimental. Another issue I remember, which is definitely non-fatal, is that constexpr variables end up in the .data section instead of the .rodata one in 4.6. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Compiler version
On Thursday, June 28, 2012 09:20:54 PM Thiago Macieira wrote: > On quinta-feira, 28 de junho de 2012 18.53.03, viv...@gmail.com wrote: > > Il 28/06/2012 16:31, Thiago Macieira ha scritto: > > > On quinta-feira, 28 de junho de 2012 14.38.37, viv...@gmail.com wrote: > > >> actually for stability and feature related to c++11 gcc-4.7 is nearly > > >> the minimum, but in my experience gcc-4.7 is still a bit rough so +1 > > >> for > > >> gcc-4.6 > > > > > > That's nonsense. C++11 support in GCC 4.5 and 4.6 is just fine. > > > > Thiago you work to qt5 which include the c++11 stuff, so probably you > > know better than rumors around, must admit that I've spoken by those > > rather than an extended experience in the field. > > We may not be talking about the same thing. > > > What made me think the rumors were true is: > > a) many programs which support to be compiled with c++11 syntax require > > gcc-4.7 > > It depends on which C++11 feature you're using. Qt has an #define for each > of them so you can know if the compiler supports such a feature. > > Qt does not require C++11 and will not for many years. What's more, any > program requiring full and unrestricted C++11 support will be extremely > niche and not very popular until at least 2014. For those of us living in > the real world, we have to accept that C++11 support is limited and > therefore limit what we use of it. > > That being the case, GCC 4.5 and 4.6 are more than enough. > > > b) that the resolved/fixed bug list is rather long: > I used GCC 4.5 and 4.6 each for a year and I don't remember any serious bugs > with them. > > There was one bug I reported (I think it was 4.5), which wasn't promptly > fixed because it was in C++11 and that was experimental. Another issue I > remember, which is definitely non-fatal, is that constexpr variables end up > in the .data section instead of the .rodata one in 4.6. It's probably worth mentioning that there are issues in GCC 4.7 with mixing C++98 and C++11 code on one system. Here's the best discussion of it I could find: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646 I don't pretend to understand all that, so I'm unlikely to be a good source of further answers, but this isn't just theoretical. There are some projects in Ubuntu that were making a lot of use of C++11 features and they stepped all over this once Ubuntu moved to GCC 4.7 (which is standard in the current development release). Scott K
Re: Compiler version
On quinta-feira, 28 de junho de 2012 15.34.31, Scott Kitterman wrote: > It's probably worth mentioning that there are issues in GCC 4.7 with mixing > C++98 and C++11 code on one system. Here's the best discussion of it I > could find: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646 > > I don't pretend to understand all that, so I'm unlikely to be a good source > of further answers, but this isn't just theoretical. There are some > projects in Ubuntu that were making a lot of use of C++11 features and they > stepped all over this once Ubuntu moved to GCC 4.7 (which is standard in > the current development release). > > Scott K We don't care. Qt code does not use the Standard Library for anything. During the discussion last year, we were almost about to permit it again. But I guess that we'll have to keep the ban on it for another 5 years now. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
