Gregory Haskins wrote: >>> >>> Hmm..well, you still have pointers. The advantage is that they are >>> implicitly maintained, but now you have to do pointer arithmetic to >>> compute it. :( I personally would probably rather have the explicit >>> management code than the run-time overhead.... >>> >>> >> Well, the pointer arithmetic consists of adding or subtracting zero, >> which gcc luckily knows how to deal with. >> > > Ah....i see. The trick is that we make it the first field. Clever! > >
Even if it isn't the first field, it's worthwhile. >> It's the equivalent of C++ inheritance; no overhead at all. >> > > You mean non-virtuals, right ;) > > Yeah, plain old derived classes but with verbose syntax. > >> Paul Turner did something much like yours, >> > > Ah, wasn't aware, thanks. What is the status? I guess I came this far, > so I will make the final change and you can take it or leave it at your > discretion. The important thing is to get this cleaned up more than who > did it, IMO. > Sure. I'm going to take the first patch that's clean enough. So far this is yours except for that pointer thing, which looks like it depends on per-arch allocation, which conflicts with the vcpu array work. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
