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

[Avi Kivity <avi@redhat.com>]

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