From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH kvm-unit-tests 2/4] Introduce a C++ wrapper for the kvm APIs Date: Sun, 28 Nov 2010 16:34:39 +0200 Message-ID: <4CF2687F.3000306@redhat.com> References: <1290595933-13122-1-git-send-email-avi@redhat.com> <1290595933-13122-3-git-send-email-avi@redhat.com> <50DD1E97-0ECD-41E6-B6F8-1D78AA4A4876@suse.de> <20101128115921.GB11685@redhat.com> <4CF252DA.1050303@redhat.com> <20101128135749.GB12874@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Graf , Marcelo Tosatti , kvm@vger.kernel.org To: "Michael S. Tsirkin" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:64401 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752951Ab0K1Oep (ORCPT ); Sun, 28 Nov 2010 09:34:45 -0500 In-Reply-To: <20101128135749.GB12874@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 user_ptr { 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 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