[Qt-interest] Are there any disadvantages with OT

BRM bm_witness at yahoo.com
Fri Feb 26 19:15:01 CET 2010


----- Original Message ----

> From: Scott Aron Bloom <Scott.Bloom at sabgroup.com>
> To: BRM <bm_witness at yahoo.com>; qt-interest at trolltech.com
> Sent: Fri, February 26, 2010 12:41:30 PM
> Subject: RE: [Qt-interest] Are there any disadvantages with OT
> > Unlike Qt, MS has invested in making their language of choice, your
> > choice.. Look Im not blaming TT/Nokia, I love Qt...
> Simply put, .Net was Microsoft's response to Java after the courts told
> them they couldn't Embrace & Extend Java; likewise, Silverlight is their
> response to Flash, this time without the court battle.
> In both cases they want to lock people on Windows, and their non-Windows
> versions (e.g. Mono and the Mac version) are only supported enough to
> make it seem like they are being cross-platform and trying to be
> friendly with competitors.
> They'll yank the plug as soon as they can, given a chance to do so.
> -----------------
> Not true.. C# is MS response to Java.  .Net is the next gen frame work,
> integrating languages and replacing the old MFC world of development.
> C# is not .Net.. to us C++ guys it is, but Linq is a really great SQL
> integration system, and hasnothing to do with thelanguage you are using
> to develop it.

Not quite. C# is one facet of .Net - true. True, it's mostly C# that is compared to Java.
But the whole ".Net is Microsoft's response to Java" goes well beyond C#, which just happens to be the Java analogue in .Net.
But their response was to move all their tools - Java, VB, etc - to the byte-compiled language format and build on top of it.
This also allows integration between the languages to happen more fluidly so projects can take advantage of each language's abilities.

So to say that only C# is the MS response to Java is like seeing a pebble on the beach.
 
> Silverlight is definitely a Flash esq, but if you are developing a SL
> app, it will run just fine on Linux.

Only if Moonlight is installed, but even there like with .Net vs. Mono no all interfaces are available. A higher percentage, yes; but not quite all.
Microsoft really wants you to use Silverlight proper, not Moonlight. Their support for Mono/Moonlight is more a facade than anything else.

> -------------
> > As has been said, in my view, Qt's biggest limitation is its lack of web
> > application/service/page deployment.
> I've been using Qt for about a year now. And it's hard to find any real
> disadvantages. It's one of the best platforms I've ever come across, and
> makes cross-platform development a breeze.
> That said:
> - I do have to agree that pimpl is way over-used. It also tends to break
> debuggers - including Visual Studios - and make it hard to debug even
> under GDB. For example, QString values are not shown directly under
> Visual Studios debugger - you have to go down several levels and search
> for a little bit. (Yes, I'm using the VS Add-in.) In GDB, I had to write
> my own user-defined functions, b/c otherwise you just get a the d
> pointer value. So now that's one more thing I have to remember - can't
> do p , I have to use my p_qstring . I haven't yet
> written one for the QByteArray or QList, or any number of others - so
> it's a little harder to get the data in debug mode without going back to
> qDebug() or something similar in the program.
> ----
> Agreed.. Just an FYI as to the debugger, get the Qt debugger plugins
> from Nokia.  It sets up the MS debugger to handle much of the pimpl
> debugging issues for the container classes.

Where I can I find said "Qt debugger plug-ins"?

As I said, I have the VS Add-in installed. I can't find any mention of anything else on their website, at least through a cursory review.
 
> -----
> 
> - Some will complain that 'moc' is a disadvantage b/c its one more tool
> you have to use. But it more than makes up for that fact once you start
> using it.
> -----
> Agreeed, however, I find singals, slots and properties using moc A LOT
> LOT cleaner then the boost signal/slots coding style. Frankly, Im afraid
> that Cx01 will finally support meta object information, and use a boost
> approach :(

Well, Boost is kind of officially accepted as part of the next-gen C++; so that's kind of expected.
I haven't tried out Boost yet; but mostly see it as a tool for when I can't use Qt for whatever reason.

> ----------
> Really, that's about it. I've done Windows programming for quite a
> while, and have done Qt for about a year. In that time, I've done a
> number of things in Qt in short order (1-3 days) that would have taken
> months to do in MFC or Win32.
> --------
> +1.  Tthough Ive been using Qt for 7 years, and have started doing more
> and more C++/cli and C# in the last year, and honestly have been really
> really impressed with it for web app deployment.

Personally I wouldn't use .Net or Java for web-apps. Call me old but:

- If you're doing a website, then make it a website, not an embedded program ala Flash/Silverlight/what-have-you. JavaScript/ECMAScript is often more than enough to do most websites, and AJAX makes it even more so.
- If you need more then just make a native application; it'll run faster and perform better; plus you remove the limits that would otherwise be placed on you (e.g. hardware access, etc.). If you're concerned over whether or not a user can install it, then come up with a way to do web-deployment to a sandboxed install - e.g. running from /tmp or %TEMP% - so that's not much of an issue. More likely than not, you need more than what your environment can provide.
- If I really had to do more than JavvScript/ECMAScript could provide client-side, then I would do Java; but then I'd be doing a bigger more full-fledged app and have to justify why it's not a regular application to start with - and there really are only very few areas where that is really justifiable.

Ben

P.S. Yes, I've used .Net for websites; it sucks pretty badly. There are far better ways to do websites.





More information about the Qt-interest-old mailing list