On Sun, Nov 28, 2010 at 03:02:18PM +0200, Avi Kivity wrote: > On 11/28/2010 01:59 PM, Michael S. Tsirkin wrote: > >> > >> > >> FWIW, I still disagree with C++ and believe this code to be hardly readable. > > > >A major issue is existing tools. > > > >Using C++ would prevent us from using sparce for static code checking. > > C++ static checking is way better than anything sparse offers. This seems a second system effect at work. sparce lets you solve C problems that C++ inherited as is. E.g. if you have a pointer you can always dereference it. > > Things like __user are easily done in C++. Some of what sparce does can be done if you create a separate type for all address spaces. This can be done in C too, and the result won't be like __user at all. > >We should be adding more annotations instead of throwing existing ones > >out. ctags is also broken with C++ which will make it much harder > >for me to browse the codebase. > > C++ does want a good IDE. For some definitions of good :). Let's start a vi versus emacs flamewar? > >C++ support in gdb has some limitations > >if you use overloading, exceptions, templates. The example posted here > >uses two of these, so it would be harder to debug. > > I haven't seen issues with overloading or exceptions. Build your test with -g, fire up gdb from command line, try to put a breakpoint in the constructor of the fd object, maybe you will see what I mean :) An example of an issue with overloading is that gdb seems unable to resolve them properly depending on the current scope. So you see a call to foo() and want to put a breakpoint there, first problem is just to find one which namespace it is in. Once you did the best it can do it prompt you to select one of the overloaded options. How do you know which one do you want? You don't, so you guess. Sometimes gdb will guess, because of a complex set of name resolution rules, and sometimes it will this wrongly. Which is not what I want to spend mental cycles on when I am debugging a problem. Functions using exceptions can not be called from the gdb prompt (gdb is not smart enough to catch them). There are more issues. > Templates are > indeed harder to debug, simply because names can become very long. That's not the only problem. A bigger one is when you type tab to complete function name and get a list of options to select from for each of the times a template was instantiated. Only one of them is relevant in a given scope. No hint is given which. Further when you step into the template, the source does not give you any hint about the types used. Some of this is true for macros as well of course. Except people know macros are bad and so make them thin wrappers around proper functions. > >I also hoped we'll be able to adopt checkpatch at some point for coding > >style enforcement, C++ syntax is just too complex for a perl script to > >be of any use. > > Not much of a loss IMO. This is just an example of how coding style is harder to specify and enforce. There are just much more ways to do any given thing. Uniform style is much harder to achieve. > -- > error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
