Здравствуйте, гость ( Вход | Регистрация )
Iron Bug | Дата 8.4.2014, 20:34 |
Тут правильнее речь вести об объекте (экземпляре класса). В каком потоке ты его создаёшь, в том он и будет жить. не совсем так. память в куче у потоков общая. а стек у каждого свой. как бы явно к локальным переменным потока доступа нет, но в линюксе если взять адрес, то пока переменная валидна, она будет доступна по этому адресу во всех других потоках (см документацию на GCC, статью о TLS). в венде чуть сложнее - там индексы областей TLS. но есть функция TlsSetValue и другие функции из этой же серии (также гуглить про TLS, если интересно). |
|
Litkevich Yuriy | Дата 8.4.2014, 18:27 |
Тут правильнее речь вести об объекте (экземпляре класса). В каком потоке ты его создаёшь, в том он и будет жить. | |
Iron Bug | Дата 7.4.2014, 8:32 |
во всех потоках. у потоков общая память. то есть, как обычный класс, определённый в программе. если в библиотеке есть статические переменные - они будут статическими и общими для всех потоков. |
|
MishaUA | Дата 6.4.2014, 23:30 |
Спасибо за ответы! Еще интересует, при загрузке библиотеки она будет работать в том же потоке программы, в котором она была загружена? |
|
Iron Bug | Дата 6.4.2014, 12:36 |
да, выше Юрий правильно заметил, что работа с классами есть самое обычное дело. экспортируется весь класс и проблем нет. более того, можно даже наследоваться от классов, объявленных в других библиотеках. я тут где-то про такой случай писала. единственная возможная проблема - это не будет работать с разными компиляторами. то есть, если основная программа скомпилена одним компилятором, а библиотеки - другим. а у мелкософта иногда даже разные версии компиляторов не совместимы. так что тут надо понимать, как это потом будет эксплуатироваться. если предполагается, что другие программисты будут собирать какие-то внешние модули, то получится ограничение на выбор компилятора. и ещё видимость классов у GCC и MSVC разная. но обычно это не представляет проблемы. |
|
Litkevich Yuriy | Дата 5.4.2014, 18:22 |
class MyLib : public QObject MishaUA, не вижу у тебя инициализации структуры w А вообще сделай функцию, которая будет создавать экземпляр (объект), а дальше работай с ним как обычно.
|
|
MishaUA | Дата 4.4.2014, 0:30 |
arial, Есть вероятность, что dll будут собираться иными компиляторами (использование виджетов будет не обязательным), поэтому я и предположил, что их выгодней использовать)))) | |
MishaUA | Дата 3.4.2014, 20:36 |
И еще, хочу в программе отображать виджет, созданный в библиотеке (библиотека должна им управлять, реагировать на сигналы и т.д.), программа только отображать. Сделал так: *.h библиотеки:
*.cpp библиотеки:
*.cpp программы:
Работает нормально, единственная проблема - если добавлять виджет не на таб, а к примеру, в компоновщик главного окна, то программа не реагирует на мышь (ни контролы виджета библиотеки, ни контролы, созданые в программе). Но предполагается, что в реальной программе будет именно создаваться новый таб. Чтобы не накосячить, хочу поинтересоваться, на сколько правильное мое решение? |
|
arial | Дата 3.4.2014, 19:33 |
А QtPlugin разве не удобнее использовать? | |
MishaUA | Дата 3.4.2014, 17:48 |
Добрый день! Настал час, когда пришлось писать динамические библиотеки. В проге через QLibrary подключается библиотека и далее используются ее функции. В коде самой dll содержится класс, методы которого нужно вызывать, но в отличии от статической библиотеки, в динамической методы вызывать нельзя, только функции, Я поступил следующим образом:
Является ли такой вариант правильным, или посоветуете что то получше? И еще интересует, как с библиотеки можно передать сигнал в программу? |
|
Просмотр темы полностью (откроется в новом окне) | |
Текстовая версия | Сейчас: 28.3.2024, 12:30 |