c++11

[frithjofh]

hi everybody,

can the devs please tell if there are plans/considerations of adapting c::b to C++11, and if so when...

and, please, I don't post this to start a polemic. c::b is doing fine without C++11. i am just curious 

regards

frithjofh

[Jenna]

What exactly do you try to do ?
You can use c++11 for your projects already (if the compiler supports this, of course  ).

[frithjofh]

oh, sorry for not being clear on that...

I know that I can already use C++11 for my projects, I am actually doing so... ( I use the gcc 4.8 )

I wanted to know for c::b itself, its code, its plugins...

[oBFusCATed]

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

[frithjofh]

makes sense I think ...

[mistar]

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

It is possible to add C++11 code to C::B sources with

Code

#if (__cplusplus >= 201103L)
// C++11 code goes here
#else
// old code here
#endif

and everybody would be happy...

[oBFusCATed]

and everybody would be happy...

And what is the benefit if we have to maintain both versions?
The idea of switching to C++11 is to make it easier to write and maintain C::B, so this will defeat the purpose of the switch.

[killerbot]

there are ways to install more recent gcc on centos and family.

[oBFusCATed]

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.

[ptDev]

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.

[oBFusCATed]

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.
But this is not the point of open source and we will loose all the benefits of distros.

[frithjofh]

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. 

[mistar]

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. 

Those features are designed to simplify code maintainance, memory management and many other things.
Of course, it would require wxWidgets to be written using smart pointers and RAII (and that would clean up their API, ownership management and so on, but it is out of scope here).
So, the important thing is that C++11 features are not just syntactic sugar to simplify writing code, but to simplify code design and those features would greatly help YOU, devs, to maintain C::B sources

[frithjofh]

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... 

regards

[mistar]

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...  

regards

rvalue references are most important for an average programmer IHMO, they enable move semantics. Lambdas are just syntactic sugar (but of course very helpful)
Both wxWidgets and C::B would benefit much from using move semantics, mainly in passing wxStrings (for example long strings from text areas).
It is interesting that the following lines (in wxWidgets source) suffice to enable move semantics (as wxString uses std::string internally):

Code

#if (__cplusplus >= 201103L)
  wxString(wxString &&) = default;
  wxString operator=(wxString &&) = default;
#endif

then pass a wxString by value whenever you modify it inside (a compiler decides whether to copy or move in this case) or by const ref for read-only.

Ok, a little bit offtopic, but I hope C::B will be going in right direction

[oBFusCATed]

Ok, 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?
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.

[thomas]

I'd be the first to use C++11, not so much for the alleged performance advantages of move semantics (which are pretty much non-existent in reality, and in most cases people get them wrong and actually make code slower), but for the easier syntax.

However, we have at least one developer who is still using GCC version 3.3 or 3.4 (I forgot which) as well as some users with some exotic embedded architectures. Therefore it's unlikely that this is going to happen any time soon.

[oBFusCATed]

...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.

[killerbot]

if people prefer to use linux distros which have a very conservative approach on updates of packages, then that is a fair choice.
However such things should not block improvements and innovation.

When we continue this conservative approach our-self, we will be stuck to old C++ for another decade.

Several of those linux distros are for server purposes, less for personal development.

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.

But any day the strategy can change, and should not be blocked by some Redhat or Centos, then those just use old packages, or are no longer usable as a development platform. And as said more modern C++ compilers can be installed on them, even if they are not the system compiler they can be used to build CB, the only problem might be ABI non compatible on for example wxwidgets.

Don't forget that the majority of our users don't build Cb them selves(they don't even use linux). so building CB is cb developers and plug-in developers territory.
If we as developers obstruct innovation, we should reconsider, since that is no good, as C++IDE we should guide and lead the way :
- by supporting the C++1 features for the users (like code completion)
- by giving example in our own code, through using it

Today is not switching time yet, but conservative distros (for good reasons in their use cases) should not hold us back.


So please all, be open minded, there is no black or white, it it some shade of gray ;-)

As for linux, most 'modern' distros will be within the next couple of months be on 4.8.1, which now even has the library regex support ready. Which are nice forecasts, bumping the "majority" of the linux users on a C++11 compliant compiler. At that time the balance might need to be re-evaluated.

[mistar]

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?

It doesn't stop me, but it would make my plugin sources less clear and so worse maintainable.

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.

Refcounting and copy-on-write isn't thread-safe and many plugins use threads (my SemanticHighlight plugin for example).
wxString in wx 2.9 uses std::(w)string under the hood which is not refcounted and has move semantic implemented in C++11.
This is more clean IMHO (and move semantics works well in case of moving/copying large parts of sources).

Anyway, let me repeat: these are wxWidgets problems, not C::B, but C::B might benefit from this a lot.

Also killerbot is right: if you wish to have modern C++ IDE, you have to support writing C++11 code.
Of course this is completely different from C++11 as C::B implementation language

As for support for writing C++11 code, bear in mind that Clang has full support for C++11 now, so code completion and static analysis (to build source tree for example) are almost for free.

[oBFusCATed]

killerbot:
You're so wrong, but I have no time to argue on every statement where you're wrong.
Just keep in mind that if you want to develop commercial/binary software on Linux CentOS is best or only choice for a distro and some people are stuck on all Linux distros because their target software works only there.

mistar: No one stops you from using C++11 in your plugins, but if you want to contribute them to the main repo then they have to be C++98 (GCC >= 4.0)

p.s. I don't intend to spend any more time on this topic.

[thomas]

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.

I'm wrong about the exact GCC version, my apologies, but I'm correct about the matter as such. If I may refresh your memory (emphasis added by me):

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!