[讨论]了解一下，有多少人认真看了QT自身的源代码，有必要吗 [复制链接]

我觉得QT只是一种C++对不同平台下的API封装，而且它要用到的C++语法是在多平台多编译器下通用的，再加上一些好用的类，比如QString等等。原理上其实挺简单的，QT入门也不难，但是想要真正掌握QT，我想也许应该还应该仔细看看QT的源代码。之所以这样说，是来源于我的delphi开发经验，我曾经使用了5、6年时间的delphi，也做了不少项目，但是总感觉自己没有真正学会delphi，直到半年前我开始看Delphi的VCL库源代码，相当于QObject及其所有子类的源代码，每天晚上坚持，看了整整半年，终于觉得懂了，然后就如臂使指，想怎么改就怎么生效，很爽。


由于项目的要求，最近开始转向QT做开发，本来也想如法炮制，但是粗略看了一下QT的库极其庞大和复杂，庞大就不用说了，复杂有两个方面：跨平台和C++语法的复杂（而且Delphi库代码修改后，可立刻编译生效，速度很快，但C++的编译速度太慢了，编译配置也比较复杂）。所以感觉有点吃不消，不知道自己究竟应该钻进去看，还是会应用层的开发就行了。所以请教一下大家的学习心得，看QT库的源代码有必要吗？有多少人仔细看了QT自身的源代码，看不完全部，至少应该仔细看10来个核心类的源代码吧？

一开始肯定是能应用就行了。但在使用过程中，你慢慢就会深入到源码中了。
比如调试程序时，一步步会跟踪到源码中。比如看文档时，有些地方感觉比较含糊，你可能会去翻翻源码。再比如你对某个东西很感兴趣，也可能主动去翻翻。

其实Delphi的VCL是非常优秀的，它的解决思路非常棒。但是Qt的原理还是源自C++的理念。

看不看源码取决于深入程度和需要了。

一有问题就去看看源码，毕竟这比网上的例子、说法、道理，实在和直接的多，是最接近真理的地方。但也不要强迫自己去看，能力是需要积累的，慢慢来就对了

圣域天子:其实Delphi的VCL是非常优秀的，它的解决思路非常棒。但是Qt的原理还是源自C++的理念。
看不看源码取决于深入程度和需要了。
 (2014-12-06 17:11) 

说的没错。不过，我就是想知道，如果想成为QT高手，是不是一定需要看源码？因为要看这份力气值不值得。比如天天C++，Delphi编程，但我们并没有C++/Delphi编译器的源码，碰到问题去查一下语法规则就行了，也能解决问题的。所以并不是一定需要。

我个人还是想看QT源码的，就是时间安排上是个问题。如果不看QT源码，也可以成为高手，顺利解决各种问题，那我宁愿去学点新技术，总版主你说呢？

stlcours:说的没错。不过，我就是想知道，如果想成为QT高手，是不是一定需要看源码？因为要看这份力气值不值得。比如天天C++，Delphi编程，但我们并没有C++/Delphi编译器的源码，碰到问题去查一下语法规则就行了，也能解决问题的。所以并不是一定需要。
我个人还是想看QT源码的，就是时间 .. (2014-12-08 17:30) 

看源码肯定是有益的。
但是看了源码不代表一定能成为高手。
不看源码也不代表一定不能成为高手。
因为Qt源码代表了它的处理和解决问题的方式，
但是能力的进步并不是被一个类库牵着鼻子走的。
百分之百了解Qt，估计可以成为Qt的技术支持人员，其它能力的培养和提高还是要靠自己的。

圣域天子:看源码肯定是有益的。
但是看了源码不代表一定能成为高手。
不看源码也不代表一定不能成为高手。
因为Qt源码代表了它的处理和解决问题的方式，
....... (2014-12-09 08:42)

总版主果然见识不凡，领教了。不过以我自己的Delphi经验来看，不看源码是不能成为真正的高手的。

至于我个人，只是公司目前有这一个QT项目，暂时学用一下，已经做了4个月了，但不打算深入研究QT源码了，有功夫继续研究我的Delphi VC，可能还有golang。不过如果QT有问题，还请继续指教。

stlcours:总版主果然见识不凡，领教了。不过以我自己的Delphi经验来看，不看源码是不能成为真正的高手的。
至于我个人，只是公司目前有这一个QT项目，暂时学用一下，已经做了4个月了，但不打算深入研究QT源码了，有功夫继续研究我的Delphi VC，可能还有golang。不过如果QT有问题，还请继 .. (2014-12-09 17:03) 

其实不同的类库（不是语言）解决和设计的方式差异很大。
就如C++在早期一直认为虚方法不应该设计成public方式，但是java却把它变成了interface，在实现形式上实现都是纯虚函数，但采用和解决问题的方式却截然不同，甚至抵触。

所以你看VCL也好，看Qt也好，甚至近日开源的.NET也行，
这些都是它们对于同样问题的不同解决方式和思路，你可以去学习、模仿它们。

但如果说想要成为高手，那我认为你必须要凌驾类库之上，找到自己的方式才行。

国外有些高手，研读成熟的类库是手段之一，在熟悉了之后，往往通过开发自己的类库
来达到提升自己的能力。

就象判断软件能力级别一样，三级水平是自己能开发一个一定规模的独立软件为判断标准，因为当开发一个完整的软件时，可能会对界面、数据库、网络、线程，甚至不同OS底层、服务、进程、
串口等等各方面都有技术要求，也能碰到各式各样的问题，这样才是提高自身能力的关键路径。

圣域天子:其实不同的类库（不是语言）解决和设计的方式差异很大。
就如C++在早期一直认为虚方法不应该设计成public方式，但是java却把它变成了interface，在实现形式上实现都是纯虚函数，但采用和解决问题的方式却截然不同，甚至抵触。
所以你看VCL也好，看Qt也好，甚至近日开源的.NET也 .. (2014-12-09 21:11)

>>其实不同的类库（不是语言）解决和设计的方式差异很大。
>>就如C++在早期一直认为虚方法不应该设计成public方式，但是java却把它变成了interface，在实现形式上实现都是纯虚函数，但采用和解决问题的方式却截然不同，甚至抵触。

C++诞生过早，那时候还没有interface，并且包袱过重（兼容C），不能有interface，头文件也相当独特，具有部分Interface的功能，如此就更没必要了。至于你说的虚方法不应该设计成public方式，我没听说，好像也没道理。而Java没有任何历史包袱，所以做成了所有函数自动全OO（C++要声明才行），加上interface自然也没问题。另外C++加上了多继承，有利有弊，不绝对，但是我自己深刻体会，感觉多继承理论上是有道理的，实际上用到的很少，所以实际上是一个造成冗余的一个鸡肋功能，但是却造成了不少困扰。另外C++有个重大缺陷，就是继承类的虚函数包袱过重，所以QT采用信号槽，VCL采用动态方法，MFC采用消息映射，无一例外。所以这些不同类库，其实不是设计方式的问题，而是时间造成的历史因素。而且对虚函数的问题，解决方式都比较相似，而且后期的语言都有interface。话说golang对interface的支持，都成了最顶级，变成自动暗含了。

>>所以你看VCL也好，看Qt也好，甚至近日开源的.NET也行，
>>这些都是它们对于同样问题的不同解决方式和思路，你可以去学习、模仿它们。
我觉得能看懂就不错了，而且我不知道自己什么时候才能百分百看懂？光学一个win32就让我感觉吐血，各种效果太多太强大，10年了，还是学了一点皮毛而已，刚够做项目的。还有许多强大功能虽然也了解一些，但是项目用不到就没有深入学习的动力，时间也不够。

>>但如果说想要成为高手，那我认为你必须要凌驾类库之上，找到自己的方式才行。
>>国外有些高手，研读成熟的类库是手段之一，在熟悉了之后，往往通过开发自己的类库来达到提升自己的能力。
找不到，也凌驾不了。你有什么具体的建议吗？或者有非著名的第三方类库看看也行。我认为，语言级RTL的类库没必要看，浪费时间，会用就行。封装OS API的类库不可能超过MFC VCL QT，好像也没必要重新封装~~~

>>就象判断软件能力级别一样，三级水平是自己能开发一个一定规模的独立软件为判断标准，因为当开发一个完整的软件时，可能会对界面、数据库、网络、线程，甚至不同OS底层、服务、进程、串口等等各方面都有技术要求，也能碰到各式各样的问题，这样才是提高自身能力的关键路径。
我独立做了好几个项目了，固然可以独当一面，但是现在却限制了进一步的提高，我倒是希望有一个高手团队一起工作。前一阵有个多线程的问题解决不了，结果还是网上有个高手一句话就醍醐灌顶（我们买了他家的控件），这就是差别。