首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 移动开发 > QT开发 >

Qt极其不稳定，想学Qt的望三思

2012-12-18 
Qt极度不稳定，想学Qt的望三思用开源的 Qt Service 写个服务，错误频出之前由于引入的为Release版本而QtSQL

Qt极度不稳定，想学Qt的望三思
用开源的 Qt Service 写个服务，错误频出
之前由于引入的为Release版本而QtSQL用的是Debug版本，导致QVariant析构崩溃。
现在是这么一段代码


QString tempurl = "http://172.16.1.149";
{
    string strUrl = tempurl.toStdString();
}

又是析构时崩溃（}这句崩溃）
这种崩溃最菊花紧了，明明是很正确的语句，想修复都无从下手
配置方面参照了新建的一个工程（执行这两行代码可行），依然崩溃。
Qt太多初学者不能解决的析构问题了，倍感压力，这破服务要是早用C++和STL写会少多少调试时间！
而且Qt只是入门快，想深入实在是难，作为新技术，技术著作又没几篇，配置之类的文章也甚少
三思哪同学们！
[最优解释]
MSDN：

Caution: Do not mix static and dynamic versions of the run-time libraries. Having more than one copy of the run-time libraries in a process can cause problems, because static data in one copy is not shared with the other copy. The linker prevents you from linking with both static and dynamic versions within one .exe file, but you can still end up with two (or more) copies of the run-time libraries. For example, a dynamic-link library linked with the static (non-DLL) versions of the run-time libraries can cause problems when used with an .exe file that was linked with the dynamic (DLL) version of the run-time libraries. (You should also avoid mixing the debug and non-debug versions of the libraries in one process.)
[其他解释]
引用:
QString在转成STL string 的时候崩溃的。


你可以贴出可以重现这种问题的最简代码，单就Qt方面来说，这没什么神秘的


inline std::string QString::toStdString() const
{ const QByteArray asc = toAscii(); return std::string(asc.constData(), asc.length()); }


Qt源码很简单，一个unicode字符串，编码为某种字节流(受用户控制)，然后使用该字节流 构造一个标准的 std::string 并返回

题外：

而你这个抱怨的问题，似乎更像是C++造成的（而不是Qt），比如，你的代码各部分是不同的C++编译器编译的(不同的厂商提供或相同厂商的不同版本)。还有不同的编译选项等等

[其他解释]
你的应用程序使用 MTd 编译的
你的应用程序使用 QtCored4 这个动态库(Qt 默认是 MDd 编译的)
[其他解释]
三思！
[其他解释]
这个跟QT恐怕没关系吧
[其他解释]
引用:
这个跟QT恐怕没关系吧

恩，

 1. Qt诞生于1991年，楼主将其定位于“新技术”
 2. (这破服务要是早用...) 将 Qt库 和 C++语言 进行比较？？
 3. (想深入实在是难) 源代码都在哪儿放着，只不过是C++的一个库而已，而且有没有用到很深的C++的知识
 4. ...
[其他解释]
恕鄙人才疏学浅，我觉得跟mfc和.Net比起来，qt确实很多问题。
资料匮乏，文档含糊，错误莫名其妙
[其他解释]
引用:
引用:

这个跟QT恐怕没关系吧

恩，

 1. Qt诞生于1991年，楼主将其定位于“新技术”
 2. (这破服务要是早用...) 将 Qt库 和 C++语言 进行比较？？


 3. (想深入实在是难) 源代码都在哪儿放着，只不过是C++的一个库而已，而且有没有用到很深的C++的知识
 4. ...


1. 根本不能看诞生时间，要看技术成熟的时间，而且我的重点是技术著作少，作为初学者想找什么东西都感觉很无助
2. 不是跟C++语言比较，我的意思QtService开源库可以很方便地写服务，纯C++也能直接写服务，但是Qt出很隐晦的BUG太频繁了，导致耗费的时间更多了
3. 这个可以赞同，作为初学者，确实比较弱，自身原因在这儿。
4. toStdString()这个函数某些情况下真的不行，我做过很多测试了，当然有导入外部的lib，可能是由于lib引起的，但是这能体现低耦合么？
5. 问过公司的前辈，基本上都是用宏来解决的，通过toLocal8Bit()然后再强转成std::string的
6. ...没说Qt不好，只是初学者慎入
[其他解释]
引用:
引用:

这个跟QT恐怕没关系吧

恩，

 1. Qt诞生于1991年，楼主将其定位于“新技术”
 2. (这破服务要是早用...) 将 Qt库 和 C++语言 进行比较？？
 3. (想深入实在是难) 源代码都在哪儿放着，只不过是C++的一个库而已，而且有没有用到很深的C++的知识
 4. ...

1，LZ的意思应该是新近流行起来的技术。
2，LZ的意思应该是QT和C++标准库功能共同的部分。
3，原代码，除了大牛！有多少人对windows和*nix编程熟悉，可以容易的看懂Qt源代码。真有这能力，谁还学qt，不是隔靴挠痒吗！
4，！！！。。。

我是初学者
[其他解释]
...
动作太慢了
[其他解释]
还是你用的不熟,有很多软件都是QT开发的.
[其他解释]
。。。。。。。只用过GUI部分的小菜飘过~~~~
[其他解释]
没有完美的技术，都有瑕疵和败笔。
总钻研成熟的技术，人家都优化到基本上逼近完美的技术，那又有什么意思？能有什么突破？
你所提到的这方面的确是qt的劣势，但是qt的跨平台最显著的优势因为你没有用到体会到而被忽视了。再说，在qt框架下也可以调用你所说的“早就可以调试完的c++程序”。
技术到底成熟不成熟，还得看程序员发挥的成熟不成熟。
[其他解释]
引用:
没有完美的技术，都有瑕疵和败笔。
总钻研成熟的技术，人家都优化到基本上逼近完美的技术，那又有什么意思？能有什么突破？
你所提到的这方面的确是qt的劣势，但是qt的跨平台最显著的优势因为你没有用到体会到而被忽视了。再说，在qt框架下也可以调用你所说的“早就可以调试完的c++程序”。
技术到底成熟不成熟，还得看程序员发挥的成熟不成熟。

妞妞V5！！！我只说一句，姚明不踢足球，谢谢！！
[其他解释]
引用:
没有完美的技术，都有瑕疵和败笔。
总钻研成熟的技术，人家都优化到基本上逼近完美的技术，那又有什么意思？能有什么突破？
你所提到的这方面的确是qt的劣势，但是qt的跨平台最显著的优势因为你没有用到体会到而被忽视了。再说，在qt框架下也可以调用你所说的“早就可以调试完的c++程序”。
技术到底成熟不成熟，还得看程序员发挥的成熟不成熟。

跨平台的确很不错，没有尝试过但是能体会那种崇高的理想。不过我真的没有说Qt或者哪门哪门语言不好的意思，理想情况下，真正的大牛可以用任何语言写出汇编相关的解释器，然后在这步的基础上实现任何汇编语言可以实现的功能，不是么？

只是对于像我这样的低端初学者不太适合，这段时间发现最恼人的问题就是析构爱崩溃，我也搜过很多资料，感觉这跟Qt的一大炒点“QString深拷贝延后”有关系，不过还没有能力和精力去证实。这种崩溃类型的问题，就是Qt库不稳定的体现，我们用MFC开发的时候是很少遇到这类问题的，即使遇到了也已经有了成熟的解决办法。

程序员发挥的成熟不成熟是有一定的影响关系，但是发挥成熟也要定义一堆宏或者改用其他函数来简介解决问题，这就不是程序员的问题了。因为这样虽然能解决问题，但代码很难看。

至于你说的Qt框架上用C++早就调试完，我没理解什么意思，因为我已经在用了，而且就是QString在转成STL string 的时候崩溃的。
[其他解释]
引用:
引用:
QString在转成STL string 的时候崩溃的。


你可以贴出可以重现这种问题的最简代码，单就Qt方面来说，这没什么神秘的


C/C++ code

inline std::string QString::toStdString() const
{ const QByteArray asc = toAscii(……


我有说过引用到外部lib，代码很简单，就是一楼发的那两句。错误不在于构造，构造是可以成功并且可以正常使用，我说的是析构，一楼贴出的代码中（}）这个地方崩溃，跟踪进去就是dbgheap.c中        _ASSERTE(_CrtIsValidHeapPointer(pUserData)); 这句的错误，这个就不是很简单了。。。

恩，你的题外很具有参考意义，我也有这么想。但只是引用lib会把编译选项一起引用进来么？而且我根本没有执行lib里面的任何语句，只是调用了头文件，就单单析构就不行了，还有个线索：我的string跟踪进去是xstring，而不是STL的string，而且不用#include<string>和using namespace std;就可以直接使用，并且我引用了这些东西以后跟踪进去还是xstring。这是后面虽然问题用toLocal8bit解决了，但是由于好奇测试出来的结果，留给大神们分析了~
------其他解决方案--------------------


qt3.0开始我就在用了。公司的项目从10年前就开始用QT了。我们的项目是solaris平台上的。美国的基金公司用的。整个项目非常大，还有，QtService应该是商业solution吧？我写过几个。反正公司都是买的商业版本的。很多solution。Qt的技术文档非常丰富，虽然没法跟MSDN比但是也很足够了。有些问题出来找不着北的时候还是到论坛上找吧。 所以，我觉得作为一个c++ lib,Qt已经很不错了
[其他解释]

引用:
引用:

没有完美的技术，都有瑕疵和败笔。
总钻研成熟的技术，人家都优化到基本上逼近完美的技术，那又有什么意思？能有什么突破？
你所提到的这方面的确是qt的劣势，但是qt的跨平台最显著的优势因为你没有用到体会到而被忽视了。再说，在qt框架下也可以调用你所说的“早就可以调试完的c++程序”。
技术到底成熟不成熟，还得看程序员发挥的成熟不成熟。
……


顶
[其他解释]
具体来说，QString中每一个字符都是一个16位的QChar，而不是一个8位的char
[其他解释]
引用:
引用:
没有完美的技术，都有瑕疵和败笔。
总钻研成熟的技术，人家都优化到基本上逼近完美的技术，那又有什么意思？能有什么突破？
你所提到的这方面的确是qt的劣势，但是qt的跨平台最显著的优势因为你没有用到体会到而被忽视了。再说，在qt框架下也可以调用你所说的“早就可以调试完的c++程序”。
技术到底成熟不成熟，还得看程序员发挥的成熟不成熟。

……


大家平时做的项目，通常问题总是发生在2个不同领域2个层面的连接不是么？
QString支持16位Unicode值，而且使用隐含共享来最优化内存和速度，保证不想被修改的数据绝不会被复制。这也就是为什么要toLocal8bit。QString不是string，Qt封装QString绝不是白忙活的。
[其他解释]
引用:
恩，toLocal8bit的存在很明显是合理的，但返回值不是string。但问题是，为什么不根据字符编码封装进toStdString？对于大家的直观理解来说，toStdString才是真正要实现QString转化为string的方法。而toLocal8bit的返回值是QByteArray，还是需要转化(自动的也算)才能变成string，这只能说是弥补这一问题的方法，而不能说是Qt库层面上的解决。

还有，崩溃是出在析构上，注意，是析构。用toStdString转换数据也是可以使用的，就是析构的时候崩溃。

13楼的题外说法很有这种可能性存在，但是我觉得QString应该负责这类错误的判别，能转就转，不能就报错或者提示，而不是不能转还充胖子，编译连接很流畅零警告然后给你来个崩溃。

比较大型的项目里面找这个BUG真的很痛苦。


现在的问题是，根据你提供的信息，似乎根本就无法认定这是Qt的bug ^_^

你不妨提供一下简化后能重现这个问题的代码。

另外：
toAscii  和 toLocal8Bit本身没什么区别
所用编码分别由
voidsetCodecForCStrings ( QTextCodec * codec )
voidsetCodecForLocale ( QTextCodec * c )
指定。
[其他解释]
引用:
引用:

引用:
没有完美的技术，都有瑕疵和败笔。
总钻研成熟的技术，人家都优化到基本上逼近完美的技术，那又有什么意思？能有什么突破？
你所提到的这方面的确是qt的劣势，但是qt的跨平台最显著的优势因为你没有用到体会到而被忽视了。再说，在qt框架下也可以调用你所说的“早就可以调试完的c++程序”。
……


恩，toLocal8bit的存在很明显是合理的，但返回值不是string。但问题是，为什么不根据字符编码封装进toStdString？对于大家的直观理解来说，toStdString才是真正要实现QString转化为string的方法。而toLocal8bit的返回值是QByteArray，还是需要转化(自动的也算)才能变成string，这只能说是弥补这一问题的方法，而不能说是Qt库层面上的解决。

还有，崩溃是出在析构上，注意，是析构。用toStdString转换数据也是可以使用的，就是析构的时候崩溃。

13楼的题外说法很有这种可能性存在，但是我觉得QString应该负责这类错误的判别，能转就转，不能就报错或者提示，而不是不能转还充胖子，编译连接很流畅零警告然后给你来个崩溃。

比较大型的项目里面找这个BUG真的很痛苦。
[其他解释]
恩我也同意13L的观点，你说QString应该负责这类错误的判别，能转就转，不能就报错或者提示，我也希望这样，可能qt把重点都放在国际化上了，就忽略这点的完善。
不过确定下到底是不是qt的bug，这是我目前最关心的哇
[其他解释]
针对你提到的：对于大家的直观理解来说，toStdString才是真正要实现QString转化为string的方法

这点我表示认同。上午刚看了jQuery之父John Resig的访谈，被问到如果能重新再来一次，你会在哪方面做出设计改变？的时候
他的回答是：我要改一些方法的名称。初期在命名上出现了一些失误，后来我花了很多时间在这上面。如果一开始就做好，可能会少走很多弯路。


[其他解释]
大神们，问题我重现了~ 


#include <QtCore/QCoreApplication>
#include <string>

using namespace std;

int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);

QString qstr = "http://www.baidu.com"; 
 
{
string str = qstr.toStdString();
}

return a.exec();
}


这是代码，在项目属性的Code Generation中的Runtime Library 改成 Multi-threaded Debug (/MTd)即可。看来有望得到解答了~期望得到详细解答，如果这个问题很弱智，别喷哈~
[其他解释]
C、C++的比较要命的就是没有unicode字符串的概念。而char* 和 std::string 这些窄字符串 如果直接叫做 字节流 估计会少很多问题。

C95 以后，引入的宽字符类型 wchar_t ，但是

"The width of wchar_t is compiler-specific and can be as small as 8 bits. Consequently, programs that need to be portable across any C or C++ compilershould not   use wchar_t for storing Unicode text. The wchar_t type is  intended for storing compiler-defined wide characters, which may be Unicode characters in some compilers."

到了 C++0x 和 C1x，才开始引入 char16_t 和 char32_t 两种类型。即便如此，仍没能解决源代码的编码标准化问题。
[其他解释]
引用:
大神们，问题我重现了~ 
C/C++ code


#include <QtCore/QCoreApplication>
#include <string>

using namespace std;

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    QString qstr = "htt……

如果你的Qt的调试库编译时用的 /MDd 选项，你可应该先用 /MTd 编译你的Qt库！


这种问题重现很容易：不用动用IDE，一条命令即可编译出 main.exe
 cl main.cpp -ID:/Qt/4.7.0/include -MTd -Femain  -link -LIBPATH:D:/Qt/4.7.0/lib QtCored4.lib

 cl main.cpp -ID:/Qt/4.7.0/include -MDd -Femain  -link -LIBPATH:D:/Qt/4.7.0/lib QtCored4.lib
[其他解释]
再补充一点，如果去掉QString里面的 http:// 则可以正常转换并析构，这种问题你们觉得又多隐晦。。。我批量的URL多线程进去处理，处理完的删除，有些没http://，有些有，崩溃的位置都不尽相同，菊花那个紧…
[其他解释]
引用:
引用:

大神们，问题我重现了~
C/C++ code


#include <QtCore/QCoreApplication>
#include <string>

using namespace std;

int main(int argc, char *argv[])
{
QCoreApplication a(arg……


问题是我有引入外部lib哪，我怎么知道问题会不会出在lib上面。而lib肯定不可能上传上来的，lib的规模很大，我只能一步一步试，引入的lib和调用的函数一个一个删。

试出来了是MTD这方面的问题，重现当然很简单了。。。用不用编译器都一样的
[其他解释]
引用:
MSDN：

Caution: Do not mix static and dynamic versions of the run-time libraries. Having more than one copy of the run-time libraries in a process can cause problems, because static data in one copy……

括号里面的我能理解，就是我之前由于Debug状态下QtSQL用的是Release版本，导致QVariant析构崩溃。
但是前面的东西，重现的时候我没有用dll哪，用MDd反而应该出问题才对
[其他解释]
QtCored4 这种后边是d4的一般是debug编译
[其他解释]
引用:

引用:
MSDN：

Caution: Do not mix static and dynamic versions of the run-time libraries. Having more than one copy of the run-time libraries in a process can cause problems, becaus……


哦，明白了，意思是说我得用MTd编译个QtCored4的动态库？这麻烦得。。我去试试看
[其他解释]
每天回帖即可获得10分可用分！
[其他解释]
。。。。。。不懂的飞过
[其他解释]
个人认为Qt要比MFC优秀吧。
Qt的moc扩展也是一大特色啊。
[其他解释]
QtCored4也不用自己去编译啊，直接到网上就有的下啊。
[其他解释]
初学，觉得QT 的 IDE很顺手
[其他解释]
楼主，问题解决了吗？等着看呢， 给大家总结一下。
[其他解释]
我也飞过！
[其他解释]
使用G++，没有了现在此类问题。这个问题不应该归类到QT上。
[其他解释]
QT这种需要二次编译的东西，我一向是不想看的～
[其他解释]
在Win平台，用mingw没有这个问题
[其他解释]
听听,学习!
[其他解释]
引用:
楼主，问题解决了吗？等着看呢， 给大家总结一下。

解决了，就是这段话
MSDN：

Caution: Do not mix static and dynamic versions of the run-time libraries. Having more than one copy of the run-time libraries in a process can cause problems, because static data in one copy is not shared with the other copy. The linker prevents you from linking with both static and dynamic versions within one .exe file, but you can still end up with two (or more) copies of the run-time libraries. For example, a dynamic-link library linked with the static (non-DLL) versions of the run-time libraries can cause problems when used with an .exe file that was linked with the dynamic (DLL) version of the run-time libraries. (You should also avoid mixing the debug and non-debug versions of the libraries in one process.) 

简单说就两句话：MTd编译的库不要和MDd编译的库混用，Debug库不要和Release库混用，在做项目的时候遇到莫名其妙的明明很正常的语句里面出现崩溃，跟踪调试发现是在“}”的地方崩溃的，并且崩溃弹出了qdbheap.h的错误位置，那就要考虑下这两个问题了。

我之前遇到的问题：
Debug模式的服务引入了两个lib：Qtsql4.lib和Qtsql4d.lib，结果是以先引入的Qtsql4.lib为准的，出现QVariant析构错误（比如QString qstr = QVariant.value(0).toString()）。

MTd模式使用默认的QtCore（默认为MDd编译），发生QString的toStdString()函数析构错误（比如std::string = QString("Hello BUG!").toStdString()）。

网上没有搜到相关的问题，比较隐晦，Qt没有提示编译链接问题，而是直接崩溃，这也是我说想学者慎入的原因。
[其他解释]
toStdString就讨论了半天，，还让人活不。。
------其他解决方案--------------------


呵呵，一直用Qt，觉得挺好。
[其他解释]
Qt还真的很好用，要是MS原生支持就好了。。。
[其他解释]

引用:
在Win平台，用mingw没有这个问题

不至于没有，而是你没发现，你没有用到MTd，库都对不上怎么可能会不出这个问题？
[其他解释]
好像还行吧
[其他解释]
引用:
大神们，问题我重现了~ 

C/C++ code


#include <QtCore/QCoreApplication>
#include <string>

using namespace std;

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    QString……

你不是已经自己找到问题了吗?你的qt库没有按照Multi-threaded Debug (/MTd)方式编译呗
[其他解释]
说到底，就是一个不会用的人发现用不了，就说人家不好用。
[其他解释]
呵呵，没用过QT的飘过～
[其他解释]
引用:
说到底，就是一个不会用的人发现用不了，就说人家不好用。


说的很对，支持你，像楼主这么用法用什么库都不稳定
[其他解释]
引用:
说到底，就是一个不会用的人发现用不了，就说人家不好用。

没错，就是这个样子，任何语言或者任何工具都是朝着易用、表述准确性、性能出发来改进，你会说机器语言好用么？
[其他解释]
引用:
引用:
大神们，问题我重现了~

C/C++ code


#include <QtCore/QCoreApplication>
#include <string>

using namespace std;

int main(int argc, char *argv[])
{
QCoreApplication a(ar……

看帖要全，我都已经结贴并且总结了。
[其他解释]
菜鸟飘过，跟40楼想法一样……
[其他解释]
QT其实不错
[其他解释]
人都是难免犯错的，工具应该尽量多的检查才是；
尤其是这种现象跟原因毫无关系的错误……

[其他解释]
只是初学者慎入 ???

这句说的， 初学者慎入，  让Qt高手来入门？
[其他解释]
Linux的哲学与UNIX是一脉相通的，即简单管用，一个程序不必做的很大，但一定要干好自己份内的事，这样当很多这样的优秀程序结合起来时，庞大的任务将轻而易举的完成。

MFC等一些图形界面开发工具不过是和用户打交道，搞得像MFC那么复杂实在是得不偿失，真正的好程序，生命力长久的程序都是命令行下的，全部使用易于迁移的C/C++开发，写成后视效果发布响应的图形界面外壳，说白了，就是没有图形外壳那个程序也可以运行，有只不过为了方便用户。

不仅QT，MFC一类的所有东西尝试封装很多的东西，就同程度的失去程序的灵活性。

所以像QT，MFC这类东西，学习高封装的东西是很不划算的，不如系统调用，exec来的实在。
[其他解释]
危言耸听，我觉得挺好的，用了一年qt的说话。
Qt Service我也用过，Qt solution里面的所有模块几乎我都用过。

呵呵，挺好的，最好的是开源，可以调试源码，不行就报Bug，而且一些是断言造成的，很多都是用户自己的代码造成的

引用:
用开源的 Qt Service 写个服务，错误频出
之前由于引入的为Release版本而QtSQL用的是Debug版本，导致QVariant析构崩溃。
现在是这么一段代码
C/C++ code

QString tempurl = "http://172.16.1.149";
{
    string strUrl = tempurl.toStdString();
}



又是析构时崩溃……


[其他解释]
QT 还是很好用的，如果有问题，先请看help，如果还有问题，去qt mail lists请教。在这里发牢骚解决不了问题的。如果你是个有经验的程序员，这个问题可能浪费了这么多时间，就应该选着另一个方法。
[其他解释]
引用:
1、首先，上面已经给出了具体使用Qt转换为std::string方法，直接转换，你的并不是标准的char*类型字符串，出错，也是应该的问题。
2、Qt中那么就尽量使用Qt的字符串，没有什么必要使用Qt外的字符串，如果为了和其他系统打交道，那么参考第一条就可以了。

。。。求问你指的上面是哪里？肿么判定我是不是标准的char *字符串？
[其他解释]
1、首先，上面已经给出了具体使用Qt转换为std::string方法，直接转换，你的并不是标准的char*类型字符串，出错，也是应该的问题。
2、Qt中那么就尽量使用Qt的字符串，没有什么必要使用Qt外的字符串，如果为了和其他系统打交道，那么参考第一条就可以了。



[其他解释]
来来来，再给大家个Qt菊花紧的例子：
数据库里面有这么个函数，写法应该没错吧。

void DBfun()
{
    QMutexLocker LOCK(&m_mutex);  //将此句注释掉，若数据库连接不上，直接跳过if
                                       //但是如果没有注释掉，程序崩溃，提示莫名其妙的无限等待信息
    if(m_db.open())
    {
         //do Something
         m_db.close();
    }
}


ASSERT failure in QMutex::lock: "Internal error, infinite wait has timed out.", file thread\qmutex.cpp, line 169

大家自己试试看。

[其他解释]
引用:
来来来，再给大家个Qt菊花紧的例子：
数据库里面有这么个函数，写法应该没错吧。
C/C++ code?12345678910void DBfun(){    QMutexLocker LOCK(&amp;m_mutex);  //将此句注释掉，若数据库连接不上，直接跳过if                                       //但是如果没有注……


lz浪费了我近半个小时来读贴，所以我觉得我有必要回复一下。
首先LZ的错误是DLL的版本和EXE的版本不统一，根本原因是用的不同的系统运行时库。这个问题在MFC中也同样存在，LINK的时候没有加验证可以说是微软的一个疏忽，但这不能算是BUG，只有你稍加了解使用正确就不会有这个问题。

你70L那个问题显而易见是你的使用问题，多线程访问资源加锁是必须的，你所描述的无限等待的现象也不过是非常常见的死锁错误，使用任何库都不可能凭空解决死锁。

LZ给人感觉非常傲慢非常自负，这贴里大部分人都比LZ水平高，回复你不是别人的义务，回复你是想帮助你而不是为了网络上的一点点积分。自以为是的态度很让人讨厌。
[其他解释]
null
[其他解释]
这是很多人的心理，一出问题，从来没考虑是自己代码的问题，只怀疑别人的东西，“极度”这两个词用的真是好啊
[其他解释]
引用:
这是很多人的心理，一出问题，从来没考虑是自己代码的问题，只怀疑别人的东西，“极度”这两个词用的真是好啊

第一，这个问题我是已经解决了然后才发这个帖子来探究下深层的原因。
第二，没有考虑自己代码的问题？这个贴子的主题是Qt应该加强自身的出错提示系统，不是什么东西都来个崩溃。并提醒初学者在学好C++有一定编程经验了再来学Qt。
请不要用“很多人的心理”来让自己特立独行，能做到提示的地方就应该提示，这是对一门语言的Debug系统很基本的要求了。换用库的问题Debug系统发现不了么？发现自己有东西不能正常析构不应该报错么？楼上要是觉得这样很合理的话，请不要用调试环境，直接文本编写代码，崩溃了直接从自己的代码去一行一行找原因。

[其他解释]
引用:
网上没有搜到相关的问题，比较隐晦，Qt没有提示编译链接问题，而是直接崩溃，这也是我说想学者慎入的原因。


这。。。编译链接问题是qt能管的吗～～～
这是cl的问题吧。。。。。
------其他解决方案--------------------


准备入门的飘过，我是学嵌入式的，不知学qt有用吗，qt的应用方向

读书人精选
热点排行