| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 5 | |
<<< text/html: EXCLUDED >>>
> Here are my 2.056 cents. [big snip of vituperative anti-MS rant] FWIW, I use Qt for the GUIs of my own personal projects. The rest of my code is straight up the middle ISO C++, deliberately avoiding things that make common compilers blow up. I don't even use Qt-isms in my core code - I stick to the standard library, plus libraries I have source for that are either easily portable with well-defined platform dependent code or that themselves only depend on the standard library. For my own stuff, I'll be supporting .NET. But then, I'll also be supporting a whole bunch of other platforms (non-.NET Win32, Linux/gcc, etc.). When MS obsolete .NET, I'll probably support what they replace it with, because it will help me continue to be able to pay my mortgage. Having been forced to use the MFC in order to earn a living for the last eight years or so, I probably hate it more even than you seem to, and that's from a standpoint of knowing it very well, not a political point, so I think that's probably about as damning as I could possibly be about a product. Back in the 16 bit MFC days, I hated it so much that I nearly gave up programming completely and took up another career. For me to actually praise a Microsoft product is not a common thing, yet I do believe that credit is due where credit is due. Qt for .NET please, ASAP. My other wish list item would be a future version of Qt that doesn't depend on the moc tool - it is possible to implement signals and slots without a preprocessor in C++ that are nevertheless fully type safe (in fact, type safe to the extent that the compiler will refuse to compile incorrect code, which is rather better than the signal failing to fire the slot and emitting a quiet complaint on the possibly nonexistent console). This does need template support in the compiler, however, although not terribly sophisticated template support (i.e. no partial specialisation necessary). The other stuff that gets added by MOC could feasibly be replaced by standards-compliant use of RTTI. This would certainly improve portability for Qt, especially when trying to use it within an IDE. The approach I have in mind is also faster than Qt's approach of using strings in a hash table to identify and match up signals and slots, since the compiler manages to resolve all of that at compile time rather than run time. Sarah
>My other wish list item would be a future version of Qt that doesn't depend >on the moc tool - it is possible to implement signals and slots without a >preprocessor in C++ that are nevertheless fully type safe (in fact, type >safe to the extent that the compiler will refuse to compile incorrect code, >which is rather better than the signal failing to fire the slot and emitting >a quiet complaint on the possibly nonexistent console). This does need >template support in the compiler, however, although not terribly >sophisticated template support (i.e. no partial specialisation necessary). >The other stuff that gets added by MOC could feasibly be replaced by >standards-compliant use of RTTI. This would certainly improve portability >for Qt, especially when trying to use it within an IDE. The approach I have >in mind is also faster than Qt's approach of using strings in a hash table >to identify and match up signals and slots, since the compiler manages to >resolve all of that at compile time rather than run time. I know this is getting a little of the subject, but this sounds strikingly familiar to an idea I presented months back. A couple of trolls were advocating it, but many flamed me. I didn't want any more flames so I just started agreeing with them. This is also on my wish list. If Trolltech would do this, I'd even help 'em write the templates. The primary concern with ditching moc is compilers that are old and have VERY bad template support. This may be a valid concern. However, maybe we could reach a happy medium. Perhaps we could have a choice whether or not to use moc. Use the Q_OBJECT macro if you want to use moc for all those who have not-so-good compilers. And for all of us with half-decent compilers, a template we can inherit from that would do the exact same thing. A novel idea, methinks. I know It's doable. Craig
> The primary concern with ditching moc is compilers that are old and have
> VERY bad template support. This may be a valid concern. However, maybe we
> could reach a happy medium. Perhaps we could have a choice
> whether or not to
> use moc. Use the Q_OBJECT macro if you want to use moc for all those who
> have not-so-good compilers. And for all of us with half-decent
> compilers, a
> template we can inherit from that would do the exact same thing. A novel
> idea, methinks. I know It's doable.
Indeed. I've done it, actually - I wrote exactly such a signal/slot library
a few months ago. I can't claim to be first however - the GTK library seems
to have something similar, as does Boost, but both I think are a little more
complex (and probably less portable), though maybe slightly more powerful
than my attempt. Mine seems to have the cleanest syntax, which was my main
goal really. I am planning to release the library on a free for use for any
purpose basis once I've finished cleaning a few things up.
Just as a quick run-down, if you want to add slots to a class, you multiply
inherit from has_slots like so:
#include "sigslot.h"
using namespace sigslot;
class MyTarget : public has_slots<>
{
public:
void go_bang()
{
cout << "Bang!" << endl;
}
void go_pop()
{
cout << "Pop!" << endl;
}
void print_info(string s, int a, int b)
{
cout << s << ", " << a << ", " << b << endl;
}
};
Signals are objects in their own right, so they can exist as members of
classes (as in Qt), as globals, or even on the stack in auto context, e.g:
class MySwitch
{
public:
signal0<> Clicked;
signal0<> Released;
signal3<string, int, int> Info;
void doit()
{
Clicked();
Released();
Info("MySwitch class", 1234, 432);
}
};
void test()
{
MySwitch s;
{
MyTarget t;
s.Clicked.connect(&t, &MyTarget::go_bang);
s.Released.connect(&t, &MyTarget::go_pop);
s.Info.connect(&t, &MyTarget::print_info);
s.doit(); // Slots get called
}
s.doit(); // Nothing happens (safely!)
}
The syntax is a little different to QT, but not really any more complex or
difficult to use.
You can of course wire up lots of slots to the same signal. Also, both the
has_slots<> support and the signal classes all have proper copy
constructors, so you can safely use these things even in classes that live
inside stl containers. As with Qt, if either the signal or the slot
object(s) go out of scope, everything disconnects safely and transparently.
The classes currently also support three multithreading modes: none at all
(i.e. assume no threads), one global mutex used by all signals and slots, or
one mutex per has_slots derived object, so you can trade off resources for
contention as you prefer. Since this is passed in as a policy argument, you
can write a single application that has a combination of approaches where
necessary - the multithreaded modes actually interoperate with each other.
The current version works fine with VC++. I do want to add Posix threads
support and make sure it works on Linux before I formally release it
however.
Sarah
On Thu 14. March 2002 22:19, you wrote:
> class MySwitch
> {
> public:
> signal0<> Clicked;
> signal0<> Released;
> signal3<string, int, int> Info;
Sorry, I couldn't hesistate to ask: I hope you don't have signal100 in your
library?
More seriously: is the number of signal's parameter limited? If yes, it's not
a good design really.
--
[ signature omitted ]
Am Freitag, 15. März 2002 07:55 schrieb Mariusz Lotko:
> On Thu 14. March 2002 22:19, you wrote:
> > class MySwitch
> > {
> > public:
> > signal0<> Clicked;
> > signal0<> Released;
> > signal3<string, int, int> Info;
>
> Sorry, I couldn't hesistate to ask: I hope you don't have signal100 in your
> library?
>
> More seriously: is the number of signal's parameter limited? If yes, it's
> not a good design really.
Hi,
you wanna have signals with 100 parameters? Put them in a struct/class and
you are down to one parameter. I think a function/method/signal/slot with
more than 5-8 parameters gets unreadable and is a proof of poor design.
greetings,
P.J.
--
[ signature omitted ]
On Fri 15. March 2002 09:10, you wrote:
> Am Freitag, 15. März 2002 07:55 schrieb Mariusz Lotko:
> > On Thu 14. March 2002 22:19, you wrote:
> > > class MySwitch
> > > {
> > > public:
> > > signal0<> Clicked;
> > > signal0<> Released;
> > > signal3<string, int, int> Info;
> >
> > Sorry, I couldn't hesistate to ask: I hope you don't have signal100 in
> > your library?
> >
> > More seriously: is the number of signal's parameter limited? If yes, it's
> > not a good design really.
>
> Hi,
>
> you wanna have signals with 100 parameters? Put them in a struct/class and
> you are down to one parameter. I think a function/method/signal/slot with
> more than 5-8 parameters gets unreadable and is a proof of poor design.
100 is not a point here. LIMIT is a point. Why not 9? Is it as much worse from
8? And why not 10?
My "idea" of having 100 parameters is as bad as any limitations to the number
of parameters.
--
[ signature omitted ]
> 100 is not a point here. LIMIT is a point. Why not 9? Is it as > much worse from > 8? And why not 10? > > My "idea" of having 100 parameters is as bad as any limitations > to the number > of parameters. I didn't add a limit because I thought limits were cool. There is a limit because there's no way to do what I did in ISO C++ without one. Sarah
Sorry for posting here, but I know that a few people on the list are
interested in this. I've placed my signal/slot library into the public
domain and made it accessible at Sourceforge. If you're interested, here's a
copy of the announcement I posted to Usenet.
Sarah Thompson
--------
SIGSLOT
The sigslot library is a portable, type-safe, thread-safe implementation of
the signal/slot paradigm written entirely as a C++ template library. No
preprocessor (a la Qt's 'moc' utility) is required.
The library can coexist with other C++ libraries, notably the Microsoft
Foundation Classes (MFC), adding Qt-like functionality to any suitably
instrumented classes.
COMPILERS
VC++ 6.0, VC++ 7.0, Intel C++ 5.01, gcc 2.9x
The library should work fine with any reasonably standards compliant C++
compiler that supports the STL and templates with optional template
parameters. Partial template specialisation is NOT required.
PLATFORMS
Win32, Posix Threads, ISO C++ (e.g. Win 95, 98, ME, 2000, XP, NT3.51, NT4.0,
Linux, OpenBSD, FreeBSD, etc.)
PROJECT WEB SITE
Documentation: http://sigslot.sourceforge.net/
Downloads, etc: http://sourceforge.net/projects/sigslot/
LICENSE
Sigslot is entirely public domain, i.e. free for use for any purpose by
anyone. No strings attached.
EXAMPLE
The sigslot library allows code like the following to be written in C++:
----
class Switch
{
public:
signal0<> Clicked;
};
class Light : public has_slots<>
{
public:
void ToggleState();
void TurnOn();
void TurnOff();
};
Switch sw1, sw2;
Light lp1, lp2;
sw1.Clicked.connect(&lp1, &Light::ToggleState);
sw2.Clicked.connect(&lp2, &Light::ToggleState);
sw1.Clicked();
----
AUTHOR
Sarah Thompson (sarah@telergy.com)
>Qt supports signal renaming, simply by wiring signals to signals and the >ability to drop parameters when wiring a signal to a slot. Can your >solution do this? >One of our bugbears is indeed the problem of the runtime aspects of >signals and slots and miswiring, and a compile-time error would be nice. >However, I think your solution is less flexible, but then I haven't had >time to study it extensively. WHATEVER about Qt moc being better. Personally, I despise dependency on a precompiler, unless of course the precompiler delivers some amazing capability that C++ can't elegantly provide (like multimethods or a runtime list of class members). However, with Qt moc this is not the case. We can get the same basic functionality with C++ templates. That said, I propose not to REPLACE Qt moc, but to COMPLEMENT it with an alternative, to give Qt users a choice between using moc or templates. Please no more flames about how moc is better than templates. Because I can come back with many good reasons why templates are better. Craig
> Sorry, I couldn't hesistate to ask: I hope you don't have > signal100 in your > library? I support up to 8 parameters at the moment. > More seriously: is the number of signal's parameter limited? If > yes, it's not > a good design really. Its a C++ limitation. You could support an infinite number of parameters, but the header file would then also be infinitely long. I know this is a possibly lame excuse, but it could also be argued that function calls with huge numbers of arguments are pretty evil in their own right - I know I prefer Qt's approach to creating QFont objects to the CFont::CreateFont member function in the MFC that seems to need half a million parameters, such that no matter how many times I use it I *still* need to get at the manual page. Sarah
Sarah Thompson wrote:
>>The primary concern with ditching moc is compilers that are old and have
>>VERY bad template support. This may be a valid concern. However, maybe we
>>could reach a happy medium. Perhaps we could have a choice
>>whether or not to
>>use moc. Use the Q_OBJECT macro if you want to use moc for all those who
>>have not-so-good compilers. And for all of us with half-decent
>>compilers, a
>>template we can inherit from that would do the exact same thing. A novel
>>idea, methinks. I know It's doable.
>>
>
> Indeed. I've done it, actually - I wrote exactly such a signal/slot library
> a few months ago. I can't claim to be first however - the GTK library seems
> to have something similar, as does Boost, but both I think are a little more
Not the GTK but the GTK-- (http://lazy.ton.tut.fi/gtk--/).
Originally part of the Gtk-- widget set, libsigc++
(http://libsigc.sourceforge.net/) is now a seperate library to provide
for more general use. It is the most complete library of its kind with
the ablity to connect an abstract callback to a class method, function,
or function object. It contains adaptor classes for connection of
dissimilar callbacks and has an ease of use unmatched by other C++
callback libraries. Libsigc++ is licensed under the GNU Library General
Public License, LGPL.
Features:
* Compile time typesafe callbacks (faster than run time checks)
* Typesaftey violations reports line number correctly with template
names (no tracing template failures into headers)
* No compiler extensions or meta compilers required
* Proper handling of dynamic objects and signals (deleted objects
will not cause seg faults)
* Extendable API at any level Slot, Connection, Object, and Signal
* Extensions do not require alteration of basic components to allow
use of extensions
* User definable marshallers
* Provides headers for up to 7 arguments and 2 callback data
* M4 Macros for building templates with various numbers of
arguements and callback data
* Easily build support for templates with number of arguments and
callback data not defined in library headers
* Now supports gcc 2.8.0, egcs all versions, gcc 2.95.x, HP aCC
A.01.22, Irix MipsPro 7.3, RISC OS with gcc 2.95, Borland C++ 5.0, and
Visual C++ 5.0.
> complex (and probably less portable), though maybe slightly more powerful
> than my attempt. Mine seems to have the cleanest syntax, which was my main
> goal really. I am planning to release the library on a free for use for any
> purpose basis once I've finished cleaning a few things up.
>
> Just as a quick run-down, if you want to add slots to a class, you multiply
> inherit from has_slots like so:
>
> #include "sigslot.h"
> using namespace sigslot;
>
> class MyTarget : public has_slots<>
> {
> public:
> void go_bang()
> {
> cout << "Bang!" << endl;
> }
>
> void go_pop()
> {
> cout << "Pop!" << endl;
> }
>
> void print_info(string s, int a, int b)
> {
> cout << s << ", " << a << ", " << b << endl;
> }
> };
>
> Signals are objects in their own right, so they can exist as members of
> classes (as in Qt), as globals, or even on the stack in auto context, e.g:
>
> class MySwitch
> {
> public:
> signal0<> Clicked;
> signal0<> Released;
> signal3<string, int, int> Info;
>
> void doit()
> {
> Clicked();
> Released();
> Info("MySwitch class", 1234, 432);
> }
> };
>
> void test()
> {
> MySwitch s;
>
> {
> MyTarget t;
>
> s.Clicked.connect(&t, &MyTarget::go_bang);
> s.Released.connect(&t, &MyTarget::go_pop);
> s.Info.connect(&t, &MyTarget::print_info);
>
> s.doit(); // Slots get called
> }
>
> s.doit(); // Nothing happens (safely!)
> }
>
> The syntax is a little different to QT, but not really any more complex or
> difficult to use.
>
> You can of course wire up lots of slots to the same signal. Also, both the
> has_slots<> support and the signal classes all have proper copy
> constructors, so you can safely use these things even in classes that live
> inside stl containers. As with Qt, if either the signal or the slot
> object(s) go out of scope, everything disconnects safely and transparently.
>
> The classes currently also support three multithreading modes: none at all
> (i.e. assume no threads), one global mutex used by all signals and slots, or
> one mutex per has_slots derived object, so you can trade off resources for
> contention as you prefer. Since this is passed in as a policy argument, you
> can write a single application that has a combination of approaches where
> necessary - the multithreaded modes actually interoperate with each other.
>
> The current version works fine with VC++. I do want to add Posix threads
> support and make sure it works on Linux before I formally release it
> however.
>
> Sarah
>
> --
> List archive and information: http://qt-interest.trolltech.com
>
>
>
--
[ signature omitted ]
> interface, so it could be sold into the VB and C# worlds too. With the best > will in the world, C++ on .NET is going to be very much a minority, niche > area, not the mainstream (maybe VB 80%, 25% C# and the rest C++ and other > languages, at a guess), so there would certainly be some commercial > advantage in looking at the option. > Visual Basic 80%? Is that right? I thought that compared to other, more general purpose, and cross platform, languages like C++, C and Java, Visual Basic was very much a minority environment. Nick
The editor you choose is entirely personal. I'll never voluntarily use either vi or emacs again - sure emacs was a great improvement on vi, but trying it again recently I can't believe how clunky it is actually. I think the Builder editor is absolutely horrible too. The VC editor was quick and easy to learn, things were where I expected them to be and it has good add-ins that enhance it, making it overall extremely capable. Ian ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **********************************************************************
> The editor you choose is entirely personal. I'll never voluntarily use either vi or emacs again - sure emacs was a great > improvement on vi, but trying it again recently I can't believe how clunky it is actually. I think the Builder editor is > absolutely horrible too. The VC editor was quick and easy to learn, things were where I expected them to be and it has > good add-ins that enhance it, making it overall extremely capable. > The first line pretty much sums it up. I *love* vi. It works the same everywhere (kinda like Qt). And I never have to take my hands off the keyboard to some "point-and-grunt" device every time I want to cut and paste or navigate around the doc. my 2c rickb