经历了好些日子的心情大起大落，终于实现了一个“又不是不能用”的版本。。。
使用的库：websocketpp
v0.0 这东西tm还能在网页上交互？！
日子回到刚接触这个项目时，平时我们在网上看到的各种ide，都只能跑一跑非交互的程序，撑死是给另一个文本一次性输入，然后得到全部输出结果（之后发现了国外有好些优秀的实现，下文将提到）。网上冲浪苦搜无果，因此从头思考这个逻辑如何实现。
经历了一段回忆不起来的时光，非常感谢hustoj的编译思路，尽管它是一次性的那种逻辑。在苦苦思索后才产生了v0.0的逻辑。
在接收代码编译结果后，用freopen重定向文件data.in、data.out，每次交互通过这两个文件去交互，再每次传输完成后删除文件，重启程序，营造一种“交互”的感觉。做过一段时间的acm，这个东西最终也会用于竞赛方面的支持，这样子每次重启的逻辑对于竞赛那种每次的输入输出是“独立”的看起来是没有问题了，对嘛。当我满心窃喜时才发现，或许之后用户会用来做一些不那么理想的操作，每次的输入也不那么独立，像是在程序中做一些随机数的操作，每次重启程序的逻辑显然就是完全不对了。0.0胎死腹中。内心mmp，这怎么交互？！
v0.1 使用更愚蠢的方法实现真正的交互却带来了更大的问题
显然0.0是不符合需求的了。0.1其实早就想到过了，只是觉得这种做法非常费事，听我慢慢道来。
在我（弱鸡）为何不好实现在线交互？用户的代码中使用的是标准的输入输出，而交互使用的websocket传输是写死的函数（尤其是选择了websocketpp，打开他的代码我真的一点也改不动，有种牵一发动全身的感觉，显然只是因为我菜）。wensocket不好改就只好顺着它，v0.1逻辑如下：
将用户代码文件转成字符串，将其中的标准输入输出全都改成websocket的发送接受，编译那个改变过的程序，让前端连接那个端口进行交互。
一段疯狂处理字符串的过程。。。
的确是实现交互了！用户可以在网页上一直输入并得到输出了！好开心！
但是！
加入了websocket框框的用户代码编译起来可一点也不快，原来在服务器上编译3、4s的程序在加入了这个后变成了2、30s，就算本地8核12线都得10s左右，或许是加入了boost的关系（websocketpp），而且对用户代码做了更严格的格式要求便于我提取字符串，且对于那么多种标准输入输出要优化到什么时候去。编译速度慢注定了这肯定不是一个正确的路，及时回头还不晚，于是这个版本就这样，只支持cincout，对代码格式有多种要求，编译速度还慢，换我我都不乐意用，但也就这样上了，准备换船新的写法。。 这才重新构思v0.2。
v0.2 又不是不能用（当前版本）
这个阶段我重新在网上找寻是否有可交互的cppide，没错，还真的有。
http://cpp.sh/ 一直藏在常百度cpp基本知识后的编译器，还挺好的
https://www.onlinegdb.com/# 安全做的非常好，网页采取了防止第三方网址内嵌，自己盈利行为
https://www.jdoodle.com/online-compiler-c++ 提供API供第三方购买。。。
腾讯的coding也出现了，但其实来看，我还是一点源码也看不到，并不知道实现方法，只知道实现了似乎可以卖钱，这段时间我也怀疑过是否该用linux c做这样一个程序，内心的自我怀疑持续到后来的明朗。
后来找到了通信的方法，实现了用户代码随便写，服务器上编译10s以下.
当前缺点：不能传输太长的数据，不接受sleep等延时一阵子的代码运行。
未来有后续更新再曝出0.2实现。
网友评论