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 ? 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. 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
