https://github.com/smarthypercube/aoc2023-rust

Advent of Code 2023 Rust 解题代码
https://github.com/smarthypercube/aoc2023-rust

Last synced: about 1 year ago
JSON representation

Advent of Code 2023 Rust 解题代码

• Host: GitHub
• URL: https://github.com/smarthypercube/aoc2023-rust
• Owner: SmartHypercube
• Created: 2023-12-02T14:02:40.000Z (over 2 years ago)
• Default Branch: master
• Last Pushed: 2023-12-06T10:23:06.000Z (over 2 years ago)
• Last Synced: 2025-02-10T08:16:28.623Z (over 1 year ago)
• Language: Rust
• Size: 42 KB
• Stars: 0
• Watchers: 1
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

          
# Advent of Code 2023 Rust 解题代码

**内含解题代码**，我只会在每道题的排行榜满了后再上传代码。

我还在入门 Rust，仅供参考，欢迎批评指正。

## 运行方式

`cargo run --bin day1` 运行 day1 的解题代码，以此类推。

## 代码结构

`data` 目录下是输入数据，`src` 目录下是解题代码。

## 额外想法

- **Day1**：有一些全局静态只读的信息时，想避免每次调用都在栈上写入，于是挪到顶层改成 const，结果发现还挺麻烦的。要重命名成大写，还不能用 Vec，还要写类型。

- **Day2**

    1. 感觉没有 monad 的 do 记法，写 parser 不太方便。我选择了硬写成 monad 风格，这样学习成本比较低，在我看来代码也比较直观，但不断重复的噪音太多了。更好的做法应该是多用一些 `nom::combinator` 和 `nom::sequence` 里的函数，但我感觉不用这些函数也很好写，而且反而更清晰直观一些（例如 `terminated`，完全不如先后调用两个 parser 然后扔掉第二个 parser 的结果来得直观）。

    2. 因为不太懂生命周期的逻辑（之前写过的函数正好都被自动推断了合适的生命周期，但闭包的规则变了，和函数不一样），导致花了很久研究为什么把函数改成一模一样的闭包就总是报错（最小复现方法：`let f = |x: &str| -> &str { x };`）。

    3. `for` 循环和引用接合在一起时写起来感觉怪怪的，`main` 函数中处理第二题的 3 层循环，一会在 `in` 右边加 `&`，一会不加。一会要在 `in` 左边加 `&`。感觉缺少一致性，写的时候总要思考一下。

- **Day3**：尝试像 Python 一样写代码，感觉不错。 然而 `.enumerate()` 会得到 `usize`，以及切片只支持 `usize` 令人不爽，搞得我只好到处转换类型。我用 Haskell 的经验是，混着用多种整数类型，尤其是如果还有无符号整数类型，会很麻烦，而且是绝大多数情况下几乎不会带来什么额外好处的麻烦。

- **Day4**：今天做了一些感觉比较“优雅”的事情，例如 `Card` 类型定义了一个 `win_count` 方法，`parser` 函数体不用写一堆 `nom::`，并且又不污染全局名字空间了，`parser` 完全没有用 monad 风格，而是只用了 nom 提供的工具函数。

- **Day5**：迭代器风格很方便做 `filter`、`map`、`min` 等操作，但循环风格方便一边循环一边插入新元素。要是有一种类似 `yield` 的写法就好了，可以在循环过程中产生新元素，但最后方便地对整体做 `map` 和 `min`。

- **Day6**：过于简单。