From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MgK0J-0007d0-0k for qemu-devel@nongnu.org; Wed, 26 Aug 2009 11:01:39 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MgK0D-0007Z0-PZ for qemu-devel@nongnu.org; Wed, 26 Aug 2009 11:01:38 -0400 Received: from [199.232.76.173] (port=39756 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MgK0D-0007Yr-Jq for qemu-devel@nongnu.org; Wed, 26 Aug 2009 11:01:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:3896) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MgK0C-0008Ot-SE for qemu-devel@nongnu.org; Wed, 26 Aug 2009 11:01:33 -0400 Subject: Re: [Qemu-devel] Coding style, C++ compatible code References: <51486eb6860d1680c1bce45e310dcd3aae096f43.1251111439.git.quintela@redhat.com> <4A928DF0.9000106@weilnetz.de> <87tyzxnwvb.fsf@pike.pond.sub.org> <4A953E20.8080806@mail.berlios.de> From: Markus Armbruster Date: Wed, 26 Aug 2009 17:01:06 +0200 In-Reply-To: <4A953E20.8080806@mail.berlios.de> (Stefan Weil's message of "Wed\, 26 Aug 2009 15\:52\:32 +0200") Message-ID: <877hwqsjpp.fsf@pike.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil Cc: Anthony Liguori , qemu-devel@nongnu.org Stefan Weil writes: > Markus Armbruster schrieb: >> Stefan Weil writes: >> >>> Juan Quintela schrieb: >>>> Signed-off-by: Juan Quintela >>>> --- >>>> hw/eepro100.c | 6 +++--- >>>> 1 files changed, 3 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/hw/eepro100.c b/hw/eepro100.c >>>> index 0031d36..09083c2 100644 >>>> --- a/hw/eepro100.c >>>> +++ b/hw/eepro100.c >>>> @@ -507,7 +507,7 @@ static void nic_selective_reset(EEPRO100State * s) >>>> >>>> static void nic_reset(void *opaque) >>>> { >>>> - EEPRO100State *s = (EEPRO100State *) opaque; >>>> + EEPRO100State *s = opaque; >>>> logout("%p\n", s); >>>> static int first; >>>> if (!first) { >>>> @@ -1544,7 +1544,7 @@ static ssize_t nic_receive(VLANClientState >>>> *vc, const uint8_t * buf, size_t size >>>> >>>> static int nic_load(QEMUFile * f, void *opaque, int version_id) >>>> { >>>> - EEPRO100State *s = (EEPRO100State *) opaque; >>>> + EEPRO100State *s = opaque; >>>> int i; >>>> int ret; >>>> >>>> @@ -1634,7 +1634,7 @@ static int nic_load(QEMUFile * f, void >>>> *opaque, int version_id) >>>> >>>> static void nic_save(QEMUFile * f, void *opaque) >>>> { >>>> - EEPRO100State *s = (EEPRO100State *) opaque; >>>> + EEPRO100State *s = opaque; >>>> int i; >>>> >>>> if (s->pci_dev) >>>> >>> I wrote these type casts, and I think they make sense. >>> In C++ code, they are even mandatory. >> >> Yes, but this isn't C++. >> >>> I think the arguments why C++ requires this kind of >>> type casts apply to C code (like in Qemu) as well. >>> >>> If it is possible with no or very litte efforts to write >>> code which is C and C++ compatible, I prefer to do so. >> >> I respectfully disagree. Casts from "void *" to "T *" are pure noise. >> Getting into the habit of writing noise casts runs the risk of silencing >> warnings that flag real type errors. > > Hello > > Do you only disagree with my first sentence or with both sentences? We can certainly discuss how to write better C, but appealing to the authority of the C++ rationale is an argument I don't buy. I prefer not to attempt to write C code that behaves identically when interpreted as C++ (extern "C" seems safer and easier). Does this answer your question? > Currently, I seem to be alone with my opinion (at least in qemu-devel). > Nevertheless, the designers of C++ thought that casts from void * to > T * were something very important. I don't know the history of their > decision. I personally think that deriving a data type T from some > bytes in memory which can contain anything is an operation which is > worth being documented by the programmer, and this is exactly what > the cast does. I don't see much value in that, sorry. > My main reason why I try to write portable code is my personal > experience with code reuse and the future development of compilers. > It is quite possible that some day C compilers will require > type casts like C++ compilers do today. I can't read the ISO C committee's mind, but I believe such an incompatible change is extremely unlikely, given the pains they've taken not to break existing C code. > And even today I want to be able to share C code from QEMU with > program code written in C++ (which makes a large part of my > business work). How about extern "C"? [...]