On Wed, May 4, 2016 at 4:17 AM, Luca Barbato <[email protected]> wrote: > On 04/05/16 03:56, Vittorio Giovara wrote: >> On Tue, May 3, 2016 at 2:14 PM, Luca Barbato <[email protected]> wrote: >>> On 04/05/16 00:50, Vittorio Giovara wrote: >>>> IMO Anton is right wrt common/uncommon, but Kieran is right for the >>>> trailing number being confusing. >>>> I would propose bitstream_uintread and bitstream_longread which would >>>> make it perfectly clear the maximum length of the read value. >>> >>> _32 and _63 is the least misleading naming, _uintread and _longread >>> fails to deliver the important information and confuses even more. > > So far I'm seeing: > > - bitstream_${something}read > That one is as confusing with the bonus points of not being clear > (is it at most or the amount?) and not state the actual size. > > - bitstream_read/bitstream_read_long > That one is just completely implicit, no idea on what long means > until you read the fine documentation. > > - bitstream_read_${atmost} > Here the confusion would be that there are other function that embed > the number as exact value and not atleast value. > > - bitstream_read_atmost${atmost} > As above but even more explicit > > Assuming you want to read 42 bits, which naming scheme would prevent you > from use the wrong function or at least make you question if you would > have to use another? > > I'm still not seeing how seeing > > v = bitstream_read_32(bc, 11); > > would confuse somebody btw. >
Having a number in the name which is not the exact number of bits it reads is just bad naming. Personally I don't see how a bitstream_read function returning (u)int which can read up to 32-bits could confuse anybody, its limit is implied by its return type. If the long function returns (u)int64 and can read up to 64-bits without any trouble, then its equally clear to me. The only problem get_bits had that it was only reliable up to 23 bits or so, which was not quite clear and something you had to know. - Hendrik _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
