From: Anthony Liguori <anthony@codemonkey.ws>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Alexander Graf <agraf@suse.de>, Avi Kivity <avi@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
kvm@vger.kernel.org
Subject: Re: [PATCH kvm-unit-tests 2/4] Introduce a C++ wrapper for the kvm APIs
Date: Sun, 28 Nov 2010 17:13:41 -0600 [thread overview]
Message-ID: <4CF2E225.7070301@codemonkey.ws> (raw)
In-Reply-To: <20101128222847.GA19081@redhat.com>
On 11/28/2010 04:28 PM, Michael S. Tsirkin wrote:
>
>> But rather need to use ugly factory functions with all sorts of
>> DO_UPCAST. This is really unfriendly especially for writing test
>> cases.
>>
> Yes, I agree. Just moving memory allocation out of there
> will fix most of the ugliness.
>
So here's a short list of things I've been working on that I don't
believe have nice implementations in C.
1) Factories with string based parameters with natural constructor
arguments.
I want to have:
I8254(DriftMode mode)
or:
void i8254_init(I8524 *self, DriftMode mode)
And either be able to directly instantiate the object or create it with
the following command:
dev = create("i8524", "mode", "catchup", NULL);
In C++, I can do:
static Device *i8524_create(DriftMode mode)
{
return new I8524(mode);
}
//...
add_factory("i8524", i8524_create, "mode");
This works because we can use templates to figure out the argument type
to create and automatically set things up for the mode parameter.
Because of overloading, we can have variable arguments so this works for
1, 2, or 10 arguments. In C, at best you would have to do something like:
static Device *i8524_create(ParameterList *list)
{
DriftMode mode;
I8524 *i8524;
if (param_list_has(list, "mode")) {
// should we check the type?
mode = (DriftMode)param_get_as_int(list, "mode"); // or do we
teach param about DriftMode?
} else {
// should we error?
}
i8524 = malloc(sizeof(*i8524));
if (i8524) {
return &i8524->dev; // I have to know how to get to this
}
return NULL;
}
struct factory_info i8524_info = {
.args = (FactoryArgument[]){
{ "mode", "DriftMode" },
{ }
}
};
add_factory("i8524", i8524_create, i8524_info);
And there's so many bad decisions I can make in the process. Do I have
a mechanism to register new types external to the system and make all
types convertable?
My C++ example uses a template specialization to convert from types to
strings. It's simple and extensible. There's no list that needs to be
kept at run time because the compiler does all of the book keeping.
I can let the compiler figure out how to go from I8524 to Device *
because it knows how to.
The same is true for generic get/set properties. In C++, I can do
something like:
class I8524 : public PropertyAccessible {
public:
enum LinkStatus {
LINK_UP,
LINK_DOWN,
};
LinkStatus get_link_status(void);
void set_link_status(void);
};
template <>
I8254::LinkStatus type_from_str(std::string value)
{
if (value == "Down") {
return LINK_DOWN;
} else if (value == "Up") {
return LINK_UP;
}
throw new InvalidTypeConversionException("LinkStatus", value);
}
template <>
std::string type_to_str(I8254::LinkStatus status)
{
if (status == LINK_DOWN) {
return "Down";
} else {
return "Up";
}
}
I8524::I8524(void) {
this->add_property("link_status", &I8524::get_link_status,
&I8524::set_link_status);
}
And now I can do:
Device *dev = new I8524();
cout << dev->get("link_status") << endl;
And it will print: Down
Simple and elegant. The main class has strong error checking, adding
the property is absolutely painless, supporting new types is absolutely
painless. The actual class implementation never sees a string--ever.
There is only one place string->type conversion happens.
I'm not going to show the C version because I know what it involves and
I suspect you do too. It totally sucks and I don't want to spend my
Sunday evening writing it. And that's really my motivation for using
C++. I get tired of doing the work that the compiler should be doing
for me. I want to spend my time doing interesting things like writing
device model test cases instead of writing code to work around the fact
that the C type system is about as powerful as a Vespa.
Regars,
Anthony Liguori
next prev parent reply other threads:[~2010-11-28 23:13 UTC|newest]
Thread overview: 130+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-24 10:52 [PATCH kvm-unit-tests 0/4] API test framework Avi Kivity
2010-11-24 10:52 ` [PATCH kvm-unit-tests 1/4] Makefile: add support for C++ Avi Kivity
2010-11-24 10:52 ` [PATCH kvm-unit-tests 2/4] Introduce a C++ wrapper for the kvm APIs Avi Kivity
2010-11-24 12:59 ` Alexander Graf
2010-11-24 13:33 ` Gleb Natapov
2010-11-24 14:18 ` Anthony Liguori
2010-11-24 14:24 ` Anthony Liguori
2010-11-24 14:32 ` Avi Kivity
2010-11-24 14:31 ` Avi Kivity
2010-11-24 14:41 ` Anthony Liguori
2010-11-24 15:40 ` Gleb Natapov
2010-11-24 15:50 ` Anthony Liguori
2010-11-24 16:10 ` Avi Kivity
2010-12-02 13:52 ` Mike Day
2010-11-24 16:12 ` [PATCH kvm-unit-tests 2/4] " Gleb Natapov
2010-11-24 16:14 ` Avi Kivity
2010-11-24 16:21 ` Gleb Natapov
2010-11-24 16:25 ` Avi Kivity
2010-11-24 16:29 ` Gleb Natapov
2010-11-24 16:33 ` Avi Kivity
2010-11-24 16:52 ` Gleb Natapov
2010-11-24 16:56 ` Avi Kivity
2010-11-24 17:02 ` Gleb Natapov
2010-11-24 17:07 ` Avi Kivity
2010-11-24 17:10 ` Jes Sorensen
2010-11-24 17:12 ` Avi Kivity
2010-11-24 17:14 ` Anthony Liguori
2010-11-24 16:43 ` Anthony Liguori
2010-11-24 16:48 ` Gleb Natapov
2010-11-24 16:56 ` Anthony Liguori
2010-11-24 17:04 ` Gleb Natapov
2010-11-24 16:40 ` Anthony Liguori
2010-11-24 17:33 ` Gleb Natapov
2010-11-24 17:39 ` Avi Kivity
2010-11-24 17:41 ` Gleb Natapov
2010-11-24 17:50 ` Avi Kivity
2010-11-24 18:23 ` Gleb Natapov
2010-11-24 18:50 ` Avi Kivity
2010-11-24 18:17 ` Anthony Liguori
2010-11-24 18:34 ` Gleb Natapov
2010-11-24 18:53 ` Anthony Liguori
2010-11-25 8:35 ` Gleb Natapov
2010-11-24 16:40 ` Jes Sorensen
2010-11-24 16:47 ` Avi Kivity
2010-11-24 16:51 ` Jes Sorensen
2010-11-24 16:57 ` Anthony Liguori
2010-11-24 17:29 ` Avi Kivity
2010-11-24 16:59 ` Avi Kivity
2010-11-24 17:06 ` Jes Sorensen
2010-11-24 17:11 ` Avi Kivity
2010-11-24 17:17 ` Jes Sorensen
2010-11-24 17:25 ` Avi Kivity
2010-11-24 17:28 ` Jes Sorensen
2010-11-24 17:31 ` Avi Kivity
2010-11-24 17:36 ` Gleb Natapov
2010-11-24 17:41 ` Avi Kivity
2010-11-24 17:27 ` Anthony Liguori
2010-11-24 17:35 ` Avi Kivity
2010-11-24 17:36 ` Jes Sorensen
2010-11-24 17:41 ` Avi Kivity
2010-11-24 17:43 ` Gleb Natapov
2010-11-24 17:50 ` Avi Kivity
2010-11-24 18:10 ` Gleb Natapov
2010-11-24 18:55 ` Avi Kivity
2010-11-24 19:29 ` Jes Sorensen
2010-11-24 19:33 ` Avi Kivity
2010-11-24 17:43 ` Jes Sorensen
2010-11-24 17:51 ` Avi Kivity
2010-11-24 17:43 ` Anthony Liguori
2010-11-24 17:45 ` Jes Sorensen
2010-11-24 17:51 ` Avi Kivity
2010-11-24 18:01 ` Anthony Liguori
2010-11-24 18:56 ` Avi Kivity
2010-11-24 16:55 ` Gleb Natapov
2010-11-24 17:01 ` Avi Kivity
2010-11-24 17:16 ` Gleb Natapov
2010-11-24 17:26 ` Avi Kivity
2010-11-24 16:53 ` Anthony Liguori
2010-11-24 17:03 ` Jes Sorensen
2010-11-28 12:27 ` Michael S. Tsirkin
2010-11-28 22:04 ` Anthony Liguori
2010-11-28 22:28 ` Michael S. Tsirkin
2010-11-28 23:13 ` Anthony Liguori [this message]
2010-11-29 8:04 ` Michael S. Tsirkin
2010-11-29 13:44 ` Anthony Liguori
2010-11-29 13:48 ` Avi Kivity
2010-11-24 16:29 ` Jes Sorensen
2010-11-24 16:34 ` Avi Kivity
2010-11-24 16:44 ` Jes Sorensen
2010-11-24 16:49 ` Avi Kivity
2010-11-28 11:59 ` Michael S. Tsirkin
2010-11-28 13:02 ` Avi Kivity
2010-11-28 13:57 ` Michael S. Tsirkin
2010-11-28 14:34 ` Avi Kivity
2010-11-28 16:57 ` Michael S. Tsirkin
2010-11-29 9:22 ` Avi Kivity
2010-11-29 10:47 ` Michael S. Tsirkin
2010-11-29 10:52 ` Avi Kivity
2010-11-29 11:26 ` Michael S. Tsirkin
2010-11-29 13:38 ` Anthony Liguori
2010-11-24 14:10 ` Anthony Liguori
2010-11-24 14:29 ` Avi Kivity
2010-11-24 14:45 ` Anthony Liguori
2010-11-24 14:53 ` Avi Kivity
2010-11-24 14:55 ` Anthony Liguori
2010-11-25 16:32 ` Avi Kivity
2010-11-26 10:16 ` Michael S. Tsirkin
[not found] ` <4CF0CB9A.5060403@redhat.com>
2010-11-28 8:58 ` Michael S. Tsirkin
2010-11-28 9:31 ` Avi Kivity
2010-11-28 9:50 ` Michael S. Tsirkin
2010-11-28 9:54 ` Avi Kivity
2010-11-28 11:44 ` Michael S. Tsirkin
2010-11-28 13:14 ` Avi Kivity
2010-11-28 14:40 ` Michael S. Tsirkin
2010-11-28 22:12 ` Anthony Liguori
2010-11-29 9:30 ` Avi Kivity
2010-11-28 11:49 ` Michael S. Tsirkin
2010-11-28 13:15 ` Avi Kivity
2010-11-28 14:49 ` Michael S. Tsirkin
2010-11-29 9:30 ` Avi Kivity
2010-11-24 10:52 ` [PATCH kvm-unit-tests 3/4] Add support for calling a function in guest mode Avi Kivity
2010-11-26 14:17 ` Michael S. Tsirkin
[not found] ` <4CF0CC26.8030407@redhat.com>
2010-11-28 8:59 ` Michael S. Tsirkin
2010-11-28 9:22 ` Avi Kivity
2010-11-24 10:52 ` [PATCH kvm-unit-tests 4/4] Add sample test using the api test harness Avi Kivity
2010-11-26 14:17 ` Michael S. Tsirkin
[not found] ` <4CF0CC4A.8070100@redhat.com>
2010-11-28 9:04 ` Michael S. Tsirkin
2010-11-28 9:21 ` Avi Kivity
2010-11-29 16:09 ` [PATCH kvm-unit-tests 0/4] API test framework Marcelo Tosatti
2010-12-01 10:38 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CF2E225.7070301@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=agraf@suse.de \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=mtosatti@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox