mirror of
https://github.com/vczh-libraries/Release.git
synced 2026-08-17 17:31:44 +08:00
Sync Copilot context
This commit is contained in:
@@ -81,6 +81,7 @@ When `VlppParser2` is available to the current project, complex parsers always r
|
||||
- One exception is `WString` which is initialized using `WString::Unmanaged`; such constructors and destructors do not do memory management.
|
||||
- Another exception is `Pair`, `Nullable`, `Variant` or `Tuple` with valid types here.
|
||||
- If pointers are needed, you could only use `T*` and do initialization or finalization explicitly. All such objects should be destroyed in `main`, `wmain`, `WinMain` or `GuiMain`, before memory leak detector runs.
|
||||
- DO NOT reset any raw/shared pointer member to nullPTR in destructorS.
|
||||
- Prefer the latest C++ features (up to C++ 20).
|
||||
- Prefer template variadic arguments, over hard-coded-counting solutions.
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@
|
||||
- Make `Stop()` drain asynchronous work before returning [5]
|
||||
- Use `WString::IndexOf` with `wchar_t` (not `const wchar_t*`) [4]
|
||||
- Use `collections::BinarySearchLambda` on contiguous buffers (guard empty) [4]
|
||||
- Proactively remove code made redundant by refactoring [3]
|
||||
- Proactively remove code made redundant by refactoring [4]
|
||||
- Use `vl::Exception` for expected semantic failures and `CHECK_ERROR` for invariants [3]
|
||||
- Capture dependent lambdas explicitly [2]
|
||||
- Don't assume observable changes are batched [2]
|
||||
@@ -226,6 +226,8 @@ Remove unused dependency parameters and fields as part of the refactor too. If e
|
||||
|
||||
Preserve helper layers that still own observable behavior. For example, flat RPC dispatcher wrappers that only forward can be removed, but JSON wrappers that record generated TypeScript artifacts should stay until their recording responsibility is moved elsewhere.
|
||||
|
||||
When a destructor only resets `Ptr`, shared-pointer, or similar owning members to null, remove that destructor/reset code and let member destruction release resources naturally.
|
||||
|
||||
## Keep design documentation aligned with code after refactoring
|
||||
|
||||
When a refactoring changes architecture or behavior, update the corresponding design documents in the same task rather than deferring it. After a structural change, re-read the related documents and reconcile anything that became misaligned (for example, descriptions of a transport path that no longer exists). Treat documentation drift left by a previous refactoring as part of the current cleanup.
|
||||
|
||||
Reference in New Issue
Block a user