Dan Eble <d...@faithful.be> writes: > On Jan 27, 2020, at 03:26, hanw...@gmail.com wrote: >> >> LGTM >> >> Not for this change, but could we do a global >> >> vsize -> size_t >> >> search & replace. Do we have a reason to keep our own typedef for this? > > I fully support this. I wasn't going to bring it up yet because I > worried that it would lead to a lot of discussion and I have bigger > fish to fry, but I would like to eliminate the following from flower > because they reduce clarity. > > * real.hh:typedef double Real; > * std-string.hh:typedef size_t ssize; > * std-vector.hh:typedef size_t vsize;
They fix certain types that are used consistently. If you say they "reduce clarity", then every typedef reduces clarity. ssize and vsize may depend on our internal implementations of std-string.hh and std-vector.hh. With the current code base, as far as I know our own types are gone, so size_t seems fine for replacement. I am decidedly less sure about Real. Different sizes than just double might make sense where it is used, say, as the base type of Offset. I am not overly sure that we use it consistently, though. > I would like to replace the following with standard types (uint8_t > etc.). The standard types are portable, but these are not. > > * flower-proto.hh:typedef unsigned char Byte; > * flower-proto.hh:typedef long long I64; > * flower-proto.hh:typedef unsigned char U8; > * flower-proto.hh:typedef short I16; > * flower-proto.hh:typedef unsigned short U16; > * flower-proto.hh:typedef unsigned U32; > * flower-proto.hh:typedef int I32; > * flower-proto.hh:typedef unsigned long long U64; I don't really mind here, but "portable" practically means just portable to GCC and Clang which closely follows GCC, so it's not a problem in practice but at most in readability, and the names are clear enough. At any rate, like with running fixcc.py I think the best point of time would be when the stable branch has seen a formal end of cherry-picking in order not to complicate it. The style changes can happen in parallel on both release branches. With regard to the somewhat more invasive type frobbing, I think I'd wait for it until 2.21.0 has already been out. -- David Kastrup