всем доброй ночи.
имеем код:

http://liveworkspace.org/code/91ac74abc456...f69fb9175b3b526

с кодом все хорошо. он даже работает.
НО! - если строку 59 изменить следующим образом: connect(im.s2, this, &type1::m1);
то код так же скомпилится, хотя сигнатуры сигнала и метода разные.

почему такое происходит? и от чего?

спасибо.

Это сообщение отредактировал(а) boostcoder - 3.3.2011, 02:58

sorry, но где у Вас завязка сигнатуры метода на сигнатуру сигнала ?!
а если они не связаны, то почему бы не компилиться ?


редко когда в таких случаях задаются вопросы 


сделать структуру конвертер, меняющую тип сигнала, на тип   метода.. 
поможет boost.function_types..



Это сообщение отредактировал(а) mes - 3.3.2011, 09:44

вот же:
void(Obj::*method)(Args...)

т.е. method - указатель на мною указываемый метод класса.
тут даже две проверки:
1. при использовании boost::bind(), он же и проверяется соответствие равенства кол-ва аргументов кол-ву плейсхолдеров.
2. результат bind`а используется для connect(), который в свою очередь тоже проверяет соответствие сигнатуры функционального объекта.

или что?

Добавлено через 1 минуту и 34 секунды

мне не нужно менять тип сигнала. и нельзя.

первая проверка не при чем..  Вы лишь по кол-ву аргументов выбираете подходящий бинд.. 
а вторая да.. я не заметил, что Вы в apply делаете signal.connect.. сорри, что ввел в заблуждение.. 
интуитивно ориентировался на предыдущий  код из соседних тем и не приглядывался к текущему.. 
сейчас гляну дальше.. 

но даже она проходит!

хм.действительно у boost.signal есть проблема (или это фича?) с сигнатурами слотов..
интегральные или плавающие типы аргументов  аргументы сигнала могут быть пропущены у слота ..
т.е. такое верно :

 


в документации ничего не нашел на этот счет.. 


Это сообщение отредактировал(а) mes - 6.3.2011, 15:34

неудивительно, ибо сами сигналы оказывается не при чем.. 
вот так тоже работает :

уменяистерика 

Добавлено через 36 секунд
никогда не замечал подобной проблемы с байндами

я тоже "восхищен"   


аналогично.. и главное что документация по bind`у, тоже упорно скрывает сей факт.. 


Это сообщение отредактировал(а) mes - 6.3.2011, 00:15

может столь странное поведение происходит только на gcc ?
у Вас нет под рукой MSVC ?

нету :(

Добавлено через 2 минуты и 49 секунд
но в gcc не только у boost::bind, но и у std::bind..

Это сообщение отредактировал(а) mes - 6.3.2011, 00:29

вряд ли... не логично.

посмотрел код.. все таки фича.. точнее "дырка" в концепции.. хотя сам бинд получается не при чем..

при конструировании бинда создается список привязанных аргументов и плейсхолдеров потом на него "накладывается" список аргументов вызова, при этом из последнего выбираются элементы соответсвующие плейсхолдрам первого.. в связи с тем, что плейсхолдер может указывать на любой элемент второго списка, у bind`a нет права его ограничивать..а проверка, чтоб кол-во элементов не превышала "индекс " наибольшего плейсхолдера просто излишняя.. 

т.е. фактически нужно для такой возможности :


Добавлено через 5 минут и 31 секунду

Цитата(mes @  6.3.2011,  00:17 )

посмотрел код..

но буст все таки ужасен.. на ночь изучать его исходники, все равно что ммм.. смотреть триллер перед сном       


Это сообщение отредактировал(а) mes - 6.3.2011, 01:19

интересно...а много людей знают об этом? ;)

остановился на том, что это "вина"/"фича" bind`a :

http://liveworkspace.org/code/8f09320bfa47...afbcd97e8bcb9cc

и все ж непонятно, почему в документации этот "спорный" и не очевидный момент явно не указан..   
  

P.S.

видать на ночь неправильно эксперимент поставил,  так как в вышеприведенном примере подобного не наблюдается.. подправил пост..

Это сообщение отредактировал(а) mes - 6.3.2011, 15:37