lilypond-devel
[Top][All Lists]
Advanced

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

Re: Issue 5698: int->vsize in various alignment and page-layout methods


From: jonas . hahnfeld
Subject: Re: Issue 5698: int->vsize in various alignment and page-layout methods (issue 563420043 by address@hidden)
Date: Mon, 27 Jan 2020 04:49:32 -0800

On 2020/01/27 12:19:53, dan_faithful.be wrote:
> On Jan 27, 2020, at 03:26, mailto:address@hidden 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;
> 
> 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;
>
> Dan
> 

Fully +1 - one step closer to eventually ditch flower completely. I
don't see a reason for keeping a separate library which nobody else
uses...

https://codereview.appspot.com/563420043/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]