Over the past few months, I’ve been working on an important refactor in Cantor: migrating the editor for command entries from our in-house QTextDocument implementation to the powerful KTextEditor framework. In my previous update, I described how Phase 1 laid the foundation—command cells were migrated to use KTextEditor::View, enabling basic syntax highlighting and a modern editing experience.

Today, I’m excited to share that Phase 2 is now complete! With this milestone, the migration of command entries to KTextEditor is fully in place, ensuring that all existing functionality works smoothly without regressions. This achievement provides a solid foundation for future enhancements while keeping Cantor stable and reliable for everyday use.

What’s New in Phase 2

With Phase 2 now complete, command entries are fully integrated into KTextEditor. Along the way, we introduced three major upgrades to Cantor’s core architecture, paving the way for a more consistent, powerful, and future-ready user experience.

🔹 Unified Highlighting Framework

All syntax highlighting in Cantor is now powered by KSyntaxHighlighting, the same robust engine behind Kate and KWrite. This change ensures that every backend (such as Python, Maxima, R, Octave, etc.) benefits from a consistent, accurate, and highly reliable highlighting system.

Previously, each backend shipped with its own ad-hoc rules that were difficult to maintain and often inconsistent in style. With the new centralized approach, Cantor handles highlighting uniformly, not only providing a smoother user experience but also laying the groundwork for future support of custom themes and user-defined keywords.

🔹 Unified Completion Infrastructure

Code completion has likewise been consolidated into a common framework coordinated through KTextEditor. In the past, each backend had its own incomplete and sometimes inconsistent completion logic. Now, all completion requests are handled in a unified, predictable manner, with backend-specific intelligent suggestions seamlessly integrated.

The result is less duplicated code, easier maintenance, and—most importantly—a more cohesive user experience. Whether you are writing Python scripts or Maxima formulas, code completion now behaves consistently, making Cantor feel smarter and more reliable.

🔹 Reduced Code Redundancy

By adopting KTextEditor as the core for command entry editing, we eliminated a significant amount of custom code that had been written in Cantor over the years to handle code completion and highlighting for the different supported languages.

This streamlining improves maintainability, reduces potential bug risks, and makes Cantor’s codebase more approachable for new contributors. Developers no longer need to reimplement low-level editor features, allowing them to focus on advancing high-level functionality. In short: less boilerplate, more room for innovation.

Functional demonstration: new and old comparison, take a look!

Thanks to the new KSyntaxHighlighting backend, we can now temporarily change the theme of command entries, demonstrating future possibilities.

Please note that this is currently a preview feature; global “sheet themes” (applying themes uniformly to the entire sheet,) are our next steps.

• Breeze Dark

  

• Github Dark

• Breeze Light

By integrating KTextEditor, Cantor now provides a unified and reliable code completion experience for all backends (such as Python, R, and Maxima).

Cantor also supports consistent multi-cell handling, with themes and syntax highlighting applied uniformly.

Why This Matters

This migration is not just a technical change under the hood—it directly impacts how Cantor evolves:

• Stability first: by ensuring no regressions during the migration, users can continue to rely on Cantor for daily work without disruption.
• Consistency across backends: highlighting and completion now feel the same, no matter which computational engine you choose.
• Future-proof foundation: less redundant code and more reliance on KDE Frameworks means Cantor can keep pace with new features in KTextEditor and the broader KDE ecosystem.

What’s Next

With command entries now fully migrated, the door is open for exciting new improvements:

• Theming support: enabling custom color schemes and styles, giving users the ability to tailor Cantor’s appearance to their preferences.

• Vi mode integration: bringing modal editing from Kate into Cantor.
• Spell checking: powered by Sonnet, useful for Markdown and explanatory text inside worksheets.
• Smarter backend completions: richer suggestions, function signatures, and inline documentation.
• Performance work: optimizing for very large worksheets and heavy computations.

Theming support (planned)

For now, Cantor will keep the Default theme, which uses the desktop palette. This preserves the familiar look and behavior.

Next, we plan to introduce a Worksheet Theme setting. Users will be able to:

• Stay with Default (desktop palette, as before), or
• Choose a theme from KTextEditor/KSyntaxHighlighting, just like in Kate.

The selected theme will apply consistently across the worksheet—including command entries and results—for a unified appearance. Instead of relying on hardcoded colors or the system palette, Cantor will use the color roles provided by KTextEditor and KSyntaxHighlighting.

This approach avoids performance overhead from repeatedly reading theme files, ensures instant updates when switching themes, and lays the foundation for richer customization in the future—such as clearer distinctions between prompts, results, and errors, all within a consistent global style.

Qt是一个用于构建图形用户界面(GUI)和跨平台应用程序的“超级工具箱”。Qt提供了一套标准化的”零件“，只需要用这些零件组装一次，应用程序就能在所有主流的操作系统上运行。

在我们深入今天的主题之前，对于初次接触Qt的同学，理解其设计的“三大基石”至关重要。

Qt的三大基石

QObject

在Qt中，几乎所有有意义的对象(窗口、按钮、定时器等)都继承自**QObject这个始祖类。QObject之所以如此特别，是因为它是通往Qt元对象系统（Meta-Object System）**的大门。

元对象系统是什么？ 你可以把它想象成每个QObject都随身携带的一张详细的“身份信息卡”。这张卡片不是C++原生就有的，而是Qt通过一个名为MOC（Meta-Object Compiler）的预处理器工具，在编译前为你的代码自动生成的。这张“身份卡”上记录了：

• 对象的类名是什么（className()）。
• 它能发出哪些信号。
• 它有哪些可供调用的槽函数。

正是因为有了这张预先生成好的“信息卡”，Qt才能够在程序运行时，动态地查询对象的信息，并实现下面要讲的、极其灵活的信号与槽通信机制。

信号与槽(singal & Slots)

这是Qt框架的灵魂，是一种无与伦比的对象间通信机制。让我们用一个生活中的例子来理解它：

• 传统方式（函数调用）： 你按下一个电灯开关，开关必须明确知道灯泡在哪里，并且调用灯泡的turnOn()方法。开关和灯泡“耦合”得非常紧，换个灯泡可能就要改动开关的“接线”。
• Qt的方式（信号与槽）：
  • 一个QPushButton（按钮）被点击时，它不会去找具体要干什么事的对象，它只是向外大喊一声：“我被点击了！”（这就是**信号 clicked()**）。
  • 而另一个对象，比如一个窗口，有一个“耳朵”在听，这个耳朵就是槽函数（例如handleButtonClick()）。
  • 我们只需要一行代码 connect(button, &QPushButton::clicked, window, &MyWindow::handleButtonClick); 就建立了一条“连接”。

从此，按钮只管发出信号，窗口只管接收并处理。它们彼此完全独立，一个按钮的点击信号可以连接到多个槽，一个槽也可以接收来自多个信号。这种“解耦”的设计是构建复杂、可维护UI的基石。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

graph TD
    subgraph "对象 (Objects)"
        Button["QPushButton<br/>(信号源)"]
        Label["QLabel<br/>(接收者)"]
    end

    subgraph "机制 (Mechanism)"
        Signal["clicked() 信号"]
        Slot["setText() 槽"]
        Connect["connect(...) 函数<br/><b>(负责连接)</b>"]
    end

    UserClick["用户点击"] --> Button
    Button -- 发出 --> Signal
    
    subgraph "连接的建立 (Setup Time)"
      Connect -.-> Signal
      Connect -.-> Slot
    end
    
    subgraph "信号的触发 (Runtime)"
      Signal -- 触发 --> Slot
    end

    Slot -- 操作 --> Label

    style Connect fill:#d5e8d4,stroke:#82b366

事件循环(The Event Loop)

GUI程序和命令行程序不同，它不会从头执行到尾然后退出。它必须一直运行，等待用户的操作。这就是事件循环的职责。

把它想象成一个兢兢业业的前台接待员 (QApplication::exec())：

1. 等待： 接待员坐在那里，循环等待。没有事情发生时，程序就“打个盹”，不消耗CPU。
2. 事件： 一个“事件”发生了（比如，一位访客到来，代表用户的一次鼠标点击）。
3. 分发： 接待员看到访客的预约单，上面写着“找三楼的按钮经理”，于是他把访客（事件）引导给了正确的对象（那个被点击的按钮）。
4. 处理： “按钮经理”处理完访客的事务（比如发出clicked()信号），然后告诉接待员“我处理完了”。
5. 接待员回到座位，继续等待下一个事件。

这个“等待-分发-处理”的循环，就是所有GUI应用能够灵敏响应我们操作的核心机制。

“组建集”与“画布”

在Qt中，构建用户界面的两个体系是QWidget(控件)体系和QGraphicsView(场景)体系。首先我们需要知道QGraphicsProxyWidget为和存在。

QWidget体系

QWidget是我们最先接触，也是最常用的UI构建方式。它的核心思想是“组件集（Component Set）”，我们可以将其比作一个结构严谨、等级分明的“城市”。

• 核心单元与父子关系： 这个“城市”的基本建筑单元是QWidget及其子类（QPushButton, QLineEdit等）。它们之间存在着严格的父子关系。子控件（child widget）在视觉上被“框”在父控件（parent widget）的矩形区域内，无法超出。当父控件被移动、隐藏或销毁时，其所有子控件也会随之移动、隐藏或销毁。这种层级关系构成了UI的骨架。
• 布局管理（Layouts）： 为了让“城市”的建筑排列整齐，QWidget体系引入了布局管理器（QLayout的子类，如QVBoxLayout, QHBoxLayout, QGridLayout）。布局管理器如同城市的“规划局”，它接管了其内部所有控件的尺寸和位置。你只需要告诉“规划局”需要放入哪些控件，以及一些基本规则（如间距、对齐方式），它就会自动计算每个控件的最佳大小和位置，并在窗口尺寸变化时智能地重新调整布局，确保UI的响应式和美观。
• 事件处理（Event Handling）： QWidget的事件处理是“直接分发”的。在Linux上，每个顶层QWidget都是一个受窗口管理器管理的原生窗口，拥有独立的窗口句柄。当操作系统捕获到一个鼠标点击或键盘输入时，它能根据事件发生的屏幕坐标，准确地判断出事件属于哪个原生窗口。该事件随后被Qt的事件循环接收，并几乎直接地派发给目标QWidget。控件通过重写虚函数（如mousePressEvent(), keyPressEvent(), paintEvent()）来响应这些事件。
• 绘制模型（Painting Model）： 其绘制模型是“独立且光栅化”的。每个QWidget都拥有一块独立的内存区域，称为“后备存储（Backing Store）”。当需要重绘时（由paintEvent触发），每个控件只负责绘制自己矩形区域内的像素。最终，由窗口系统或父控件将这些独立的绘制结果合成（Composite）在一起，形成我们看到的完整窗口。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

graph TD
    subgraph 操作系统屏幕
        A["QMainWindow<br/>(顶层Widget, 原生窗口句柄: XID/HWND)"]
    end

    subgraph A [QMainWindow]
        B[QMenuBar]
        C[QToolBar]
        D[CentralWidget]
        E[QStatusBar]
    end
    
    subgraph D [CentralWidget]
        F{"QGridLayout<br/>(布局管理器)"}
        G[QPushButton]
        H[QLineEdit]
    end

    A --> B
    A --> C
    A --> D
    A --> E
    
    D --> F
    F --> G
    F --> H

    style A fill:#dae8fc,stroke:#6c8ebf,stroke-width:2px
    style F fill:#e1d5e7,stroke:#9673a6,stroke-width:1px,stroke-dasharray: 5 5
   

QGraphicsView体系

与QWidget的严谨不同，QGraphicsView提供了一个极其自由、动态的创作环境，其核心思想是“画布（Canvas）”或“场景图（Scene Graph）”。我们可以将其比作一个拥有“上帝视角”的数字创作空间。

这个世界由三个核心组件构成：

1. QGraphicsScene (场景 - 逻辑世界):
   • 这是“无限大的宇宙”或“数据模型”。它是一个逻辑容器，容纳着成千上万个图形项（QGraphicsItem）。
   • 场景本身不关心如何被显示，它只负责管理所有item的逻辑坐标、状态和层次关系。它使用高效的空间索引算法（如BSP树），能够飞快地查询到特定区域内有哪些item。
2. QGraphicsView (视图 - 观察窗口):
   • 这是我们观察场景的“摄像机”或“取景器”。它是一个标准的QWidget，也是整个体系中唯一与操作系统直接交互的原生窗口。
   • 它的核心职责是将QGraphicsScene中的矢量坐标映射到它自己的像素坐标上，并将用户的鼠标、键盘事件翻译后传递给场景。
   • 最强大的一点是，同一个场景可以被多个视图观察。你可以创建两个视图，一个显示场景的全貌（如地图），另一个则放大显示场景的某个局部细节（如街道），并且在一个视图中对item的修改会立刻反映在另一个视图中。视图本身还可以旋转和缩放，如同调整摄像机的角度和焦距。
3. QGraphicsItem (图形项 - 世界居民):
   • 这些是场景中的“演员”或“居民”，是构成视觉内容的基本单元。它们是轻量级的，因为它们没有自己的窗口句柄或事件循环。
   • 每个QGraphicsItem都知道如何绘制自己（通过paint()方法）、自己的边界范围（boundingRect()）以及精确形状（shape()，用于碰撞检测）。
   • 它们可以被自由地移动、缩放、旋转、扭曲，可以被组合成复杂的复合体，并且拥有Z值来控制其堆叠顺序。

• 事件处理（Event Handling）： QGraphicsView的事件处理是“间接且由场景驱动”的。所有原生事件首先被QGraphicsView接收。然后，视图会询问场景：“鼠标在(x, y)这个像素位置，对应到你的逻辑世界里是哪个坐标？这个坐标上最顶层的item是谁？”场景利用其高效的索引找到目标item后，QGraphicsView再将事件分发给这个item。整个过程由Qt在应用程序内部完成，操作系统对此一无所知。
• 渲染模型（Rendering Model）： 其渲染是“集中式”的。QGraphicsView是唯一的“渲染引擎”。在需要重绘时，它会根据当前的视口范围，要求场景提供所有可见的item列表，然后按照Z值顺序遍历这些item，并调用它们的paint()方法，将它们统一绘制到自己的视口上。这个过程可以无缝地切换到OpenGL/Vulkan后端，利用GPU进行硬件加速，从而在渲染大量动态对象时保持极高的流畅度。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

graph TD
    subgraph 操作系统屏幕
        A["QGraphicsView<br/>(顶层Widget, 原生窗口句柄: XID/HWND)"]
    end

    subgraph A ["QGraphicsView - “取景器”"]
        subgraph B ["QGraphicsScene - “无限画布”"]
            C["QGraphicsRectItem<br/>(x:10, y:20, rotation:15deg)"]
            D["QGraphicsTextItem<br/>(x:150, y:100, scale:1.5)"]
            E["QGraphicsPixmapItem<br/>(x:80, y:180, z-value:1)"]
            F["QGraphicsEllipseItem<br/>(x:-50, y:90, z-value:2)"]
        end
    end

    D --- C
    E --- D
    F --- E

    linkStyle 0,1,2 stroke-width:0px;

    style A fill:#dae8fc,stroke:#6c8ebf,stroke-width:2px
    style B fill:#d5e8d4,stroke:#82b366,stroke-width:2px,stroke-dasharray: 5 5
    style C fill:#f8cecc,stroke:#b85450
    style D fill:#f8cecc,stroke:#b85450
    style E fill:#f8cecc,stroke:#b85450
    style F fill:#f8cecc,stroke:#b85450

桥梁(QGraphicsProxywidget)

现在，我们已经深刻理解了这两个世界的根本不同：

• QWidget体系：一个由拥有独立“户口”（窗口句柄）的“公民”构成的社会，秩序井然，但缺乏灵活性。
• QGraphicsView体系：一个由没有“户口”的“虚拟灵魂”构成的魔法世界，自由奔放，但缺少现成的、功能丰富的“公民”。

核心矛盾也因此凸显：如何将一个功能完备的QWidget“公民”，请到QGraphicsScene这个魔法世界里来，并让它在这里依然能行动、能交互，享受缩放和旋转的“魔法”？

这就是QGraphicsProxyWidget需要登场的原因。它，就是为了连接这两个平行宇宙而生的“次元之桥”。

核心翻译机制

QGraphicsProxyWidget的桥接作用并非魔法，而是一套精密的、在用户空间实现的“合成器”，其核心是两大翻译机制。

事件流的捕获与”再注入”

一个控件不仅要能看，还要能用。QGraphicsProxyWidget通过一个巧妙的事件重定向流程保证了交互性。

1
2
3
4
5
6
7
8
9
10
11
12
13

sequenceDiagram
    participant U as 用户
    participant OS as 操作系统 (X11/Wayland)
    participant V as QGraphicsView
    participant P as QGraphicsProxyWidget
    participant W as QPushButton (被代理)

    U->>OS: 点击鼠标
    OS->>V: 转发原生鼠标事件
    V->>P: 投递QGraphicsSceneMouseEvent (场景坐标)
    P->>P: **内部翻译**: <br/>1. 转换坐标系<br/>2. 转换事件类型
    P->>W: **“再注入”**伪造的QMouseEvent (控件坐标)
    W->>W: 像往常一样处理点击, 发出clicked()信号

如上图所示，QGraphicsProxyWidget像一个海关，它“拦截”了来自QGraphicsScene的事件，经过一番“翻译”和“伪装”后，再“注入”给它所代理的QWidget。被代理的控件对此毫无察觉，以为自己生活在普通的窗口环境中。

绘制机制的重定向

QGraphicsProxyWidget采用了“离屏渲染”的技术，让QWidget在不知情的情况下将自己画在一张“影子画布”上。

1
2
3
4
5
6
7
8
9

graph TD
    A["QGraphicsScene请求重绘代理项"] --> B{"QGraphicsProxyWidget::paint() 被调用"};
    B --> C["<b>步骤一：</b>在内存中准备一块'影子画布'<br/>(QPixmap)"];
    C --> D["<b>步骤二：</b>调用内部widget->render(...)<br/>命令控件将自己画在这块画布上"];
    D --> E["<b>步骤三：</b>QPushButton完成绘制<br/>'影子画布'上现在有了按钮的图像"];
    E --> F["<b>步骤四：</b>ProxyWidget将最终的画布内容<br/>作为一个普通图片绘制到场景中<br/>(此时可应用旋转、缩放等变换)"];
    F --> G["绘制完成"];

    style E fill:#d5e8d4,stroke:#82b366

这个过程，QGraphicsProxyWidget像一个技艺高超的画家，它先让QWidget在一张不对外展示的画纸上画好自画像，然后它再拿起这张画，进行艺术加工（变换），最后贴到QGraphicsScene这个大展板上。

构建强大的UI

掌握了QGraphicsProxyWidget，我们就能构建出许多传统QWidget布局难以实现的复杂UI。最典型的就是节点编辑器。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

graph TD
    subgraph QGraphicsScene ["画布: 节点编辑器"]
        subgraph NodeA ["QGraphicsItem: 节点 '向量运算'"]
            P1["QGraphicsProxyWidget"] --> W1["QLabel: '输入A'"]
            P2["QGraphicsProxyWidget"] --> W2["QLineEdit"]
            P3["QGraphicsProxyWidget"] --> W3["QLabel: '输入B'"]
            P4["QGraphicsProxyWidget"] --> W4["QLineEdit"]
            P5["QGraphicsProxyWidget"] --> W5["QLabel: '操作'"]
            P6["QGraphicsProxyWidget"] --> W6["QComboBox: [Add, Multiply, ...]"]
        end
        subgraph NodeB ["QGraphicsItem: 节点 '输出'"]
             P7["QGraphicsProxyWidget"] --> W7["QLabel: '结果'"]
             P8["QGraphicsProxyWidget"] --> W8["QLineEdit (只读)"]
        end
        NodeA -- 连接线 --> NodeB
    end

“过路费”

这套精密的机制并非没有代价。

• 内存开销：每个QGraphicsProxyWidget都需要一块QPixmap作为“影子画布”。如果你的场景中有成千上万个复杂的代理控件，这部分内存占用会相当可观。
• CPU开销：相比于一个只执行简单绘图命令的QGraphicsItem，代理项的QWidget::render()调用（本质上是软件光栅化）和频繁的事件翻译都会带来额外的CPU开销。

因此，QGraphicsProxyWidget是一个“大杀器”，而不是“常规武器”。如果一个功能可以通过自定义一个轻量级的QGraphicsItem来实现，那么就优先选择它。只有当你需要嵌入一个功能极其复杂、如果重写为QGraphicsItem则成本过高的现有QWidget时，QGraphicsProxyWidget才是你的最佳选择。

总结

从始至终，QGraphicsProxyWidget的核心使命就是：在两个不同就阿狗的图形与时间系统之间，充当一个高性能的实时翻译官和用户空间合成器。

1. 绘制重定向（Painting Redirection）：QGraphicsProxyWidget 通过接管被代理QWidget的绘制目标，将其从屏幕的“后备存储”重定向到一块内存中的“离屏画布”（QPixmap）。它巧妙地利用 QWidget::render() 函数，命令控件在这块“影子画布”上完成所有绘制。随后，它再将这张已经画好的、光栅化的位图作为一张普通的纹理，绘制到QGraphicsScene的最终渲染目标上。这个过程，在应用层面实现了一套独立的离屏渲染与位图合成（Off-screen Rendering & Blitting）流程。
2. 事件流重塑（Event Stream Remodeling）：它在事件传递的路径上设立了一个“检查点”。所有发往其在场景中所在位置的QGraphicsScene事件都会被它捕获。它会基于场景图的变换（Transform）信息，将事件的坐标系、类型和参数从QGraphicsScene的语境，精确地“翻译”成QWidget内部的局部语境，并构造成一个全新的、标准的QWidget事件。最后，它通过Qt的事件系统，将这个“伪造”的事件重新注入（Re-inject）到被代理控件的事件队列中，从而“欺骗”QWidget，使其相信自己正与操作系统直接交互。
3. 几何状态同步（Geometry State Synchronization）：QGraphicsProxyWidget持续监听其内部QWidget的尺寸策略（Size Policy）和几何变化。当QWidget因内部布局变化而希望改变大小时，代理项会相应地更新自己在QGraphicsScene中的边界框（Bounding Rectangle）。反之，当代理项在场景中被用户或动画系统缩放、变形时，它也会将这种几何变换信息传递给内部的QWidget，触发其布局的重新计算。这种双向的几何状态同步，保证了两个世界在视觉和布局上的一致性。

综上所述，QGraphicsProxyWidget并非一个简单的容器，而是一个精密的运行时适配器（Runtime Adapter）。它以一定的内存和CPU开销为代价，通过在用户空间模拟QWidget的绘制环境和事件来源，实现了在矢量化、可变换的场景图中嵌入和复用功能完备的光栅化组件这一高难度任务，是Qt框架中“组合优于继承”和“适配器模式”的绝佳体现。

Project Introduction

Cantor is a powerful scientific computing front-end in the KDE ecosystem, providing users with a unified and friendly interface for mathematical and statistical analysis.

Currently, Cantor’s worksheet cells are based on a custom implementation using QTextDocument. While this approach meets basic needs, it has revealed its limitations in terms of feature expansion and long-term maintenance. To fundamentally enhance the editing experience, simplify the codebase, and embrace the advanced technology of the KDE Frameworks, this project plans to deeply integrate the feature-rich KTextEditor component into Cantor, completely replacing the existing cell implementation.

This core upgrade will bring a suite of long-awaited, powerful features to Cantor, including:

• Enhanced Multi-line Editing: Significantly improves the editing experience for complex, multi-line code blocks. This includes more robust syntax highlighting, accurate bracket matching, and a more stable editing environment, resolving key issues present in the current implementation.

• Vi Mode: Provides native Vi-style text editing for users accustomed to Vim’s efficient workflow, significantly improving editing speed.
• Improved Syntax Highlighting: Supports more comprehensive and precise code coloring rules, making complex mathematical and programming expressions clearer and easier to read.
• Smart Auto-indent: Enhances code formatting capabilities, making it exceptionally convenient to write structured scripts and multi-line formulas.
• Code Completion: Intelligently suggests variables, functions, and keywords, thereby speeding up input and reducing syntax errors.
• Spell Check: Ensures the accuracy of text comments and documentation, which is crucial for writing rigorous formula explanations and reports.

By integrating KTextEditor, Cantor will not only optimize the user’s workflow but also reduce code redundancy and improve the project’s overall maintainability. This move will further strengthen the Cantor and KDE ecosystems, providing users with a smoother and more unified experience across different KDE applications.

Why this is needed

As scientific computing demands become increasingly complex, a modern, full-featured editor is essential for boosting productivity. The current custom implementation has become a bottleneck hindering Cantor’s future development:

1. High Maintenance Cost: Maintaining a custom editor component consumes significant development resources and struggles to keep pace with the advancements in modern editors.
2. Difficult to Extend: Implementing complex features like Vi mode or advanced code completion on the existing architecture is akin to “reinventing the wheel”—it’s inefficient and prone to introducing new bugs.
3. Failure to Leverage the Ecosystem: The KDE Frameworks already provide the very mature and powerful KTextEditor component. Not utilizing it is a waste of available resources. Integrating KTextEditor means Cantor can directly benefit from the years of effort and refinement the entire KDE community has invested in this component.

Current Status: Phase 1 Complete

The first phase of the project has been completed. We have successfully introduced Cantor into the core of KTextEditor and achieved the following key results:

• Core replacement completed：We created a new WorksheetTextEditorItem class, which acts as a proxy for KTextEditor::View, successfully replacing the old QTextDocument-based cell implementation.

• Basic functions available：Users can already perform basic operations such as text input and code execution in the new cells, proving the feasibility of the integration solution.

  • short text

  

  • multi-line display

  

• integration of KTextEditor features：Basic syntax highlighting and text editing features are now available in new cells.

  • Python

  

  • Maxima

  

  • Lua

  

Event Handling and UI Interaction: Core user interactions such as mouse events and drag-and-drop functionality for worksheet entries are working as expected within the new framework.

• drag

• shotcut key

The Road Ahead: The Plan for Phase 2

With the foundation now firmly in place, the second phase of the project will focus on unlocking the full potential of KTextEditor and refining the user experience. The planned work includes:

• Activating Advanced Editor Features: We will progressively enable and configure KTextEditor’s sophisticated features, including Vi Mode, integrated Spell Check, and smart indentation rules, ensuring they are seamlessly integrated into the Cantor workflow.
• Connecting Backend-driven Code Completion: A major goal is to connect Cantor’s various computation backends (e.g., Python, R, Octave) to the KTextEditor code completion framework. This will provide users with context-aware, intelligent suggestions.
• Bug Fixing and UX Polishing: We will systematically address any remaining issues from the initial integration, focusing on perfecting UI/UX details like focus management, text selection, and context menu consistency.
• Comprehensive Testing: Rigorous regression testing will be conducted across all features—new and existing—to guarantee the stability and reliability of Cantor following this major architectural upgrade.

功能

账号管理

• 实现登录、注册、注销
• 实现找回密码（提高）

好友管理

• 实现好友的添加、删除、查询操作
• 实现显示好友在线状态
• 禁止不存在好友关系的用户间的私聊
• 实现屏蔽好友消息
• 实现好友间聊天

群管理

• 实现群组的创建、解散
• 实现用户申请加入群组
• 实现用户查看已加入的群组
• 实现群组成员退出已加入的群组
• 实现群组成员查看群组成员列表
• 实现群主对群组管理员的添加和删除
• 实现群组管理员批准用户加入群组
• 实现群组管理员/群主从群组中移除用户
• 实现群组内聊天功能

聊天功能

• 实现查看历史消息记录
• 实现用户间在线聊天
• 实现在线用户对离线用户发送消息，离线用户上线后获得通知
• 实现在线发送文件
• 实现在线用户对离线用户发送文件，离线用户上线后获得通知/接收
• 实现后台发送文件
• 实现用户在线时,消息的实时通知
  • 收到好友请求
  • 收到私聊
  • 收到加群申请

其他

• 使用 C++编程语言
• 使用 I/O 多路复用完成本项目
  • C++：Epoll ET 模式
• 使用数据库完成数据存储
  • Redis 和 mysql
  • 历史消息采用redis做告诉缓存，mysql来存储大量历史消息
• 数据库中数据的存储和取用使用序列化和反序列化完成(Json)
• 支持大量客户端同时访问
• 实现服务器日志，记录服务器的状态信息
• C/S 双端均支持在 CLI/Web 自行指定 IP:Port
• 实现具有高稳定性的客户端和服务器，防止在用户非法输入时崩溃或异常
  • 实现 TCP 心跳检测

遇到的问题

• 在客户端因某些原因异常退出时，服务端将无法正常处理其他请求.

  • 开始时服务端没有将新连接的描述符设置为非阻塞模式，导致客户端异常退出时服务端的接收recv一直在阻塞着读取，且无法处理其他请求

• 如何往线程池中传入类的成员函数.

  • auto task = [](){     类的成员函数 } m_pool.submit(task);
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    
    * `Tcp`传输为字节流传输，采用在每条消息前面加上`长度`来正确接收每条请求.
    * 在代码中往`redis`数据库中添加好友申请数据时，没有正确插入.
      * 由于好友申请当中包含时间，姓名等信息，中间含有**空格**，在redis的哈希表中无法插入.
      * 经过查阅在redis哈希表中，**空格**可以用`+`代替，在遇到`+`时会被转义为**空格**，或者存储为**十六进制**，但是这种方法在终端中的**空格**为灰色.
    
    * 在聊天界面如果输入带有`%`，服务器直接挂掉.
    
      * ```c++
        int redisAsyncContext::Lpush(const std::string &key, const std::string &value)
        {
            //std::string cmd = "lpush " + key + " " + value;
            this->m_reply = (redisReply *)redisCommand(this->m_connettion, "LPUSH %s %s", key.c_str(), value.c_str());
             // 检查 m_reply 是否为 NULL
            if (this->m_reply == NULL) {
                std::cerr << "Error: redisCommand returned NULL" << std::endl;
                return -1; // 或其他合适的错误值
            }
        
            // 检查 m_reply 类型
            if (this->m_reply->type != REDIS_REPLY_INTEGER) {
                std::cerr << "Error: Expected integer reply" << std::endl;
                freeReplyObject(this->m_reply);
                return -1; // 或其他合适的错误值
            }
            int num  = this->m_reply->integer;
            freeReplyObject(this->m_reply);
            std::cout << "G" << std::endl;
            return num;
        }
    

  • 在执行下面两句是，%会被替换为cmd.c_str(),导致无法将消息插入历史记录表，导致出现错误.

    1 2	std::string cmd = "lpush " + key + " " + value; this->m_reply = (redisReply *)redisCommand(this->m_connettion, cmd.c_str());

  • 只要更改为下面即没有问题

    1	this->m_reply = (redisReply *)redisCommand(this->m_connettion, "LPUSH %s %s", key.c_str(), value.c_str());

• 在某次测试时，新注册账号id为0614897828,导致与该账号聊天的账号进入聊天界面时，0614897828发送的消息会在他人界面显示为通知消息.

  • 由于与人聊天时会在数据库中创建有排序集合来记录某人正在聊天的人的id.运行时通过查看发现，其余账号与0614897828聊天时，数据库中记录账号为614897828.
  • 更换为首位非0的id就不会出现该问题.
  • redis会将有序集合中的score字段字符串中的0去除.将从字符串的首位非0开始存储.

• 在进入好友私聊界面时，客户端新建了来接收消息，同时主线程发消息，主线程通过判断用户是否键入Esc来退出聊天界面，在输入Esc时，接收消息线程无法正确回收，无法退出聊天界面.

  • 在接收消息线程中来判断标志位来结束该线程，主线程在键入Esc时，将标志位设置为false,但由于客户端的recv为阻塞，导致无法及时获取到标志位的更改.
  • 在键入Esc时，服务器向客户端发送退出信号，这样就可以正确及时的获取到标志位的更改，从而正确退出.

• 在进行发送文件时，服务器会先将文件存储在本地，但是服务器存储的文件会多写入一些信息，导致接收文件大小偏大.

  • 由于在用户登陆进入之后，会有一个线程每5秒向服务器送送刷新请求，导致服务器会将刷新请求当作文件内容写入文件，导致接收文件不一致
  • 在进入文件收发菜单后，关闭实时刷新，在文件结束后，再将实时刷新打开.

• 实现后台发送文件，由于会有实时刷新的存在，会导致文件发送不准确.

  • 在发送文件时，重新创建一个socket连接到服务器，在将发送这个文件交给另外一个线程
  • 初始时在用户选择发送文件时开始线程，但会导致主线程与发送线程会同时运行菜单.主线程继续循环菜单，而发送线程运行获取发送文件的信息。
    • 更改线程开始时间，在用户选择发送文件时，获取到发送文件信息后，在启动线程.
    • 新连接的socket发送文件后，服务器不用手动断开连接，服务器有心跳检测，会在一段时间后断开.

eventfd

详解

是一个Linux系统调用，也是一种进程间通信(IPC)机制，主要通过使用文件描述符生成和使用事件通知.

提供了一种在不同进程之间或同一进程内的线程之间的同步事件的方法.

异常处理

异常是程序在执行期间产生的问题。c++异常是指在程序运行时发生的特殊情况.

异常提供了一种转移程序控制权的方式。C++ 异常处理涉及到三个关键字：try、catch、throw

关键字：try、catch、throw。

• throw: 当问题出现时，程序会抛出一个异常。这是通过使用 throw 关键字来完成的。

• catch: 在您想要处理问题的地方，通过异常处理程序捕获异常。catch 关键字用于捕获异常

• try: try 块中的代码标识将被激活的特定异常。它后面通常跟着一个或多个 catch 块

1
2
3
4
5
6
7
8
9
10
11
12
13

try
{
   // 保护代码
}catch( ExceptionName e1 )
{
   // catch 块
}catch( ExceptionName e2 )
{
   // catch 块
}catch( ExceptionName eN )
{
   // catch 块
}

nlohmann::json

链接

SIGPIPE

SIGPIPE 是一种信号，当一个进程尝试向一个已经关闭的或不可写的管道或套接字写数据时，会触发这个信号。默认情况下，接收到 SIGPIPE 信号的进程会终止。这在网络编程中会导致一些问题，因为如果客户端断开连接，服务器进程在写入数据时会因为这个信号而意外退出。

在网络编程中，特别是使用套接字进行通信时，忽略 SIGPIPE 信号是一个常见的做法。这样可以防止进程因为 SIGPIPE 信号而意外终止。相反，程序可以通过检测 send 或 write 操作的返回值来处理错误，从而使程序更加健壮。

后续问题

1. 初始客户端构思方面的缺陷，导致实时消息没有线程及时接收。

   当前处理方式为服务端将通知消息放入数据库当中，客户端在登陆之后，增加一个线程来定时执行刷新函数，刷新数据库中的通知消息

   可以优化为在客户端登陆之后，采用多线程的方式来处理相关操作.

2. 目前只有在历史消息这一操作涉及到redis+mysql的处理方式.

   可以将一些重要信息也采用redis+mysql的处理方式(涉及到redis的存储方式，redis存储于内存当中，会造成数据丢失的情况)

   可以考虑将redis全部做为缓存的形式，将重要信息与历史消息类似，达到一定情况下放入mysql,使数据更加的持久化.

后续学习

1. 继续学习epoll的相关内容.

2. 了解其余网络框架，使得该项目的服务端更加的健壮.

3. 了解消息队列的信息同步的问题.

4. 熟悉零拷贝的过程，以及零拷贝的具体实现.

5. 序列化的相关协议，json与其他序列化的区别、json的优点，以及为什么不用其他的序列化

6. 数据库的深入学习，了解redis的缓存穿透、缓存雪崩、缓存击穿。加强对mysql数据库的学习.

7. 加强对网络协议相关知识的学习.

C++提供了四个强制类型转换的关键字：

• static_cast
• const_cast
• reinterpret_cast
• ``dynamic_cast`

static_cast

1

static_cast<目标类型>(表达式)

1
2

int num = 2;
double result =static_cast<double>(num);

该运算符将表达式转换为目标类型。但没有进行运行时类型检查来保证转换的安全性。

主要用法

1. 用于类层次结构中父类和子类之间指针或引用的转换.进行上行转换是安全的（即将子类的指针或引用转换成父类是正确的）；进行下行转换的时候，由于没有动态类型检查，所以是不安全的。继承必须为public
2. 用于基本类型之间的转换，如int与char，安全性也需要程序员来保证
3. 把空指针转换为目标类型的空指针

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

class Person
{
public:
    void  print()
    {
        cout << "Person " << endl;
    }
};

class Son : public Person
{
public:
    void print()
    {
        cout << "Son " << endl;
    }
};

void print1(Person *p)
{
    p->print();
}

int main()
{
    Son s;
    print1(static_cast<Person *>(&s));
    return 0;
}

const_cast

const_cast是c++中专用于处理与const相关的强制类型转换的关键字

其功能为：为一个变量重新设定其const描述.

即：const_cast可以为一个变量强行增加或删除其const限定.

需要明确的是，即使用户通过const_cast强行去除了const属性，也不代表当前变量从不可变变为了可变。const_cast只是使得用户接管了编译器对于const限定的管理权，故用户必须遵守“不修改变量”的承诺。如果违反此承诺，编译器也不会因此而引发编译时错误，但可能引发运行时错误。

1. const_cast可用于更改const成员函数内的非const类成员。
2. const_cast可用于将const数据传递给不接收const的函数。
3. const_cast<>里边的内容必须是引用或者指针。
4. const_cast也可以用来抛弃volatile和__unaligned属性。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

class Student
{
private:
int roll;
public:
Student(int r) :roll(r) {}
void fun() const
{
(const_cast<Student*> (this))->roll = 5;
}
int getRoll() { return roll; }
};

int main() {
    Student student(3);
    std::cout << "Old roll number: " << student.getRoll() << std::endl;
    student.fun();
    std::cout << "New roll number: " << student.getRoll() << std::endl;

    // const_cast只能调节类型限定符，不能更改基础类型
    int a1 = 40;
    //const int* b1 = &a1;
    //char* c1 = const_cast <char*> (b1); // 编译程序时出错

    const volatile int* d1 = &a1;
    std::cout << "typeid of d1 " << typeid(d1).name() << '\n'; // int const volatile *
    int* e1 = const_cast <int*> (d1);
    std::cout << "typeid of e1 " << typeid(e1).name() << '\n'; // int *
    
    return 0;
}

在const成员函数fun()中，编译器将“this”视为“ const student const this”，即“this”是指向常量对象的常量指针，因此编译器不允许通过以下方式更改数据成员“这个”指针。const_cast将“this”指针的类型更改为“student const this”。

const_cast比简单类型转换更安全。从某种意义上讲，如果强制类型与原始对象不相同，则强制转换不会发生，这是比较安全的。

1
2
3

int a=20;
const int *p=&a;
char *c1=const_cast<char*> (p);//编译时程序出错

reinterpret_cast

reinterpret,即重新解释.

该强制类型转换的作用是提供某个变量在底层数据上的重新解释.

当我们对一个变量使用reinterpret_cast后，编译器将无视任何不合理行为，强行将被转换变量的内存数据重解释为某个新的类型。用于进行各种不同类型的指针之间、不同类型的引用之间以及指针和能容纳指针的整数类型之间的转换。转换时，执行的是逐个比特复制的操作。 它不检查指针类型和指针所指向的数据是否相同。

需要注意的是，reinterpret_cast要求转换的两个数据所占用的内存大小一致，否则会引发编译时错误.

1

data_type *var_name = reinterpret_cast <data_type *>(pointer_variable);

使用 reinterpret_cast 的目的：

1. reinterpret_cast是一种非常特殊且危险的类型转换操作符。并且建议使用适当的数据类型使用它，即（指针数据类型应与原始数据类型相同）。
2. 它可以将任何指针类型转换为任何其他数据类型。
3. 当我们要使用位时使用它。
4. 它仅用于将任何指针转换为原始类型。
5. 布尔值将转换为整数值，即0表示false，1表示true。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

class A {
public:
    int a;
    A(int i) :a(i) {}
    void fun_a()
    {
        std::cout << "In class A\n";
    }
};

class B {
public:
    int b;
    B(int i) :b(i) {}
    void fun_b()
    {
        std::cout << "In class B\n";
    }
};

void testReinterpretCast() {
    B *x = new B(5);
    A* y = reinterpret_cast<A*>(x);
    y->fun_a();                      // In class A
    std::cout << y->a << std::endl;  // 5
}

dynamic_cast

dynamic用于在运行时实现向下类型转换。

1

dynamic_cast <type-id> (expression)

将expression转换为type-id类型,type-id必须是类的指针，类的引用或者是void,

如果type-id是一个指针，那么expression也是一个指针，是引用的话同为引用

特点如下：

1. 它是在运行是进行处理的，其余三个都是在编译时完成. 运行时进行类型检查
2. 不能用于内置的基本数据类型之间的强制转换
3. dynamic_cast 要求 <> 内所描述的目标类型必须为指针或引用。dynamic_cast 转换如果成功的话返回的是指向类的指针或引用，转换失败的话则会返回 nullptr。
4. 在类的转换时，在类层次上进行向上转换（子类指针指向父类指针），与static_cast的效果是一样的。在进行父类指针向子类指针的转换时，dynamic_cast具有类型检查的功能，比static_cast更安全。
5. 向下转换的成功与否还与将要转换的类型有关，即要转换的指针指向的对象的实际类型与转换以后的对象类型一定要相同，否则转换失败。在C++中，编译期的类型转换有可能会在运行时出现错误，特别是涉及到类对象的指针或引用操作时，更容易产生错误。dynamic_cast操作符则可以在运行期对可能产生问题的类型转换进行测试。
6. 使用 dynamic_cast 进行转换的，基类中一定要有虚函数，否则编译不通过（类中存在虚函数，就说明它有想要让基类指针或引用指向派生类对象的情况，此时转换才有意义）。这是由于运行时类型检查需要运行时类型信息，而这个信息存储在类的虚函数表中，只有定义了虚函数的类才有虚函数表。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

class AA {
public:
    virtual void print() {
        cout << "in class AA" << endl;
    };
};

class BB :public AA {
public:
    void print() {
        cout << "in class BB" << endl;
    };
};

void testDynamicCast() {
    AA* a1 = new BB; // a1是A类型的指针指向一个B类型的对象
    AA* a2 = new AA; // a2是A类型的指针指向一个A类型的对象

    BB* b1, * b2, * b3, * b4;

    b1 = dynamic_cast<BB*>(a1);// not null，向下转换成功，a1 之前指向的就是 B 类型的对象，所以可以转换成 B 类型的指针。
    if (b1 == nullptr) 
        cout << "b1 is null" << endl;
    else               
        cout << "b1 is not null" << endl;

    b2 = dynamic_cast<BB*>(a2);// null，向下转换失败
    if (b2 == nullptr) 
        cout << "b2 is null" << endl;
    else               
        cout << "b2 is not null" << endl;

    // 用 static_cast，Resharper C++ 会提示修改为 dynamic_cast
    b3 = static_cast<BB*>(a1);// not null
    if (b3 == nullptr) 
        cout << "b3 is null" << endl;
    else               
        cout << "b3 is not null" << endl;

    b4 = static_cast<BB*>(a2);// not null
    if (b4 == nullptr) 
        cout << "b4 is null" << endl;
    else               
        cout << "b4 is not null" << endl;

    a1->print();// in class BB
    a2->print();// in class AA

    b1->print();// in class BB
    //b2->print();    // null 引发异常
    b3->print();// in class BB
    b4->print();// in class AA
}

详细

匿名函数是很多高级语言都支持的概念，如lisp语言在1958年首先采用匿名函数。匿名函数有函数体，但没有函数名。C++11中引入了lambda表达式。利用lambda表达式可以编写内嵌的匿名函数，用以替换独立函数或者函数对象，并且使代码更可读。但是从本质上来讲，lambda表达式只是一种语法糖，因为所有其能完成的工作都可以用其它稍微复杂的代码来实现。但是它简便的语法却给C++带来了深远的影响。如果从广义上说，lamdba表达式产生的是函数对象。

相同类似功能我们也可以使用函数对象或者函数指针实现：函数对象能维护状态，但语法开销大，而函数指针语法开销小，却没法保存范围内的状态。lambda表达式正是结合了两者的优点。

声明Lambda表达式

1
2
3
4
5
6
7

// 完整语法
[capture list] (params list) mutable(optional) constexpr(optional)(c++17) exception attribute -> return type { function body };

// 可选的简化语法
[capture list] (params list) -> return type {function body};  //1
[capture list] (params list) {function body};//2
[capture list] {function body};//3

• capture list：捕获外部变量列表，不能省略；
• params list：形参列表，可以省略（但是后面必须紧跟函数体）；
• mutable指示符： 可选，将lambda表达式标记为mutable后，函数体就可以修改传值方式捕获的变量；
• constexpr：可选，C++17，可以指定lambda表达式是一个常量函数；
• exception：异常设定， 可选，指定lambda表达式可以抛出的异常；
• attribute：可选，指定lambda表达式的特性；
• return type：返回类型
• function body：函数体

标号1. 函数声明了一个const类型的表达式，此声明不可改变capture list中的捕获的值。

标号2. 函数省略了返回值，此时如果function body内含有return语句，则按return语句返回类型决定返回值类型，若无则返回值为void类型。

标号3. 函数无参数列表，意味无参函数。

1
2
3

vector<int> vec{1,0,9,5,3,3,7,8,2};

sort(lbvec.begin(), lbvec.end(), [](int a, int b) -> bool { return a < b; });  

捕获外部变量

lambda表达式最前面的方括号的意义何在？其实这是lambda表达式一个很Hong要的功能，就是闭包。这里我们先讲一下lambda表达式的大致原理：每当你定义一个lambda表达式后，编译器会自动生成一个匿名类（这个类当然重载了()运算符），我们称为闭包类型（closure type）。那么在运行时，这个lambda表达式就会返回一个匿名的闭包实例，其实一个右值。所以，我们上面的lambda表达式的结果就是一个个闭包。闭包的一个强大之处是其可以通过传值或者引用的方式捕捉其封装作用域内的变量，前面的方括号就是用来定义捕捉模式以及变量，我们又将其称为lambda捕捉块。

Lambda表达式可以捕获外面变量，但需要我们提供一个谓词函数（[capture list]在声明表达式最前）。类似参数传递方式：值传递、引入传递、指针传递。在Lambda表达式中，外部变量捕获方式也类似：值捕获、引用捕获、隐式捕获。

值捕获

1
2
3
4
5

int a = 123;
auto f = [a] { cout << a << endl; }; 
f(); // 输出：123
a = 321;
f(); // 输出：123

值捕获和参数传递中的值传递类似，被捕获的值在Lambda表达式创建时通过值拷贝的方式传入，类中会相应添加对应类型的非静态数据成员。在运行时，会用复制的值初始化这些成员变量，从而生成闭包。因此Lambda表达式函数体中不能修改该外部变量的值； 因为函数调用运算符的重载方法是const属性的。同样，函数体外对于值的修改也不会改变被捕获的值。 想改动传值方式捕获的值，那么就要使用mutable。

1
2
3

auto add_x = [x](int a) mutable { x *= 2; return a + x; };  // 复制捕捉x
    
cout << add_x(10) << endl; // 输出：30

因为一旦将lambda表达式标记为mutable，那么实现的函数调用运算符是非const属性的。

引用捕获

1
2
3
4

int a = 123;
auto f = [&a] { cout << a << endl; }; 
a = 321;
f(); // 输出：321

引用捕获的变量使用的实际上就是该引用所绑定的对象，因此引用对象的改变会改变函数体内对该对象的引用的值。 对于引用捕获方式，无论是否标记mutable，都可以在lambda表达式中修改捕获的值。

隐式捕获

隐式捕获有两种方式，分别是 [=]：以值补获的方式捕获外部所有变量 [&]：表示以引用捕获的方式捕获外部所有变量。

1
2
3

int a = 123, b=321;
auto df = [=] { cout << a << b << endl; };    // 值捕获
auto rf = [&] { cout << a << b << endl; };    // 引用捕获

其他

既然只使用一次，那直接写全代码不就行了，为啥要函数呢？——因为lambda可以捕获局部变量

在上面的捕获方式中，注意最好不要使用[=]和[&]默认捕获所有变量。首先说默认引用捕获所有变量，你有很大可能会出现悬挂引用（Dangling references），因为引用捕获不会延长引用的变量的声明周期：

1
2
3
4

std::function<int(int)> add_x(int x)
{
return [&](int a) {return x+a;};
}

因为参数x仅是一个临时变量，函数调用后就被销毁，但是返回的lambda表达式却引用了该变量，但调用这个表达式时，引用的是一个垃圾值，所以会产生没有意义的结果。如果通过传值的方式来解决上面的问题：

1
2
3
4

std::function<int(int)> add_x(int x)
{
    return [=](int a) { return x + a; };
}

使用默认传值方式可以便面悬挂引用问题.但是采用默认值捕获所有变量仍然有风险。例如当在类中捕获私有变量，当返回值为lambda表达式时，无法捕获到私有变量，但当指定为[=]时，会捕获到this指针的副本，当类已经调用析构函数，使用该指针仍然不安全.

参数

• 参数列表中不能有默认参数
• 不支持可变参数
• 所有参数必须要参数名（相当于不可以有占位参数）

返回类型

单一的return语句可以推断返回类型；多语句则默认返回void，否则报错，应指定返回类型

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

// 正确，单一return语句
transform(vi.begin(),vi.end(),vi.begin(), 
    [] (int i) { 
    return i<0? -i; i;
    }
);
// 错误。不能推断返回类型
transform(vi.begin(),vi.end(),vi.begin(), 
    [] (int i) { 
        if (I<0) return -i;
        else return i;
    }
);
// 正确，尾置返回类型
transform(vi.begin(),vi.end(),vi.begin(), 
    [] (int i) ->int{ 
        if (I<0) 
            return -i;
        else 
            return i;
    }
);

赋值

auto和function可接受lambda表达式的返回：

1
2
3

int x =8,y=9;
auto add = [](int a,int b){return a+b;};
std::function<int(int,int)> Add = [=] (int a,int b){return a+b};

lambda表达式产生的类不含有默认构造函数、赋值运算符、默认析构函数。至于闭包类中是否有对应成员，C++标准中给出的答案是：不清楚的，看来与具体实现有关。还有一点要注意：lambda表达式是不能被赋值的：

1
2
3
4
5

auto a = [] { cout << "A" << endl; };
auto b = [] { cout << "B" << endl; };

a = b;   // 非法，lambda无法赋值
auto c = a;   // 合法，生成一个副本

因为禁用了赋值操作符：

1

ClosureType& operator=(const ClosureType&) = delete;

但是没有禁用复制构造函数，所以可以用一个lambda表达式去初始化另外一个lambda表达式而产生副本。并且lambda表达式也可以赋值给相对应的函数指针，这也使得你完全可以把lambda表达式看成对应函数类型的指针。

新特性

在C++14中，lambda又得到了增强，一个是泛型lambda表达式，一个是lambda可以捕捉表达式。

lambda捕捉表达式

lambda表达式可以按复制或者引用捕获在其作用域范围内的变量。而有时候，我们希望捕捉不在其作用域范围内的变量，而且最重要的是我们希望捕捉右值。所以C++14中引入了表达式捕捉，其允许用任何类型的表达式初始化捕捉的变量：

1
2
3
4
5
6
7
8

// 利用表达式捕获，可以更灵活地处理作用域内的变量
int x = 4;
auto y = [&r = x, x = x + 1] { r += 2; return x * x; }();
// 此时 x 更新为6，y 为25

// 直接用字面值初始化变量
auto z = [str = "string"]{ return str; }();
// 此时z是const char* 类型，存储字符串 string

可以看到捕捉表达式扩大了lambda表达式的捕捉能力，有时候你可以用std::move初始化变量。这对不能复制只能移动的对象很重要，比如std::unique_ptr，因为其不支持复制操作，你无法以值方式捕捉到它。但是利用lambda捕捉表达式，可以通过移动来捕捉它：

1
2
3
4

auto myPi = std::make_unique<double>(3.1415);

auto circle_area = [pi = std::move(myPi)](double r) { return *pi * r * r; };
cout << circle_area(1.0) << endl; // 3.1415

原文章

可变参数模板是C++11引入的一个特性，它允许定义一个接受任意数量参数的模板.

在函数模板或类模板中，我们可以使用可变参数模板来定义接受任意数量参数的函数或类。可变参数模板使用了模板参数包（template parameter pack），它允许我们将零个或多个模板参数打包成一个参数集合。

1
2
3
4
5
6
7
8
9

template <typename T>
T sum(T arg){
    return arg;
}

template<typename T,typename...Args>
T sum(T first ,Args...res){
    return first+sum(rest...);
}

尾部类型推导

当需要使用尾部类型推导的时候，通常是因为函数的返回类型依赖于函数参数或其他的上下文.

1
2
3
4
5
6
7
8
9
10
11
12

auto add=[](int x,int y)->int {
    return x+y;
}
auto add=[](int x,int y)->auto
{
    return x+y;
}
//函数模板
template<typename T, typename U>
auto multiply(T x, U y) -> decltype(x * y) {
    return x * y;
}

std::accumulate

std::accumulate 是 C++ 标准库 <numeric> 头文件中提供的一个算法函数，用于计算给定范围内的元素的总和。它接受一个起始迭代器和一个终止迭代器，以及一个初始值，然后对范围内的元素进行累加，并返回结果。

它的基本语法如下：

1
2

cppCopy codetemplate< class InputIt, class T >
T accumulate( InputIt first, InputIt last, T init );

其中：

• InputIt 是起始迭代器和终止迭代器的类型。
• first 是范围的起始迭代器。
• last 是范围的终止迭代器（不包括在范围内）。
• init 是初始值，用于累加元素。

decltype

decltype 是 C++11 引入的一个关键字，用于获取表达式的类型。它可以用于声明变量、函数返回类型、模板参数等地方。

1

decltype(expression)

std::bind

链接

std::bind的头文件是

解释

std::result_of

std::result_of 是一个 C++11 标准库中的模板工具，用于获取函数对象的返回类型。它可以用于在编译时确定函数对象的返回类型，而不需要实际调用该函数对象。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

#include <iostream>
#include <type_traits>

int add(int a, int b) {
    return a + b;
}

int main() {
    // 获取 add 函数的返回类型
    typedef std::result_of<decltype(add)&(int, int)>::type result_type;

    // 输出返回类型
    std::cout << "Result type: " << typeid(result_type).name() << std::endl;

    return 0;
}

std::result_of 和 decltype 都是用于获取表达式的类型，但它们之间有一些区别：

1. 用法：
   • std::result_of 用于获取函数对象的返回类型，而不需要实际调用该函数对象。它是一个模板类，需要指定函数对象的类型和参数类型。
   • decltype 用于获取表达式的类型，可以是任意的表达式，不仅限于函数调用。它是一个关键字，可以直接用于变量声明、返回类型推断等地方。
2. 适用范围：
   • std::result_of 主要用于获取函数对象的返回类型，因此在涉及函数对象的场景下更为常见。
   • decltype 不仅可以用于函数调用，还可以用于变量声明、表达式的类型推断等场景，更为灵活。
3. 语法：
   • std::result_of 的语法是模板类模板参数，需要传递函数类型和参数类型。
   • decltype 的语法更为灵活，可以直接对任意表达式使用。

std::filesvstem

cppreference

csdn

std::thread

标准库

C++11引入了std::thread来创建线程，支持对线程join或者detach.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

#include <iostream>
#include <thread>

using namespace std;

int main() {
    auto func = []() {
        for (int i = 0; i < 10; ++i) {
            cout << i << " ";
        }
        cout << endl;
    };
    std::thread t(func);
    if (t.joinable()) {
        t.detach();
    }
    auto func1 = [](int k) {
        for (int i = 0; i < k; ++i) {
            cout << i << " ";
        }
        cout << endl;
    };
    std::thread tt(func1, 20);
    if (tt.joinable()) { // 检查线程可否被join
        tt.join();
    }
    return 0;
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

class ThreadGuard
{
public:
    enum class DeAction{join,detach};
    ThreadGuard(std::thread&& t,DeAction action): m_t(move(t)) , m_action(action){};
    ~ThreadGuard()
    {
        if(m_t.joinable())
        {
            if(m_action==DeAction::join)
            {
                m_t.join();
            }
            else
            {
                m_t.detach();
            }
        }
    }
    ThreadGuard(ThreadGuard&&)=default;
    ThreadGuard& operator=(ThreadGuard&&)=default;
private:
    std::thread m_t;
    DeAction m_action;
};

c++11还提供了获取线程id，或者系统cpu个数，获取thread native_handle，使得线程休眠等功能

1
2
3
4
5

std::thread t(func);
cout << "当前线程ID " << t.get_id() << endl;
cout << "当前cpu个数 " << std::thread::hardware_concurrency() << endl;
auto handle = t.native_handle();// handle可用于pthread相关操作
std::this_thread::sleep_for(std::chrono::seconds(1));

std::mutex

std::mutex是一种线程同步的手段，用于保存多线程同时操作的共享数据。

文库

mutex分为四种：

• std::mutex：独占的互斥量，不能递归使用，不带超时功能

• std::recursive_mutex：递归互斥量，可重入，不带超时功能

• std::timed_mutex：带超时的互斥量，不能递归

• std::recursive_timed_mutex：带超时的互斥量，可以递归使用

  std::mutex

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

#include <iostream>
#include <mutex>
#include <thread>

using namespace std;
std::mutex mutex_;

int main() {
    auto func1 = [](int k) {
        mutex_.lock();
        for (int i = 0; i < k; ++i) {
            cout << i << " ";
        }
        cout << endl;
        mutex_.unlock();
    };
    std::thread threads[5];
    for (int i = 0; i < 5; ++i) {
        threads[i] = std::thread(func1, 200);
    }
    for (auto& th : threads) {
        th.join();
    }
    return 0;
}

std::timed_mutex

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

#include <iostream>
#include <mutex>
#include <thread>
#include <chrono>

using namespace std;
std::timed_mutex timed_mutex_;

int main() {
    auto func1 = [](int k) {
        timed_mutex_.try_lock_for(std::chrono::milliseconds(200));
        for (int i = 0; i < k; ++i) {
            cout << i << " ";
        }
        cout << endl;
        timed_mutex_.unlock();
    };
    std::thread threads[5];
    for (int i = 0; i < 5; ++i) {
        threads[i] = std::thread(func1, 200);
    }
    for (auto& th : threads) {
        th.join();
    }
    return 0;
}

std::lock相关

这里主要介绍两种RAII方式的锁封装，可以动态的释放锁资源，防止线程由于编码失误导致一直持有锁。

c++11主要有std::lock_guard和std::unique_lock两种方式，使用方式都类似，如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

#include <iostream>
#include <mutex>
#include <thread>
#include <chrono>

using namespace std;
std::mutex mutex_;

int main() {
    auto func1 = [](int k) {
        // std::lock_guard<std::mutex> lock(mutex_);
        std::unique_lock<std::mutex> lock(mutex_);
        for (int i = 0; i < k; ++i) {
            cout << i << " ";
        }
        cout << endl;
    };
    std::thread threads[5];
    for (int i = 0; i < 5; ++i) {
        threads[i] = std::thread(func1, 200);
    }
    for (auto& th : threads) {
        th.join();
    }
    return 0;
}

std::lock_guard

1
2
3
4

#include <mutex>

template <class Mutex>
class lock_guard;

Mutex 是互斥量的类型。

使用 std::lock_guard 时，只需在需要保护的代码块中创建一个 std::lock_guard 对象，并将需要保护的互斥量传递给它的构造函数。当 std::lock_guard 对象创建时，会自动锁定互斥量，当对象销毁时，会自动解锁互斥量。

std::unique_lock

1
2
3
4

#include <mutex>

template <class Mutex>
class unique_lock;

Mutex 是互斥量的类型。

与 std::lock_guard 不同，std::unique_lock 对象可以在构造时不锁定互斥量，并且可以在后续的代码中手动锁定或解锁。此外，std::unique_lock 还提供了更多的功能，如可延迟锁定、条件变量的支持等。

std::atomic

c++11提供了原子类型std::atomic，理论上这个T可以是任意类型，但是我平时只存放整形，别的还真的没用过，整形有这种原子变量已经足够方便，就不需要使用std::mutex来保护该变量啦。看一个计数器的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

struct OriginCounter { // 普通的计数器
    int count;
    std::mutex mutex_;
    void add() {
        std::lock_guard<std::mutex> lock(mutex_);
        ++count;
    }

    void sub() {
        std::lock_guard<std::mutex> lock(mutex_);
        --count;
    }

    int get() {
        std::lock_guard<std::mutex> lock(mutex_);
        return count;
    }
};

struct NewCounter { // 使用原子变量的计数器
    std::atomic<int> count;
    void add() {
        ++count;
        // count.store(++count);这种方式也可以
    }

    void sub() {
        --count;
        // count.store(--count);
    }

    int get() {
        return count.load();
    }
};

std::call_once

c++11提供了std::call_once来保证某一函数在多线程环境中只调用一次，它需要配合std::once_flag使用，直接看使用代码吧：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

std::once_flag onceflag;

void CallOnce() {
    std::call_once(onceflag, []() {
        cout << "call once" << endl;
    });
}

int main() {
    std::thread threads[5];
    for (int i = 0; i < 5; ++i) {
        threads[i] = std::thread(CallOnce);
    }
    for (auto& th : threads) {
        th.join();
    }
    return 0;
}

volatile

volatile通常用来建立内存屏障，volatile修饰的变量，编译器对访问该变量的代码通常不再进行优化，看下面代码：

1
2
3

int *p = xxx;
int a = *p;
int b = *p;

a和b都等于p指向的值，一般编译器会对此做优化，把*p的放入寄存器，之后a,b都等于寄存器的值，但是如果把中间p地址的值改变，内存值改变了，但a,b还是从寄存器中取的值(不一定，看编译器的优化结果),这不符合需求，所以对p加上volatile修饰可以避免此类优化.

注意：volatile不能解决多线程安全问题，针对特种内存才需要使用volatile，它和atomic的特点如下：

• std::atomic用于多线程访问的数据，且不用互斥量，用于并发编程中
• volatile用于读写操作不可以被优化掉的内存，用于特种内存中

std::condition_variable

条件变量是c++11引入的一种同步机制，它可以阻塞一个线程或者个线程，直到有线程通知或者超时才会唤醒正在阻塞的线程，条件变量需要和锁配合使用，这里的锁就是上面介绍的std::unique_lock。

成员函数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

class CountDownLatch {
   public:
    explicit CountDownLatch(uint32_t count) : count_(count);

    void CountDown() {
        std::unique_lock<std::mutex> lock(mutex_);
        --count_;
        if (count_ == 0) {
            cv_.notify_all();
        }
    }

    void Await(uint32_t time_ms = 0) {
        std::unique_lock<std::mutex> lock(mutex_);
        while (count_ > 0) {
            if (time_ms > 0) {
                cv_.wait_for(lock, std::chrono::milliseconds(time_ms));
            } else {
                cv_.wait(lock);
            }
        }
    }

    uint32_t GetCount() const {
        std::unique_lock<std::mutex> lock(mutex_);
          return count_; 
    }

   private:
    std::condition_variable cv_;
    mutable std::mutex mutex_;
    uint32_t count_ = 0;
};

• notify_one

  • 通知一个线程等待

• notify_all

  • 通知所有线程等待

• wait

  • 阻塞当前线程，直到条件变量被唤醒

• wait_for

  • 阻塞当前线程，知道条件变量被唤醒或指定的超时时间后

• wait_until

  • 阻塞当前线程，直到条件变量被唤醒或到达指定时间点

std::future

c++11关于异步操作提供了future相关的类，主要有std::future、std::promise和std::packaged_task，std::future比std::thread高级些，std::future作为异步结果的传输通道，通过get()可以很方便的获取线程函数的返回值，std::promise用来包装一个值，将数据和future绑定起来，而std::packaged_task则用来包装一个调用对象，将函数和future绑定起来，方便异步调用。而std::future是不可以复制的，如果需要复制放到容器中可以使用std::shared_future。

std::promise与std::future配合使用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

#include <functional>
#include <future>
#include <iostream>
#include <thread>

using namespace std;

void func(std::future<int>& fut) {
    int x = fut.get();
    cout << "value: " << x << endl;
}

int main() {
    std::promise<int> prom;
    std::future<int> fut = prom.get_future();
    std::thread t(func, std::ref(fut));
    prom.set_value(144);
    t.join();
    return 0;
}

std::packaged_task与std::future配合使用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

#include <functional>
#include <future>
#include <iostream>
#include <thread>

using namespace std;

int func(int in) {
    return in + 1;
}

int main() {
    std::packaged_task<int(int)> task(func);
    std::future<int> fut = task.get_future();
    std::thread(std::move(task), 5).detach();
    cout << "result " << fut.get() << endl;
    return 0;
}

std::future用于访问异步操作的结果，而std::promise和std::packaged_task在future高一层，它们内部都有一个future，promise包装的是一个值，packaged_task包装的是一个函数，当需要获取线程中的某个值，可以使用std::promise，当需要获取线程函数返回值，可以使用std::packaged_task。

async

async是比future，packaged_task，promise更高级的东西，它是基于任务的异步操作，通过async可以直接创建异步的任务，返回的结果会保存在future中，不需要像packaged_task和promise那么麻烦，关于线程操作应该优先使用async，看一段使用代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#include <functional>
#include <future>
#include <iostream>
#include <thread>

using namespace std;

int func(int in) { return in + 1; }

int main() {
    auto res = std::async(func, 5);
    // res.wait();
    cout << res.get() << endl; // 阻塞直到函数返回
    return 0;
}

async具体语法如下：

1

async(std::launch::async | std::launch::deferred, func, args...);

第一个参数是创建策略：

• std::launch::async表示任务执行在另一线程
• std::launch::deferred表示延迟执行任务，调用get或者wait时才会执行，不会创建线程，惰性执行在当前线程。

如果不明确指定创建策略，以上两个都不是async的默认策略，而是未定义，它是一个基于任务的程序设计，内部有一个调度器(线程池)，会根据实际情况决定采用哪种策略。

若从 std::async 获得的 std::future 未被移动或绑定到引用，则在完整表达式结尾， std::future的析构函数将阻塞直至异步计算完成，实际上相当于同步操作：

1
2

std::async(std::launch::async, []{ f(); }); // 临时量的析构函数等待 f()
std::async(std::launch::async, []{ g(); }); // f() 完成前不开始

注意：关于async启动策略这里网上和各种书籍介绍的五花八门，这里会以cppreference为主。

有时候我们如果想真正执行异步操作可以对async进行封装，强制使用std::launch::async策略来调用async。

1
2
3
4

template <typename F, typename... Args>
inline auto ReallyAsync(F&& f, Args&&... params) {
    return std::async(std::launch::async, std::forward<F>(f), std::forward<Args>(params)...);
}

原文章

补充

主函数

• 先创建一个Shell类型的类
• 然后屏蔽信号ctrl+c与ctrl+D
• 接着打印提示符，接收命令的输入
• 判断该次命令是否含有exit clear !等信息，如果有，执行相应操作
• 通过调用解析函数解析本次输入的命令

屏蔽信号

• ctrl + C

  1	signal(SIGINT, SIG_IGN);//将该信号的处理方式设置为忽略

• ctrl + D

  1 2 3 4

  struct termios term; tcgetattr(STDIN_FILENO, &term); term.c_cc[VEOF] = _POSIX_VDISABLE; tcsetattr(STDIN_FILENO, TCSANOW, &term);

首先定义一个termios类型的结构体，用来存储终端相关的属性信息

然后通过调用tcgetattr函数将获取终端的相关属性，并将这些属性保存到 **term **结构体中，第一个参数表示标准输入，是一个预定的文件描述符常量

将结构体中的c_cc数组成员的VEOF设置为禁用. c_cc数组是包含终端特殊字符的数组，VEOF是其中的一个索引，第二个参数是一个特殊的宏，用于禁用该特殊字符

最后，tcsetattr(STDIN_FILENO, TCSANOW, &term);调用tcsetattr()函数，它用于设置终端的属性。STDIN_FILENO表示标准输入文件描述符，TCSANOW表示立即生效的选项，&term是要设置的终端属性结构体。

tcgetattr

1

int tcgetattr(int fd, struct termios *termios_p);

参数说明：

• fd 是一个打开的终端设备文件描述符。

• termios_p 是一个指向 termios 结构体的指针，用于存储获取

  到的终端属性。

tcgetattr 函数返回一个整数值，表示函数调用的成功与否。如果函数成功执行，返回值为0；如果出现错误，返回值为-1，并设置相应的错误码。在调用该函数时，你需要检查返回值以确保函数调用是否成功。

tcsetattr

1

int tcsetattr(int fd, int optional_actions, const struct termios *termios_p);

参数说明：

• fd 是一个打开的终端设备文件描述符。
• optional_actions 是一个表示操作选项的整数值，用于指定何时应用属性的更改。
• termios_p 是一个指向 termios 结构体的指针，其中包含了要应用的终端属性。

optional_actions 参数用于指定何时应用属性的更改，它可以取以下三个值之一：

• TCSANOW：立即更改属性。
• TCSADRAIN：在所有输出都被传输后更改属性。
• TCSAFLUSH：在所有输出都被传输后更改属性，并丢弃所有未读的输入。

print

getlogin

1
2

char* getlogin(void)
//返回一个指向当前登陆用户的用户名的字符串指针

strcspn

1
2
3
4

size_t strscpn(const char *str1,const char *str2);
//str1：要搜索的字符串
//str2：要查找的字符集合
//计算字符串中连续不包含指定字符集合的最大前缀长度。

strftime

1

size_t strftime(char *str, size_t maxsize, const char *format, const struct tm *timeptr);

参数说明：

• str 是一个指向字符数组的指针，用于存储格式化后的时间字符串。
• maxsize 是 str 所指向的字符数组的最大容量。
• format 是一个格式字符串，用于定义输出的时间格式。
• timeptr 是一个指向 struct tm 结构体的指针，其中包含要格式化的时间和日期。

1
2
3
4

chrono::system_clock::now();
//是c++<chrono>头文件中的一个函数调用，用于获取当前的系统时间点
chrono::system_clock::to_time_t
//是一个函数模板，将time_point对象转换为time_t的类型

mycd

getenv

1

char* getenv(const char* name);

参数说明:

• name是一个指向以null结尾的字符串，表示要获取的环境变量的名称.

根据指定的环境变量的名称，返回对应的环境变量的值。找到则返回一个null结尾的字符串，表示该环境变量的值.否则返回null.

1
2

const char* path = s[1].c_str();
//将string对象转换为c风格的字符串.

需要注意的是c_str()返回的指针指向的仍为string内部存储的字符数组，因此需要确保在使用path指针时，string对象仍然有效

get_current_dir_name

是一个标准的POSIX函数，用于获取当前工作目录的路径

由于get_current_dir_name( )分配了动态内存，因此使用完毕后需要调用free( )。

setenv

1

int setenv(const char* name, const char* value, int overwrite);

参数说明：

• name 是一个指向以 null 结尾的字符串，表示要设置或新建的环境变量的名称。
• value 是一个指向以 null 结尾的字符串，表示要设置的环境变量的值。
• overwrite 是一个整数值，指示在环境变量已经存在时是否进行覆盖。如果 overwrite 为非零值，则会覆盖现有环境变量；如果 overwrite 为零，则不进行覆盖。

parse

istringstream是C++标准库中的一个类，他是用于从字符串中进行输入操作的输入流类.

getline()

1

std::istream& getline(std::istream& is, std::string& str, char delim);

参数说明：

• is 是一个输入流对象，表示要从中读取文本的输入流，通常是 std::cin（标准输入）或文件流对象。
• str 是一个字符串对象的引用，表示读取的文本将存储在其中。
• delim 是一个字符（默认为换行符 \n），表示行的结束符。

pipe

“pipe”（管道）是一种在进程间进行通信的机制。它允许一个进程的输出直接成为另一个进程的输入，从而实现进程间的数据传输。

1. 匿名管道：
   • 匿名管道是最常见的管道类型。它是一种单向通信管道，只能在具有父子关系的进程之间使用。父进程创建管道后，可以通过文件描述符进行读取或写入。子进程继承了父进程的文件描述符，从而可以使用相反的操作进行读取或写入。
   • 匿名管道是一种半双工通信方式，即数据只能在一个方向上流动。如果需要双向通信，需要创建两个匿名管道。
   • 使用匿名管道的典型流程是：父进程创建管道，然后调用 fork() 创建子进程。父进程关闭不需要的管道端口，子进程关闭另一个不需要的端口。然后父进程可以向管道写入数据，子进程可以从管道读取数据。
2. 命名管道：
   • 命名管道也称为FIFO（First-In-First-Out），它提供了一种无关进程关系的进程间通信方式。命名管道在文件系统中有一个与之相关联的路径名，多个进程可以通过这个路径名来进行通信。
   • 命名管道是一种半双工通信方式，类似于匿名管道，只能在一个方向上流动数据。
   • 命名管道可以使用 mkfifo 函数创建，也可以使用命令行工具 mkfifo 创建。

管道的使用可以通过系统调用函数来实现，例如 POSIX 标准中的 pipe() 函数。在使用管道时，重要的是要了解管道的读取和写入端口以及数据的流动方向，以确保正确的通信。

1

int pipe(int pipefd[2]);

pipe() 函数接受一个整型数组 pipefd[2]，用于存储管道的文件描述符。pipefd[0] 表示管道的读取端口，pipefd[1] 表示管道的写入端口。该函数返回值为 0 表示成功，-1 表示失败。

以下是 pipe() 函数的详细解释：

• pipefd 参数是一个包含两个元素的整型数组，用于存储管道的文件描述符。pipefd[0] 是管道的读取端口，用于从管道中读取数据；pipefd[1] 是管道的写入端口，用于向管道中写入数据。
• pipe() 函数创建一个匿名管道，并将管道的读取端口和写入端口的文件描述符填充到 pipefd 数组中。
• 匿名管道是一种半双工通信方式，数据只能在一个方向上流动。如果需要双向通信，需要创建两个匿名管道。
• 管道是内核中的一个缓冲区，用于在相关进程之间传输数据。数据写入管道后，可以从管道的读取端口读取。
• 管道的大小是有限的，一旦管道的缓冲区满了，进程写入数据时可能会被阻塞，直到有足够的空间来容纳数据。同样，如果管道为空，从管道读取数据时可能会被阻塞，直到有数据可读。
• 如果一个进程关闭了管道的读取端口，而另一个进程关闭了管道的写入端口，这两个进程之间的管道通信将结束。

dup2

1
2
3

#include <unistd.h>

int dup2(int oldfd, int newfd);

• oldfd 参数是需要复制的文件描述符。它可以是任何有效的文件描述符，包括标准输入（0）、标准输出（1）和标准错误（2）。
• newfd 参数是要复制到的新文件描述符。如果 newfd 已经打开，则会先关闭它，然后将 oldfd 复制到 newfd。
• 复制后，newfd 将和 oldfd 指向相同的文件表项，它们共享同一个文件偏移量和文件状态标志。
• 如果 newfd 等于 oldfd，则 dup2() 函数不进行任何操作，直接返回 newfd。
• dup2() 函数的一个常见用途是重定向标准输入、标准输出和标准错误。例如，可以将标准输出重定向到一个文件，或者将标准错误重定向到一个套接字。

executeCommand

open

• command[i + 1].c_str()：command是一个字符串向量，command[i + 1]表示该向量中的第i + 1个元素。.c_str()将该元素转换为C风格的字符串，以便与open()函数的参数类型匹配。这个参数是要打开的文件的路径。
• O_WRONLY：是open()函数的一个打开模式，表示以只写方式打开文件。这意味着你可以向文件写入数据，但不能读取文件的内容。
• O_CREAT：是open()函数的一个打开模式，表示如果文件不存在，则创建该文件。如果文件已经存在，open()函数仍然会成功打开文件。
• O_TRUNC：是open()函数的一个打开模式，表示如果文件已经存在且以只写方式打开，那么在打开文件时将截断文件的长度为0。这意味着打开文件后，文件中已经存在的内容将被清空。
• 0644：表示文件的权限。在这里，0644表示文件所有者具有读和写的权限，而其他用户只有读的权限。它是一个八进制数，其中第一个数字0表示这是一个八进制数，后面的三个数字分别表示文件所有者、文件所属组和其他用户的权限。

代码

shepp.hpp

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

#include <iostream>
using namespace std;
#include <string>
#include <vector>
#include <sstream>
#include <chrono>
#include <unistd.h>
#include <csignal>
#include <algorithm>
#include <termios.h>
#include <cstdlib>
#include <wait.h>
#include <fstream>
#include <sys/stat.h>
#include <fcntl.h>

class Shell
{
public:
    void print();
    void setlinebuf();
    string retlinebuf();
    void setsignal();
    bool isempty();
    void addHistory(const string& line);
    void setEOF();
    void printHistory();
    void searchAndReplay(const string &keyword);
    void mycd(vector<string> &s);
    void executeCommand(const vector<string> &command);
    void parse(string &s);
private:
    string linebuf;
    vector<string> history;
};

func.cpp

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343

#include "shell.hpp"

void Shell::print()
{   cout << "----------------------------------------------------------------------------" << endl;
    cout << "           ___                                                     ___" << endl;
    cout << "  ______  /  /___       ______  _____  ___   ___       ____  _____/  /___" << endl;
    cout << " /  __  \\/  __   \\     /  ___ - ___  \\/  /  /  /     /_   / /  __/  __   \\" << endl;
    cout << "/  /_/  /  /  /  /    /  /  /  /  /  /  /__/  /       /  /_(__  )  /  /  /" << endl;
    cout << "\\______/__/  /__/    /__/  /__/  /__/\\____,  /       /____/____/__/  /__/" << endl;
    cout << "                                    /_______/" << endl;
    cout << "----------------------------------------------------------------------------" << endl;
    char cwd [1024];
    auto now = chrono::system_clock::now();//返回当前的时间
    time_t time = chrono::system_clock::to_time_t(now);//将time_t point转换为time_t类型
    tm* timeinfo = std::localtime(&time);//将time_t转换为本地时间年月日,并存储在timeinfo中
    char timeStr[9];
    strftime(timeStr, sizeof(timeStr), "%H:%M:%S", timeinfo);
    //std::strftime()将std::tm结构的时间信息格式化为字符串，并将结果存储在指定的字符数组中。这里使用"%H:%M:%S"作为格式字符串
    //，它表示小时、分钟和秒的格式。timeStr是目标字符数组，sizeof(timeStr)用于指定数组的大小，
    //timeinfo是包含时间信息的std::tm结构的指针。
    cout << "# future @ future-arch in " << getcwd(cwd,1024) << " [" << timeStr << "]" << endl;
    cout << "$ " ;
    fflush(stdout);
}

void Shell ::setlinebuf()
{
    getline(cin,this->linebuf);
}

string Shell::retlinebuf ()
{
    return this->linebuf;
}

void Shell:: setsignal()
{
    signal(SIGINT, SIG_IGN);//忽略ctrl+c的操作
}

bool Shell ::isempty() 
{
    if(this->linebuf.empty())
    {
        return true;
    }
    return false;
}

void Shell::addHistory(const string& line)
{
    for(vector<string>::iterator it = history.begin(); it != history.end();it++)
    {
        if((*it).compare(line) == 0)
        return ;
    }
    history.push_back(line);
}

void Shell ::setEOF()
{
    struct termios term;//存储终端的相关信息
    tcgetattr(STDIN_FILENO, &term);//获取相关信息，并存入结构体
    term.c_cc[VEOF] = _POSIX_VDISABLE;//禁止使用EOF
    tcsetattr(STDIN_FILENO, TCSANOW, &term);//将设置存入终端
}

void Shell::printHistory()
{
    for(vector<string>::iterator it = this->history.begin(); it != this->history.end();it++)
    {
        cout << *it << endl;
    }
    cout << "~~~~~~~~~~~~~~~~~~~~~~~~~~~"<< endl;
}

void Shell::searchAndReplay(const string& keyword)
{
    for (const string& line : history)
    {
        if (line.find(keyword) != string::npos)
        {
            cout << "Replaying: " << line << endl;
            linebuf = line;
            break;
        }
    }
}

void Shell::parse(string& s)
{
    vector<vector<string>> tokens;
    istringstream iss(s);//可方便的从字符串中读取数据
    string root;
    while (getline(iss, root, '|'))//将s以|分割开
    {
        istringstream root_iss(root);
        vector<string> root_tokens;
        string token;
        while (root_iss >> token)//将单个命令以空格分隔开
        {
            root_tokens.push_back(token);
        }

        tokens.push_back(root_tokens);
    }
    if (tokens.size() == 1)
    {
        vector<string>& command = tokens[0];
        if (command[0] == "cd")
        {
            mycd(command);
        }
        else
        {
            executeCommand(command);
        }
    }
    else if (tokens.size() > 1)
    {
        int numPipes = tokens.size() - 1;
        vector<int> pipefds(2 * numPipes, 0); // 用于存储管道的文件描述符
        for (int i = 0; i < numPipes; ++i)
        {
            if (pipe(pipefds.data() + i * 2) < 0)
            {
                perror("pipe()");
                exit(1);
            }
        }
        int commandIndex = 0;
        for (auto& command : tokens)
        {
            pid_t pid = fork();
            if (pid < 0)
            {
                perror("fork()");
                exit(1);
            }
            if (pid == 0)
            {
                // 子进程
                if (commandIndex != 0) // 不是第一个命令，读取前一个管道的输出
                {
                    if (dup2(pipefds[(commandIndex - 1) * 2], STDIN_FILENO) < 0)
                    {
                        perror("dup2()");
                        exit(1);
                    }
                }
                if (commandIndex != numPipes) // 不是最后一个命令，将输出写入下一个管道
                {
                    if (dup2(pipefds[commandIndex * 2 + 1], STDOUT_FILENO) < 0)
                    {
                        perror("dup2()");
                        exit(1);
                    }
                }
                // 关闭所有管道的文件描述符
                for (int i = 0; i < 2 * numPipes; ++i)
                {
                    close(pipefds[i]);
                }
                if (command[0] == "cd")
                {
                    mycd(command);
                }
                else
                {
                    executeCommand(command);
                }

                exit(0);
            }
            else
            {
                // 父进程
                ++commandIndex;
            }
        }
        // 关闭所有管道的文件描述符
        for (int i = 0; i < 2 * numPipes; ++i)
        {
            close(pipefds[i]);
        }

        // 等待所有子进程结束
        for (size_t i = 0; i < tokens.size(); ++i)
        {
            wait(NULL);
        }
    }
}

void Shell::mycd(vector<string>& s)
{
    if (s.size() > 2)
    {
        cout << "cd: 函数调用参数过多" << endl;
        return;
    }
    else if (s.size() == 1 || s[1].compare("~") == 0)
    {
        const char* homeDir = getenv("HOME");
        if (homeDir)
        {
            if (chdir(homeDir) == -1)
            {
                perror("chdir()");
            }
        }
        else
        {
            cout << "cd: 无法获取家目录路径" << endl;
            return;
        }
    }
    else if (s[1].compare("-") == 0)
    {
        const char* lastDir = getenv("OLDPWD");
        if (lastDir)
        {
            if (chdir(lastDir) == -1)
            {
                perror("chdir()");
            }
        }
        else
        {
            cout << "cd: 无法找到上一个路径" << endl;
        }
    }
    else
    {
        const char* path = s[1].c_str();
        if (chdir(path) == -1)
        {
            perror("chdir()");
        }
    }
    // 更新环境变量 OLDPWD
    char* currentDir = get_current_dir_name();//获取当前工作目录的路径
    if (currentDir)
    {
        if (setenv("OLDPWD", currentDir, 1) == -1)//设置环境变量
        {
            perror("setenv()");
        }
        free(currentDir);
    }
    else
    {
        perror("get_current_dir_name()");
    }
}

void Shell::executeCommand(const vector<string>& command)
{
    pid_t pid;
    fflush(NULL);
    pid = fork();
    if (pid < 0)
    {
        perror("fork()");
    }
    if (pid == 0)
    {
        vector<char*> args;
        vector<int> outputFds; // 存储输出文件描述符的容器

        for (size_t i = 0; i < command.size(); ++i)
        {
            if (command[i] == ">") // 输出重定向：覆盖写入文件
            {
                int fd = open(command[i + 1].c_str(), O_WRONLY | O_CREAT | O_TRUNC, 0644);
                if (fd == -1)
                {
                    perror("open()");
                    exit(1);
                }
                outputFds.push_back(fd); // 将新的文件描述符添加到容器中
                dup2(fd, STDOUT_FILENO);
                close(fd);
                i++;
            }
            else if (command[i] == ">>") // 输出重定向：追加写入文件
            {
                int fd = open(command[i + 1].c_str(), O_WRONLY | O_CREAT | O_APPEND, 0644);
                if (fd == -1)
                {
                    perror("open()");
                    exit(1);
                }
                outputFds.push_back(fd); // 将新的文件描述符添加到容器中
                dup2(fd, STDOUT_FILENO);
                close(fd);
                i++;
            }
            else if (command[i] == "<") // 输入重定向
            {
                int fd = open(command[i + 1].c_str(), O_RDONLY);
                if (fd == -1)
                {
                    perror("open()");
                    exit(1);
                }
                dup2(fd, STDIN_FILENO);
                close(fd);
                i++;
            }
            else if (command[i] == "<<") // Here文档
            {
                string delimiter = command[i + 1];
                string inputText;

                while (getline(cin, inputText))
                {
                    if (inputText == delimiter)
                        break;
                    inputText += "\n";
                    write(STDIN_FILENO, inputText.c_str(), inputText.size());
                }

                i++;
            }
            else
            {
                args.push_back(const_cast<char*>(command[i].c_str()));
            }
        }

        args.push_back(nullptr); // execvp 需要以 nullptr 结尾的参数数组
        execvp(args[0], args.data());

        // execvp 执行失败时才会执行到这里
        perror("execvp()");
        exit(1);
    }
    else
    {
        wait(NULL);
    }
}

shell.cpp

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48