Qt-interest Archive, March 2002
AW: Alternatives to VC++ IDE?
Message 1 in thread
I have tested CodeWarrior 6.0 for Linux in my Company because I am searching
for a professional IDE for Linux (better then KDevelop / KDE Studio) that
has at least the same funktionality then MSVC 6.0 has.
What I have seen is that CodeWarrior 6.0 (latest available for Linux) totaly
sucks compared to KDevelop / KDE Studio. There is no support for KDE / QT
included and the motiv style looks ugly too. There is no intuitive
UserInterface at all. Maybe I haven't seen everything from the Tool, but I
don't want to use a lot of time learning the tricks form the IDE. I expect a
VC like interface like Kdevelop has with a good Class browser and so on...
If anyone know a good alternative IDE for VC++ 6.0 (windows) or KDE
Studio/KDevelop (linux) I would be very happy to hear about. Anyway in my
opinion VC6.0 is still the best IDE that I know at the moment (don't know
VC.net yet, but I heard it has problems with qt).
Hear is my wish list *g*:
- VC 6.0 like intuitive user interface
- Classbrowser (supporting template classes, private member classes and so
on...)
- Workspace for more projects (Projektmanagement)
- An full configurable source editor.
- Macro and plugin support
- Individual build options for each file (making moc'ing and so on
available)
- Individual Pre/Post compile options/macros/compilers...
- Showing generated/"none project" - files in the classbrowser
- Integrated debugger/profiler...
- Intelligent online syntax checker.
- Relativ source file paths (flexability) (don't want the IDE to make copys
of the source, the source should be taken from where I tell the IDE)
- Fully integrated version control system (cvs, sourcesave...)
- Integrated QT Support *g* (slots, signal createn dialogs like in
KDevelop...)
- Full make file generation configuration (don't want to manually edit
anything in the makefiles...)
- Import funktions for MSVC++/KDevelop/KDEStudio/Watcom/CW projekts...
- Wizards...
- short period of vocational adjustment
- and much more....
-----Ursprüngliche Nachricht-----
Von: Craig Black [mailto:cblack@ara.com]
Gesendet: Dienstag, 12. März 2002 20:30
An: qt-interest@trolltech.com
Betreff: Alternatives to VC++ IDE?
Please pardon my frustration. I'm so sick of VC6!!! I want a modern C++
compiler!! I thought VC7 would be better but it doesn't even work with Qt.
I need a good IDE, a more standard-compliant compiler, and Qt compatability.
Does anyone know of a viable alternative to the MS VC6? I don't think C++
Builder builds Qt apps. Only VCL and CLX. What about CodeWarrior? Any
suggestions?
Craig
--
[ signature omitted ]
Message 2 in thread
> Why would you think that VC 6 is broken? Can you provide an example?
have you ever tried this:
template<typename T1>
class A
{
template<typename T2> //constructor
A( T2 arg )
{
... some code ...
}
A( const A<T1>& rhs ) //copy constructor
{
... some code ...
}
}
it doesn't even work this way:
template<typename T1>
class A
{
template<typename T2> //constructor
A( T2 arg )
{
... some code ...
}
template<T3>
A( const A<T3>& rhs ) //copy constructor
{
... some code ...
}
}
//////////////////////////////////////
When trying the first version MS VC++6 didn't recognize the copy constructor
although the standard says that when using constructor templates they must
never be taken for copy constructors by the compiler... and using the second
version a lot of funny things can happen starting with fatal errors during
compile time up to a case where after constructing an object the following
line of code wasn't compiled and when I tried to work around this bug
putting two semicolons after the code line which constructed the object the
app crashed with some memory error when exiting.
I circumvented the problem by not declaring a constructor template but a
separate init member function template because I needed the copy constructor
more desperately than initialization during construction due to the need to
use the class within stl containers.
Tom
-----Ursprüngliche Nachricht-----
Von: Paul Curtis [mailto:plc@rowley.co.uk]
Gesendet: Mittwoch, 13. März 2002 13:54
An: John Dean; ibarrett@grintek.com; qt-interest@trolltech.com
Betreff: RE: Alternatives to VC++ IDE?
John Dean wrote:
> >The VC++ pros (can't really speak for .NET in general) is that:
> >
> >(a) it's rock solid.
> >(b) it has a few bugs, but service packs generally fix them up.
> >(c) lots of 3rd party plug-ins and support (even Trolltech provides a
> >plug-in)
> >(d) It works. I start it in the morning and don't come out until I
> >leave for home. It runs all day.
> >
> >The cons:
> >
> >(a) The configuration/project system could be better.
> >(b) It could have a more capable compiler, but it'll come. No C++
> >compiler is perfect.
> >(c) Editor could be more powerful.
> >(d) Help system could be better.
>
> You forgot to mention that the compiler and linker are both broken
The compiler and linker in VC 6 are not particularly broken in my
experience. VC6 compiles Qt, our ECMAScript compiler, our smart card
loader, our project system, our help system, our crypto, our C compiler,
our linker & optimizer, and everything else we've thrown into this
single application. The application is now quite large at about 8MB,
and has a huge amount of code. There are no real problems to speak of.
We've stumbled across one optimizer bug when compiling our own RSA/DSS
code.
Why would you think that VC 6 is broken? Can you provide an example?
I have no experience of VS.NET *release* (as I said), so cannot comment
on the perceived problems with VS.NET, but there are other on the
mailing list that seem to be researching the issue and making progress.
-- Paul.
--
[ signature omitted ]
Message 3 in thread
Seems as if a lot of people had the same idea at the same time. I did
something close to your stuff a few weeks ago, except that I first developed
a general function pointer class template which can reference and call
(through the overload () operator) any type of function no matter if it's a
normal function pointer or a pointer to a member function. Then I developed
a something similar to your signal class which exposes an interface for the
caller (again the overload () operator) and an interface for the one who
connects the slots ro the signal (connect(), disconnect(), isConnected()).
The syntax for the connects and calls is also very similar to yours e.g.:
s.clicked().connect( makeVoidFunctionPtr0( &t, &MyTarget::go_bang ) )
or s.clicked().connect( makeVoidFunctionPtr5( &t, &MyTarget::go_bang ) ) if
the signal/slot has 5 arguments.
The signal gets emited like this:
clicked.emitSignal()
or in the latter case clicked.emitSignal( arg1, arg2, arg3, arg4, arg5 )
... but I could also overload the () operator again...
The advantage of this approach is that I can also connect to global
functions or to static member functions. This is achieved through the use of
an intermediate class the so called 'remember pointer' which actually
holds the pointer to the the member function pointer and the pointer to its
associated object. The function pointer class itself has a template member
function to initialize it with either a 'normal' function pointer or the
'remember pointer'. Couldn't do it with a constructor template because VC++
wasn't able to distinguish it from the copy constructor ( which I need to
put the 'function pointer' into STL containers (like inside the signal
class)). This produced some very funny effects on VC++, really. Anyway.. all
this 'remember pointer' stuff is hidden by the makeVoidFunctionPtr#
respectively makeFunctionPtr# functions. Further I can use the 'function
pointers' without the signal objects for a different callback technique like
e.g.:
render( makeVoidFunctionPtr0( this, &MyTarget::renderFinished ) )
where render would be running asynchronously.
Tom
-----Ursprüngliche Nachricht-----
Von: Sarah Thompson [mailto:sarah@telergy.com]
Gesendet: Donnerstag, 14. März 2002 22:20
An: cblack@ara.com
Cc: Qt-Interest@Trolltech. Com
Betreff: RE: Alternatives to VC++ IDE?
> 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
--
[ signature omitted ]
Message 4 in thread
[snip]
> The advantage of this approach is that I can also connect to global
> functions or to static member functions. This is achieved through
> the use of
> an intermediate class the so called 'remember pointer' which actually
> holds the pointer to the the member function pointer and the
> pointer to its
> associated object.
Your approach is very similar to the signal/slot stuff that is in the queue
for adoption by Boost at the moment. Mine actually does build a wrapper
class for connection objects, but it does it internally such that you don't
see it.
I had considered adding a
MySignal.connect(&function);
facility, which would be easy enough to do. My main focus, rather than being
just on building a sig/slot class was really on trying to make it look as
nice as I possibly could from a syntactic sugar point of view. This is
something of an obsession for me I'm afraid! Your approach is still very
valid, of course.
> The function pointer class itself has a template member
> function to initialize it with either a 'normal' function pointer or the
> 'remember pointer'. Couldn't do it with a constructor template
> because VC++
> wasn't able to distinguish it from the copy constructor ( which I need to
> put the 'function pointer' into STL containers (like inside the signal
> class)). This produced some very funny effects on VC++, really.
> Anyway.. all
> this 'remember pointer' stuff is hidden by the makeVoidFunctionPtr#
> respectively makeFunctionPtr# functions. Further I can use the 'function
> pointers' without the signal objects for a different callback
> technique like
> e.g.:
> render( makeVoidFunctionPtr0( this, &MyTarget::renderFinished ) )
> where render would be running asynchronously.
Yes, I see your point. Your implementation is probably more powerful than
mine. I was trying to write something that got as close as I could to Qt's
clean syntax as my primary goal, which is why we've maybe ended up at
slightly different end points.
Sarah
Message 5 in thread
If it would be possible to do things like this
class Foo
{
...
};
template<typename Arg1>
class Foo
{
...
};
template<typename Arg1, typename Arg2>
class Foo
{
...
};
template<typename Arg1, typename Arg2, typename Arg3>
class Foo
{
...
};
you would not have to use different names for different numbers of
arguments. This however does not work at least with MS VC++ 6 and I don't
know if it should work according to the standard (maybe this would be
partial template specialization ?). So in my opinion the only usable
solution is to name the calsses like Foo0, Foo1, Foo2, Foo3,...
Tom
-----Ursprüngliche Nachricht-----
Von: P.J. Meisch [mailto:pjmeisch@web.de]
Gesendet: Freitag, 15. März 2002 09:10
An: qt-interest@trolltech.com
Betreff: Re: Alternatives to VC++ IDE?
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 ]
Message 6 in thread
I did this to keep the header short.. yes I know.. macros are considered bad
style... but it was a lot less typing and I think it's more readable this
way. It's not that obvious in this example but when implementing my
'function pointer' class it really saved thousands of lines of code.
#define TEMITSIGNAL( FORMARGS, ACTARGS )\
void emitSignal##FORMARGS\
{\
TMultiThread::AutoMutex mutex( this );\
\
SlotList::iterator it = _slotList.begin();\
SlotList::iterator end = _slotList.end();\
while( it != end )\
{\
(*it)##ACTARGS##;\
++it;\
}\
}
//////////////////////////////////////////////////////////////////////
// class methods
public:
TEMITSIGNAL( (), () )
template<typename AT1>
TEMITSIGNAL( ( AT1 a1 ), ( a1 ) )
template<typename AT1, typename AT2>
TEMITSIGNAL( ( AT1 a1, AT2 a2 ), ( a1, a2 ) )
template<typename AT1, typename AT2, typename AT3>
TEMITSIGNAL( ( AT1 a1, AT2 a2, AT3 a3 ), ( a1, a2, a3 ) )
template<typename AT1, typename AT2, typename AT3, typename AT4>
TEMITSIGNAL( ( AT1 a1, AT2 a2, AT3 a3, AT4 a4 ), ( a1, a2, a3, a4 )
)
template<typename AT1, typename AT2, typename AT3, typename AT4,
typename AT5>
TEMITSIGNAL( ( AT1 a1, AT2 a2, AT3 a3, AT4 a4, AT5 a5 ), ( a1, a2,
a3, a4, a5 ) )
template<typename AT1, typename AT2, typename AT3, typename AT4,
typename AT5, typename AT6>
TEMITSIGNAL( ( AT1 a1, AT2 a2, AT3 a3, AT4 a4, AT5 a5, AT6 a6 ), (
a1, a2, a3, a4, a5, a6 ) )
template<typename AT1, typename AT2, typename AT3, typename AT4,
typename AT5, typename AT6, typename AT7>
TEMITSIGNAL( ( AT1 a1, AT2 a2, AT3 a3, AT4 a4, AT5 a5, AT6 a6, AT7
a7 ), ( a1, a2, a3, a4, a5, a6, a7 ) )
template<typename AT1, typename AT2, typename AT3, typename AT4,
typename AT5, typename AT6, typename AT7, typename AT8>
TEMITSIGNAL( ( AT1 a1, AT2 a2, AT3 a3, AT4 a4, AT5 a5, AT6 a6, AT7
a7, AT8 a8 ), ( a1, a2, a3, a4, a5, a6, a7, a8 ) )
Tom
-----Ursprüngliche Nachricht-----
Von: Sarah Thompson [mailto:sarah@telergy.com]
Gesendet: Freitag, 15. März 2002 10:46
An: mariusz.lotko@pruftechnik.com.pl; Qt-Interest@Trolltech. Com
Betreff: RE: Alternatives to VC++ IDE?
> 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
--
[ signature omitted ]
Message 7 in thread
sure it could be better but unfortunately you cannot parameterize the number
of parameters. First I thought about variable argument lists but that
solution had too many drawbacks and it would have made the mechanism very
slow and I actually don't know if it would have worked anyway (the slots
would also have had to use var arglists to not impose a limit etc...)
because I dropped the thought soon after discovering the aforementioned
drawbacks.
Tom
-----Ursprüngliche Nachricht-----
Von: Mariusz Lotko [mailto:mariusz.lotko@pruftechnik.com.pl]
Gesendet: Freitag, 15. März 2002 11:40
An: qt-interest@trolltech.com
Betreff: Re: Alternatives to VC++ IDE?
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 ]
