[Development] API for multiple (but variable number of) return arguments

[Andre Somers]

Op 27-7-2013 23:28, Philip Ashmore schreef:
> On 27/07/13 13:55, Andre Somers wrote:
>> Hi,
>>
>> Op 27-7-2013 14:05, Philip Ashmore schreef:
>>> Hi there.
>>>
>>> On 27/07/13 10:36, Andre Somers wrote:
>>>> 1) pointers to ints
>>>> bool getUnits(int* years, int* monts = 0, int* weeks = 0, int* days = 0,
>>>> int* hours = 0, int* minutes = 0, int* seconds = 0, int* milliSeconds = 0);
>>> You could wrap this into a struct:
>>>      struct TimeSpanResult {
>>>         int m_years, m_months, m_weeks, m_days, m_hours, m_minutes,
>>> m_seconds, m_milliseconds;
>>>      };
>>>
>>> and return it from the call:
>>> TimeSpanResult getUnitsTimeSpan(Qt:Minutes | Qt:Seconds);
>>>
>>> I just used a different name as the return type can't be overloaded.
>>>
>>>
>>> TimeSpanResult getUnitsTimeSpan(int flags)
>>> {
>>>       TimeSpanResult res;
>>>       getUnits((flags & Qt:Years) ? & res.m_years : (int *)0, (flags &
>>> Qt:Years) ? & res.m_months : (int *)0, ...
>>>       return res;
>>> }
>>> I've left out error checking for clarity.
>> Thanks for your suggestion. It is almost the same as option 2, only you
>> replaced the map with a purpose-made struct. I think that indeed that
>> might be beneficial to do.
>>
>> Note that the different name is not needed; I'd like to only expose
>> *one* API for this, and not multiple different ones. If I'd choose your
>> suggestion, there would be no name clashes with other functions doing
>> the same thing. In this case, there would be no clash either, as the
>> arguments are different as well as the return type.
> Sorry for mylack of clarity.
Thanks for your clarification.
> I'm not developing Qt code at the minute and forgot about the Qt way of
> passing flags.
> The clash is with
>     QMap<Qt::TimeSpanUnit, int> getUnits(Qt::TimeSpanFormat);
>
>     QTimeSpanResult getUnits(Qt::TimeSpanFormat);
> would clash.
Ah, right. But as I said: if I'd choose your suggestion, then the 
version returning a QMap would not be there at all. So, no clashes. The 
exact naming of the function is not set in stone either.
> Also, the proposal I'm making is an inline wrapper for option 1, so the
> compiler would eliminate the wrapper completely.
That might be a solution, but I'm not sure if that is the most efficient 
way to do it. I don't think that the int* version is going to be 
significantly more efficient than a direct implementation of the chosen 
version.

Thank you for your inputs though!

André