================
@@ -9,21 +9,28 @@
#ifndef LLDB_TOOLS_LLDB_DAP_BREAKPOINTBASE_H
#define LLDB_TOOLS_LLDB_DAP_BREAKPOINTBASE_H
-#include "llvm/Support/JSON.h"
#include <string>
+#include "llvm/Support/JSON.h"
+
+#include "DAPForward.h"
+
namespace lldb_dap {
struct BreakpointBase {
+ // Associated DAP session.
+ DAP *dap;
----------------
labath wrote:
Although I don't consider myself an lldb-dap maintainer, I want to speak out,
as strongly as I can, against the usage of shared/weak_ptr here. I have a
couple of reasons for that:
1. it's an LLDB tradition that can't be found almost anywhere else in llvm
2. it encourages "vague ownership" semantics, where noone can be really sure
whether some object still exists or not (so it handles the "not" case "just in
case"). This in turn leads to a lot of dead/untested code. If what you say is
true and the DAP object is the owner of this object, then I would say this is a
reason to *not* use weak (or shared) pointers, as that the owned object should
be able to assume that its owner is always around (and not worry about what to
do with a possibly empty result of `weak_ptr::lock`). LLDB sort of has an
excuse for using shared_ptrs (a python scripting API, which means code outside
our influence can hold on to lldb objects), but I don't think anything like
that applies to lldb-dap.
3. it's impossible to distinguish a "potentially empty" shared/weak pointer
from one that is always set. This is kind of similar to the previous one, but
without the temporal aspect. Even if you ignore the possibility of the object
going away mid-flight, you still can't enforce that it is always there to start
with. With raw pointers/reference, you can.
4. Makes it harder to maintain const correctness. It still possible
(`shared_ptr<const T>` is a thing), but it seems people don't usually bother to
do that. Const correctness is of particular importance for multithreaded code.
5. All of this copying, locking and atomic operations inherent in shared
pointers make things slower.
https://github.com/llvm/llvm-project/pull/114881
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
