- 博客(20)
- 收藏
- 关注
RSS订阅原创 Rust知识点——注释与文档注释
在 Rust 中，注释早已超越了其传统定义。常规注释（尤其是）是 Rust 追求极致安全、鼓励开发者承担责任的体现。文档注释（///和rustdoc）则是 Rust 追求高质量生态、强调“开发者体验”和“API 正确性”的产物。它们是可测试的、可链接的、语义化的“活契约”。编写马虎的注释（或不写注释）在其他语言中可能只是“坏习惯”，但在 Rust 中，这近乎于“渎职”。因为在 Rust 的世界里，文档即代码，代码即文档。掌握这套哲学，是成为一名合格 Rustacean 的必经之路。
2025-10-31 00:03:12
505
原创 Rust知识点——异步递归的解决方案
异步递归在 Rust 中的困境，是类型安全和零成本抽象必然带来的代价。但正是这种"约束"，迫使我们重新审视算法设计，寻找更优雅、更高效的解决方案。真正的 Rust 专家，不会抱怨"为什么 Rust 不支持异步递归"，而是会深入理解背后的原因，熟练掌握 Box、宏和迭代改写等多种工具，并在每个具体场景中做出最优的工程决策。这不仅是技术能力的体现，更是对性能、可维护性和类型安全的深刻理解和平衡艺术。🔄💪。
2025-10-30 18:25:42
948
原创 Rust知识点——异步错误处理最佳实践
异步错误处理是 Rust 编程中最具挑战性，也最能体现工程素养的领域之一。它不仅需要对FutureResult等语言特性的深刻理解，更需要对系统可靠性、可观测性和性能的全局思考。真正的 Rust 专家，会在简洁性与完备性、性能与健壮性之间找到精妙的平衡。他们不会过度设计，为每个可能的错误场景编写复杂的处理逻辑；也不会粗暴地使用unwrap()或expect()，让程序在遇到错误时直接崩溃。
2025-10-30 18:18:56
892
原创 Rust知识点——Context与任务上下文传递
Context 与任务上下文传递看似复杂，实则是 Rust 异步编程中最优雅、最有效率的设计之一。它以最小的成本实现了最大的灵活性和性能。
2025-10-30 18:08:50
811
原创 Rust知识点——异步任务的生命周期管理
在某些场景中，你需要实现自定义 Future 来精细控制任务的生命周期。这时，正确理解和实现 Waker 机制就变得至关重要。一个常见的模式是状态机 Future——通过枚举来表示 Future 的不同状态，在 poll() 方法中根据当前状态进行转换。这种模式提供了对任务生命周期的完全控制，但也要求开发者手动管理状态转换和 Waker 注册。异步任务的生命周期管理在表面上看似神秘，但本质上遵循着清晰的、可预测的规律。从创建、轮询、挂起、唤醒到完成，每一个阶段都有其精确的目的和影响。
2025-10-30 18:02:01
708
原创 Rust知识点——Waker与唤醒机制
虽然大多数开发者只需要使用运行时提供的 Waker，但在某些特殊场景下（如嵌入式系统、自定义调度器），你可能需要实现自己的 Waker。实现 Waker 的核心是定义RawWaker和对应的 vtable。你需要提供：如何唤醒任务（wake和如何克隆 Waker（clone如何清理资源（drop一个典型的实现会使用Arc包装一个包含任务 ID 和发送器（Sender）的结构体。当wake被调用时，通过 Sender 将任务 ID 发送到执行器的就绪队列。
2025-10-30 17:58:00
631
原创 仓颉知识点——元组的使用
什么时候应该使用元组，什么时候应该定义一个专门的类或结构体？这是一个体现设计判断力的选择题。数据组合是临时性的，只在局部范围内使用（如函数内部、函数返回值）数据的语义非常明显，无需额外的命名就能理解（如坐标(x, y)、键值对数据组合不包含业务逻辑，纯粹是数据的打包数据会在多个模块间传递，需要明确的类型名称来表达语义数据包含业务逻辑或行为（方法），不仅仅是被动的数据容器数据的字段含义不明显，需要通过命名字段来增强可读性举个例子：如果你在实现一个简单的数学函数，返回除法的商和余数，使用元组。
2025-10-29 17:27:16
677
原创 仓颉知识点——继承机制
继承是仓颉面向对象编程中一把强大的工具，但它从来不应该是设计的起点或目的。真正的专业开发者，会在继承、组合和接口之间做出精准的权衡：当存在清晰的"is-a"关系，且需要复用大量实现时，选择继承当只需要复用行为，而无严格类型关系时，选择组合当需要定义能力契约，且支持多重实现时，选择接口在仓颉的大型项目开发中，继承应该被谨慎而明智地使用。它不是万能药，过度使用会导致系统僵化、难以测试和维护。
2025-10-29 17:18:48
829
原创 仓颉知识点——访问修饰符
访问修饰符是仓颉编程中最不起眼，却又最能体现专业功底的细节。它们是封装原则的具体实现，是模块化设计的基础工具，更是系统长期演化能力的重要保障。这个元素应该暴露给谁？为什么？未来会如何演化？只有养成这种**"权限意识"**，你才能在仓颉的世界中，构建出既灵活又稳定、既强大又易维护的软件系统。这不仅是技术能力的体现，更是工程素养的升华。💪🔒。
2025-10-29 17:09:26
456
原创 仓颉知识点——抽象类的使用
抽象类是仓颉面向对象编程中一把锋利的双刃剑。用得好，它能让你的代码优雅、可扩展且易于维护；用得不好，它会让系统变得僵化、难以测试和修改。真正的仓颉专家，不仅要理解抽象类的语法和特性，更要在实践中反复推敲何时抽象、如何抽象、抽象到何种程度。这需要对业务领域的深刻理解，对设计模式的熟练运用，以及对性能和可维护性的精准权衡。只有这样，你才能在仓颉的世界中，真正驾驭抽象的力量，构建出既强大又优雅的软件系统。💪✨。
2025-10-29 17:00:40
499
原创 仓颉知识点——HashMap 实现原理
HashMap是一个在时间、空间和实现复杂度之间做出精妙平衡的艺术品。在仓颉中，它不仅是一个工具，更是对开发者内功的考验。深入理解其冲突解决策略、扩容机制，并在实践中思考Key的设计、初始容量的选择乃至并发安全问题，你才能真正发挥出仓颉这门语言的全部潜力，构建出真正稳定、高效且安全的系统。💪。
2025-10-29 16:45:42
730
原创 范式判断笔记
指一个非主属性依赖于另一个非主属性，而不是直接依赖于主键。如果有一个非主属性通过另一个非主属性依赖于主键，就形成了传递依赖。：在关系数据库中，一个非主属性依赖于主键的一部分，而不是整个主键。关系模式R，F（依赖集），R属于BCNF，且F中的每个依赖的决定因素必定包含R的某个候选码。仅当前关系模式是1NF，且每个非主属性完全依赖候选键。在第一范式的基础上，消除非主属性对候选键的部份依赖。在第二范式的基础上，消除非主属性对候选键的传递依赖。在第三范式的基础上，消除主属性对候选键的传递依赖。
2024-10-20 21:05:42
314
原创 软件设计师笔记——错题分析（2018年下半年真题）
发生在模块之间通过传递复杂的数据结构（如记录或对象）进行交互，但只使用了其中的一部分。：指的是两个模块通过参数传递数据的方式进行交互，模块之间只共享数据而不共享控制信息。：用户或应用程序不需要了解数据是如何被分割成多个部分（分片）并分布在多个节点上的。：是最紧密的耦合类型，发生在一个模块直接访问另一个模块的内部数据或代码。：用户或应用程序不需要知道数据是如何被复制到多个节点或服务器上的。：指的是一个模块向另一个模块传递控制信息，以影响后者的执行逻辑。：用户或应用程序不需要知道数据或资源的物理位置。
2024-10-20 20:42:33
243
原创 软件设计师笔记——错题分析（2016年下半年真题）
解析：磁盘容量为300g，一个物理块大小为1m，则该磁盘一共有:300*1024/1=300*1024块 位示图中用每一位表示一个磁盘块的使用情况，1个字是32位，所以1个字可以表示32个物理块的使用情况，需要 300*1024/32=9600。注意递归可枚举语言与递归语言的区别，后者是前者的一个真子集，是能够被一个总停机的图灵机判定的语言。这种文法规定的语言可以被。如下图所示，其中顶点表示项目里程碑，连接顶点的边表示包含的活动，边上的数字表示相应活动的持续时间（天），则完成该项目的最少时间为（18）天。
2024-10-09 11:35:23
1092
原创 解决gitblit运行问题
开始想的是直接把IP地址固定下来，后面发现不行（因为我要连校园网，如果固定IP地址就会连不上校园网）；所以后面我想把server.httpBindInterface和server.httpsBindInterface的IP地址变成0.0.0.0，gitblit.cmd可以运行，但是浏览器执行不出来；：每次运行gitblit都需要改一下server.httpBindInterface和server.httpsBindInterface的IP地址，因为每次登陆电脑会自动获取一个IP地址，每次都要改，很麻烦。
2024-04-14 16:29:26
859
1
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人