pit_type as unsigned
Richard Kimberly Heck
rikiheck at lyx.org
Mon May 11 21:55:38 UTC 2020
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
More information about the lyx-devel
mailing list