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

Anthony Liguori
2010-11-28T22:12:18Z

On 11/28/2010 08:40 AM, Michael S. Tsirkin wrote:
>
>> This code is not reusable. Everywhere you use an fd, you have to
>> repeat this code.
>>
> But that's not a lot of code. And you can abstract it away at a higher
> level. For example kvm_init and kvm_cleanup would setup/cleanup
> state in a consistent way.
>
> My experience tells me C++ code has much more boilerplate code that you
> are forced to repeat over and over. This is especially true for unix
> system programming: by the time you are done wrapping all of unix you
> have created more LOC than you are ever likely to save.
>

I've said it earlier but I think it's worth repeating--trying to wrap
libc in "pretty" C++ interfaces is a waste of time.

In an ideal world, the device model doesn't interact at all with libc.
Most of the code simply manipulates internal state and some code will
provide a bridge to well defined internal interfaces.

The nice thing about C++ though is that you can still write "C" code and
compile it with g++ (or even gcc if you care). So you can use objects
where they make sense and not use them where they don't.

>> class kvm::fd is reusable, if you embed it in another object you
>> don't have to worry about errors any more (as long as the object's
>> methods are exception safe).
>>
> To get exception safe code, you have to constantly worry about errors.
> And it's easier to spot an unhandled return code than exception-unsafe
> code: gcc actually has __attribute__((warn_unused_result)) which
> might help catch common errors. No such tool to catch
> exception-unsafe code AFAIK.
>

I tend to agree that writing exception safe code and using exceptions
for expected errors is a bad idea. I think exceptions should be used
primarily for unexpected errors.

Regards,

Anthony Liguori

>
>> --
>> 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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>