Re: [PATCH kvm-unit-tests 2/4] Introduce a C++ wrapper for the kvm APIs

Michael S. Tsirkin
2010-11-28T13:58:11Z

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