[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] libxc, libxenstore: make the headers C++-friendly
>>> On 22.01.13 at 18:07, Razvan Cojocaru <rzvncj@xxxxxxxxx> wrote: >> > - struct hvm_hw_cpu *new=h; >>> - struct hvm_hw_cpu_compat *old=h; >>> + struct hvm_hw_cpu *newcpu=(struct hvm_hw_cpu *)h; >>> + struct hvm_hw_cpu_compat *old=(struct hvm_hw_cpu_compat *)h; >> >> That's not really C++. But yes, I recognize that the alternative >> would be an even uglier #ifdef. > > Is this about reinterpret_cast<type>(h)? I'm not trying to turn a C > header into a C++ header, I'm trying to make a C header usable with C++, > obviously. I understand that. Yet I'm opposed to casts in C where they aren't needed. >>> - } private; \ >>> + } rprivate; \ >> >> This is a no-go: In a public header, you can't change names like >> this. Since the stuff under io/ isn't really tied to >> __XEN_INTERFACE_VERSION__, I'm also not immediately seeing >> how else you could adjust this. > > That ammounts to not being able to use libxc with C++ if you ever use > ring.h's DEFINE_RING_TYPES() macro (that is, if you ever use mem_events). Not exactly - with all of this being macros, the _consumer_ of DEFINE_RING_TYPES() could define private to rprivate (or whatever is being liked best), with the respective uses of the other macros using that field suitably placed inside the scope of that #define. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |