================ @@ -0,0 +1,66 @@ +//===-- RealpathPrefixes.cpp ----------------------------------------------===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===----------------------------------------------------------------------===// + +#include "lldb/Utility/RealpathPrefixes.h" + +#include "lldb/Target/Statistics.h" +#include "lldb/Target/Target.h" ---------------- royitaqi wrote:
> If you want this to be a Utility class What is the general guidance of when a class should be in "Target" vs. in "Utility"? > dependency inversion technique Like how? I tried to make an interface `RealpathPrefixStats` which contains the two increment functions, then have `TargetStats` implement this interface, in the hope of the Target can create the `RealpathPrefix` and feed its own `TargetStats` to it as `RealpathPrefixStats` (where `RealpathPrefixStats` only sees `RealpathPrefixStats`, which is also in `Utility`). However, there is the lifecycle problem Jim pointed out earlier, that what guarantees that the `RealpathPrefixStats` object lives longer than the `RealpathPrefix` object. In order to guarantee this, I will need to make `Target::m_stats` a shared pointer, then give a weak pointer of `RealpathPrefixStats` to `RealpathPrefix`. Is the above a good plan? Do you see a better approach? --- FWIW, I did search for the inclusion of Target stuff in Utility, but did it wrong and thought it's a common case. This involves a VS Code bug in "Find in Folder...". https://github.com/llvm/llvm-project/pull/102223 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
