c******g
发帖数: 63 | 1 一个比较大的仿真程序(NS-2，很多做网络的人应该都用过）里面，想把数据输出到文
件。在C++源码某个相关类里加了个ofstream类的成员函数ofs，开始仿真的入口点初始
化（也就是以ios::trunc打开相应文件），在此后的代码中输出时，在ofs << buf外头
加个if （即 if (ofs << buf) {...}）也没有问题，但是输出的文件一直是空的（用
cout则可以确定buf里是有内容的），感觉很诡异。
于是，在输出前检验了ofs.is_open()、ofs.good()和ofs.bad()，发现值为true,
false, true。试了ofs.clear()，发现没用，就改用每次输出前重新用ios::app方式打
开一次这个文件（文件名是记在另一个成员变量outFileName中的），居然就work了，
但是这样会让程序速度大大减慢。于是另加了一句判断 if (!ofs.is_open() || !ofs.
good()) 才重新打开这个文件。这样速度提升了，内容也都写进去了。。。但是这还没
完。。。
改了一些其他的仿真参数仿真，又不行了（这诡异到居然是scenario-based的...）。
做sanity check，这回甚至是确认每次写入前都是open且good（没有bad的），也就是
根本就不用重打开。又在写入之后，check ofs.fail()，也是false，但是就是空白内
容（最初打开时的ios::trunc倒是每次都能实现呵呵，把之前的内容抹去）。改回了每
次输出前都必打开一次这个文件做ios::app的方式，又work了。。。
另外，在程序结束，是做了ofs.close()的。
omg，难道还真得每次都重新打开文件吗？那个三个条件判断的check也不凑效了。。。
有没有更加好的解决方案？拜谢！ | t****t
发帖数: 6806 | 2 别处出错了吧, 拿valgrind跑跑看.
ofs.
【在 c******g 的大作中提到】
: 一个比较大的仿真程序(NS-2，很多做网络的人应该都用过）里面，想把数据输出到文
: 件。在C++源码某个相关类里加了个ofstream类的成员函数ofs，开始仿真的入口点初始
: 化（也就是以ios::trunc打开相应文件），在此后的代码中输出时，在ofs << buf外头
: 加个if （即 if (ofs << buf) {...}）也没有问题，但是输出的文件一直是空的（用
: cout则可以确定buf里是有内容的），感觉很诡异。
: 于是，在输出前检验了ofs.is_open()、ofs.good()和ofs.bad()，发现值为true,
: false, true。试了ofs.clear()，发现没用，就改用每次输出前重新用ios::app方式打
: 开一次这个文件（文件名是记在另一个成员变量outFileName中的），居然就work了，
: 但是这样会让程序速度大大减慢。于是另加了一句判断 if (!ofs.is_open() || !ofs.
: good()) 才重新打开这个文件。这样速度提升了，内容也都写进去了。。。但是这还没
| c******g
发帖数: 63 | 3 这个神器比eclipse内嵌的debug tools好在哪里？具体怎样缩小问题的包围圈？谢谢！
【在 t****t 的大作中提到】
: 别处出错了吧, 拿valgrind跑跑看.
:
: ofs.
| w***g
发帖数: 5958 | 4 你试试给ofs.ofstream或者ofs.open加断点, 看是什么时候执行的. 根据你的描述有可
能是这么一种情况, 就是NS-2由于某些特殊的需要可能会在正常simulation之后又创建
了一个带有ofs的instance, 然后把你的正常输出给trunc了.
或者你每次用ofs打开文件的时候用不同的文件名看看.
ofs.
【在 c******g 的大作中提到】
: 一个比较大的仿真程序(NS-2，很多做网络的人应该都用过）里面，想把数据输出到文
: 件。在C++源码某个相关类里加了个ofstream类的成员函数ofs，开始仿真的入口点初始
: 化（也就是以ios::trunc打开相应文件），在此后的代码中输出时，在ofs << buf外头
: 加个if （即 if (ofs << buf) {...}）也没有问题，但是输出的文件一直是空的（用
: cout则可以确定buf里是有内容的），感觉很诡异。
: 于是，在输出前检验了ofs.is_open()、ofs.good()和ofs.bad()，发现值为true,
: false, true。试了ofs.clear()，发现没用，就改用每次输出前重新用ios::app方式打
: 开一次这个文件（文件名是记在另一个成员变量outFileName中的），居然就work了，
: 但是这样会让程序速度大大减慢。于是另加了一句判断 if (!ofs.is_open() || !ofs.
: good()) 才重新打开这个文件。这样速度提升了，内容也都写进去了。。。但是这还没
| t****t
发帖数: 6806 | 5 没用过eclipse, 好象内置的就是gdb吧. 那比valgrind差远了. 这种诡异的问题用
valgrind一查一个准.
当然, valgrind跑起来很慢, 但是你的时间比电脑的值钱不是.
【在 c******g 的大作中提到】
: 这个神器比eclipse内嵌的debug tools好在哪里？具体怎样缩小问题的包围圈？谢谢！
| c*******y
发帖数: 1630 | 6 thrust展开说说valgrind比gdb好的地方？？ 谢谢
【在 t****t 的大作中提到】
: 没用过eclipse, 好象内置的就是gdb吧. 那比valgrind差远了. 这种诡异的问题用
: valgrind一查一个准.
: 当然, valgrind跑起来很慢, 但是你的时间比电脑的值钱不是.
| t****t
发帖数: 6806 | 7 gdb告诉你问题爆发的地方
valgrind告诉你问题发生的地方
哪个好一目了然
当然, 如果你程序逻辑有问题, 比如+写成了-, 那什么都帮不了你.
【在 c*******y 的大作中提到】
: thrust展开说说valgrind比gdb好的地方？？ 谢谢
|
|
