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