Re: [PATCH] strbuf.c: optimize program logic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



胡哲宁 <adlternative@xxxxxxxxx> writes:

> Junio C Hamano <gitster@xxxxxxxxx> 于2021年1月26日周二 下午2:17写道:
>>
>> "阿德烈 via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
>>
>> > From: ZheNing Hu <adlternative@xxxxxxxxx>
>> >
>> > the usage in strbuf.h tell us"Alloc is somehow a
>> > "private" member that should not be messed with.
>> > use `strbuf_avail()`instead."
>>
>> When we use the word "private", it generally means it is private to
>> the implementation of the API.  IOW, it is usually fine for the
>> implementation of the API (i.e. for strbuf API, what you see in
>> strbuf.c) to use private members.
>>
> Well, I just think most other functions in strbuf.c follow the use
> of `strbuf_avail()` instead of "sb->alloc-sb->len-1", and the
> "sb->alloc-sb->len-1" that appears in `strbuf_read()` is not so uniform.

I actually wouldn't have minded if this were sold as "code clean-up
to use _avail() when we open-code in the implementation of strbuf
API in codepaths that are not performance critical."

I am not sure about the _setlen() side of the thing.  It is quite
obvious what is going on in the original, and it falls into "when it
is written one way that is good enough, replacing it with another
that is not significantly better often ends up being mere code
churn.", I would think.

Thanks.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux