On 09/24/13 15:01, Paolo Bonzini wrote:
> Il 24/09/2013 10:46, Laine Stump ha scritto:
>> On 09/23/2013 08:03 PM, Laszlo Ersek wrote:
>>> ... and adapt functions that would cast away the new const qualifier.
>>>
>>> Given
>>>
>>> typedef virSocketAddr *virSocketAddrPtr;
>>>
>>> Compare the parse trees of the following two declarations:
>>>
>>> (a) const virSocketAddrPtr addr;
>>> (b) const virSocketAddr *addr;
>>
>> Umm.. Eric? A little help? :-)
>
> Heh :)
>
> In more layman terms, you can read types out in English like this:
>
> (1) read the type from right to the left
>
> (2) if "const" is the first token, read it as "that is constant" and
> associate it to the closest type. Alternatively, move such a "const"
> right but no further than the first *.
>
> (3) if "const" is anywhere else, read it as "constant"
>
> So:
>
> const virSocketAddrPtr addr
> ("addr is a virSocketAddrPtr that is constant")
> -> virSocketAddrPtr const addr
> ("addr is a constant virSocketAddrPtr")
> -> virSocketAddr * const addr
> ("addr is a constant pointer to virSocketAddr
>
> const virSocketAddr *addr
> ("addr is a pointer to a virSocketAddr that is constant")
> -> virSocketAddr const *addr
> ("addr is a pointer to a constant virSocketAddr")
>
> Laszlo, correct me if I'm wrong.
Never thought of it this way before, but it does seem to work in the
examples above :)
>
> I suspect that forbidding const.*Ptr in "make syntax-check" wouldn't be
> a bad idea.
The pattern should probably require some whitespace in the middle as
well, if constWhateverPtr typedefs are to be accepted as valid.
Thanks
Laszlo
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list