C++11 for Experimental Branch?
Hi,
I noticed a bunch of 'for' loops in Liam's code and that got me wondering about using C++11 in the experimental branch as 'auto' is so much nicer that "std::map<SPDocument*,int>::iterator iter". When can we start using C++11?
I noticed that http://wiki.inkscape.org/wiki/index.php/C%2B%2B11 only shows results for one Window's compiler. Is there a test program we can run? Fedora 20 is using GCC 4.8 and clang 3.4; both support 'auto' (GCC since 4.4).
Tav
On Fri, Jun 27, 2014, at 12:03 PM, Tavmjong Bah wrote:
Hi,
I noticed a bunch of 'for' loops in Liam's code and that got me wondering about using C++11 in the experimental branch as 'auto' is so much nicer that "std::map<SPDocument*,int>::iterator iter". When can we start using C++11?
I noticed that http://wiki.inkscape.org/wiki/index.php/C%2B%2B11 only shows results for one Window's compiler. Is there a test program we can run? Fedora 20 is using GCC 4.8 and clang 3.4; both support 'auto' (GCC since 4.4).
Well... there are two different issues "start using C++ 11" and "require C++ 11".
We can start using it now. The main question is when to make it a requirement. (I've written lots of production code that compiles both with and without C++ 11 features)
The secondary question is *which* parts of C++ 11 we can require, and which we have to defer. I believe last time I checked things for the day job included versions of gcc had only about 40% C++ 11 coverage. We also will need to take care to differentiate between C++ 11 features that are present versus those that function correctly. :-)
So we'll need to add a chart of which compilers we need to stay compatible with. Then we can cross-reference with the Apache page and quickly update our chart.
For the record my computer is currently stuck with gcc 4.2.1 since the hardware itself (32-bit CPU) is limited to OSX 10.6 and that does not have newer.
BTW, for that type of verbose code as in the iterator you mention the common workflow is to typedef a much simpler phrase. It's also commonly used for several things on that wiki page including std::unique_ptr.
2014-06-27 21:33 GMT+02:00 Jon A. Cruz <jon@...18...>:
Well... there are two different issues "start using C++ 11" and "require C++ 11".
We can start using it now. The main question is when to make it a requirement. (I've written lots of production code that compiles both with and without C++ 11 features)
All non-ancient compilers support the parts of C++11 we want. The real problem is that the C++11 standard library is not completely ABI-compatible with the C++98 one. So if we use any external C++ library that uses the STL, it must also be compiled in C++11 mode.
I'm not completely sure, but I think gtkmm uses the STL only in the headers. Other libraries would need to be checked as well.
https://gcc.gnu.org/wiki/Cxx11AbiCompatibility
Regards, Krzysztof
On 27-6-2014 21:41, Krzysztof Kosiński wrote:
2014-06-27 21:33 GMT+02:00 Jon A. Cruz <jon@...18...>:
Well... there are two different issues "start using C++ 11" and "require C++ 11".
We can start using it now. The main question is when to make it a requirement. (I've written lots of production code that compiles both with and without C++ 11 features)
All non-ancient compilers support the parts of C++11 we want. The real problem is that the C++11 standard library is not completely ABI-compatible with the C++98 one. So if we use any external C++ library that uses the STL, it must also be compiled in C++11 mode.
I'm not completely sure, but I think gtkmm uses the STL only in the headers. Other libraries would need to be checked as well.
I think this page actually says that there are none or very little ABI issues; I compile inkscape on windows with gcc 4.9 just fine with and without c++11, and have not run into weird linker/run-time errors. Just for very specific versions of gcc, there may be trouble. I think we can safely ignore that. We can skip this chicken-egg problem easily, imho.
-Johan
On Fri, Jun 27, 2014, at 12:41 PM, David Evans wrote:
MacPorts has ports for newer compilers both gcc and clang that should work on 10.6.
Yes... but "should" is the key word here. Unfortunately MacPorts llvm/clang was broken for myself and others, and that also blocks other dependencies from working.
*However* there is another problem with not using the system compiler. Doing so requires blocking any potential users from contributing without building custom versions of the compilers themselves. That's perhaps not much of an issue for an advanced coder, but definitely limits a certain pool of potential contributors.
I'm not saying we can't do this, just that we need to actively consider and weight the factors.
On Fri, 2014-06-27 at 12:52 -0700, Jon A. Cruz wrote:
*However* there is another problem with not using the system compiler. Doing so requires blocking any potential users from contributing without building custom versions of the compilers themselves. That's perhaps not much of an issue for an advanced coder, but definitely limits a certain pool of potential contributors.
It wouldn't be easier to put together a FreeDesktop distribution for development. Or at least Feature Development. Split that out from packaging/compiling on Mac for best effect.
Martin,
On 6/27/14 1:20 PM, Martin Owens wrote:
On Fri, 2014-06-27 at 12:52 -0700, Jon A. Cruz wrote:
*However* there is another problem with not using the system compiler. Doing so requires blocking any potential users from contributing without building custom versions of the compilers themselves. That's perhaps not much of an issue for an advanced coder, but definitely limits a certain pool of potential contributors.
It wouldn't be easier to put together a FreeDesktop distribution for development. Or at least Feature Development. Split that out from packaging/compiling on Mac for best effect.
Martin,
I'm not sure breaking out Mac for compiling is necessary, just that people who want to work on this need to use a more recent OS version. The default system compiler (clang) for 10.7+ supports -std=cxx11. libc++ is the default library for 10.9+ and is optional for 10.8 where libstdc++ is the default, 10.7 is libstd++ only.
Using MacPorts, clang-3.3/clang-3.4/clang-3.5 currently build for 10.6 64-bit and install from prebuilt binaries. I don't have any information about 32 bit builds, per se, but would encourage Jon to try again as I believe the previous problems have been resolved. If there are remaining problems a ticket would be appreciated.
Dave
On Fri, Jun 27, 2014, at 01:51 PM, David Evans wrote:
I'm not sure breaking out Mac for compiling is necessary, just that people who want to work on this need to use a more recent OS version. The default system compiler (clang) for 10.7+ supports -std=cxx11.
The main problem is that the hardware itself can't run 10.7 or later. If someone wants to buy me a new machine, that would be great. :-)
Using MacPorts, clang-3.3/clang-3.4/clang-3.5 currently build for 10.6 64-bit and install from prebuilt binaries. I don't have any information about 32 bit builds, per se, but would encourage Jon to try again as I believe the previous problems have been resolved.
I've tried several times, and will run a pass again. However, there hadn't been much traction on the 32-bit clang issues.
On 6/27/14 1:59 PM, Jon A. Cruz wrote:
On Fri, Jun 27, 2014, at 01:51 PM, David Evans wrote:
I'm not sure breaking out Mac for compiling is necessary, just that people who want to work on this need to use a more recent OS version. The default system compiler (clang) for 10.7+ supports -std=cxx11.
The main problem is that the hardware itself can't run 10.7 or later. If someone wants to buy me a new machine, that would be great. :-)
Crowd funding, perhaps? :-).
Using MacPorts, clang-3.3/clang-3.4/clang-3.5 currently build for 10.6 64-bit and install from prebuilt binaries. I don't have any information about 32 bit builds, per se, but would encourage Jon to try again as I believe the previous problems have been resolved.
I've tried several times, and will run a pass again. However, there hadn't been much traction on the 32-bit clang issues.
I don't see any open tickets on the subject right now and usually people are not shy to file them. Still see support tickets for ppc on Tiger for instance and we have a few developers who have the hardware to work these issues.
If you do give it a try, be sure to first upgrade to the latest MacPorts 2.3.1 (released this week) which has some new features regarding libcxx/libstdcxx selection and now uses clang 3.4 as the fallback compiler (instead of clang 3.3) for ports that don't build using gcc 4.2 (typically 10.6 or earlier).
Please let me know if you have problems
Dave
On Fri, Jun 27, 2014, at 01:51 PM, David Evans wrote:
Using MacPorts, clang-3.3/clang-3.4/clang-3.5 currently build for 10.6 64-bit and install from prebuilt binaries. I don't have any information about 32 bit builds, per se, but would encourage Jon to try again as I believe the previous problems have been resolved. If there are remaining problems a ticket would be appreciated.
I had things settle down enough to have time to re-try once again. This time it fails much earlier in the process, on libffi which happens to be a dependency for llvm. One of the work-arounds listed is to just compile it with llvm :-(
Oh, and ticket:
libffi @3.1 fails to build on 32-bit systems https://trac.macports.org/ticket/44170
However, latter comments point out that it is also failing on 64-bit systems.
:-(
On Wed, Jul 2, 2014, at 09:34 AM, Jon A. Cruz wrote:
On Fri, Jun 27, 2014, at 01:51 PM, David Evans wrote:
Using MacPorts, clang-3.3/clang-3.4/clang-3.5 currently build for 10.6 64-bit and install from prebuilt binaries. I don't have any information about 32 bit builds, per se, but would encourage Jon to try again as I believe the previous problems have been resolved. If there are remaining problems a ticket would be appreciated.
I had things settle down enough to have time to re-try once again. This time it fails much earlier in the process, on libffi which happens to be a dependency for llvm. One of the work-arounds listed is to just compile it with llvm :-(
Oh, and ticket:
libffi @3.1 fails to build on 32-bit systems https://trac.macports.org/ticket/44170
However, latter comments point out that it is also failing on 64-bit systems.
:-(
FYI, the macports guys got libffi resolved and I was able to start rebuilding ports yesterday. I did hit one error with libcdr, but a PPC fix corrected that for me locally.
https://trac.macports.org/ticket/43487
So *FINALLY* I am able to start a compile of Inkscape again. :-)
On 27-6-2014 21:33, Jon A. Cruz wrote:
On Fri, Jun 27, 2014, at 12:03 PM, Tavmjong Bah wrote:
Hi,
I noticed a bunch of 'for' loops in Liam's code and that got me wondering about using C++11 in the experimental branch as 'auto' is so much nicer that "std::map<SPDocument*,int>::iterator iter". When can we start using C++11?
I noticed that http://wiki.inkscape.org/wiki/index.php/C%2B%2B11 only shows results for one Window's compiler. Is there a test program we can run? Fedora 20 is using GCC 4.8 and clang 3.4; both support 'auto' (GCC since 4.4).
Well... there are two different issues "start using C++ 11" and "require C++ 11".
We can start using it now. The main question is when to make it a requirement. (I've written lots of production code that compiles both with and without C++ 11 features)
You mean to #ifdef the hell out of it? I am very much against this. We already have this in our code, and it is terrible. For me "using C++11" means we require it, full stop.
The secondary question is *which* parts of C++ 11 we can require, and which we have to defer. I believe last time I checked things for the day job included versions of gcc had only about 40% C++ 11 coverage. We also will need to take care to differentiate between C++ 11 features that are present versus those that function correctly. :-)
So we'll need to add a chart of which compilers we need to stay compatible with. Then we can cross-reference with the Apache page and quickly update our chart.
This is what this page is about: http://wiki.inkscape.org/wiki/index.php/C%2B%2B11 On Windows, we can easily use gcc 4.9 with devlibs64, and I hope after release we can update devlibs 32bit to gcc 4.9 too (because of ABI compatibility issues, we are stuck at 4.6) . I agree we should be careful using too many C++11 features; notably the threading stuff (it's great, but needs checking if all platforms support it correctly).
For the record my computer is currently stuck with gcc 4.2.1 since the hardware itself (32-bit CPU) is limited to OSX 10.6 and that does not have newer.
I hope you realize that this is not really tenable for Inkscape to keep compatible with such old compilers... (7 years is not that old in human terms, but it is a lot in computer terms)
With the current pace of development, any code one writes now will live for a long time. Therefore, I feel it is important we make the switch to C++11 asap.
- Johan
On Fri, Jun 27, 2014, at 03:48 PM, Johan Engelen wrote:
You mean to #ifdef the hell out of it? I am very much against this. We already have this in our code, and it is terrible. For me "using C++11" means we require it, full stop.
Well... some is more using typedef, rather than #ifdef. A bit of #ifdef does come in... but "the hell out of it" is probably to the degree we want to avoid.
We are still going to need at least some judicious #ifdef to keep cross-platform and cross-OS support working. However we do want to keep it to a minimum. Explicitly defining what is "too old" will help both users and devs.
The secondary question is *which* parts of C++ 11 we can require, and which we have to defer. I believe last time I checked things for the day job included versions of gcc had only about 40% C++ 11 coverage. We also will need to take care to differentiate between C++ 11 features that are present versus those that function correctly. :-)
So we'll need to add a chart of which compilers we need to stay compatible with. Then we can cross-reference with the Apache page and quickly update our chart.
This is what this page is about: http://wiki.inkscape.org/wiki/index.php/C%2B%2B11
OK. That can be a good start. However we are missing the other info... namely which version of which OS's are and are not supported, and which compilers they have.
Ubuntu is pretty good for defining their support lifetimes, but slightly poor with which compilers & libs are in which versions. So we just need a little legwork to sync from that.
I'd say the main question will be for the enterprise distros. CentOS/RHEL, Scientific and SUSE might cover the bases. RHEL 5.x is still in production for a few more years, so we might want to consider that. RHEL 6.x could replace it as a baseline target. Some end-user research on this specific point would be good.
For the record my computer is currently stuck with gcc 4.2.1 since the hardware itself (32-bit CPU) is limited to OSX 10.6 and that does not have newer.
I hope you realize that this is not really tenable for Inkscape to keep compatible with such old compilers... (7 years is not that old in human terms, but it is a lot in computer terms)
Yes. However we need to keep in mind that compatibility with older hardware is a key selling point for many in their decision to use open source software.
I am open, however, to being declared to be on "ancient" hardware. As long as we make an informed explicit decision we should be good.
On Fri, 2014-06-27 at 19:06 -0700, Jon A. Cruz wrote:
Some end-user research on this specific point would be good.
I can give you website data, unfortunately google is terrible at labeling "Linux" as an operating system (when it's a kernel) so we get a bad breakdown showing CPUs instead of distros for those. Also if we went by these numbers, we'd all invest in writing an iOS version, so everyone grab their emergency statistical pinch of salt before review:
[May 28th 2014 to June 27th 2014] Website: inkscape.org
Windows 134139 7 243591 8.1 61171 XP 34431 8 26147 Vista 12390 OSX 89146 10.9 63886 10.8 8821 10.6 8024 10.7 6830 10.5 989 10.10 596 PPC 10.4 302 Intel 10.4 365
Linux 22723 64bit 15457 32bit 7266 Unknown 189 arm7 23 Unnkown 1548 Android 9858 iOS 14369 Other 747
On 28-6-2014 4:06, Jon A. Cruz wrote:
On Fri, Jun 27, 2014, at 03:48 PM, Johan Engelen wrote:
You mean to #ifdef the hell out of it? I am very much against this. We already have this in our code, and it is terrible. For me "using C++11" means we require it, full stop.
Well... some is more using typedef, rather than #ifdef. A bit of #ifdef does come in... but "the hell out of it" is probably to the degree we want to avoid.
We are still going to need at least some judicious #ifdef to keep cross-platform and cross-OS support working. However we do want to keep it to a minimum. Explicitly defining what is "too old" will help both users and devs.
It's just that many of the C++11 things we would want to use (and are safe to) are not typedef'able. I'm thinking about: auto, initializer lists, =delete, move, ranged for, enum class, lambda, constructor delegation, ...
The only thing I know of that we probably cannot use yet (or need to do tests with) is the threading functionality.
cheers, Johan
On 28-6-2014 4:06, Jon A. Cruz wrote:
On Fri, Jun 27, 2014, at 03:48 PM, Johan Engelen wrote:
The secondary question is *which* parts of C++ 11 we can require, and which we have to defer. I believe last time I checked things for the day job included versions of gcc had only about 40% C++ 11 coverage. We also will need to take care to differentiate between C++ 11 features that are present versus those that function correctly. :-)
So we'll need to add a chart of which compilers we need to stay compatible with. Then we can cross-reference with the Apache page and quickly update our chart.
This is what this page is about: http://wiki.inkscape.org/wiki/index.php/C%2B%2B11
OK. That can be a good start. However we are missing the other info... namely which version of which OS's are and are not supported, and which compilers they have.
Ubuntu is pretty good for defining their support lifetimes, but slightly poor with which compilers & libs are in which versions. So we just need a little legwork to sync from that.
I'd say the main question will be for the enterprise distros. CentOS/RHEL, Scientific and SUSE might cover the bases. RHEL 5.x is still in production for a few more years, so we might want to consider that. RHEL 6.x could replace it as a baseline target. Some end-user research on this specific point would be good.
For the record my computer is currently stuck with gcc 4.2.1 since the hardware itself (32-bit CPU) is limited to OSX 10.6 and that does not have newer.
I hope you realize that this is not really tenable for Inkscape to keep compatible with such old compilers... (7 years is not that old in human terms, but it is a lot in computer terms)
Yes. However we need to keep in mind that compatibility with older hardware is a key selling point for many in their decision to use open source software.
I am open, however, to being declared to be on "ancient" hardware. As long as we make an informed explicit decision we should be good.
Cool. Making an informed decision is tiring though, and I don't think we need more info for this. It's just a waste of dev time to try and look up all these details. If people want to use Inkscape on old systems, fine, download 0.91. For trunk, tough luck. Our dependency requirements are upped much quicker it seems, even though requiring C++11 is much less invasive.
Note that building LLVM/clang now requires C++11. This tells me that we are very late in making the switch.
-Johan
On Sat, 2014-06-28 at 13:49 +0200, Johan Engelen wrote:
On 28-6-2014 4:06, Jon A. Cruz wrote:
On Fri, Jun 27, 2014, at 03:48 PM, Johan Engelen wrote:
The secondary question is *which* parts of C++ 11 we can require, and which we have to defer. I believe last time I checked things for the day job included versions of gcc had only about 40% C++ 11 coverage. We also will need to take care to differentiate between C++ 11 features that are present versus those that function correctly. :-)
So we'll need to add a chart of which compilers we need to stay compatible with. Then we can cross-reference with the Apache page and quickly update our chart.
This is what this page is about: http://wiki.inkscape.org/wiki/index.php/C%2B%2B11
OK. That can be a good start. However we are missing the other info... namely which version of which OS's are and are not supported, and which compilers they have.
Ubuntu is pretty good for defining their support lifetimes, but slightly poor with which compilers & libs are in which versions. So we just need a little legwork to sync from that.
I'd say the main question will be for the enterprise distros. CentOS/RHEL, Scientific and SUSE might cover the bases. RHEL 5.x is still in production for a few more years, so we might want to consider that. RHEL 6.x could replace it as a baseline target. Some end-user research on this specific point would be good.
For the record my computer is currently stuck with gcc 4.2.1 since the hardware itself (32-bit CPU) is limited to OSX 10.6 and that does not have newer.
I hope you realize that this is not really tenable for Inkscape to keep compatible with such old compilers... (7 years is not that old in human terms, but it is a lot in computer terms)
Yes. However we need to keep in mind that compatibility with older hardware is a key selling point for many in their decision to use open source software.
I am open, however, to being declared to be on "ancient" hardware. As long as we make an informed explicit decision we should be good.
Cool. Making an informed decision is tiring though, and I don't think we need more info for this. It's just a waste of dev time to try and look up all these details. If people want to use Inkscape on old systems, fine, download 0.91. For trunk, tough luck. Our dependency requirements are upped much quicker it seems, even though requiring C++11 is much less invasive.
I agree. Users of long-term releases are probably not our target audience. Long-term releases are generally used for servers where long-term stability is required and not on users desktops.
Note that building LLVM/clang now requires C++11. This tells me that we are very late in making the switch.
I added the -std=c++11 to the compiler flags on Fedora 20 and compiled and linked Inkscape without any trouble, with both GCC 4.8.3 and clang 3.4. (I also changed one 'for' loop to use 'auto' to verify that I was compiling with c++11.)
Tav
On Fri, Jun 27, 2014 at 09:03:54PM +0200, Tavmjong Bah wrote:
Hi,
I noticed a bunch of 'for' loops in Liam's code and that got me wondering about using C++11 in the experimental branch as 'auto' is so much nicer that "std::map<SPDocument*,int>::iterator iter". When can we start using C++11?
I noticed that http://wiki.inkscape.org/wiki/index.php/C%2B%2B11 only shows results for one Window's compiler. Is there a test program we can run? Fedora 20 is using GCC 4.8 and clang 3.4; both support 'auto' (GCC since 4.4).
One thing I'd recommend in general with the experimental branch is to avoid changes that will cause a lot of refactoring. The reason for this is that patches added to the branch later will be more work to port them to other branches (like bringing them back to main, once it's reopened for development).
Bryce
On 27-6-2014 21:59, Bryce Harrington wrote:
On Fri, Jun 27, 2014 at 09:03:54PM +0200, Tavmjong Bah wrote:
Hi,
I noticed a bunch of 'for' loops in Liam's code and that got me wondering about using C++11 in the experimental branch as 'auto' is so much nicer that "std::map<SPDocument*,int>::iterator iter". When can we start using C++11?
I noticed that http://wiki.inkscape.org/wiki/index.php/C%2B%2B11 only shows results for one Window's compiler. Is there a test program we can run? Fedora 20 is using GCC 4.8 and clang 3.4; both support 'auto' (GCC since 4.4).
One thing I'd recommend in general with the experimental branch is to avoid changes that will cause a lot of refactoring. The reason for this is that patches added to the branch later will be more work to port them to other branches (like bringing them back to main, once it's reopened for development).
++11 ;P
I agree we should wait until after release for flipping the switch.
-Johan
Hi all, Now that we have branched for release, can we now *finally* switch trunk to require C++11? Let's start with features supported by GCC 4.6 [1].
I am very rapidly loosing my patience here and find it very demotivating that we are still hung-up on this.
Googling a bit and reading on our mail thread finds plenty of options for people on ancient hardware.
-Johan
[1] http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport
On 27-6-2014 21:03, Tavmjong Bah wrote:
Hi,
I noticed a bunch of 'for' loops in Liam's code and that got me wondering about using C++11 in the experimental branch as 'auto' is so much nicer that "std::map<SPDocument*,int>::iterator iter". When can we start using C++11?
I noticed that http://wiki.inkscape.org/wiki/index.php/C%2B%2B11 only shows results for one Window's compiler. Is there a test program we can run? Fedora 20 is using GCC 4.8 and clang 3.4; both support 'auto' (GCC since 4.4).
Tav
I seem to remember starting a thread on building Inkscape with std=c++11 and the build fails since M_PI and friends would become undefined. So, the build will fail or at least fails for me with revision 13747 (Is that the same as 0.91 release branch?).
I think one suggestion was to collect them all into one header file...
On Sat, Nov 22, 2014 at 7:37 AM, Johan Engelen <jbc.engelen@...2592...> wrote:
Hi all, Now that we have branched for release, can we now *finally* switch trunk to require C++11? Let's start with features supported by GCC 4.6 [1].
I am very rapidly loosing my patience here and find it very demotivating that we are still hung-up on this.
Googling a bit and reading on our mail thread finds plenty of options for people on ancient hardware.
-Johan
[1] http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport
On 27-6-2014 21:03, Tavmjong Bah wrote:
Hi,
I noticed a bunch of 'for' loops in Liam's code and that got me wondering about using C++11 in the experimental branch as 'auto' is so much nicer that "std::map<SPDocument*,int>::iterator iter". When can we start using C++11?
I noticed that http://wiki.inkscape.org/wiki/index.php/C%2B%2B11 only shows results for one Window's compiler. Is there a test program we can run? Fedora 20 is using GCC 4.8 and clang 3.4; both support 'auto' (GCC since 4.4).
Tav
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
You should compile with -std=g++11 or -std=gnu++0x. Per default, gcc includes a bunch on non-standard C++ things, so the default is something like -std=g++03. Our code is non-standard compliant, but I have not found the energy yet to fix that.
Our 64bit Windows builds have been using -std=gnu++0x for a while now btw.
-Johan
On 22-11-2014 14:32, Partha Bagchi wrote:
I seem to remember starting a thread on building Inkscape with std=c++11 and the build fails since M_PI and friends would become undefined. So, the build will fail or at least fails for me with revision 13747 (Is that the same as 0.91 release branch?).
I think one suggestion was to collect them all into one header file...
On Sat, Nov 22, 2014 at 7:37 AM, Johan Engelen <jbc.engelen@...2592...> wrote:
Hi all, Now that we have branched for release, can we now *finally* switch trunk to require C++11? Let's start with features supported by GCC 4.6 [1].
I am very rapidly loosing my patience here and find it very demotivating that we are still hung-up on this.
Googling a bit and reading on our mail thread finds plenty of options for people on ancient hardware.
-Johan
[1] http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport
On 27-6-2014 21:03, Tavmjong Bah wrote:
Hi,
I noticed a bunch of 'for' loops in Liam's code and that got me wondering about using C++11 in the experimental branch as 'auto' is so much nicer that "std::map<SPDocument*,int>::iterator iter". When can we start using C++11?
I noticed that http://wiki.inkscape.org/wiki/index.php/C%2B%2B11 only shows results for one Window's compiler. Is there a test program we can run? Fedora 20 is using GCC 4.8 and clang 3.4; both support 'auto' (GCC since 4.4).
Tav
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Isn't that still a little nonstandard? Some g++11 would not be allowed with c++11? :)
On Sat, Nov 22, 2014 at 9:04 AM, Johan Engelen <jbc.engelen@...2592...> wrote:
You should compile with -std=g++11 or -std=gnu++0x. Per default, gcc includes a bunch on non-standard C++ things, so the default is something like -std=g++03. Our code is non-standard compliant, but I have not found the energy yet to fix that.
Our 64bit Windows builds have been using -std=gnu++0x for a while now btw.
-Johan
On 22-11-2014 14:32, Partha Bagchi wrote:
I seem to remember starting a thread on building Inkscape with std=c++11 and the build fails since M_PI and friends would become undefined. So, the build will fail or at least fails for me with revision 13747 (Is that the same as 0.91 release branch?).
I think one suggestion was to collect them all into one header file...
On Sat, Nov 22, 2014 at 7:37 AM, Johan Engelen <jbc.engelen@...2592...> wrote:
Hi all, Now that we have branched for release, can we now *finally* switch trunk to require C++11? Let's start with features supported by GCC 4.6 [1].
I am very rapidly loosing my patience here and find it very demotivating that we are still hung-up on this.
Googling a bit and reading on our mail thread finds plenty of options for people on ancient hardware.
-Johan
[1] http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport
On 27-6-2014 21:03, Tavmjong Bah wrote:
Hi,
I noticed a bunch of 'for' loops in Liam's code and that got me wondering about using C++11 in the experimental branch as 'auto' is so much nicer that "std::map<SPDocument*,int>::iterator iter". When can we start using C++11?
I noticed that http://wiki.inkscape.org/wiki/index.php/C%2B%2B11 only shows results for one Window's compiler. Is there a test program we can run? Fedora 20 is using GCC 4.8 and clang 3.4; both support 'auto' (GCC since 4.4).
Tav
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Correct.
On 22-11-2014 15:34, Partha Bagchi wrote:
Isn't that still a little nonstandard? Some g++11 would not be allowed with c++11? :)
On Sat, Nov 22, 2014 at 9:04 AM, Johan Engelen <jbc.engelen@...2592...> wrote:
You should compile with -std=g++11 or -std=gnu++0x. Per default, gcc includes a bunch on non-standard C++ things, so the default is something like -std=g++03. Our code is non-standard compliant, but I have not found the energy yet to fix that.
Our 64bit Windows builds have been using -std=gnu++0x for a while now btw.
-Johan
On 22-11-2014 14:32, Partha Bagchi wrote:
I seem to remember starting a thread on building Inkscape with std=c++11 and the build fails since M_PI and friends would become undefined. So, the build will fail or at least fails for me with revision 13747 (Is that the same as 0.91 release branch?).
I think one suggestion was to collect them all into one header file...
On Sat, Nov 22, 2014 at 7:37 AM, Johan Engelen <jbc.engelen@...2592...> wrote:
Hi all, Now that we have branched for release, can we now *finally* switch trunk to require C++11? Let's start with features supported by GCC 4.6 [1].
I am very rapidly loosing my patience here and find it very demotivating that we are still hung-up on this.
Googling a bit and reading on our mail thread finds plenty of options for people on ancient hardware.
-Johan
[1] http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport
On 27-6-2014 21:03, Tavmjong Bah wrote:
Hi,
I noticed a bunch of 'for' loops in Liam's code and that got me wondering about using C++11 in the experimental branch as 'auto' is so much nicer that "std::map<SPDocument*,int>::iterator iter". When can we start using C++11?
I noticed that http://wiki.inkscape.org/wiki/index.php/C%2B%2B11 only shows results for one Window's compiler. Is there a test program we can run? Fedora 20 is using GCC 4.8 and clang 3.4; both support 'auto' (GCC since 4.4).
Tav
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sat, Nov 22, 2014 at 4:37 AM, Johan Engelen <jbc.engelen@...2592...> wrote:
Hi all, Now that we have branched for release, can we now *finally* switch trunk to require C++11?
I know this is exciting and useful stuff, but since we branched for release it would really be nice if people would focus on the remaining issues we have for 0.91. You talk about losing patience, and it would really be nice if you understood how quickly our users will lose patience with Inkscape if we keep breaking features and accumulating regression bugs on things that used to work. I'm not saying C++11 is a low priority. However, releasing a minimally broken new stable release (the first in over FOUR years) should probably be worthy of more attention than trunk for issues of this nature at this at this point (which is not a perspective I would have if things weren't in such bad shape).
Cheers, Josh
On Sat, Nov 22, 2014 at 10:13:13AM -0800, Josh Andler wrote:
On Sat, Nov 22, 2014 at 4:37 AM, Johan Engelen <jbc.engelen@...2592...> wrote:
Hi all, Now that we have branched for release, can we now *finally* switch trunk to require C++11?
I know this is exciting and useful stuff, but since we branched for release it would really be nice if people would focus on the remaining issues we have for 0.91. You talk about losing patience, and it would really be nice if you understood how quickly our users will lose patience with Inkscape if we keep breaking features and accumulating regression bugs on things that used to work. I'm not saying C++11 is a low priority. However, releasing a minimally broken new stable release (the first in over FOUR years) should probably be worthy of more attention than trunk for issues of this nature at this at this point (which is not a perspective I would have if things weren't in such bad shape).
Yes, Josh is completely right.
I know folks are anxious to enact a variety of large scale changes, so I'll kickstart a separate brainstorming discussion about coordinating these into a proper roadmap so we can tackle them in good order.
Bryce
participants (9)
-
Bryce Harrington -
David Evans -
Johan Engelen -
Jon A. Cruz -
Josh Andler -
Krzysztof Kosiński -
Martin Owens -
Partha Bagchi -
Tavmjong Bah