Hello,
I would like to go with the times and switch Genode to use C++11 by default. This will enable us to solve a number of problems in a more elegant way, e.g., by using variadic templates for the RPC framework, we can possibly get rid of the current limit of the number of RPC functions supported by the 'GENODE_RPC_INTEFACE' declarations.
Are there any objections from Genode users? For example, is anyone of you still using a custom tool chain that does not support C++11?
If no one disagrees, I would go forward and add '-std=gnu++11' as default argument to g++.
Regards Norman
Hi,
On Sat, Mar 23, 2013 at 02:08:49PM +0100, Norman Feske wrote:
I would like to go with the times and switch Genode to use C++11 by default.
...
Are there any objections from Genode users? For example, is anyone of you still using a custom tool chain that does not support C++11?
I have not investigated deeply into that matter, but there could be a problem for users linking together genode code with c++ code which cannot be compiled in c++11 mode.
I'm no expert in that field but somebody who is might take a look at http://gcc.gnu.org/wiki/Cxx11AbiCompatibility and http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
As far as I understand the above deal mainly with issues within the standard library which might not be a problem when relying on the genode toolchain but could for the lx_hybrid platform.
Grüsse Andreas
2013/3/23 Norman Feske <norman.feske@...1...>:
Hello,
I would like to go with the times and switch Genode to use C++11 by default. This will enable us to solve a number of problems in a more elegant way, e.g., by using variadic templates for the RPC framework, we can possibly get rid of the current limit of the number of RPC functions supported by the 'GENODE_RPC_INTEFACE' declarations.
Very nice! using c++11 type inference and lambdas would be awesome. Besides, initializer lists are a nice feature. I think c++11 nicely closes the gap between C++, C99 and modern languages like C#
Btw, how about adding some "map" like container to base with a simpler interface than avl_tree and maybe based on some other data structure? (I'm not asking to do it, just wonder if you think it's a good idea). Sorry for the off-topic
Hi Andreas,
I'm no expert in that field but somebody who is might take a look at http://gcc.gnu.org/wiki/Cxx11AbiCompatibility and http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
thank you for these insightful (and admittedly frightening) links. Given these discussions, mixing compilation units compiled with -std=c++11 and -std=c++98 looks risky indeed. It seems that the problem can be avoided only by compiling the whole C++ code base consistently with one kind of -std argument. But I wonder how do Linux distributions do that? For example, if Qt5 uses C++11, does it mean that Qt5 must not be linked to programs compiled with -std=c++98? This is hard to believe.
As far as I understand the above deal mainly with issues within the standard library which might not be a problem when relying on the genode toolchain but could for the lx_hybrid platform.
I agree. But how should we go about this?
Cheers Norman
Hi Alexander,
Btw, how about adding some "map" like container to base with a simpler interface than avl_tree and maybe based on some other data structure? (I'm not asking to do it, just wonder if you think it's a good idea). Sorry for the off-topic
I was not planning to do so. If you come up with a useful structure that leads to code simplifications at a number of places, it would be a good idea to include it under 'os/include/'. We use to grow the utilities provided there quite organically. For example, the 'Signal_dispatcher' template class appeared first in the implementation file of a single component. Because it was useful, it subsequently appeared in the implementation files of a number of other components. This tells me that it has passed the test of utility. Moving it to a central place is just natural to avoid duplicated code. In this particular case, the code ended up in 'base/include/base/signal.h'. Other examples are the 'Static_root' and 'Slave' class templates, or the path utilities.
It may be hard to match the convenience of the STL containers though. I think that STL containers should be used wherever it is acceptable to pull in the complexity of the standard C++ library and where no exact accounting of memory allocations is needed. (see the other discussion "Standard placement operator") In contrast to STL containers, Genode's data structures follow the "invasive" pattern to alleviate the need for extra allocations (and the accounting) for meta data. That is, the meta data always gets incorporated into the object. (e.g., the next pointer of a list element is stored in the same object as the list element) There are no hidden allocations. But it makes the data structures a bit awkward to use.
In short, if you have a good data structure, just use it in your component. When it is useful, it will "magically" appear elsewhere. If this happens, we will certainly move it to a central place to ease and promote its further adoption.
Cheers Norman
Hello,
I'd like to finally follow up on my suggestion to enable C++11 by default back in March. As more and more targets are selectively using the current standard by manually adding 'CC_CXX_OPT += -std=gnu++11' to their respective target-description files, I will make this option the default. This will remove thos repetitive declarations and, more importantly, open the opportunity to use the new standard for simplifying the base system as well.
Admittedly, I have not thoroughly followed up on the corner cases cited by Andreas. The best would be to enable the option consistently across all C++ software packages linked against Genode programs, which sounds reasonable to me. For all programs built within Genode's build system, this will be the case anyway. External libraries linked against hybrid Linux/Genode programs must be considered. But for those, the change to enabling C++11 seems natural, too.
I hope that everyone (in particular Andreas) is fine with the changed default for Genode.
Regards Norman
On 03/25/2013 06:50 PM, Norman Feske wrote:
Hi Andreas,
I'm no expert in that field but somebody who is might take a look at http://gcc.gnu.org/wiki/Cxx11AbiCompatibility and http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
thank you for these insightful (and admittedly frightening) links. Given these discussions, mixing compilation units compiled with -std=c++11 and -std=c++98 looks risky indeed. It seems that the problem can be avoided only by compiling the whole C++ code base consistently with one kind of -std argument. But I wonder how do Linux distributions do that? For example, if Qt5 uses C++11, does it mean that Qt5 must not be linked to programs compiled with -std=c++98? This is hard to believe.
As far as I understand the above deal mainly with issues within the standard library which might not be a problem when relying on the genode toolchain but could for the lx_hybrid platform.
I agree. But how should we go about this?
Cheers Norman
-
Alexander Tarasikov -
Andreas Fett -
Norman Feske