-----------MSDN里的几个 print(在翻译上)的含义,您清楚吗?----------

johnsunwg 2002-07-29 04:14:35
The overridden Dump usually calls the Dump function of its base class before printing data members unique to the derived class.

CObject::Dump prints the class name if your class uses the IMPLEMENT_DYNAMIC or IMPLEMENT_SERIAL macro.

Note Your Dump function should not print a newline character at the end of its output.

三句话中分别有print,我的英文不太好,找不出最适合的意思,望高手告知几个句子的意思,尤其是print的用法和含义. 谢谢拉

...全文
49 3 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
3 条回复
切换为时间正序
请发表友善的回复…
发表回复
johnsunwg 2002-07-29
  • 打赏
  • 举报
回复
打印在这里的含义是什么意思呢? 我觉得不用打印啊,垃圾收集器有这个
用法吗?
opentuxedo 2002-07-29
  • 打赏
  • 举报
回复
几个print是同一个意思都有是打印:
1 dump在打印自己的数据前先打印父类的数据。
2 如果你用了***或***宏,dump就会把类名也打印出来。
3 你的dump在输出的结尾不打印换行符。
4 dump的调用只在debug版中有效。
johnsunwg 2002-07-29
  • 打赏
  • 举报
回复
还有这句 :) 万分感谢

Dump calls make sense only in the Debug version of the Microsoft Foundation Class Library.
1. 封装了几个自定义的函数, 例如 move_to_root, array_get_length, array_move_to_index, 这样可以少调用一些 X64Call; 2. 简单实现了对于类似 [0].A.B[0].C 的路径的解析取值. 接下来说一下遇到的问题和一些体验: 1. 我构造的测试数据大小是大约是 96MB , 在我的机器上可以正常解析, 再大一些(例如 128MB )会崩溃, 崩溃位于 ParsedJson.allocateCapacity , 琢磨了下没琢磨明白 (温馨提示: 真要是这种大小级别了还是建议各位用 SAX 方式); 2. 除了上面这点, 还有个已知的比较隐蔽 BUG, 貌似是 print_ 这个函数的锅: 静态编译之后, 在 demo 中如果 print_ 递归打印了一个 Object 例如 [0] , 再点击解析就会在 iterator_free 崩溃. 如果只是取值就不崩溃. 3. 这个库会拷贝数据, 在针对过长的数据的时候这不是好做法, 感觉这个库更像是科研性质, 和那些千锤百炼的老牌库相比, 目前可能只有速度占优势了; 4. 机器或者其它方面的限制, 我用 易语言 跑不出宣传文章中的千兆字节每秒, 不过几百 MB/s 还是有的; 5. 由于解析的时候它会拷贝数据, 我不清楚有没有可能会产生 64-bit 的内存地址, 暂时就是指针到文本当 32-bit 用, 但心很没底, 希望 eWOW64Ext 作者有空可以帮忙看一下... @shier2817 谢谢! 6. 库用的是 10.0.17134.0 版本的 SDK /MT 编译的, 但已经无法支持 WindowXP, 低版本的 SDK 编译不过去, 对这些指令不熟悉所以没有去探究原因(也许就是不支持, 详情请翻阅 MSDN); 7. 关于编译模式: 用 MinSizeRel 生成的话, 会导致 double 取值异常, 具体原因未深究, 所以默认使用了 Release . 我将会在附件中附上三种编译模式生成的文件供各位研究: RelWithDebInfo, MinSizeRel, Release; 用到的模块: 1. 感谢 eWOW64Ext : https://bbs.125.la/thread-14322538-1-1.html 2. Jβec : https://bbs.125.la/thread-14069145-1-1.html
今天更新一下, 解决之前贴子中提到的一些问题: 1. 封装了几个自定义的函数, 例如 move_to_root, array_get_length, array_move_to_index, 这样可以少调用一些 X64Call; 2. 简单实现了对于类似 [0].A.B[0].C 的路径的解析取值. 接下来说一下遇到的问题和一些体验: 1. 我构造的测试数据大小是大约是 96MB, 在我的机器上可以正常解析, 再大一些(例如 128MB)会崩溃, 崩溃位于 ParsedJson.allocateCapacity , 琢磨了下没琢磨明白 (温馨提示: 真要是这种大小级别了还是建议各位用 SAX 方式); 2. 除了上面这点, 还有个已知的比较隐蔽 BUG, 貌似是 print_ 这个函数的锅: 静态编译之后, 在 demo 中如果 print_ 递归打印了一个 Object 例如 [0], 再点击解析就会在 iterator_free 崩溃. 如果只是取值就不崩溃. 3. 这个库会拷贝数据, 在针对过长的数据的时候这不是好做法, 感觉这个库更像是科研性质, 和那些千锤百炼的老牌库相比, 目前可能只有速度占优势了; 4. 机器或者其它方面的限制, 我用易语言跑不出宣传文章中的千兆字节每秒, 不过几百 MB/s 还是有的; 5. 由于解析的时候它会拷贝数据, 我不清楚有没有可能会产生 64-bit 的内存地址, 暂时就是指针到文本当 32-bit 用, 但心很没底, 希望 eWOW64Ext 作者有空可以帮忙看一下... @shier2817  谢谢! 6. 库用的是 10.0.17134.0 版本的 SDK /MT 编译的, 但已经无法支持 WindowXP, 低版本的 SDK 编译不过去, 对这些指令不熟悉所以没有去探究原因(也许就是不支持, 详情请翻阅 MSDN); 7. 关于编译模式: 用 MinSizeRel 生成的话, 会导致 double 取值异常, 具体原因未深究, 所以默认使用了 Release . 我将会在附件中附上三种编译模式生成的文件供各位研究: RelWithDebInfo, MinSizeRel, Release; 8. 我对于 WOW64Ext 方面的知识不了解, 所以无法保证代码的稳定性, 抛砖引玉, 所以如果你希望封装完整的模块和工具, 可以进群与我交流.

16,547

社区成员

发帖
与我相关
我的任务
社区描述
VC/MFC相关问题讨论
社区管理员
  • 基础类社区
  • AIGC Browser
  • encoderlee
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……

试试用AI创作助手写篇文章吧