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

[Avi Kivity <avi@redhat.com>]

On 11/29/2010 12:47 PM, Michael S. Tsirkin wrote:
> On Mon, Nov 29, 2010 at 11:22:44AM +0200, Avi Kivity wrote:
> >  >>   No need for an additional toolchain.
> >  >
> >  >It's a feature :) This way  you are not forced to rewrite all code each
> >  >time you realize you need an extra check, and checks can be added
> >  >gradually without breaking build.
> >
> >  You can see that user_ptr<>  is not just for the checks, it adds
> >  functionality (sizeof-less copy_from and copy_to).  That's usually
> >  the case.  If there's something you must not do because of some
> >  rule, there's also something you want to do, and those become member
> >  functions.
> >
> >  In C++ you could also introduce user_ptr<>  gradually, it won't break
> >  anything.
>
> Yes but in
> 	void foo(void *p) {
> 		bar(p);
> 	}
> both foo and bar must be converted.

No.  You can convert from user_ptr<> to __user * and back.

> >  >Sparse has some advantages: it makes the contract obvious so you clearly
> >  >see it's a pointer and know ->, [], + will work, * and<<   will not.
> >
> >  I don't really see how you can tell this from __user.
>
> I can tell this is a pointer from T *foo :), and I can tell
> it has some attribute.
>
> >   You have to
> >  look up the definition.  For user_ptr<>, the definition is actually
> >  available.
>
> The definition for __user is also available:
> #ifdef __CHECKER__
> # define __user                __attribute__((noderef, address_space(1)))
> #else
> # define __user
> #endif
>
> Which is a very transparent way to say: this is just a checker
> attribute, it does not affect actual code.

Can you tell you must not dereference it?

> With a template we go 'I have overridden + but compiler should
> optimize it back to original'. Note the should :)

We do this in C all the time with pte_t and lots of inlines.

> >  Do a 'git grep hash' for examples of duplication.
>
> I see. Don't know enough about tcg to fix unfortunately, but
> the logic is different: e.g. sparc opcode table is completely
> static, translation cache is dynamic, jump cache has
> static size but dynamic content, qdict could do
> with linear lookups just as well. So it could
> just be different optimization strategies.

The default is duplication.  With C++ your default is 
tr1::unordered_map<> and you can optimize it later if you like.

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