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