[lldb-dev] fate of TimeValue
Greg Clayton via lldb-dev
lldb-dev at lists.llvm.org
Tue Oct 11 11:36:33 PDT 2016
I am fine with TimeValue going away. I would love to just use STL std::chrono stuff if we can get away with it. If there is a bunch of code that gets re-written all of the time, then using the LLVM TimeValue class is fine if it is needed.
> On Oct 7, 2016, at 10:29 PM, Mehdi Amini via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>> On Oct 7, 2016, at 10:19 PM, Pavel Labath <labath at google.com> wrote:
>> On 7 October 2016 at 21:42, Mehdi Amini <mehdi.amini at apple.com> wrote:
>>>> On Oct 7, 2016, at 9:30 PM, Pavel Labath via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>>>> The llvm-dev thread seems to have fizzed out - I would assume they are
>>>> not interested in std::chrono.
>>> I suggest a totally different course of action: any utility (except specific to the debugger for some reason) should be submitted into LLVM (Support?).
>>> I may be happy to have it available next months in LLVM, and I may not think about looking in every subproject.
>>> The question is not if “they” (I rather have you guys say “we”) are not interested, but rather “is anyone opposing to having utilities wrapping / manipulating std::chrono in LLVM”.
>> I like that idea. I've added you to the reviews so you can see what
>> kind of utility functions I am talking about. BTW, LLVM seems to have
>> a TimeValue class as well (presumably because not all compilers used
>> to support std::chrono)
> I believe TimeValue was created before std::chrono was standardized (first committed in 2004!)
>> - one possibility would be to start using that
>> instead, although I would prefer std::chrono.
> Indeed, I believe we tend to move to the standard version of our utilities when the feature is complete in the compiler versions we support.
> It is also possible that not all of TimeValue features are supported by std::chrono, I haven't compared in detail.
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
More information about the lldb-dev