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

Avi Kivity
2010-11-28T14:34:45Z

On 11/28/2010 03:57 PM, Michael S. Tsirkin wrote:
> 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.

It's the other way round.

For example __user cannot be done in C. It has to be done as an add-on.

In C++ it's simply:

template <class T>
class user_ptr<T>
{
public:
explicit user_ptr(unsigned long addr);
void copy_from(T& to); // throws EFAULT
void copy_to(const T& from); // throws EFAULT
private:
unsigned long addr;
};

No need for an additional toolchain.

> >
> > 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.

That's quite a lot of work.

Sparse: T __user *foo;
C++: user_ptr<T> foo;
C : struct T_user_ptr { unsigned long addr } foo; + lots of accessors.

> > >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?

Like we haven't enough...

> > >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 :)
>
(gdb) break 'kvm::fd::fd'
Breakpoint 3 at 0x8049650: file api/kvmxx.cc, line 25.
Breakpoint 4 at 0x8049628: file api/kvmxx.cc, line 31.
Breakpoint 5 at 0x8049080: file api/kvmxx.cc, line 21

> 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.

That's not restricted to gdb. C has just three scopes: block (may be
nested), file static, and global. C++ has more. Stating everything
leads to verbose code and potential conflicts. Having more scopes
allows tighter code usually but more head-scratching if something goes
wrong.

In my experience conflicts are very rare. But it's true that when they
happen they can be surprising.

> > 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.

Or they simply avoid it and duplicate the code. You can't always wrap
functions with macros.

> > >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.

The language does more, so it's more complicated.

--
error compiling committee.c: too many arguments to function