pit_type as unsigned

[Richard Kimberly Heck]

On 5/11/20 7:00 AM, Jean-Marc Lasgouttes wrote:
> Le 03/05/2020 à 21:03, Richard Kimberly Heck a écrit :
>> That said, there are now a lot of other warnings like this one:
>>
>> /cvs/lyx/lyx-devel/src/Text.cpp:116: warning: implicit conversion
>> changes signedness: 'unsigned long' to 'typename
>> iterator_traits<_List_iterator<Paragraph> >::difference_type' (aka
>> 'long')
>>
>>      Paragraph & tmp = *pars.insert(lyx::next(pars.begin(), **pit +
>> 1**),
>>                         Paragraph());
>
> What about the patch below? I find it ridiculous (and slow) to use
> next() to access our random access container. I am surprised though by
> this issue, since using 'begin() + i' in things like insert or erase
> is supposed to be normal.

Yes, that seems much cleaner.


>> I'm not sure what to do about those. There are similar things in
>> TextMetrics.cpp, and a lot of them. Enough to make me start to wonder
>> whether this is worth it.
>
> What do you have in TextMetrics?
    h += pm.height();

    dim_.des = h - dim_.asc;

With h an unsigned int.

This one's a bit weirder:

        l_margin += bfm.signedWidth(layout.leftmargin) * 4
                     / (par.getDepth() + 4);

Here, l_margin is an int; getDepth() returns unsigned; so the convesion
is actually of bfm.signedWidth. Can l_margin be negative?

This is the vector sort of case I mentioned (not to do with pit_type):

    Row const & r = pm.rows()[row];

Here row is an int but vector::size_type is unsigned long.


>>
>> * It is not clear that depth needs to be an int instead of a depth_type
>>>
>>> @@ -1635,7 +1635,7 @@ int TextMetrics::leftMargin(pit_type const pit,
>>> pos_type const pos) const
>>>           l_margin += bfm.signedWidth(tclass.leftmargin());
>>>       }
>>>
>>> -    int depth = par.getDepth();
>>> +    int depth = int(par.getDepth());
>>
>> I can change it, but then it throws a different warning here:
>>
>>      int nestmargin = depth * nestMargin();
>
> Because nestMargin is naturally unsigned?

I would have thought so, but I often find myself unsure whether
something could be negative. Perhaps what I should do is just flag these
cases for someone else to verify?

Riki