Re: o3tl::make_unsigned

On 31/01/2020 12:41, Luboš Luňák wrote: I'm fine with this if this would be ok for you (the way I see it, this o3tl::ssize() would be basically my proposed o3tl::make_signed() with a different name). see here: On 30/01/2020 11:39, Stephan Bergmann wrote: > C++20 will have ssize for container

Re: o3tl::make_unsigned

On Friday 31 of January 2020, Stephan Bergmann wrote: > If you want to follow down the "Unsigned considered harmful" path, > another option that may long-term prove more fruitful then that > o3tl::make_signed could be an o3tl::ssize mimicing C++20 std::ssize > (

Re: o3tl::make_unsigned

On Friday 31 of January 2020, Kaganski Mike wrote: > On 2020-01-30 17:25, Luboš Luňák wrote: > > Not worth it. That'd be like doing error checking for every memory > > allocation - we also bother only with those few cases where it > > realistically can go wrong. > > I disagree with this approach.

Re: o3tl::make_unsigned

On 31/01/2020 10:23, Kaganski Mike wrote: My take on this is https://gerrit.libreoffice.org/c/core/+/87762. I can see why it might be considered wrong and rejected (e.g., because overhead it brings is unacceptable; or because asserting on valid range is considered correct...) - but at least this

Re: o3tl::make_unsigned

On 2020-01-30 17:25, Luboš Luňák wrote: > On Thursday 30 of January 2020, Kaganski Mike wrote: >> Can the hypothetical make_signed function return a signed integer when >> there's a bigger integer type exist, > > Yes. > >> and a struct with overloaded >> operator<=> when there's not, and that o

Re: o3tl::make_unsigned

On Thursday 30 of January 2020, Kaganski Mike wrote: > Can the hypothetical make_signed function return a signed integer when > there's a bigger integer type exist, Yes. > and a struct with overloaded > operator<=> when there's not, and that overloaded operator<=> would > check if contained uns

Re: o3tl::make_unsigned

On Thursday 30 of January 2020, Stephan Bergmann wrote: > On 30/01/2020 12:56, Luboš Luňák wrote: > > This contradicts your original mail, where you stated that what is used > > is "if (sal_uInt32(e1) < e2) ...// (B)" (i.e. without the <0 check). > > And > > Maybe it is unclear, but my origin

Re: o3tl::make_unsigned

On 2020-01-30 15:30, Stephan Bergmann wrote: > On 30/01/2020 12:56, Luboš Luňák wrote: >> On Thursday 30 of January 2020, Stephan Bergmann wrote: >>> On 29/01/2020 17:14, Luboš Luňák wrote:    Exactly my point. It's just that you seem to find it guaranteed that people won't mess up range

Re: o3tl::make_unsigned

On 30/01/2020 12:56, Luboš Luňák wrote: On Thursday 30 of January 2020, Stephan Bergmann wrote: On 29/01/2020 17:14, Luboš Luňák wrote: Exactly my point. It's just that you seem to find it guaranteed that people won't mess up range checks and only likely there won't be titanically huge files

Re: o3tl::make_unsigned

On Thursday 30 of January 2020, Stephan Bergmann wrote: > On 29/01/2020 17:14, Luboš Luňák wrote: > > Exactly my point. It's just that you seem to find it guaranteed that > > people won't mess up range checks and only likely there won't be > > titanically huge files/allocations/containers, and I

Re: o3tl::make_unsigned

On 29/01/2020 17:14, Luboš Luňák wrote: On Wednesday 29 of January 2020, Stephan Bergmann wrote: On 29/01/2020 15:20, Luboš Luňák wrote: Which is the assumption. Using o3tl::make_signed would not require such an assumption, or it would be even less likely false. But a precondition-free o3t

Re: o3tl::make_unsigned

On Wednesday 29 of January 2020, Stephan Bergmann wrote: > On 29/01/2020 15:20, Luboš Luňák wrote: > > Which is the assumption. Using o3tl::make_signed would not require such > > an assumption, or it would be even less likely false. > > But a precondition-free o3tl::make_signed would need to map

Re: o3tl::make_unsigned

On 29/01/2020 15:20, Luboš Luňák wrote: On Wednesday 29 of January 2020, Stephan Bergmann wrote: On 29/01/2020 11:41, Luboš Luňák wrote: On Wednesday 29 of January 2020, Stephan Bergmann wrote: if (o3tl::make_unsigned(e1) < e2) ...// (C) instead of (B), avoiding an explicit cast and

Re: o3tl::make_unsigned

On Wednesday 29 of January 2020, Stephan Bergmann wrote: > On 29/01/2020 11:41, Luboš Luňák wrote: > > On Wednesday 29 of January 2020, Stephan Bergmann wrote: > >> if (o3tl::make_unsigned(e1) < e2) ...// (C) > >> > >> instead of (B), avoiding an explicit cast and making the intent clear. >

Re: o3tl::make_unsigned

On 29/01/2020 11:41, Luboš Luňák wrote: On Wednesday 29 of January 2020, Stephan Bergmann wrote: if (o3tl::make_unsigned(e1) < e2) ...// (C) instead of (B), avoiding an explicit cast and making the intent clear. (o3tl::make_unsigned is defined "header-only", so can be used everywhere LI

Re: o3tl::make_unsigned

On Wednesday 29 of January 2020, Stephan Bergmann wrote: >if (o3tl::make_unsigned(e1) < e2) ...// (C) > > instead of (B), avoiding an explicit cast and making the intent clear. > (o3tl::make_unsigned is defined "header-only", so can be used everywhere > LIBO_INTERNAL_ONLY is defined.) > > T