[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.