[Qt-interest] Qt library in (non)Qt application

[Tumarov Alexander]

Thank you.

Marco Borm wrote:

> Tumarov Alexander wrote:
>> Marco Borm wrote:
>>
>>
>>   
>>> Also under Windows there is no real problem sharing objects between app
>>> and dlls if you do it the right way:
>>> 1. Components sharing objects on the head must use the same heap-manager
>>> Typically this means using the same crt in all components and use them
>>> as a dll/so.
>>> 2. If you share objects using a base class / interface pointer don't
>>> miss the virtual deconstructor if the receiver should delete the object.
>>>     
>> Hm... this is the point - I am not sure if the same CRT will solve this
>> issue. Can you drop a link that can shed a light on this topic more
>> deeply? I remember that I have some hard time of exporting stl objects
>> out from dlls... virtual destructor did not solved that. May be the issue
>> was a different CRTs... but anyway - I wanna be sure on this topic. At
>> this point it bother me more then existance of QApplication since that
>> can be defined as requirement (on this later).
>>   
>>> I think the bigger problem here is that you don't know if the app will
>>> construct a QApplication or not.
>>>     
>>
>> This is a second issue. Can QApplication be instantiated inside library?
>> Will dll's objects work correctly with QApplication installed in
>> application itself (like queued connections or event's handling)?
>>
>>
>> Thank you in advance.
>>
>> p.s.: To be honest - the issues with right memory handling bothers me a
>> lot. The possibility of existance of several heap managers can become a
>> real headache if new/delete used across library boundaries (and if
>> "recommended"
>> way is used  - what created in library should be deleted in library
>> itself). Virtual destructors will not solve this since the final
>> memory "free" will operate on heap manager that used in the execution
>> unit of "delete" call (app/dll).
> You're right and thats why I don't wrote "1." OR "2.". The virtual
> destructor hint wasn't more than a hint. Its a typical c++ pitfall, but
> of course there are more.
> 
>> I beleive that what you say is that the
>> difference in the way I link CRT. If it is going to be static linkage - I
>> will have the problem. If dynamic on both the app and dll - all of them
>> will get the only one CRT with only 1 heap manager and then there will be
>> no problem. Am I right or wrong?
>>   
> You're right.
> You have simply take sure that you always use the same heap manager
> instance for a new/delete-pair.
> If you use different crt-dlls in your application, you get multiple
> instances. If parts are linked statically to a crt, they also get there
> personal heap manager instance.
> 
>> BTW - good question  - is there any issues like this on linux/mac os?
>> Additional issues may arize if QT uses static variables inside their
>> libraries (if something inlined  - application and dll can get different
>> copies of the same variable).
>>
>>
>>
>> _______________________________________________
>> Qt-interest mailing list
>> Qt-interest at trolltech.com
>> http://lists.trolltech.com/mailman/listinfo/qt-interest
>>
>>