I wanted to know for c::b itself, its code, its plugins...No, until all major long-term-support linux distros switch to GCC 4.7 at least.
I wanted to know for c::b itself, its code, its plugins...No, until all major long-term-support linux distros switch to GCC 4.7 at least.
Or to make it a bit more clear: When there is a RHEL/CentOS that uses GCC 4.7 as its native compiler and I've this distro installed on my work machine.
I've just switched to the latest CentOS and the compiler is GCC 4.4, so you're out of luck:)
Until then I'll revert all C++11 commits :)
#if (__cplusplus >= 201103L)
// C++11 code goes here
#else
// old code here
#endifand everybody would be happy...And what is the benefit if we have to maintain both versions?
there are ways to install more recent gcc on centos and family.This doesn't change anything, because they won't be the system compiler!
there are ways to install more recent gcc on centos and family.This doesn't change anything, because they won't be the system compiler!
And would require hacking the LD_LIBRARY_PATH or using rpath for the libstdc++.so,
which will make using C::B on CentOS a nightmare and people won't do it.
Also it will be a nightmare to support on the various older Ubuntus...
p.s. from my tests GCC 4.6 is not a C++11 compiler one can depend on. GCC 4.7 is the first one.
I remember seeing a while back a program that was distributed as single packed archive that even contained its own version of libstdc++ and a number of system shared objects, so it is possible to provide a custom build that is not based on the system libraries, it will just prevent one from using debian packages or rpms, but it still is possible at the expense of a rather bloated binary distribution.Of course this is technically possible, all binary-only softwares do it.
I should not brought this up at all. but I think the devs are right from every practical standpoint...
just because I (or anyone else) like some features of C++11 is NOT enough. ;)
hi,
so we found another point: the whole wxWidgets part of the game. What do the devs think about this, and the problem it presents for adapting c::b to c++11 ?
and as a note: I am certainly not a dev here :) just a guy who does programming in spare time. and I certainly don't mean to say that c++11 is syntactical sugar. nothing would be more wrong thinking. it takes out so much of the clumsiness of c++, and lets one focus more on what to express and achieve... my personal favorite are the lamdas and the move semantics... ;D
regards
#if (__cplusplus >= 201103L)
wxString(wxString &&) = default;
wxString operator=(wxString &&) = default;
#endifOk, a little bit offtopic, but I hope C::B will be going in right direction :)But why would you care as a user of C::B about C++11?
...who is still using GCC version 3.3 or 3.4...We require GCC 4.0 (C++ TR1) for quite awhile, so I doubt you're correct.
But why would you care as a user of C::B about C++11?
C++11 in C::B will make a difference to you, only if you plan to contribute to C::B, is this the case?
If it is will forcing C++98 stop you from doing so?
Move semantics won't make a big difference to wxString, because it is reference counted, at least in 2.8.
wx 3.0 has some C++11 support.
When we continue this conservative approach our-self, we will be stuck to old C++ for another decade.
[...]
So there is a balance somewhere, and for sure no aggressive dictatorship claiming to revert any commit with c++11, that's just an opinion like any other, a valid opinion at this time.
...who is still using GCC version 3.3 or 3.4...We require GCC 4.0 (C++ TR1) for quite awhile, so I doubt you're correct.
But more important, the build is broken. Thomas, you have introduced C++11 code, which will not compile unless we start using that option. I want to avoid the discussion at this moment, I would like to open it after the next release ;-)No need to discuss it (again), I'll revert any c++11 commit because I use gcc4.1.2 at work ( Centos 5.8 ), which is non c++11 enabled. C++11 will be allowed when we have a redhat release with gcc4.7!