Re: [boost] Slots and signals: Listening to a value
Jared McIntyre <jmcintyre <at> dfsoftware.com> writes:
I'd rather have the overloads. I was actually playing around with something similar recently, and that is how I was doing it. As for explicitly telling the user that they will be sending a message with the set call, I don't think set really tells you anymore as a user than = about how messaging is occurring. Further, as a setter of a value, I rarely care whether an event will be sent or not. I only care about that when I am also the receiver of the message, but at that point I should already know they are tied together, since I hooked into the slot.
Hmm, maybe you're right. I guess get and set should be removed and replaced then. Do you think this is general and useful enough to be included in boost slots and signals? Best Regards, Johan Torp
Johan Torp <johan.torp <at> gmail.com> writes:
Do you think this is general and useful enough to be included in boost slots and signals?
I can't really say whether it belongs in the slots and signals library, but it certainly has a great deal of utility. It would be particularly interesting if you could figure out a way to expose other operators if they were supported by the wrapped type. So if it is a number, you could do +=, etc. Jared
On 23/05/07, Jared McIntyre <jmcintyre@dfsoftware.com> wrote:
Johan Torp <johan.torp <at> gmail.com> writes:
Do you think this is general and useful enough to be included in boost slots and signals?
I can't really say whether it belongs in the slots and signals library, but it certainly has a great deal of utility. It would be particularly interesting if you could figure out a way to expose other operators if they were supported by the wrapped type. So if it is a number, you could do +=, etc.
If it's a template class, which I strongly suspect it is (and if it's the class mentioned above, it is) you can add them all as direct forwards which will fail to compile if and only if you try to use them without the base class supporting them. I'm not sure how you'd get this to work with C++0x concepts though.
Peter Bindels <dascandy <at> gmail.com> writes:
If it's a template class, which I strongly suspect it is (and if it's the class mentioned above, it is) you can add them all as direct forwards which will fail to compile if and only if you try to use them without the base class supporting them. I'm not sure how you'd get this to work with C++0x concepts though.
Until C++0x concepts are added, we can use boost::concept_check to get a better compilation error for this case. As a sidenote: I think it might be possible to not define the operator at all if we have a type which doesn't support += if we want to. It'd look something like this: struct null_base {}; struct operator_plus_equal_base { template<T> operator+=(....) }; template<class T> class observable_value : public some_mpl_expression<T>::type {}; where some_mpl_expression is a boost::mpl expression which results in either null_base or operator_plus_equal_base depending on whether += exists for a given type T or not. I suppose that this solution wouldn't add much value, it's just interesting :) Best Regards, Johan Torp
participants (3)
-
Jared McIntyre -
Johan Torp -
Peter Bindels