[solved] QT with QT_NO_STL?

STiAT · 2005-01-03 15:56:01

Hello ARCH people.

I lately experienced a problem converting from std::string to QString compiling QT Applications. The following error i get:

error: conversion from `std::string' to non-scalar type `QString' requested

.

By searching google and reading a bit, i've found out that this problem seems to occur if QT_NO_STL is used as a compile option to QT.

Is there any specific reason why ARCH has set the option QT_NO_STL? Is it set, or am i wrong in this case?

I've never had this problem in any other distribution, so i'm asking you here for advice. Of course, i'd like if i dont have to recompile QT completely.

TIA,
STi

STiAT · 2005-01-03 23:23:03

Solved in the thread
http://bbs.archlinux.org/viewtopic.php?t=9005

vicious · 2005-01-04 08:50:22

No, It isn't solved.

It is a stupid idea to build qt with --no-stl and -no-g++-exceptions. Why? For efficiency? So that programs use bubblesort instead of introsort?

Seem the packager has NO idea about C++ and Qt. Qt should have another maintainer.

STiAT · 2005-01-04 10:50:27

I've no idea about QT, but i got my compile problem solved.

I actually dont know the reason why QT was built like this, but agree that it seems not to be "common".

Maybe just tell the QT maintainer about which advantages users / developers would gain of building it without this options, may you can convince him. It was Judd Vinet who maintained the lib, and i thought he knows what he is doing... but maybe it was really just maintained by Judd, since John Proctor contributed it (according to the CVS logs)

STi

phrakture · 2005-01-04 15:26:11

vicious wrote:

No, It isn't solved.
It is a stupid idea to build qt with --no-stl and -no-g++-exceptions. Why? For efficiency? So that programs use bubblesort instead of introsort?
Seem the packager has NO idea about C++ and Qt. Qt should have another maintainer.

You're missing the point.
a) C++ exceptions cause a very big performance hit... why throw an exception when you can just return an error code...
b) Removing the STL has nothing to do with sorting algorithms... the C library still has qsort and other functions... removing the STL when building Qt is most likely intended... I'd check the Qt docs for it.

When using a 3rd party library it is best to try and stay within the bounds of that library.... if using the MFC, use CString instead of std::string, if using Qt, use QString instead of other options.

You need to understand that the --no-stl compile option removes STL compatability from Qt, but you can still use the STL in your own code...

Making an immediate, uneducated call that "this package needs a new maintainer" is ignorant. Take a look at who maintains Qt

STiAT · 2005-01-04 17:29:57

phrakture wrote:

a) C++ exceptions cause a very big performance hit... why throw an exception when you can just return an error code...

In some codeparts exceptions are quite "nice to have", i.e. i use to throw exceptions when i'm using socket connections, for read and write errors.

Anyway, of course i have to agree that exceptions are a very big performance hit. But they're sometimes just convenient.

STi

vicious · 2005-01-04 19:26:30

Phrakture, you are wrong. What you say is not much more than a bunch of myths.

You're missing the point.

No, I'm not.

a) C++ exceptions cause a very big performance hit... why throw an exception when you can just return an error code...

No, this is not true. Don't speak about exceptions if you don't know what they are designed for. Some information for you:
Typically, errors occur very rarely. However, if you use error codes you pay the price each time you check them (one more "if"). But exceptions solve this problem - no need to check error codes. The compiler stores additional cross-reference information in the executable which allows for quickly passing control from the place where error occured to the place where the error is handled. You pay the price only when exception is thrown - you don't check errno every now and then.
C++ exceptions follow the "zero overhead" rule of C++ - you don't pay for them unless you throw them (besides the negligible overhead in the executable size, which is small in recent gccs).
You now what, removing exception support from Qt not only removes exception support from Qt, but also PREVENTS ANY USE OF EXCEPTIONS IN PROGRAMS LINKING TO QT. This is because the mentioned cross-reference information is not stored and it's not possible to call Qt's destructors when the exception occurs.
The exceptions in C++ have a PURPOSE, which you seem to forget.

b) Removing the STL has nothing to do with sorting algorithms... the C library still has qsort and other functions... removing the STL when building Qt is most likely intended... I'd check the Qt docs for it.

It has. Qt has something called QTL - a small library intended to replace STL when it is not available. However, QTL is to large extend useless - O(n^2) sorting, O(n) map and set.
Could you tell me WHAT IS THE REASON of removing stl support from Qt?
Is this:

When using a 3rd party library it is best to try and stay within the bounds of that library.... if using the MFC, use CString instead of std::string, if using Qt, use QString instead of other options.

This advice is the reason? Please, allow everybody to use what they want. Please, allow me to use STL with Qt in the same program, because I NEED this for my application. Sometimes you can't "stay within the bounds". Don't make artificial bounds in Arch.

You need to understand that the --no-stl compile option removes STL compatability from Qt, but you can still use the STL in your own code...

But how do I convert between QString?

(...)uneducated call

Really? Maybe somebody else here is uneducated?

Take a look at who maintains Qt

I don't care WHO, I care HOW.

Besides, I don't use Qt. I don't like it. The ONLY reason why I'm writting this is to help others. Take this into account.

phrakture · 2005-01-04 19:49:22

I'm not going to address most of the stuff above, because it is only an attempt to start a flame war....

vicious wrote:

But how do I convert between QString?

QString qt_string("this is a Qt string");
std::string stl_string("this is an stl string");

std::string stl_tmp1((const char*)qt_string);
std::string stl_tmp2(qt_string.latin1());

QString qt_tmp(stl_string.c_str());

vicious wrote:

Please, allow me to use STL with Qt in the same program, because I NEED this for my application

# man abs

vicious · 2005-01-04 22:50:57

Okay, phrakture. Of course I can afford to recompile Qt, KDE and all apps that depend on Qt just to enable exception support. But I won't do this, because I don't use qt.

But what about other users? Isn't it a waste of their time to force them to recompile?

As far as I can see, you didn't provide ANY reasonable argument for no-exceptions compiler option. KDE being 10% smaller is not a reasonable argument.

I'm just asking why Arch disables exceptions and stl in case of Qt? In every other case (besides some useless docs), Arch enables all software features. Why this time not?

phrakture · 2005-01-04 23:10:34

vicious wrote:

As far as I can see, you didn't provide ANY reasonable argument for no-exceptions compiler option. KDE being 10% smaller is not a reasonable argument.
I'm just asking why Arch disables exceptions and stl in case of Qt? In every other case (besides some useless docs), Arch enables all software features. Why this time not?

a) I chose not to provide an agrument for it, my original one speaks for itself... c++ exceptions are poor for performance. Enabling the exceptions doesn't mean it removes the use of throw and catch, it just means that Qt doesn't throw errors... you can still:

QString blah("some string");
throw std::exception(blah.latin1());

if you want to.... disabling the exception is only in the Qt library... it doesn't somehow block you from ever using an exception in your code.... meaning:

void someFuncInQtLibrary()
{
...
#ifdef USE_CPP_EXCEPTIONS
throw std::runtime_error("error X");
#else
errno=12345;
#endif
}

or something of the sort...

As for why Arch does it, it's just a judgement call - at some point someone decided "let's disable stl support for reason X"... that is why I used the term "uneducated" - because you are assuming that enabling stl is 100% good with no downsides.... I am not claiming to be educated in it either, it's just that I trust the judgement calls made on these packages seeing as they work with no real hiccups....
The same goes for exceptions.... personally I hate c++ exceptions.... yes it's easy to use a try/catch block... but it just seems lazy to me. It's personal preference.

On another note, you were not "Just asking why Arch disables exceptions and stl in case of Qt?"....

vicious wrote:

Seem the packager has NO idea about C++ and Qt. Qt should have another maintainer.

A much better course of action would have been "hey why is this done?" and await a response.... but the immediate calls for mutiny made me balk.

tyrade time
In my opinion, the key thing open source has going for it is this sort of "anyone can contribute" thing. It's the exact opposite of the way us american's are taught to believe... here it's compitition that drives someone to make a good product better, it is not done for the sake of doing it. OSS is very existensialist in a way.... now this is great, and I love the fact that someone like me could send a minor patch to linus, or kieth packard, or someone and have it accepted into code that millions of people use. A big problem errupts when "hey here's something you did wrong, I fixed it" turns to "everything you do is wrong, I'm forking your project"... that's the attitude I get from this thread.... not an email to the maintainer or anything, but a flat out cry for a replacement....

If you want something to strive, help it, don't beat it down... you water your plants when they begin wilt, you don't chuck them in the trash and buy a cactus....

vicious · 2005-01-04 23:48:23

phrakture wrote:

c++ exceptions are poor for performance.

No, you are wrong. How often do you throw exceptions? They are slower than error codes when they do occur, but faster when they don't occur (because you don't check for them with an "if"). So in average they are FASTER.

Enabling the exceptions doesn't mean it removes the use of throw and catch, it just means that Qt doesn't throw errors... you can still:
QString blah("some string");
throw std::exception(blah.latin1());
if you want to.... disabling the exception is only in the Qt library...

No, you are wrong. If you disable exceptions when compiling Qt, this means that you can't reliably throw an exception from a slot (a signal handler). If you do throw, then Qt's destructors won't be called when unwinding happens -> crash.
You will be able to use exceptions provided they don't go through Qt's code. This is restricting, actually. You can't say it's not an issue.

because you are assuming that enabling stl is 100% good with no downsides....

I can't see the downside. Enabling stl means anabling just a few additional functions in Qt, this is not bloat. Afterall, enabling stl doesn't cause any additional runtime dependency, because STL is contained in headers and you have to link to libc++ no matter what options you specify.

I am not claiming to be educated in it either, it's just that I trust the judgement calls made on these packages seeing as they work with no real hiccups....

I guess you don't develop in C++, so you should listen when somebody with greater knowledge on this subject tries to teach you something.

personally I hate c++ exceptions.... yes it's easy to use a try/catch block... but it just seems lazy to me. It's personal preference.

Have you read Herb Sutter's "Exceptional C++?" Writing good exception-enabled code is actually a lot of additional work. But it usually leads to better, much more reliable code.

On another note, you were not "Just asking why Arch disables exceptions and stl in case of Qt?"....
vicious wrote:
Seem the packager has NO idea about C++ and Qt. Qt should have another maintainer.
A much better course of action would have been "hey why is this done?" and await a response.... but the immediate calls for mutiny made me balk.

I agree here. I shouldn't talk this way. It's just the people who try to pretend they are more knowledgable than they really are who drive me crazy.

I understand it's your preference not to use exceptions. But it doesa lot of harm to disable exceptions when compiling libraries for people who want to use exceptions.

tyrade time
In my opinion, the key thing open source has going for it is this sort of "anyone can contribute" thing. It's the exact opposite of the way us american's are taught to believe... here it's compitition that drives someone to make a good product better, it is not done for the sake of doing it. OSS is very existensialist in a way.... now this is great, and I love the fact that someone like me could send a minor patch to linus, or kieth packard, or someone and have it accepted into code that millions of people use. A big problem errupts when "hey here's something you did wrong, I fixed it" turns to "everything you do is wrong, I'm forking your project"... that's the attitude I get from this thread.... not an email to the maintainer or anything, but a flat out cry for a replacement....
If you want something to strive, help it, don't beat it down... you water your plants when they begin wilt, you don't chuck them in the trash and buy a cactus....

I agree completely. But I'm sure I'm not the only one responsible for the attitude you get from this thread.

phrakture · 2005-01-05 00:18:38

vicious wrote:

I am not claiming to be educated in it either, it's just that I trust the judgement calls made on these packages seeing as they work with no real hiccups....
I guess you don't develop in C++, so you should listen when somebody with greater knowledge on this subject tries to teach you something.

I'm tired of childish banter... only an idiot makes claims such as "I am better than you" over the internet.... you have no clue who I am and know nothing about me except from the words I have written in this post....

go lookup the term ad hominem - you've lost this one, and nothing you can do will recover... sorry, I'm done with you

kakabaratruskia · 2005-01-05 05:21:34

According to dictionary.com:

vicious: Marked by an aggressive disposition; savage.

STiAT · 2005-01-05 07:06:50

vicious wrote:

No, you are wrong. How often do you throw exceptions? They are slower than error codes when they do occur, but faster when they don't occur (because you don't check for them with an "if"). So in average they are FASTER.

I doubt this is true. According to a lot of books i've looked up exceptions, they produce an enourmouse overhead, and in most cases they suggest not to use exceptions.

References:
Addison-Wesley / Effective C++
Bjarne Stroustrup / The C++ Programming Language (Special 3rd Edition)

No, you are wrong. If you disable exceptions when compiling Qt, this means that you can't reliably throw an exception from a slot (a signal handler).

Why you must throw an exception there? A well implemented internal error handling works fine there as well.

STi

dekernel · 2005-01-05 17:16:03

I think we need some clarification here about a few things.
First, exceptions are a good and powerful feature of C++ when used correctly. Please note the last word (correctly). For me, this feature is the most misunderstood feature as well as the most abused feature of the language. To make best use, you need to understand the whole "design" which will allow you to best place the catch{...} statement. There should not be a try{...} catch{....} in each and every method in every class. It is my experience that this is where the size overhead comes into play.

Now comes the execution time performance issue. As far as I remember (this comes from the time spent in "mixed mode" debug sessions!! :oops: ) this only comes into play when the exception is being processed only. This means after you leave the catch{...} is left and the stack is being unwound and objects being cleaned up.

I could be wrong since it has been some time since I really had to look in-depth. The fervor with is issue really comes down to the point: do you want your code to be the epitomy of size/speed versus having code that is easy to maintain/feature-add. If you are writing embedded code, the former is very important, but normal application code the latter is more important (just my opinion) because the speed of normal PC's is monsterous.

Just my $0.02.

dekernel · 2005-01-07 12:34:51

As a side note, if you build the qt package and remove " -no-stl" from the configure command, KDE's toolbars appear slightly different. They don't seem to "blend". Not sure what the technical term is but there is a difference at least on my machine.

phrakture · 2005-01-07 15:46:53

dekernel wrote:

As a side note, if you build the qt package and remove " -no-stl" from the configure command, KDE's toolbars appear slightly different. They don't seem to "blend". Not sure what the technical term is but there is a difference at least on my machine.

color difference? or spacing maybe? i'd take a look at it if it weren't for my random kernel panics 8)

dekernel · 2005-01-11 01:38:09

Sorry to hear about the ol' crashes. Nothing worse.

Arch Linux

#1 2005-01-03 15:56:01

[solved] QT with QT_NO_STL?

#2 2005-01-03 23:23:03

Re: [solved] QT with QT_NO_STL?

#3 2005-01-04 08:50:22

Re: [solved] QT with QT_NO_STL?

#4 2005-01-04 10:50:27

Re: [solved] QT with QT_NO_STL?

#5 2005-01-04 15:26:11

Re: [solved] QT with QT_NO_STL?

#6 2005-01-04 17:29:57

Re: [solved] QT with QT_NO_STL?

#7 2005-01-04 19:26:30

Re: [solved] QT with QT_NO_STL?

#8 2005-01-04 19:49:22

Re: [solved] QT with QT_NO_STL?

#9 2005-01-04 22:50:57

Re: [solved] QT with QT_NO_STL?

#10 2005-01-04 23:10:34

Re: [solved] QT with QT_NO_STL?

#11 2005-01-04 23:48:23

Re: [solved] QT with QT_NO_STL?

#12 2005-01-05 00:18:38

Re: [solved] QT with QT_NO_STL?

#13 2005-01-05 05:21:34

Re: [solved] QT with QT_NO_STL?

#14 2005-01-05 07:06:50

Re: [solved] QT with QT_NO_STL?

#15 2005-01-05 17:16:03

Re: [solved] QT with QT_NO_STL?

#16 2005-01-07 12:34:51

Re: [solved] QT with QT_NO_STL?

#17 2005-01-07 15:46:53

Re: [solved] QT with QT_NO_STL?

#18 2005-01-11 01:38:09

Re: [solved] QT with QT_NO_STL?

Board footer