我在C++ Primer Plus第6版中文版的输入、输出和文件一章查看语法时，发现用的是C风格的强制类型转换，代码如下：
fin.read((char *)&p1,sizeof(p1));
p1是一个结构体变量。
作者为什么不使用reinterpret_cast呢？
这本书其它章节没有看过，不知道作者是否都是用C风格的强制类型转换，他为什么偏向C风格呢？
7 个解决方案
#1
所以不推荐《C++ Primer Plus》。
http://*.com/questions/388242/the-definitive-c-book-guide-and-list
https://isocpp.org/get-started
这俩相对权威的书籍推荐网站里也不包括《C++ Primer Plus》。
http://*.com/questions/388242/the-definitive-c-book-guide-and-list
https://isocpp.org/get-started
这俩相对权威的书籍推荐网站里也不包括《C++ Primer Plus》。
#2
顺便关于这俩的比较，参见
http://*.com/questions/103512/in-c-why-use-static-castintx-instead-of-intx
http://*.com/questions/103512/in-c-why-use-static-castintx-instead-of-intx
#3
C方式的比较粗鲁，可任何类型直接转换
C++相对就要细致，不同的转换操作符只转换其该转换的类型
C方式的优点就写起来简单，C++的就可读性高，容易发现问题
写C++代码时建议使用C++式的，当然有时也常常就直接使用C的了
C++相对就要细致，不同的转换操作符只转换其该转换的类型
C方式的优点就写起来简单，C++的就可读性高，容易发现问题
写C++代码时建议使用C++式的，当然有时也常常就直接使用C的了
#4
请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。
意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。
试对比
图书馆（对图书的分类够结构化了吧）
和
搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索）
哪个处理信息更方便、更高效。
所以
与其费劲去重构代码让其看上去更简洁、更合理
不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。
结构越复杂，越难修改，越难除错。
有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。
程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George
前微软C#编辑器的开发主管Jay Bazuzi列出的一些有助于找到正确方向的问题；他觉得前同事们应该用这些问题来问自己；实际上不管在哪里工作的开发者们都应该经常问问自己这些问题：
◆“要保证这个问题不会再出现，我该怎么做？”
◆“要想少出些Bug，我该怎么做？”
◆“要保证Bug容易被修复，我该怎么做？”
◆“要保持对变化的快速响应，我该怎么做？”
◆“要保证我的软件的运行速度，我该怎么做？”
如果大多数团队都能不时问一下自己，必定会从中得益，因为这些都是真正强而有力的问题。
意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。
试对比
图书馆（对图书的分类够结构化了吧）
和
搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索）
哪个处理信息更方便、更高效。
所以
与其费劲去重构代码让其看上去更简洁、更合理
不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。
结构越复杂，越难修改，越难除错。
有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。
程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George
前微软C#编辑器的开发主管Jay Bazuzi列出的一些有助于找到正确方向的问题；他觉得前同事们应该用这些问题来问自己；实际上不管在哪里工作的开发者们都应该经常问问自己这些问题：
◆“要保证这个问题不会再出现，我该怎么做？”
◆“要想少出些Bug，我该怎么做？”
◆“要保证Bug容易被修复，我该怎么做？”
◆“要保持对变化的快速响应，我该怎么做？”
◆“要保证我的软件的运行速度，我该怎么做？”
如果大多数团队都能不时问一下自己，必定会从中得益，因为这些都是真正强而有力的问题。
#5
一个写起来简单，可读性不好。
一个写起来麻烦，但看起来比较清晰，转换什么东西，进行哪种转换
一个写起来麻烦，但看起来比较清晰，转换什么东西，进行哪种转换
#6
C++ 的 类型转换方式，相比 C 的类型转换方式来说，更安全，更容易在早期发现问题。
缺点嘛。。。没有缺点。挺好的。
缺点嘛。。。没有缺点。挺好的。
#7
谢谢各位，还是觉得C++ Primer Plus作者可能有某种考虑？
#1
所以不推荐《C++ Primer Plus》。
http://*.com/questions/388242/the-definitive-c-book-guide-and-list
https://isocpp.org/get-started
这俩相对权威的书籍推荐网站里也不包括《C++ Primer Plus》。
http://*.com/questions/388242/the-definitive-c-book-guide-and-list
https://isocpp.org/get-started
这俩相对权威的书籍推荐网站里也不包括《C++ Primer Plus》。
#2
顺便关于这俩的比较，参见
http://*.com/questions/103512/in-c-why-use-static-castintx-instead-of-intx
http://*.com/questions/103512/in-c-why-use-static-castintx-instead-of-intx
#3
C方式的比较粗鲁，可任何类型直接转换
C++相对就要细致，不同的转换操作符只转换其该转换的类型
C方式的优点就写起来简单，C++的就可读性高，容易发现问题
写C++代码时建议使用C++式的，当然有时也常常就直接使用C的了
C++相对就要细致，不同的转换操作符只转换其该转换的类型
C方式的优点就写起来简单，C++的就可读性高，容易发现问题
写C++代码时建议使用C++式的，当然有时也常常就直接使用C的了
#4
请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。
意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。
试对比
图书馆（对图书的分类够结构化了吧）
和
搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索）
哪个处理信息更方便、更高效。
所以
与其费劲去重构代码让其看上去更简洁、更合理
不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。
结构越复杂，越难修改，越难除错。
有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。
程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George
前微软C#编辑器的开发主管Jay Bazuzi列出的一些有助于找到正确方向的问题；他觉得前同事们应该用这些问题来问自己；实际上不管在哪里工作的开发者们都应该经常问问自己这些问题：
◆“要保证这个问题不会再出现，我该怎么做？”
◆“要想少出些Bug，我该怎么做？”
◆“要保证Bug容易被修复，我该怎么做？”
◆“要保持对变化的快速响应，我该怎么做？”
◆“要保证我的软件的运行速度，我该怎么做？”
如果大多数团队都能不时问一下自己，必定会从中得益，因为这些都是真正强而有力的问题。
意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。
试对比
图书馆（对图书的分类够结构化了吧）
和
搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索）
哪个处理信息更方便、更高效。
所以
与其费劲去重构代码让其看上去更简洁、更合理
不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。
结构越复杂，越难修改，越难除错。
有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。
程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George
前微软C#编辑器的开发主管Jay Bazuzi列出的一些有助于找到正确方向的问题；他觉得前同事们应该用这些问题来问自己；实际上不管在哪里工作的开发者们都应该经常问问自己这些问题：
◆“要保证这个问题不会再出现，我该怎么做？”
◆“要想少出些Bug，我该怎么做？”
◆“要保证Bug容易被修复，我该怎么做？”
◆“要保持对变化的快速响应，我该怎么做？”
◆“要保证我的软件的运行速度，我该怎么做？”
如果大多数团队都能不时问一下自己，必定会从中得益，因为这些都是真正强而有力的问题。
#5
一个写起来简单，可读性不好。
一个写起来麻烦，但看起来比较清晰，转换什么东西，进行哪种转换
一个写起来麻烦，但看起来比较清晰，转换什么东西，进行哪种转换
#6
C++ 的 类型转换方式，相比 C 的类型转换方式来说，更安全，更容易在早期发现问题。
缺点嘛。。。没有缺点。挺好的。
缺点嘛。。。没有缺点。挺好的。
#7
谢谢各位，还是觉得C++ Primer Plus作者可能有某种考虑？