> On Thu, 2005-12-22 at 09:42 +0100, Murray Cumming wrote:
>> On Wed, 2005-12-21 at 20:40 +0100, Matthias Langer wrote:
>> > At least for libsigc++-2.0.15 the return type R in sigc::slot<R, ...>
>> > needs to be default constructible.
>>
>> This is probably so that a signal can return a value even when no slots
>> are connected. But your example uses a slot and no signals, so that
>> seems unnecessary. But I guess the same code must compile whether or not
>> the slot is
>>
>> sigc::slot<NoDefCtor> tSlot(ptr_func(func));
>> or
>> sigc::slot<NoDefCtor> tSlot;
>>
>> And then tSlot() must return something.
>>
> Of course you are right. The reason i stumbled about this was because i
> wanted to use libsigc++ for it's slots only as they seem to be very
> convenient functors to me. From this point of view it would perfectly
> make sense if operator() throws unless there are functions/methods
> attached. Sure enough this behavour has unwanted side effects when using
> libsigc++ in a more straight forward manner - as signaling library. But
> what about prividing an additional constructor for passing a default
> return value for classes with no default constructor ?
Sure. A patch would be welcome. However, I doubt that it's possible,
because the template would still contain code to create a default value in
case you haven't. And even if you don't use that part of the code, the
whole template must completely compile.
Templates have some disadvantages.
> To be more
> precise, what i'm thinking about is something like this:
>
> #include <iostream>
> using namespace std;
>
> template<class R> class ReturnDefault
> {
> public:
> ReturnDefault() {}
> ReturnDefault(R r) : _r(r) {}
>
> R returnStoredValue() { return _r; }
>
> private:
> R _r;
> };
>
> class NoDefCtor
> {
> public:
> NoDefCtor(int dummy) : _dummy(dummy) {}
>
> friend ostream& operator<<(ostream& os, const NoDefCtor& obj)
> {
> os << "NoDefCtor: dummy value is " << obj._dummy
> << endl;
> return os;
> }
>
> private:
> int _dummy;
> };
>
> int main()
> {
> ReturnDefault<int> rInt;
> ReturnDefault<NoDefCtor> rNoDefCtor(NoDefCtor(0));
> //ReturnDefault<NoDefCtor> rCompileError;
>
> cout << "rInt.returnStoredValue():" << endl;
> cout << "\t" << rInt.returnStoredValue() << endl;
>
> cout << "rNoDefCtor.returnStoredValue():" << endl;
> cout << "\t" << rNoDefCtor.returnStoredValue() << endl;
> }
>
> By the way: There is still an outstanding answer from my side regarding
> stock icons in win32.
This is the libsigc++ list. I'm sure that Cedric will investigate.
> I'll look after that as soon as there is at least
> one other reason for me to boot into windows. In my opinion the problem
> i'm talking about is a mingw bug, as i have experienced strange behavour
> with mingw-gcc-3.4 and enums. Not only one time i fixed my code for this
> compiler by switching from
> enum SomeEnum { OK, WARNING, ERROR };
> to
> enum SomeEnum { E_OK, E_WARNING, E_ERROR };
> while the same worked fine with gcc-3.4.
>
> Matthias
>
> _______________________________________________
> libsigc-list mailing list
> libsigc-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/libsigc-list
>
Murray Cumming
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com
_______________________________________________
libsigc-list mailing list
libsigc-list@gnome.org
http://mail.gnome.org/mailman/listinfo/libsigc-list
