寒假作业_3

寒假第三次作业

文件读写的学习过程及心得

之前在读《C++ primer plus》时，看到用文件进行输入输出时，看得一脸懵逼，不了解为什么那样做可以实现文件输入输出。
经过这个寒假上慕课对C++面向对象特性的进一步学习，总算搞懂了，掌握了通过定义fstream中的ifstream、ofstream对象，调用成员函数来对文件进行打开，检查，读写，关闭等操作，有时间会专门开个随笔对那些成员函数进行一个整理。

git commit 信息学习心得体会

其实之前做西二在线的作业时就接触到了GitHub，但是对commit信息完全没有重视，直到这次特地看了一些教程，才知道commit信息需要规范才能便于管理。
常用的如用feat（新功能），fix（bug修复），style（格式修改），refactor（重构）等打头，表明此次修改的类型，然后在后面对这次修改作简要的说明。
个人感觉一开始使用Git时很不习惯，特别是那些指令不好记，但随着实践次数的增加，熟练之后发现确实很方便，而且还可以关联远程仓库，实现多人合作管理。

程序编码情况

问题设定

①设定电梯只有在请求发出时刻才能得知这条请求，然后做出当前最优决策，即执行在该请求发出时刻的状态下,使已发出请求的乘客的等待时间总和最小的方案。
②每次停靠接、放人需要1s，每移动一层需要1s，每位乘客的等待时间从请求发出开始计算，直到到达目的楼层。
③乘客可以选择去任意楼层，不再局限于1F或10F。

编码思路及优化过程

思路：

①因为只有一部电梯，所以尽可能少掉头。原则上把当前这一方向上的事做完后，再掉头。换句话说，只有在电梯继续上升（或下降）没有意义（接不到人且放不出人）时，才掉头。
②对请求采取实时处理，即每一秒确认一次有无请求，有请求则马上处理，并存下决策结果。
③决策结果存在“控制中心类”的一个int数组plan[11]里，下标对应1-10F，元素的值0-6分别有不同的含义（详细见头文件“elevator.h”中的注释）。
④电梯处理当前时刻下的所有请求后进入停止状态，直到下一条请求出现。

优化过程：

其实就是debug过程，最难写的就是请求处理函数 “ask_solve” ，因为要讨论很多情况下的请求应该如何处理，并用上面提到的plan数组储存下决策，并且针对每一次请求，都要更新决策即改动数组。一下列举几个值得一提找了很久才发现的BUG：
①请求发生的楼层和电梯所在楼层相同，忽略了这种情况下的决策，解决方法较简单，和请求发生楼层高于电梯所在楼层并在一起讨论。
②在制定新决策，清除旧决策上，犯了一堆错误，比如把刚做的决策当做旧决策清除掉了。
③这个其实不太好意思说，但是真的找了很久，最后通过调试，一步步追踪电梯状态和plan数组的变化，才发现。。。。。。我把等号写成赋值了，就是少扣了个=。。。。
PS：emmmm感觉程序可能还有会一些BUG，如还有决策冲突的情况，但暂时还未发现。电梯效率不敢说很高，但应该是一个效率可以接受的算法。

打码情况一览

代码行数	Debug数	总耗时
43+424	近10个	5天

因为个人的代码风格，所以行数看起来有点恐怖。debug数没有具体去记，具体耗时也是，每天打一部分，然后花了大概5天

测试样例设计

应要求设计了5组比较有代表性的测试样例：

①常规的请求
②较为密集的请求，即5秒内连续5个各式各样的请求
③极其稀疏的请求，基本一趟就为一个人服务
④同一时刻，5个不同楼层的请求
⑤同一时刻，同一楼层的5个请求
暂时就想到这些

运行结果

GitHub

链接：点击进入
提交日志：

前两次commit是做第一个电梯时的提交，代码是未完成的，思路也不太好，在“elevator_dispatch”文件夹
第三次commit是这次的电梯，即“Elevator_2”文件夹
第四次commit是改exe程序的名字为“elevator.exe”

转载于:https://www.cnblogs.com/orangee/p/8445562.html