想修改接口函数的举手~

[~/future]

route.cpp里面访问不了输出文件路径真是蛋疼。想修改接口函数或者想自己设计IO的举手~说不定人一多，就允许了呢~

[Dorrit_Waitting]

引用 10 楼 qq_33151593 的回复:

[quote=引用 9 楼 dlnuyj 的回复:] 能访问啊……

你是怎么做到的？[/quote] 代码根目录下不要有自己建的lib，所有文件都放到根目录下。两条边不一样长的时候，我是比较长的那部分单独写的，能写进去

[open_source_library]

希望能自由选择！强迫使用官方SDK就跟中学时代强迫穿校服一样！唉，程序员何必为难程序员嘛！！！

[~/future]

引用 19 楼 dlnuyj 的回复:

[quote=引用 10 楼 qq_33151593 的回复:] [quote=引用 9 楼 dlnuyj 的回复:] 能访问啊……

你是怎么做到的？[/quote] 代码根目录下不要有自己建的lib，所有文件都放到根目录下。两条边不一样长的时候，我是比较长的那部分单独写的，能写进去[/quote] 你是写在缓冲区的吧。我是说route.cpp文件里面不能访问主函数里面的 char *result_file~然后就不能在route.cpp里面直接写文件

[~/future]

引用 20 楼 open_source_library 的回复:

希望能自由选择！强迫使用官方SDK就跟中学时代强迫穿校服一样！唉，程序员何必为难程序员嘛！！！

连大神都觉得自己选择好一点呀~

[coldpeak ??]

如果是因为要多次写文件，为什么不能多次写缓存，以最后一次缓存写入文件呢？ 不是很多人抱怨io慢吗，少io几次充分利用缓存，这不是可以大大的节省效率吗

[qq_34002724]

多次写缓存，解决不了时间到了，图没跑完(但是已经找到了一些解，只是不知道是不是最优解)，导致答案一直在缓冲区的问题。要是找到一个更好的解，就覆盖文件，就不用担心答案未写入文件的问题了。而且可以把10s充分用在找解上面，而不用分心去看时间是不是快到了…

[open_source_library]

引用 30 楼 coldpeak 的回复:

如果是因为要多次写文件，为什么不能多次写缓存，以最后一次缓存写入文件呢？ 不是很多人抱怨io慢吗，少io几次充分利用缓存，这不是可以大大的节省效率吗

官方的SDK每读进一行，就分配4002个字节的动态数组来存储，直到程序运行结束才会释放。虽然说现在的内存够大，能让我们肆意地使用，但我不觉得这是一个很漂亮的IO方法。还有其他的一些地方，我都觉得并不是我最想要的。所以还是真心希望官方能给参赛者自由选择的空间。

[tJ2014Qt]

引用 32 楼 open_source_library 的回复:

[quote=引用 30 楼 coldpeak 的回复:] 如果是因为要多次写文件，为什么不能多次写缓存，以最后一次缓存写入文件呢？ 不是很多人抱怨io慢吗，少io几次充分利用缓存，这不是可以大大的节省效率吗

官方的SDK每读进一行，就分配4002个字节的动态数组来存储，直到程序运行结束才会释放。虽然说现在的内存够大，能让我们肆意地使用，但我不觉得这是一个很漂亮的IO方法。还有其他的一些地方，我都觉得并不是我最想要的。所以还是真心希望官方能给参赛者自由选择的空间。[/quote] 都写文件了不退出还需要干什么？ 你的话，我听着很像是下面的话： 我觉得很多人张的不够漂亮，不是我想要的世界，所以还是真心希望玉皇大帝能给我们自由选择自己容貌的权利。

[open_source_library]

引用 33 楼 tJ2014Qt 的回复:

[quote=引用 32 楼 open_source_library 的回复:] [quote=引用 30 楼 coldpeak 的回复:] 如果是因为要多次写文件，为什么不能多次写缓存，以最后一次缓存写入文件呢？ 不是很多人抱怨io慢吗，少io几次充分利用缓存，这不是可以大大的节省效率吗

官方的SDK每读进一行，就分配4002个字节的动态数组来存储，直到程序运行结束才会释放。虽然说现在的内存够大，能让我们肆意地使用，但我不觉得这是一个很漂亮的IO方法。还有其他的一些地方，我都觉得并不是我最想要的。所以还是真心希望官方能给参赛者自由选择的空间。[/quote] 都写文件了不退出还需要干什么？ 你的话，我听着很像是下面的话： 我觉得很多人张的不够漂亮，不是我想要的世界，所以还是真心希望玉皇大帝能给我们自由选择自己容貌的权利。[/quote] 用不着偷换概念来展现自己对高级IO的无知，你尽可以谷歌一点资料来充实自己。官方规定不能修改SDK唯一的原因就是不想让你输在这里。而官方的SDK对我来说，使用起来还有一些不便之处。

[tJ2014Qt]

引用 34 楼 open_source_library 的回复:

[quote=引用 33 楼 tJ2014Qt 的回复:] [quote=引用 32 楼 open_source_library 的回复:] [quote=引用 30 楼 coldpeak 的回复:] 如果是因为要多次写文件，为什么不能多次写缓存，以最后一次缓存写入文件呢？ 不是很多人抱怨io慢吗，少io几次充分利用缓存，这不是可以大大的节省效率吗

官方的SDK每读进一行，就分配4002个字节的动态数组来存储，直到程序运行结束才会释放。虽然说现在的内存够大，能让我们肆意地使用，但我不觉得这是一个很漂亮的IO方法。还有其他的一些地方，我都觉得并不是我最想要的。所以还是真心希望官方能给参赛者自由选择的空间。[/quote] 都写文件了不退出还需要干什么？ 你的话，我听着很像是下面的话： 我觉得很多人张的不够漂亮，不是我想要的世界，所以还是真心希望玉皇大帝能给我们自由选择自己容貌的权利。[/quote] 用不着偷换概念来展现自己对高级IO的无知，你尽可以谷歌一点资料来充实自己。官方规定不能修改SDK唯一的原因就是不想让你输在这里。而官方的SDK对我来说，使用起来还有一些不便之处。[/quote] 照你这个意思，允许修改sdk你就赢定了呗。 来来来，我们先给你颁个奖好了。

[tJ2014Qt]

引用 34 楼 open_source_library 的回复:

[quote=引用 33 楼 tJ2014Qt 的回复:] [quote=引用 32 楼 open_source_library 的回复:] [quote=引用 30 楼 coldpeak 的回复:] 如果是因为要多次写文件，为什么不能多次写缓存，以最后一次缓存写入文件呢？ 不是很多人抱怨io慢吗，少io几次充分利用缓存，这不是可以大大的节省效率吗

官方的SDK每读进一行，就分配4002个字节的动态数组来存储，直到程序运行结束才会释放。虽然说现在的内存够大，能让我们肆意地使用，但我不觉得这是一个很漂亮的IO方法。还有其他的一些地方，我都觉得并不是我最想要的。所以还是真心希望官方能给参赛者自由选择的空间。[/quote] 都写文件了不退出还需要干什么？ 你的话，我听着很像是下面的话： 我觉得很多人张的不够漂亮，不是我想要的世界，所以还是真心希望玉皇大帝能给我们自由选择自己容貌的权利。[/quote] 用不着偷换概念来展现自己对高级IO的无知，你尽可以谷歌一点资料来充实自己。官方规定不能修改SDK唯一的原因就是不想让你输在这里。而官方的SDK对我来说，使用起来还有一些不便之处。[/quote] 我无知的都无地自容了，比赛的重点在算法，而不是你开心不开心，你想不想要，这个你晓得伐。禁止修改sdk也是为了突出算法之间的差距，而不是在非算法的细节上。 既然你这么高大上，干脆你办个比赛好了，你高兴怎么来就怎么来，不用损别人无知来抬高自己。

[open_source_library]

引用 36 楼 tJ2014Qt 的回复:

[quote=引用 34 楼 open_source_library 的回复:] [quote=引用 33 楼 tJ2014Qt 的回复:] [quote=引用 32 楼 open_source_library 的回复:] [quote=引用 30 楼 coldpeak 的回复:] 如果是因为要多次写文件，为什么不能多次写缓存，以最后一次缓存写入文件呢？ 不是很多人抱怨io慢吗，少io几次充分利用缓存，这不是可以大大的节省效率吗

官方的SDK每读进一行，就分配4002个字节的动态数组来存储，直到程序运行结束才会释放。虽然说现在的内存够大，能让我们肆意地使用，但我不觉得这是一个很漂亮的IO方法。还有其他的一些地方，我都觉得并不是我最想要的。所以还是真心希望官方能给参赛者自由选择的空间。[/quote] 都写文件了不退出还需要干什么？ 你的话，我听着很像是下面的话： 我觉得很多人张的不够漂亮，不是我想要的世界，所以还是真心希望玉皇大帝能给我们自由选择自己容貌的权利。[/quote] 用不着偷换概念来展现自己对高级IO的无知，你尽可以谷歌一点资料来充实自己。官方规定不能修改SDK唯一的原因就是不想让你输在这里。而官方的SDK对我来说，使用起来还有一些不便之处。[/quote] 我无知的都无地自容了，比赛的重点在算法，而不是你开心不开心，你想不想要，这个你晓得伐。禁止修改sdk也是为了突出算法之间的差距，而不是在非算法的细节上。 既然你这么高大上，干脆你办个比赛好了，你高兴怎么来就怎么来，不用损别人无知来抬高自己。[/quote] 我说了想改sdk是因为带来不便，IO带来的十几毫秒的延迟不是致胜关键。损不损你不是我所想，你自己先看看自己的回复多么地让人不爽。官方最终的决定是什么都有一定的道理，我都能够接受，我只是表达一下自己的看法。

[~/future]

引用 37 楼 open_source_library 的回复:

[quote=引用 36 楼 tJ2014Qt 的回复:] [quote=引用 34 楼 open_source_library 的回复:] [quote=引用 33 楼 tJ2014Qt 的回复:] [quote=引用 32 楼 open_source_library 的回复:] [quote=引用 30 楼 coldpeak 的回复:] 如果是因为要多次写文件，为什么不能多次写缓存，以最后一次缓存写入文件呢？ 不是很多人抱怨io慢吗，少io几次充分利用缓存，这不是可以大大的节省效率吗

官方的SDK每读进一行，就分配4002个字节的动态数组来存储，直到程序运行结束才会释放。虽然说现在的内存够大，能让我们肆意地使用，但我不觉得这是一个很漂亮的IO方法。还有其他的一些地方，我都觉得并不是我最想要的。所以还是真心希望官方能给参赛者自由选择的空间。[/quote] 都写文件了不退出还需要干什么？ 你的话，我听着很像是下面的话： 我觉得很多人张的不够漂亮，不是我想要的世界，所以还是真心希望玉皇大帝能给我们自由选择自己容貌的权利。[/quote] 用不着偷换概念来展现自己对高级IO的无知，你尽可以谷歌一点资料来充实自己。官方规定不能修改SDK唯一的原因就是不想让你输在这里。而官方的SDK对我来说，使用起来还有一些不便之处。[/quote] 我无知的都无地自容了，比赛的重点在算法，而不是你开心不开心，你想不想要，这个你晓得伐。禁止修改sdk也是为了突出算法之间的差距，而不是在非算法的细节上。 既然你这么高大上，干脆你办个比赛好了，你高兴怎么来就怎么来，不用损别人无知来抬高自己。[/quote] 我说了想改sdk是因为带来不便，IO带来的十几毫秒的延迟不是致胜关键。损不损你不是我所想，你自己先看看自己的回复多么地让人不爽。官方最终的决定是什么都有一定的道理，我都能够接受，我只是表达一下自己的看法。[/quote] 对头，官方最终的决定是什么都有一定的道理，都能够接受。但是我们发表一下自己的看法也是可以的

[tJ2014Qt]

楼主又是计时有争议，又是要修改io的，感觉你在下一盘很大的棋，pk赛也是莫名恐怖

[DMY_memory]

希望route函数能随便改接口 不传输出文件路径进去很难搞 意味着只能在main中route函数结果返回时写一次文件 很多同学应该和我一样需要多次写入文件吧

[~/future]

引用 28 楼 yuzil1992312 的回复:

希望route函数能随便改接口 不传输出文件路径进去很难搞 意味着只能在main中route函数结果返回时写一次文件 很多同学应该和我一样需要多次写入文件吧

说到痛处了

[_Meta]

可不可以这样…… 在 route.h 里面加个 #define main xxx 把SDK里的main函数替换掉，然后把自己的跟SDK没有半毛钱关系的代码加进来？ 话说官方SDK只是在用户数据结构和系统IO缓冲区之间额外加了一个缓冲区，感觉没什么意义啊？还不方便跨平台开发。 我们自己写的读算例，30几行，顺便把不连续节点ID到连续ID的映射和去掉多余的边的预处理做完了，感觉现在用SDK反而变麻烦了。 （不过，说查时间耗时的人，其实查几百万次时间的开销可能比写一次文件的耗时还少，至少在windows底下C++的std::chrono::steady_clock是这样）

[frostbolt]

引用 39 楼 Phoenix_SZX 的回复:

可不可以这样……
在 route.h 里面加个 #define main xxx 把SDK里的main函数替换掉，然后把自己的跟SDK没有半毛钱关系的代码加进来？

话说官方SDK只是在用户数据结构和系统IO缓冲区之间额外加了一个缓冲区，感觉没什么意义啊？还不方便跨平台开发。
我们自己写的读算例，30几行，顺便把不连续节点ID到连续ID的映射和去掉多余的边的预处理做完了，感觉现在用SDK反而变麻烦了。

（不过，说查时间耗时的人，其实查几百万次时间的开销可能比写一次文件的耗时还少，至少在windows底下C++的std::chrono::steady_clock是这样）

没这个漏洞的，因为route.h上传后会被我们重新覆盖的。只有实现文件不会被覆盖。

[_Meta]

引用 40 楼 frostbolt 的回复:

[quote=引用 39 楼 Phoenix_SZX 的回复:]
可不可以这样……
在 route.h 里面加个 #define main xxx 把SDK里的main函数替换掉，然后把自己的跟SDK没有半毛钱关系的代码加进来？

话说官方SDK只是在用户数据结构和系统IO缓冲区之间额外加了一个缓冲区，感觉没什么意义啊？还不方便跨平台开发。
我们自己写的读算例，30几行，顺便把不连续节点ID到连续ID的映射和去掉多余的边的预处理做完了，感觉现在用SDK反而变麻烦了。

（不过，说查时间耗时的人，其实查几百万次时间的开销可能比写一次文件的耗时还少，至少在windows底下C++的std::chrono::steady_clock是这样）

没这个漏洞的，因为route.h上传后会被我们重新覆盖的。只有实现文件不会被覆盖。[/quote]

那这个readme是不是写错了……

[tJ2014Qt]

引用 39 楼 Phoenix_SZX 的回复:

可不可以这样…… 在 route.h 里面加个 #define main xxx 把SDK里的main函数替换掉，然后把自己的跟SDK没有半毛钱关系的代码加进来？ 话说官方SDK只是在用户数据结构和系统IO缓冲区之间额外加了一个缓冲区，感觉没什么意义啊？还不方便跨平台开发。 我们自己写的读算例，30几行，顺便把不连续节点ID到连续ID的映射和去掉多余的边的预处理做完了，感觉现在用SDK反而变麻烦了。 （不过，说查时间耗时的人，其实查几百万次时间的开销可能比写一次文件的耗时还少，至少在windows底下C++的std::chrono::steady_clock是这样）

我说的检查时间的开销，指的不是这个。。。可能我没有说清楚，so sorry 假如当前检查时间已经8s了，下次检查可能会超过10s，所以一般保守操作都是提前结束写文件。 所以，实际执行时间远远小于10s。 楼主意思是，找到一个比当前结果好的解，就写文件覆盖掉之前的解，完全不用考虑超时问题，所以，他的程序是完全可以跑完10s的，是结结实实的10s，没有一点水分的十秒。 我说的时间差别是在这里，如果时间检查太频繁，没有那个必要，如果检查太少，又不得不在八九s左右的时候就提前退出，因为下次检查很可能在10s之后，与其输出NA，不如输出个解。