Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a comment in the SB API doc about keeping the SB API's lightweight. #108462

Merged
merged 1 commit into from
Sep 13, 2024
Merged

Add a comment in the SB API doc about keeping the SB API's lightweight. #108462

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions lldb/docs/resources/sbapi.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -72,6 +72,17 @@ building the LLDB framework for macOS, the headers are processed with
``unifdef`` prior to being copied into the framework bundle to remove macros
involving SWIG.

Another good principle when adding SB API methods is: if you find yourself
implementing a significant algorithm in the SB API method, you should not do
that, but instead look for and then add it - if not found - as a method in the
underlying lldb_private class, and then call that from your SB API method.
If it was a useful algorithm, it's very likely it already exists
because the lldb_private code also needed to do it. And if it doesn't at
present, if it was a useful thing to do, it's likely someone will later need
it in lldb_private and then we end up with two implementations of the same
algorithm. If we keep the SB API code to just what's needed to manage the SB
objects and requests, we won't get into this situation.

Lifetime
--------
Many SB API methods will return strings in the form of ``const char *`` values.
Expand Down
Loading