Clearly late to the party, On 08.04.2016 22:14, Paolo Bonzini wrote: > > On 08/04/2016 15:15, Markus Armbruster wrote: >>> On the other hand, minimal usage of templates instead of some of the >>> preprocessor gunk we have would be a very good thing IMNSHO. I am >>> referring to the multiply included header files and to the macros with >>> type arguments (mostly QOM casts). >>> >>> I don't think we need more C++ than that, but using templates as >>> basically a type-safe preprocessor would improve QEMU a little bit. >>> More rarely, lambdas could replace some preprocessor magic too, but >>> that's C11 and not many compilers support them. >>> >>> But I won't weep if people say no because we have a lot other >>> low-hanging fruit to make QEMU better (especially the header file >> >> "No!" (Hey, you asked for it) >> >> Back to serious. As Peter Maydell said, "if we move away from C I'd >> rather it to be a language that's nicer than C rather than one that's >> uglier and larger and still retains all of C's flaws." > > Sure, except that one plan is feasible now and can be done in small > steps; the other is not feasible now (for example Rust is not even > packaged in Fedora) and entails pretty much a rewrite of the whole code > base.
I skip my personal take on these specific issue, but one very practical concern I have with a potential move to C++, if I understand these proposals correctly, is with the speed of compilation and the binary size, and also QEMU startup time. I noticed while developing for OSv that compilation with C++ and templates was very slow compared with C, so certain scripts around git I am using to build and check code from scratch after each patch took a long time to complete. Do you know what these refactoring proposals' impact on compilation speed, binary size and startup time would be? Thank you, Claudio > >> People sometimes propose to defang C++ by subsetting and/or coding >> conventions. I'll take that seriously when I see the tool that >> rigorously checks adherence to subset / convention. > > The problem with subsetting and conventions is that they always come > with exceptions, besides the fact that no one writes the tool. > > So I prefer common sense :) and common sense says that a million-line > codebase that mixes procedural, home-grown OO and language OO is going > to stink from ten miles. And maintainers sit at most two feet from the > screen. > > Really even just -Wc++-compat would be a nice improvement so we enjoy a > little more type safety. IMHO, C++'s biggest tax is that Coccinelle > does not like it. > >>> cleanups that Markus started and I want to conclude very early in 2.7). >> >> Speaking of which: the plan was you post yours for 2.7, and then I can >> build on top (assuming there's useful work left), right? > > I have rebased my stuff already, but I'm going to disappear in about a > week and for the first week or two after the 2.6 release (depending on > whether it slips or not). Also, I will travel most of next week. So I > either I'll post it soonish or it will have to wait a little. > > Anyhow, there's definitely useful work left from your last two patches, > even more so after Veronia Bahaa cleaned up qemu-common.h substantially > so there may be more pointless inclusions of it and fewer headers that > really need it. > > Paolo >