[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: xmin versus std::min in gl-render.cc
From: |
Rik |
Subject: |
Re: xmin versus std::min in gl-render.cc |
Date: |
Mon, 14 Oct 2013 11:55:06 -0700 |
On 10/14/2013 11:14 AM, Pascal Dupuis wrote:
> The macro-implementation has some issues when arguments are of
> different types. IMHO the function version will be less error prone.
In this case, this won't be a problem. The function that was replaced only
accepted arguments of the same type (octave_idx_type).
--Rik
>
> Pascal
>
> 2013/10/14 Michael Goffioul <address@hidden>:
>> On Mon, Oct 14, 2013 at 12:35 PM, Rik <address@hidden> wrote:
>>> 10/14/13
>>>
>>> Michael,
>>>
>>> Is there a reason why we define our own min function in gl-render.cc?
>>>
>>> The code at line 47 is
>>>
>>> static octave_idx_type
>>> xmin (octave_idx_type x, octave_idx_type y)
>>> {
>>> return x < y ? x : y;
>>> }
>>>
>>> There is also a class variable, xmin, so it it sometimes confusing whether
>>> the function or the variable is intended. It seems like it would be
>>> cleaner to replace our own function xmin with std::min.
>>
>> I don't remember the reason to be honest. Replacing with std::min seems ok.
>>
>> Michael.
>>
>
>