| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 5 | |
> 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 It can build Qt, but it's a horrible IDE. MSVC completely blows it out of the water. I've yet to find another IDE as good as VC++. ********************************************************************** 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 **********************************************************************
Ian Barrett wrote: > > 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 > > It can build Qt, but it's a horrible IDE. MSVC completely > blows it out of the water. I've yet to find another IDE as > good as VC++. I would concur that CodeWarrior is a pretty nasty IDE. It may have been state of the art 10 years ago on the Macintosh, but it does not translate well to Windows. It's must too different. (Actually, Macromedia titles seem to have the same problem.) It doesn't work well for me, and we purchased a big-ticket version for Java Card work, and then promptly returned it. C++Builder is OK for small RAD projects, I fear it's inadequate for project teams or such things as generating new controls (gee, it ships with the Delphi compiler...) You can throw something together very quickly with C++Builder, and if you need database integration and static forms it may be for you. Anything more, get a real environment. These two environments suffer the "lots of windows" syndrome. At least Visual C++ is nice and clean in a single window. VS.NET extends VS' undocking capability, if you can stomach such stuff. 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. The beta versions of VS.NET (haven't tried the release version) fix many of the cons. You need a big machine to run it on, though. However, it's very swish. When Qt is supported on VS.NET, I'll move. -- Paul.
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.
John Dean wrote: > >Why would you think that VC 6 is broken? Can you provide an example? > > The following piece of code will compile but not link > QPtrList<QWidget> > parents. Hmm, sorry? Don't understand here. Do you mean that if you have a C++ file which contains: #include <qlist.h> #include <qwidget.h> static QPtrList<QWidget> parents; ...then this does not link? I have no problem linking this. > Intel C++ has no problem with it Can't comment, we don't use it. > RTTI is does not work. The > following code works fine with Intel C++ and gcc but not with MSVC > > LibraryLoader* loader = > dynamic_cast<LibraryLoader*>(kore_loader_factory()); We use RTTI and it works for us. Can you tell me why it does *not* work or what provokes it? You need to compile Qt with RTTI enabled (Under Advanced Features or somesuch in the installer) to get RTTI to work across DLLs or in a static build with Qt, I grant you, but RTTI works just dandy. Plug your stuff into Purify, I'm sure it'll do you a power of good. > The MSVC can not handle the following STL code > > typedef hash_multimap<const char*,const ComponentRef, > hash<const char*>, > eqstr> srv_hash_type; Sorry? hash_multimap is not a standard STL container, so why should VC++ not complain? (If you're using some other STL such as SGI's or whatever, then that has problems too). The problem with the boxed STL, as far as it goes, is well documented by Dinkumware and has little to do with the base compiler; that conflict is now resolved. If you purchase Dinkumware's replacement STL for VC++, then you find that VC++ is more capable than you realised, and hashed containers are thrown in for free. > These are just a few examples Hmm. I don't think you've demonstrated that VC++ is broken. -- Paul.
I wouldn't call this "broken." The deficiencies with Visual C++ are
well documented, and the standard is a complex beast. Even EDG battle
problems in the template area. Granted it may not be behaving according
to the standard, but all C++ compilers are aflicted with some problem or
other. Face it, templates are a big problem for all compilers, so we
need to live with these problems for the present. In time, things may
get better.
I am not an advocate of Microsoft products, but nor am I a detractor.
We write software pragmatically here: if there's a problem in a
compiler, code around it or don't use the feature. We had code that
compiled with Borland C++ and Microsoft C++, and managed to maintain it.
Microsoft C++ isn't unusable. Staying to the well-troden path will
help. Straying off into "new feature land" will obviously cause
problems.
We'll see how far MS has come with VS.NET. Perhaps they'll try to move
us all over to Managed C++ or C#, who knows?
There's always hope in the Open Watcom project, but I fear this is as
dead as a doornail; it's not producing timely results, anyway.
-- Paul.
> -----Original Message-----
> From: Bauer Thomas [mailto:Thomas.Bauer@fh-joanneum.at]
> Sent: 13 March 2002 15:02
> To: Paul Curtis; John Dean; ibarrett@grintek.com;
> qt-interest@trolltech.com
> Subject: AW: Alternatives to VC++ IDE?
>
>
> > 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.
>
> --
> List archive and information: http://qt-interest.trolltech.com
>
> --
> List archive and information: http://qt-interest.trolltech.com
>
> We'll see how far MS has come with VS.NET. Perhaps they'll try to move > us all over to Managed C++ or C#, who knows? Speaking as someone who has recently been forcibly moved to Managed C++ (don't ask), I have to say that the whole .NET thing is not quite what I'd expected or feared. I'd gotten the idea, from the early marketing hype really, that it was all about moving to a web based, micropayment, everything's kind of like a Java applet, world. Sure, you can *do* that with .NET, but this is very much missing the point. Microsoft have taken a very big, brave step with .NET - if anything (and I know that this is flame bait, but hear me out), I think that .NET is probably the most innovative move in computing inside the last ten years. It would be nicer if the idea had come genuinely from the public domain, of course, but that's all history. Quick one paragraph .NET tutorial: Everything runs under the Common Language Runtime (CLR) environment. Executables are intermediate code, and get compiled into native code at load time. The intermediate code isn't really that close to Java/Smalltalk/UCSD p-system bytecode. Rather, it is effectively a post-order unwinding of a compiler's abstract syntax tree at a point after high level optimisations have been carried out, but strictly before code generation in the usual sense of the word. There is a Common Type System which is enforced by the intermediate code, which makes it much easier (i.e. the default rather than the exception) for languages to be able to interoperate. You can declare a class in Managed C++, inherit from it in C#, then inherit from that class in VB if you want to. All of the .NET languages now share a single class library, so if you learn to use it from C++, writing C# or VB is more like learning to speak with a funny accent rather than learning a foreign language. CLR executables are either verifiable, or they aren't. Verifiable executables are guaranteed memory safe (i.e. no buffer overruns, dangling pointers, etc). Some .NET languages (e.g. VB and C#) can only generate verifiable code. This is incompatible with the way that most C and C++ programs are written of course, hence the need for 'Managed' as well as 'Unmanaged' C++. These things aren't separate languages, or even separate compilers. Managed C++ is a subset of C++ which also happens to deal with pointers a bit differently (they behave like smart pointers a la boost or ATL), with restrictions that allow it to interwork with the common type system. A managed C++ class can be called by anything, regardless of what it was written in. It can include any managed data types you like. However, it *can't* include unmanaged data structures. You can't, for example, put a stl vector in a managed C++ class. However, it is trivially easy to write an unmanaged class however you like, then write a managed C++ wrapper for it. Sure, it's messier than it could be, and at some point I'd not be surprised if it is improved upon, but it is at least workable. Its a billion times nicer than COM - the thought of never needing to see the like of the ATL or MFC COM support again is very enticing to me. The .NET framework is much closer to Qt than it is to MFC or ATL code. However, Qt is still nicer - it's layout management, and ease of coding especially, quite apart from its cross platform capability, still give it a significant edge. Maybe less of an edge than it had against MS's previous offerings, but an edge all the same. What I'd personally love to see is a good .NET implementation of Qt, allowing it to interoperate properly within the .NET environment. Since Qt doesn't typically need multiple inheritance, templates or the STL, it may even be possible to give it a CTS compliant 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. As for Managed C++ being a MS attempt to 'own' C++ through the back door, it may be possible that some execudrones in the marketing department may think that way, but having read the background material written by the .NET people, I suspect it was just due to the pragmatics of getting C++ to work within a (dare I say this?) more modern run time system. Maybe one day I'll be able, smoothly and without hassle, to be able to write core functionality in Haskell or New Jersey SML, with a GUI in C++ and Qt - this would make me a very happy bunny indeed. Sarah PS: I'm writing this from the point of view of an artisan contract software engineer. I get paid to write code, and only infrequently get much choice over development platform as a consequence of this, so too much language/platform/class library zealotry on my part is not really an option if I want to remain employed. I suppose this makes me more agnostic on these kinds of issue than many! ;)
> (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. Mental arithmetic wasn't ever a strong point for me. s/25/15/ if you please. :) This is based on looking at typical large corporates - the bank that is paying me at the moment has huuuuuge numbers of VB programmers, but sufficiently few C++ people that we could all reasonably fit into a Mini, without even needing to get all that friendly. Sarah PS: You can include a pointer to an unmanaged class as a member of a managed class, by the way - you're just not allowed direct containment or inheritance.
Others on the Qt list, please just delete this message if you feel it has wondered too far off-topic. Sarah: (nice last name :) I am interested in your response, I'm _really_ trying to understand .NET. Feel free to email me off-list if you wish. On Wednesday 13 March 2002 4:52 pm, Sarah Thompson wrote: > bait, but hear me out), I think that .NET is probably the most innovative > move in computing inside the last ten years. It would be nicer if the idea > had come genuinely from the public domain, of course, but that's all > history. I'm _very_ interested in knowing how .NET is innovative. I actually asked a Microsoft employee and his response was that it was 'not innovative, just evolutionary'. He also said, 'No, there's nothing in .NET that isn't already available elsewhere'. You seem to think differently but I cannot find any evidence of .NET actually being innovative based on what I've read and on the contents of your message. > before code generation in the usual sense of the word. There is a Common > Type System which is enforced by the intermediate code, which makes it much > easier (i.e. the default rather than the exception) for languages to be > able to interoperate. You can declare a class in Managed C++, inherit from True enough. That said, CLR supports fewer languages than the JVM. Furthermore, the CLR _seems_ to force all languages to look like C#. No more multiple inheritance, no templates, etc. etc. etc. Question: If the CLR does not support multiple inheritance, does it work around this using 'interfaces', similar to Java? > least workable. Its a billion times nicer than COM - the thought of never > needing to see the like of the ATL or MFC COM support again is very > enticing to me. Amen to that. :) > 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. The last place I worked was considering adopting either VB.NET or C#.NET. Last I heard, they were switching to C#.NET because even though all their programmers knew VB6 already, VB.NET was such a fundamentally huge change that they may as well pick a 'real language' as they said. > As for Managed C++ being a MS attempt to 'own' C++ through the back door, > it may be possible that some execudrones in the marketing department may > think that way, but having read the background material written by the .NET > people, I suspect it was just due to the pragmatics of getting C++ to work > within a (dare I say this?) more modern run time system. Maybe one day I'll Personally, I'd love to see a nice, safe garbage-collected implementation of C++ where memory issues were a thing of the past. However, losing access to the STL is absolutely crippling. C# looks nice enough but has as many keywords as C++ and I dislike some of the design decisions made therein. That said, I dislike some of Java's design decisions, too. :) > PS: I'm writing this from the point of view of an artisan contract software > engineer. I get paid to write code, and only infrequently get much choice > over development platform as a consequence of this, so too much > language/platform/class library zealotry on my part is not really an option > if I want to remain employed. I suppose this makes me more agnostic on > these kinds of issue than many! ;) For what it is worth, I am an employee who develops Windows applications in Linux using Qt. :)
> Personally, I'd love to see a nice, safe garbage-collected implementation of
> C++ where memory issues were a thing of the past. However, losing access to
> the STL is absolutely crippling. C# looks nice enough but has as many
> keywords as C++ and I dislike some of the design decisions made therein.
> That said, I dislike some of Java's design decisions, too. :)
I'm actually teaching a C++ course at the moment, and a very strong
impression I get from a lot of the students is that they dislike the
somewhat "piecemeal" way that it's been built up over the years, in
particular the slightly awkward console I/O.
(e.g. getline(istream,std::string is broken in VC6!) A lot of
them would like to learn C++ by writing more modern, GUI based apps, but
with only MFC built into the compiler that isn't easily possible. So I'm
stuck with having to use console apps to teach the general OO principles,
which is basically fine but - like you can with Java and the AWT or Swing
- it would be good to bring in GUI stuff later on. I, and many of my
students, think it would be nice if C++ had a standard, easy to use GUI
like Java does.
I've always thought it's time to invent a new C++ based language with all
the power of C++ - being able to use pointers if you want - but also with
the fully-reference-based Java model if you want too, to lessen confusion.
It should be a compiled language, to maximise performance, which is where
IMHO a lot of these new languages are going wrong. It would also be nice
to have it thoroughly OO from the start with everything inheriting from a
class Program containing a virtual main which you then override
appropriately.
e.g.
class MyProg : public Program
{
// main() is a virtual method of the Program class
int main(int argc,string argv[])
{
cout << "hello world!" << endl;
return 0;
}
}
I suppose something like Qt is already close to this ideal, although the
lack of non commercial updates in the Windows world is a disadvantage for
free software developers and educational use.
Nick
<<< text/html: EXCLUDED >>>
On Thursday 14 March 2002 6:01 am, Nick Whitelegg wrote: > I'm actually teaching a C++ course at the moment, and a very strong > impression I get from a lot of the students is that they dislike the > somewhat "piecemeal" way that it's been built up over the years, in > particular the slightly awkward console I/O. > (e.g. getline(istream,std::string is broken in VC6!) A lot of You can hardly blame C++ on the deficiencies in VC++. Btw, isn't istream in the std namespace? > them would like to learn C++ by writing more modern, GUI based apps, but > with only MFC built into the compiler that isn't easily possible. So I'm > stuck with having to use console apps to teach the general OO principles, > which is basically fine but - like you can with Java and the AWT or Swing > - it would be good to bring in GUI stuff later on. I, and many of my > students, think it would be nice if C++ had a standard, easy to use GUI > like Java does. Personally, I agree. However, this is not likely to happen, at least partly because C++ is used in so many places. For example, I write software that must sometimes run on embedded devices. Having to support a GUI library in order to implement a C++ compiler would be a big problem as the device has no graphical display unit. :) > I've always thought it's time to invent a new C++ based language with all > the power of C++ - being able to use pointers if you want - but also with > the fully-reference-based Java model if you want too, to lessen confusion. Again, I agree. And give me garbage collection. :) Some say C# was an attempt at this, though I strongly disagree. I think C# was a copy of Java. Java was certainly an attempt, mind, but I think they perhaps stripped out too much from Java. > It should be a compiled language, to maximise performance, which is where > IMHO a lot of these new languages are going wrong. It would also be nice > to have it thoroughly OO from the start with everything inheriting from a > class Program containing a virtual main which you then override > appropriately. Yes. And make even things like the number 3 an object. There might be a performance cost but then you wouldn't have the weird hacks that have sprung up in C++ to get around this. > I suppose something like Qt is already close to this ideal, although the > lack of non commercial updates in the Windows world is a disadvantage for > free software developers and educational use. While I agree and I really wish the trolls would release Qt 3.x non-commercial for Windows, I really don't think this is an issue for students. Qt 2.3.x supports more than enough to provide them with a fully-functional GUI library. That said, I'm not convinced that students should be learning Qt while learning C++... the memory management and signal/slot mechanism is sufficiently different from normal C++ practices that it would likely serve to confuse someone new to C++.
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. 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#. Not to mention the use of other small scripting languages like Tcl and things like functional programming languages and such. 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! -- [ signature omitted ]
Here are my 2.056 cents. Lets say 3 or 4 years ago, you were to make a decision between adoping Microtrash MFC or Qt. If you chose MFC, look at yourself today. You have to re-write your application from scratch. Yes, MFC is provided for legacy apps only but you are told that your application is outdated and should be rewritten from scratch. Using MFC today is playing with "outdated" technology. If you adopted Qt, you can modify your application by spending just a couple of hours (depending on the size). I have ported apps from Qt 1.44 to 2.x using only a couple of minutes---best of all, these are the apps that I downloaded from the internet and had not even written myself!! Using Qt today is NOTHING outdated. Why does F*&*#@ MicroJunk and F#&*%$# Junk Gates does this? Becuase when they expire the old stuff, they get to sell more training, more books, more certifications etc and it brings them more money. When they don't change, they can't sell---no $$$$. So they do this all at the cost of screwing up their customers to the maximum extent possible. Look at Com, DCOm, COM+ etc etc. So now is the time to make the correct decision. If you choose Qt, you will be spending just a small amount of time porting your app to Qt 4, 5 and so on. If you choose .NET, 6 months down the road, there will be .NET+, then .NET++, then F%$#.NET, and then Okay_ReWrite_Your_Application_from_Scratch.NET. Guaranteed. What is Trolltech goes out ot business?? Qt will be maintained by the open source community. Your application once written will never have to be re-written from scratch. Look at several of the UNIX applications that were written in the 80s and still are maintained and used widely today. Show me any MicroPoop apps that did this. I'd say the hell with Bill Gates, the hell with his software, the hell with .NET, the hell with MicroTrash, the hell with anything that has anything to do with Microsoft. This follows exactly with Trolltech's philosophy of not creating "vaporware". Eventhough sometimes I think the marketing practices of MS might some day vaporize TT itself. But I dont' care, open source will stay here for as long as I will live. And Yes, I read somewhere that if TT goes out of business, Qt will be maintained and enhanced by the open source community. Salman __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/
> > >What is Trolltech goes out ot business?? Qt will be >maintained by the open source community. Your >application once written will never have to be >re-written from scratch. Look at several of the UNIX >applications that were written in the 80s and still >are maintained and used widely today. Show me any >MicroPoop apps that did this. > This is only true if you are developing GPL:ed applications. If you are developing a commercial application you are in exactly the same spot as if it was a closed source project. I for one does not think overly much about this myself (Proud Qt/Windows owner), but that a GPL:ed version exists does not give any more security than if it didn't exist at all from proprietary software developers perspective. /Henrik Johnson Underscore AB
On Thu, 14 Mar 2002, Henrik Johnson wrote: > This is only true if you are developing GPL:ed applications. If you are > developing a commercial application you are in exactly the same spot as > if it was a closed source project. I for one does not think overly much > about this myself (Proud Qt/Windows owner), but that a GPL:ed version > exists does not give any more security than if it didn't exist at all > from proprietary software developers perspective. You're forgetting this: http://www.kde.org/kdeqtfoundation.html If TT goes out of business or takes Qt proprietary or whatever, the latest free QT will be released under a BSD-like license (meaning, basically, do with it whatever you like). -- [ signature omitted ]