From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH kvm-unit-tests 2/4] Introduce a C++ wrapper for the kvm APIs Date: Wed, 24 Nov 2010 21:33:46 +0200 Message-ID: <4CED689A.6060100@redhat.com> References: <4CED4276.9090103@redhat.com> <4CED445E.30105@redhat.com> <4CED4629.2060804@redhat.com> <4CED4738.2020406@redhat.com> <4CED488D.40806@redhat.com> <4CED4B0E.3030805@codemonkey.ws> <4CED4D36.3060708@redhat.com> <4CED4E5C.5020602@redhat.com> <20101124174311.GL20014@redhat.com> <4CED5074.5080908@redhat.com> <20101124181000.GA21364@redhat.com> <4CED5F8B.1080106@redhat.com> <4CED67A6.5030506@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , Anthony Liguori , Alexander Graf , Marcelo Tosatti , kvm@vger.kernel.org To: Jes Sorensen Return-path: Received: from mx1.redhat.com ([209.132.183.28]:54889 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753808Ab0KXTdy (ORCPT ); Wed, 24 Nov 2010 14:33:54 -0500 In-Reply-To: <4CED67A6.5030506@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 11/24/2010 09:29 PM, Jes Sorensen wrote: > >> > > >> Bug can still be yours but all this virtual inheritance make it much > >> harder to understand what happens. > > > > No, it's easier, since there's a lot less code to chase. > > > > Of course, you have to learn the pattern in the language, but you do > > this once and keep reusing this. If it's emulated in C, you have to > > read all the code over and over again (in different uses), always on the > > lookout to see if it's exactly the same pattern, or if some bug crept in. > > How does it get easier when you have to debug templated code? It is much > harder to read the assembly and match it to the code, so no it becomes > much harder to debug. Oh yes, looking at compiled template heavy code is hard, especially with aggressive inlining (quite common in template code). But what are the C alternatives? forests of #defines, which are even harder, or abstracting via callbacks, which isn't what you want, or simply not doing it. Try coding something like tr1::unordered_hash<> in C. A simple resizeable hash table that doesn't use callbacks for everything. You can't do it. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.