RE: [sigc] default constructor needed for R in sigc::slot<R, A1, ...>
- From: "Ulrich Eckhardt" <Eckhardt satorlaser com>
- To: "libsigc" <libsigc-list gnome org>
- Subject: RE: [sigc] default constructor needed for R in sigc::slot<R, A1, ...>
- Date: Thu, 22 Dec 2005 15:08:50 +0100
Matthias Langer wrote:
> 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.
I'd take a look at Boost's (or TR1's) Function lib then, this is a 1:1
instead of 1:many calling library. Further, it has the (possible)
advantage that you don't need a lib to link with and is even an official
part of C++ in that it is in a TR.
> But what about prividing an additional constructor for passing a
> default return value for classes with no default constructor ?
You can turn that around: instead of returning the type that has no
default ctor, return a different type that allows assignment from the
real returntype. No need to change libsigC++ that way.
Hmmm, wasn't that what 'marshallers' were used for in libsigC++ 1? Isn't
there an equivalent in version 2?
> 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.
Isn't the use of ALL_UPPERCASE for enums just asking for trouble like
collisions with macros?
Uli
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]