Сигналы и массив

[serg_hd]

Вопрос ко всем знающим - можно ли сигналы "загнать" в массив, именно какой-либо qt-массив (или коллекцию и т.п.) не средствами с++ (ну можно и с++, я уже прикину аналог на java если возможно будет). Вобщем куда-нибудь, но чтобы потом из другого класса можно было указать слот на каждый из этих элементов-сигналов массива. Собсна закидывать в массив уже могу:

Код:

ArrayList signals = new ArrayList();
signals.add(0, new Signal1<Integer>()); 

Но emit() нужно вызвать без переменной посредника (т.е. не применяя например

Код:

Signal<Integer> x = signals.get(0); 
x.emit(111))

Проще говоря, мне нужно осуществить что-то наподобие signals.get(0).emit(111);

[spectre71]

Вопрос ко всем знающим - можно ли сигналы "загнать" в массив, именно какой-либо qt-массив (или коллекцию и т.п.) не средствами с++ (ну можно и с++, я уже прикину аналог на java если возможно будет). Вобщем куда-нибудь, но чтобы потом из другого класса можно было указать слот на каждый из этих элементов-сигналов массива. Собсна закидывать в массив уже могу:

Код:

ArrayList signals = new ArrayList();
signals.add(0, new Signal1<Integer>()); 

Но emit() нужно вызвать без переменной посредника (т.е. не применяя например

Код:

Signal<Integer> x = signals.get(0); 
x.emit(111))

Проще говоря, мне нужно осуществить что-то наподобие signals.get(0).emit(111);

Не вижу смысла в таком массиве.  Советую изменить архитектуру.
Опиши задачу, для чего тебе потребовался такой массив.

[lit-uriy]

почему-то мне это напомнило QSignalMaper

[serg_hd]

Есть основной поток и множество других. Каждый из "других" имеет свой сигнал, основной поток имеет слот, на который все сигналы второстепенных потоков будут ссылаться. Это первая часть. Другая состоит в том, что основной поток должен будет испускать сигналы так, чтобы только нужные потоки его получали.
С массивом это было бы просто - главный поток делал бы connect() только с теми сигналами, которые нужны (чтобы слоты не срабатывали по прогрессии, накопления). Ну и наоборот.

п.с. на самом деле немного упростил, у меня 3 уровня потоков: основной, второй (единственный) поток, который создаёт потоки 3го уровня, и собственно куча потоков 3го уровня которые будут слать сигналы через через 2й аж на 1й, но не в том суть.

[serg_hd]

почему-то мне это напомнило QSignalMaper

Много думал о вариантах и с ним тоже. Типа создам мапер в классе, который создаёт потоки 3го уровня, чтобы эти потоки в него пихать. Создам слот мапера, который будет принимать, например, номер созданного потока при каждом их испускании сигнала, а что потом делать с этим номером? С массивом сигналов было бы и проще и удобнее как-то.

[spectre71]

Есть основной поток и множество других. Каждый из "других" имеет свой сигнал, основной поток имеет слот, на который все сигналы второстепенных потоков будут ссылаться. Это первая часть.

Для этого можно использовать QSignalMaper - если требуется идентификация того кто послал сигнал.

Другая состоит в том, что основной поток должен будет испускать сигналы так, чтобы только нужные потоки его получали.
С массивом это было бы просто - главный поток делал бы connect() только с теми сигналами, которые нужны (чтобы слоты не срабатывали по прогрессии, накопления). Ну и наоборот.

Опиши чуть подробнее, есть предположение что ты имеешь ввиду, но не совсем уверен.

[Igors]

Сигналы между нитками все равно сводятся к postEvent - так почему бы, не мудрствуя лукаво, его и не задействовать? Получатели известны, все что надо передать - поместить в потомок QEvent и.т.д

[serg_hd]

Опиши чуть подробнее, есть предположение что ты имеешь ввиду, но не совсем уверен.

Не знаю как бы ещё по-подробнее...Просто не хочу приводить ява-код, только лишний раз вводить в заблуждение.
Жму на форме "старт", запускается поток, который клепает множество других (в цикле), которые испускают сигналы. Зачем это дело кинул в отдельный поток? - чтобы легко было управлять, ставить паузы, запускать заново с обнулением счётчика, не тормозила форма при этом цикле и т.п.
Главный поток (который отвечает за gui) принимает сигналы и создаёт gui-объекты, после создания каждого объекта шлёт такой сигнал, чтобы именно нужный поток 3го уровня его подхватил. Затем поток 3 уровня может послать на главный поток другой сигнал (если надо), главный поток ему (и только ему) ответит результатом.

[lit-uriy]

>>Другая состоит в том, что основной поток должен будет испускать сигналы так,
>>чтобы только нужные потоки его получали.
Ты не говорил, что у основного потока есть сигналы, говорил, что один слот. И не говорил, что у потоков есть слоты.
Но даже если это так, то не вижу никакой причины просто сединить их в основном птоке

[lit-uriy]

Жму на форме "старт", запускается поток, который клепает множество других (в цикле), которые испускают сигналы.

в цикле же и делаешь соединение

Главный поток (который отвечает за gui) принимает сигналы и создаёт gui-объекты, после создания каждого объекта шлёт такой сигнал, чтобы именно нужный поток 3го уровня его подхватил.

Объект отправитель (из потока) знаешь (через sender()) вызываешь его метод с помощью invokeMethod()

Затем поток 3 уровня может послать на главный поток другой сигнал (если надо), главный поток ему (и только ему) ответит результатом.

аналогично выше перечисленному

[serg_hd]

>>Другая состоит в том, что основной поток должен будет испускать сигналы так,
>>чтобы только нужные потоки его получали.
Ты не говорил, что у основного потока есть сигналы, говорил, что один слот. И не говорил, что у потоков есть слоты.
Но даже если это так, то не вижу никакой причины просто сединить их в основном птоке

Каждый раз, когда поток основной формы будет слать сигнал, то все ранее связанные с ним connect()'ы также сработают, прогрессия получится. Поэтому испускать нужно конкретный сигнал для конкретного потока...

[serg_hd]

Главный поток (который отвечает за gui) принимает сигналы и создаёт gui-объекты, после создания каждого объекта шлёт такой сигнал, чтобы именно нужный поток 3го уровня его подхватил.

Объект отправитель (из потока) знаешь (через sender()) вызываешь его метод с помощью invokeMethod()

Затем поток 3 уровня может послать на главный поток другой сигнал (если надо), главный поток ему (и только ему) ответит результатом.

аналогично выше перечисленному

этого я не знал, спасибо, попробую

[lit-uriy]

Каждый раз, когда поток основной формы будет слать сигнал, то все ранее связанные с ним connect()'ы также сработают, прогрессия получится. Поэтому испускать нужно конкретный сигнал для конкретного потока...

про это я не понял, расскажи как ты представляешь соединение (напримере не массы потоков а одного дополнительного)

[serg_hd]

Каждый раз, когда поток основной формы будет слать сигнал, то все ранее связанные с ним connect()'ы также сработают, прогрессия получится. Поэтому испускать нужно конкретный сигнал для конкретного потока...

про это я не понял, расскажи как ты представляешь соединение (напримере не массы потоков а одного дополнительного)

Я себе его пока (без массива сигналов) не представлю, иначе бы не запостил тему.
Если бы можно было сигналы пихать в массив, то:
при старте цикла в потоке, создающего потоки - создался поток (в который я передам i цикла и класс главного потока). Тут же, при этой же итерации присваиваю массиву mas сигнал (ну можно и в самом только что созданном потоке), делаю connect() главной формы с новоприсвоенным элементом mas. Делаю в созданном потоке коннект с главным потоком (для получения результата) и испускаю сигнал для создания главным потоком gui-объекта.

[serg_hd]

Каждый раз, когда поток основной формы будет слать сигнал, то все ранее связанные с ним connect()'ы также сработают, прогрессия получится. Поэтому испускать нужно конкретный сигнал для конкретного потока...

про это я не понял

Если я в главной форме объявлю единственный сигнал signal, а потом в каждом из потоков буду с ним соединять, то при каждом emit() этого главного потока, все предыдущие соединения будут также реагировать