| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 5 | |
Prejudices against MS aside what reason is there to believe they're introducing new software technology just to break the old stuff? I just compiled and ran an app I wrote 5 years ago in VC 4.2 - absolutely no changes necessary - still works and does what is required; even my oldest COM app will compile and run today with zero changes - same here, it doesn't require and update. When I moved an MFC app to ATL I simply copied all the core code into the ATL app - took at most half an hour and I had a COM component. If I want to move that app to Qt I simply have to rewrite the GUI, again no big deal, but if I'm doing the kind of re-write that requires the GUI part to be changed significantly then I expect it to take time anyway, even if I'd written the original in Qt I'd still end up redoing most of the GUI. COM was and remains a good idea - certainly saved us a huge amount of time and money; and there were no alternatives; it does what it does extremely well. And nobody forces you to update your older stuff to the latest - if I've written a DLL and it doesn't require updating why would I move it to the latest thing? 3 or 4 years ago we used MFC because it was simply impossible to afford the upfront cost of a toolkit like Qt. It still is difficult to justify the R25000 per developer cost on top of the development environment costs, buying something like the Intel compiler at another R6000 per developer is just insane. Of course these things are all sold in dollars which basically screws everyone except those that actually earn dollars. 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 **********************************************************************
HI, Anyone tryed eclipse from www.eclipse.org ?
Brad, > The problem with .NET is a general problem with MS and that > is that they > think one tool can work for everything. The CLR is based on > what C# needed. I think that's a little unfair. > This handles a fair bit of C++ as well but not the > interesting bits and also > some other languages like Java and C but its going to be a > poor match for > others (Forth, Ada, ...) that don't closely match C#. Why do you assert that it's a poor match for Ada? I don't think this is true, yet I have never written an Ada compiler, but have studied the language and have written compilers for C, Modula-2, Forth, Fortran 90, C++, Pascal, and Oberon-2, so I think my hypothesis is valid. > Not to > mention the use of other small scripting languages like Tcl and things like > functional > programming languages and such. Microsoft can compile JavaScript to IL, and JavaScript is indeed a scripting language. In fact, I assert that you will be able to compile *any* language to the CLR. I have already written a Forth-style language that compiles to Java bytecodes, and a Modula-2 compiler that compiles to MSIL, both hobby projects. The implementation of a language that does not fit well into the MSIL/CLR framework can still be implemented, just not as efficiently as one that does. As for functional programming languages, compiling them to MSIL is a darn site easier than compiling to native code, given that the CLR has an efficient garbage collector. Having written both Prolog and Common Lisp compilers in the past, I'm pretty sure you can compile functional languages using continuations in the CLR, and declarative languages fit well too. > Its the same idea with running Windows on every device. Its just not > designed to scale well down to a PDA and up to enterprise servers. > > The analogy in my head is with other tools. Sure I can open > a can and cut a > board in half with a hammer but its just not the best tool > for the job! MSIL isn't half bad; certainly better than Java. Should you ever try programming a smart card in Java Card, you'll soon realise the pain inflicted by the inadequate VM. We're looking at putting a small .NET interpreter on a smart card as a project, now that smart cards are getting bigger. -- Paul.
> That still doesn't help you if you are developing for Windows, but then Why not? As I understand that license I can take the code develop from it and keep my own development commercial and private. 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 **********************************************************************
<<< text/html: EXCLUDED >>>
On Thu, 14 March 2002, Nick Whitelegg wrote > Visual Basic 80%? Is that right? I tend to follow the rule, stolen from the Dilbert author Scott Addams: "Never research a statistic that you can just make up on the spur of the moment", but from what I typically see in the corporate world, VB has a serious strangle hold. Banks especially like VB because they can employ door-stops to write it, managed by door-stops, and then hire a bunch of other door stops to maintain it. They turn a peculiar shade of white if C++ is mentioned, although they know perfectly well that it is essential for a proportion of their work. Typically, the door stops drag and drop dialogs into life in VB, with maybe the odd 'Form1.Show' added to a button's click handler. They hire a 'database consultant' to write the rest of the VB. If the 'database consultant' can't do everything, they hire a 'contractor' to write a COM component in VC++ (or whatever) so they can drop it into their VB app. I wish I was exaggerating here, but it really is like this in the corporate world. Read some Dilbert cartoons (the books are great). It's all real. Me? I'm more of an ideas rat... >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. I suppose it depends where you are standing - not a lot of VB gets written under Linux (thank doG - LOL). However, in the corporate world, MS has a strangle hold that is quite frightening to witness. Sarah PS: For anyone non-English, s/door stop/idiot/.
Sarah, [ big snip ] > 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. 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. -- Paul.
> 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?
It doesn't currently support signal renaming, but there is no fundamental
technical or aesthetic reason why it shouldn't be able to do that. I'll look
into it when I clean the code up for release. As for dropping parameters
when wiring to a slot, I'll give that some thought - it might be possible. I
can think of one or two ways this might be done. I don't want to end up with
something like the GTK approach with lots of weird extra syntax being
necessary to support it.
My only issue really is that, apart from technical feasibility, I'm not
quite convinced that I'd *want* to be able to do something like
class C
{
void f()
{
}
};
signal1<int> bang;
C o;
bang.connect(&o, &C::f);
and have it not actually be a compile-time type violation. I suspect I could
make connect() able to take reduced parameter versions of its right-hand
parameter, but personally I'd rather have the compiler refuse this kind of
thing, because if I write that kind of code, there is a 98% chance that I've
done it by mistake and I'd like to be warned about it.
> 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.
There are much more flexible pure C++ alternatives than mine. I wasn't going
for flexibility per se, as I've mentioned a few times now, I was going for
cleanest possible syntax, easy to read/understand code, and (most of all)
type safety. I didn't write the library to replace moc - I actually wrote it
in order to hopefully stay sane whilst having to write MFC code, so Qt
compatibility or being all things to all people weren't on my wish list.
After all, it's only C++ - if you don't like it, you can always write your
own! ;-)
Sarah
Craig, > >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. I didn't say moc was "better" than templates, I simply stated that as presented, the converse is less flexible than that which currently exists. I then enquired whether Sarah had considered the fact that signals can be renamed and parameters dropped using moc. > 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. I didn't flame anybody. I simply enquired whether the proposed template solution would happen to cover two features that exist and I already use. IMHO, the Trolls aren't about to drop moc and nor will they jump feet-first into template land for everything simply because right now they need to nurse some crufty compilers. -- Paul.