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