GitHub仓库
提交日志截图
文件读写
文件读写之前接触过一些，而这次显然与之前不同，c++的文件读写打开方式便于c有所差别，而所用的指令也不同。至于如何学习，笔者则是通过了网上查阅了一些博客来学习这项东西（主要是c++文件读写详解），可以说这篇博客确实对得起”详解“，笔者从中学习了很多，也改变了许多以往旧的观念。之前笔者所知的文件读写指令很单一（例如pascal的assign、close，c的freopen），但并不知道c++与c的读写方式不同，更不用说c++的读写方式在笔者看来虽然比较繁复，但是更为严谨，因为它规定的参数、方式都给人一种相比c来说更加谨慎的感觉。
在笔者看来文件读写的学习很有必要，因为文件是获取数据的一种巧妙方式，有时候不仅可以打开需要的，也可以去看看其他的
编码规范、注释、git commit信息
对于编码规范和注释，笔者并没有学习多少，因为本来就有注意编码规范，比如一些的变量的命名，也自己会写一些注释，但是去学习了以后还是有了不少观念更新，以前注释可以说写得比较随性，可能就给自己看看而已，没想到会有别人来阅读。而git commit信息的学习，笔者发现，原来commit信息如此重要，竟然包括了如此多的细节和注意事项（第一次学习的时候并没有注意那么多的细节，例如笔者第一次学习只注意到了commit相当于提交备注，需要有Header、Body、Footer，却没有仔细去了解下一层的东西，不知道Header需要type、subject、scope，以及这些再分解的细节如fix、feat、Body需要第一人称描述等等），而至于注意事项，笔者认为首先commit一定要简洁，笔者觉得一个规范的简洁的commit信息，可以减少不少的工作量，就相对于大的提交量和修改次数而言；其次commit既要符合既定规范，也要比较严谨认真，不容得些许玩笑（当然笔者觉得吐槽可以出现，但是最后肯定是要修改的），毕竟commit需要被阅读，笔者认为commit的表达也一定程度上体现了提交者的素养。
编码、debug
这次编码并没有花费太多的时间（相比于上次），因为思考得比较详细，所以写起来也比较快，比较痛苦的就是debug，想的是这样，跑出来是那样，一直在纠错，很是头大，好在思路比较清晰，纠错起来问题也不是很大，只是次数比较多导致效率并不是很高。
| Lines | Bugs | Time |
|---|---|---|
| 445 | 10+ | 10h |
设计样例
这次样例的设计还是沿用了上次的风格，即特殊数据占多数，普通数据较少，笔者认为这样才能说比较客观的反应代码的可行性，因为普通情况处理肯定差别不大，不同就在于对于较为特殊的数据的处理方式。
特别地，笔者在第二次作业中说到要解决的问题，笔者都进行了解决：
1、当某一乘客发出请求后，对于顺路的乘客，笔者先将其接入电梯（如果其所在楼层也在电梯当前运行轨迹上的话），之后判断在电梯运动过程中，会不会经过顺路乘客的目的地，经过便停靠，不经过便继续移动到先前准备接送的楼层、
2、笔者此次的电梯采用先接后送，边接边送的思路，来保证能得到较小的等待时间总和，接乘客时采用队列，送乘客是采用栈（对于有顺路乘客的情况更优，但这在普通情况下会牺牲掉一些乘客的时间，即后文所述），笔者考虑如无顺路乘客便牺牲掉一部分乘客的时间，优先接送栈顶（即最后进入电梯）的乘客。
3、笔者对于电梯的运行方向加入了dir来表示，虽然并没有什么比较大的改观，笔者目前也没有什么思路来更好地运用dir。
以下是样例及输出截图
SAMPLE_INPUT：
以下简述所构造样例：
样例一：多名乘客在同一楼层发出请求，请求时间连续且恰为前一名乘客进入电梯后的时间
样例二：乘客请求楼层连续，目的楼层一致，可被顺路捎达
样例三：乘客已经到达目的楼层却不知情
样例四：普通情况，正常需求的混杂（可能有点特别在时间比较集中和连续）
样例五：普通请求的情况下，有一大时间请求，其请求足以覆盖至其他乘客到达目的地以及电梯到达其出发楼层
SAMPLE_OUTPUT：
