book: cpp11: add bitwidth issue to long long chapter

Author: Sunrisepeak

book/build.sh

@@ -11,6 +11,10 @@ echo "[Sub - 1] - Building English book..."
 cd "$SCRIPT_DIR"
 cd en && mdbook build
 
+echo "[imgs] - copy imgs to output directory..."
+cd "$SCRIPT_DIR"
+cp -r imgs book/
+
 echo "Build completed."
 
 # python -m http.server --directory book/book

book/en/src/cpp11/13-long-long.md

@@ -88,6 +88,23 @@ if (bigValue > std::numeric_limits<int>::max() || bigValue < std::numeric_limits
 }
 ```
 
+### Bit-Width Confusion - Why Doesn't the Standard Fix the Bit Width?
+
+**Reasons**
+
+- **Hardware Variations:** Different architectures have different "natural word sizes," such as 16/32/64 bits, and many embedded systems only support 8/16-bit multiplication and division instructions. If `long` were forcibly defined as 64 bits, it would cause significant performance issues on some machines (e.g., 32-bit MCUs).
+  - For example: Performing 64-bit calculations on an 8-bit machine without relevant hardware instructions would require algorithmic simulation, leading to a sharp increase in `instruction cycles`.
+- **Historical and ABI Compatibility:** C/C++ predates the widespread adoption of modern 32/64-bit systems. Many platforms have system interfaces, file formats, and calling conventions that have already encoded the size of `int`/`long` into their ABI. Forcing a change in the standard would break binary compatibility and disrupt the ecosystem.
+- **Zero-Cost Abstraction:** The C/C++ standard is designed to map efficiently to the underlying hardware. It only specifies behavior and minimum ranges, allowing implementations to choose the most natural width for the platform, thereby achieving zero-cost or near-zero-cost abstraction.
+
+**Solutions**
+
+- **Optional Fixed-Width Types in C/C++:** When precise bit widths are required, use types from `<cstdint>`/`<stdint.h>` such as `int8_t`, `int16_t`, `int32_t`, `int64_t`, etc.
+- **Avoid Bit-Width Assumptions and Use Static Assertions:** Avoid assuming the bit width of types during development to improve portability. If certain code relies on specific bit-width assumptions, use static assertions to ensure the width meets expectations: `static_assert(sizeof(T) == N)`.
+
+
+![](../../imgs/long-long.0.png)
+
 ## III. Practice Code
 
 ### Practice Code Topics
@@ -106,4 +123,4 @@ d2x checker long-long
 - [Discussion Forum](https://forum.d2learn.org/category/20)
 - [mcpp-standard Tutorial Repository](https://github.com/Sunrisepeak/mcpp-standard)
 - [Tutorial Video List](https://space.bilibili.com/65858958/lists/5208246)
-- [Tutorial Support Tool - xlings](https://xlings.d2learn.org)
+- [Tutorial Support Tool - xlings](https://xlings.d2learn.org)

book/imgs/long-long.0.png

@@ -88,6 +88,25 @@ if (bigValue > std::numeric_limits<int>::max() || bigValue < std::numeric_limits
 }
 ```
 
+### 位宽疑惑 - 标准中为什么不固定位宽?
+
+**原因**
+
+- **硬件差异问题:** 不同架构“自然字长”不同：16/32/64 位都有，大量嵌入式甚至只有 8/16 位乘除指令.若强行规定(long为64位)，一些机器(32 位 MCU）上会造成巨大的性能损失
+  - 例如: 在8位机器上做64位计算, 但没有相关的机器指令。所以需要通过算法模拟的方式实现, 进而导`指令周期`攀升
+- **历史与 ABI 兼容:** C/C++ 起源早于现代 32/64 位普及，许多平台的系统接口、文件格式、调用约定都已把 int/long 的大小写进了 ABI。标准若强制改变，会破坏二进制兼容和生态
+- **零成本抽象:** C/C++ 标准面向“与机器高效映射”的抽象机，只规定行为与最小范围，让实现能选择对该平台最自然的宽度，从而获得零开销抽象或接近零开销
+
+**解决方案**
+
+- **C/C++提供了可选方案:** 需要精确位宽时，可以使用`<cstdint>/<stdint.h>`里的 `int8_t`、`int16_t`、`int32_t`、`int64_t`...
+- **不假设位宽和静态断言:** 开发时不假设类型的位宽, 从而提高可移植性. 如果部分代码做了位宽假设, 可以通过静态断言来保证位宽符合预期 `static_assert(sizeof(T)==N)`
+
+
+![](../imgs/long-long.0.png)
+
+###
+
 ## 三、练习代码
 
 ### 练习代码主题