chore: sync Anki note IDs for arrays-and-refs flashcards

Adds ANKI_NOTE_ID properties after syncing cards to Anki deck.
Minor table alignment reformatting from the sync process.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
2026-04-22 23:23:33 +08:00
parent 09ce69a51a
commit ffdbb39158
+19 -11
View File
@@ -1,6 +1,7 @@
* Why can't you return a raw C-style array :cpp:arrays:elaborative-why:
:PROPERTIES:
:ANKI_NOTE_TYPE: Basic
:ANKI_NOTE_ID: 1776793508138
:END:
** Front
Why is returning a raw C-style array illegal in C++?
@@ -15,23 +16,25 @@ return arr; // ❌ returns pointer to dead stack memory
* std::array vs int[]: key differences :cpp:arrays:comparative:
:PROPERTIES:
:ANKI_NOTE_TYPE: Basic
:ANKI_NOTE_ID: 1776793508134
:END:
** Front
How does ~std::array<int, 26>~ differ from ~int[26]~?
** Back
| Feature | ~int[26]~ | ~std::array<int,26>~ |
|----------------------+-----------+---------------------|
| Return by value | No | Yes |
| Copy/assign | No | Yes |
| Knows its own size | No | ~.size()~ |
| Works with STL algos | No | Yes |
| Zero-init with ~{}~ | No | Yes |
|----------------------+---------+--------------------|
| Return by value | No | Yes |
| Copy/assign | No | Yes |
| Knows its own size | No | ~.size()~ |
| Works with STL algos | No | Yes |
| Zero-init with ~{}~ | No | Yes |
Same machine code — zero overhead.
* Task: return character frequency count from string :cpp:arrays:production:
:PROPERTIES:
:ANKI_NOTE_TYPE: Basic
:ANKI_NOTE_ID: 1776793508129
:END:
** Front
Write a function that counts character frequencies in a string and returns the result. The string has only lowercase letters.
@@ -49,6 +52,7 @@ std::array<int, 26> calc(const std::string& str) {
* Stack vs heap: std::array vs std::vector :cpp:arrays:comparative:
:PROPERTIES:
:ANKI_NOTE_TYPE: Basic
:ANKI_NOTE_ID: 1776793508124
:END:
** Front
Where is the data stored for ~std::array<int,26>~ vs ~std::vector<int>(26)~?
@@ -61,6 +65,7 @@ Rule: use ~std::array~ when size is known at compile time (fast, no alloc). Use
* Why const in const T& parameter :cpp:references:elaborative-why:
:PROPERTIES:
:ANKI_NOTE_TYPE: Basic
:ANKI_NOTE_ID: 1776793508119
:END:
** Front
Why write ~const std::string&~ instead of ~std::string&~ for a read-only parameter?
@@ -79,6 +84,7 @@ calc(s); // ❌ without const
* Why & instead of pass-by-value for string param :cpp:references:elaborative-why:
:PROPERTIES:
:ANKI_NOTE_TYPE: Basic
:ANKI_NOTE_ID: 1776793508114
:END:
** Front
Why pass ~std::string~ by reference (~const std::string&~) instead of by value?
@@ -95,21 +101,23 @@ For a function that only reads, the copy is pure waste.
* Reference vs pointer for function parameters :cpp:references:comparative:
:PROPERTIES:
:ANKI_NOTE_TYPE: Basic
:ANKI_NOTE_ID: 1776793508109
:END:
** Front
When do you use ~T&~ vs ~T*~ for a function parameter?
** Back
| Feature | Reference ~T&~ | Pointer ~T*~ |
|-------------------+----------------+--------------------|
| Can be null | No | Yes |
| Dereference | ~str[i]~ | ~(*str)[i]~ |
| Can be reassigned | No | Yes |
| Feature | Reference ~T&~ | Pointer ~T*~ |
|-------------------+--------------+------------|
| Can be null | No | Yes |
| Dereference | ~str[i]~ | ~(*str)[i]~ |
| Can be reassigned | No | Yes |
Use ~T*~ when null is a valid input. Use ~T&~ when the value is *guaranteed to exist* — which is almost always the case for function parameters.
* Rule of thumb: C++ function parameter types :cpp:references:factual:
:PROPERTIES:
:ANKI_NOTE_TYPE: Basic
:ANKI_NOTE_ID: 1776793508102
:END:
** Front
What's the general rule for choosing parameter types in C++ functions?