Re: [PATCH v2] gdb: Use C++11 std::chrono

[Pedro Alves <palves@redhat.com>]

On 11/23/2016 02:01 AM, Simon Marchi wrote:

> From what I understand, {user,system}_cpu_time_clock are only defined in
> order to be able to use their time_point type?  It feels a bit
> overengineered, unless you expect those types to differ at some point. 
> Is there an advantage of having different types over having a single
> clock type and this
> 
>   run_time_clock::now (run_time_clock::time_point &user,
> run_time_clock::time_point &system)
> 
> ?

I kept them (from v1) for type-safety: it makes it impossible to swap
the arguments to this new now() method by mistake, or compare old
system time with new user time by mistake.  E.g.:

/usr/include/c++/5.3.1/chrono:650:7: note: candidate: template<class _Clock, class _Dur1, class _Dur2> constexpr typename std::common_type<_Duration1, _Duration2>::type std::chrono::operator-(const std::chrono::time_point<_Clock, _Duration1>&, const std::chrono::time_point<_Clock, _Duration2>&)
       operator-(const time_point<_Clock, _Dur1>& __lhs,
       ^
/usr/include/c++/5.3.1/chrono:650:7: note:   template argument deduction/substitution failed:
src/gdb/mi/mi-main.c:2493:48: note:   deduced conflicting types for parameter ‘_Clock’ (‘system_cpu_time_clock’ and ‘user_cpu_time_clock’)
   duration<double> utime = end->stime - start->utime;
                                                ^

Would you still prefer I remove those?

> Unrelated: for future work, it looks like an std::priority_queue would
> be a nice match for timer_list.

Maybe, but we'd need to inherit from it in order to be able to
delete timers that are not at the top of the heap.  A set or
multiset would be other options.

Thanks,
Pedro Alves