On Thu, 26 Jun 2025 at 13:52, Tomasz Kaminski <tkami...@redhat.com> wrote: > > > > On Thu, Jun 26, 2025 at 2:26 PM Jonathan Wakely <jwak...@redhat.com> wrote: >> >> On 26/06/25 11:39 +0200, Tomasz Kamiński wrote: >> >This patch reworks the formatting for the chrono types, such that they are >> >all >> >formatted in terms of _ChronoData class, that includes all required fields. >> >Populating each required field is performed in formatter for specific type, >> >based on the chrono-spec used. >> > >> >To facilitate above, the _ChronoSpec now includes additional _M_needed >> >field, >> >that represnts the chrono data that is referenced by format spec (this value >> >is also configured for __defSpec). This value differs from the value of >> >__parts passed to _M_parse, which does include all fields that can be >> >computed >> >from input (e.g. weekday_indexed can be computed for year_month_day). Later >> >it is used to fill _ChronoData, in particular _M_fill_* family of functions, >> >to determine if given field needs to be set, and thus it's value needs to be >> >> "its" >> >> >computed. >> > >> >In consequence _ChronoParts enum was exteneded with additional values, >> >> "extended" >> >> >that allows more fine grained indentification: >> >> "identification" >> >> > * _TimeOfDay is separated into _HoursMinutesSeconds and _Subseconds, >> > * _TimeZone is separated into _ZoneAbbrev and _ZoneOffset, >> > * _LocalDays, _WeekdayIndex are defiend in included in _Date, >> >> "defined" >> >> > * _Duration is removed, and instead _EpochUnits and _UnitSuffix are >> > introduced. >> >Furthermore, to avoid name conflicts _ChonoParts is now defined as enum >> >class, >> >with additional operators that simplify uses. >> >> I don't love overloading operator- to mean clearing bits, but it does >> make clearing the bits very convenient. Maybe just add a comment >> before operator-(_ChronoParts x, _ChronoParts y) saying that it >> returns a copy of x with all bits from y unset. > > I have added a comment. I actually think operator- makes the filling code > pretty readable, and intuitive. We have set some files, and remove it from > parts.
Yes, it definitely makes the code more readable. I'm just generally cautious about overloading operators to give them meanings which are different from their conventional meanings. Here we have operator- which does not produce the same result as (int)x - (int)y, but this is not a user-facing type so it's OK. >> >> That comment will be >> know that's what the function body Sorry, I'm not sure what happened to the sentence above! What I was trying to say is that a comment will make it easier to see at a glance that operator- unsets bits, without having to parse the function body. >> >> (Which is x&(x^y) I think, right?) > > I think both x&(x^y) and x & ~y gives the same result. I prefer the later. I agree.
