I assume that there's some good reason(s) to run the intel compiler vs gcc. I would guess that it involves specific optimizations for Intel chip(set)s. Am I wrong? Is there more(or less) to it than that?
Yeah, that's about it. GCC continues to produce mediocre code for the P4 and Itanium. (The latter's very significant - some reports of 50% slower.) There are efforts to fix this but Intel has a significant lead.
The other advantage is vectorization - Intel's compiler makes much better use of MMX/SSE/SSE2 than GCC does. I don't know how ICC compares to VectorC but I'd guess they'd have the edge back by now.
The lack of an snprintf method in the DevStudio standard C lib causes MS developers to use the unbounded sprintf instead, potentially resulting in buffer overruns.
Does rapid improvement in processor technology cancel out the need for developers to learn how to write better code on a particular platform in order to achieve the maximum possible benefit from Information Technology?
No, that's
the advances in compiler technology
the divergence in architectures with a common instruction set.
It's no longer practical to hand-code assembler for speed: chances are your C compiler will do it much better than you can and in a fraction of time, too. Nowadays if you get the basic algorithms right your compiler should do all the rest. (And if it doesn't, go contribute to gcc until that does.)
Anyone who does the slightest bit of physics knows that Windows and Microsoft Fortran is the standard operating environment in professional research anyway.
Physicists/mathematicians I know use Fortran on miscellaneous unices, but yeah. *However* that's just for the number crunching. They use other tools for data presentation, and that's really what's needed here. Fortran is not the answer here.
Once encryption is wide spread, you will know something is spam by the fact that it wont be encrypted... Your friends and people you want to email you will have your public key to encrypt...
What's to stop spammers trawling public keyservers? (Good source of addresses! I don't think GPG matches anti-spam mangled addresses... yet?)
If they encrypt everybody's spam with the same symmetric key then they only need one asymmetric operation per bulk mail. Yes, that's relatively expensive compared to the effort they take now but it's still not a huge barrier. And the sell-you-a-CD spammers can sell you these precomputed for a given symmetric key.
(And then people start implementing symmetric key blacklists, etc. - except they'll have to be downloadable or you've just let the NSA read your message, etc. I forsee much fun.)
We can GPG sign each megabyte of the files to be downloaded.
GPG signed by whom?
You can't use a one-time key because there's no trust. The poisoners could just make their own keys and spam with those.
You can't use a valuable key (or reuse an anonymous key to build trust in it) because if you the lawyers ever do catch up with you, they have a non-repudiatable record of everything you've done.
This doesn't gain over posting per-megabyte checksums. You still have to trust the source.
"We're a Linux development company and we'd like to partner with you to port your product X to Linux.
"We're willing to pay you up-front for your developers' time to get us up to speed with your codebase and we'll take Y% of profit on sales of the Linux product.
"In other words, we're taking all the risk and you can't lose."
If they're not likely to make money from it so they can't afford to do it.
Re:Just contributes to that mountain in China
on
Pentium 4 2.8GHz
·
· Score: 1
He doesn't need the power for writing that kind of stuff.
He needs power to run php and MySQL with a setup of any complexity. He needs power to perform any sort of useful testing on his finished application.
Besides, having a full compile take ~15 mins encourages programmers to write code well instead of just compile-and-see-what-the-errors are.
No, that's the first line of defence. No-one sets out to write bugged code. Self-review is a good idea but it's pointless duplicating the effort the basic syntactic sanity check compiler can do for you automatically. Once it compiles cleanly *then* you review.
Having slower processors also encourages them to optimise the app that bit more.
Yes and no - the only real win is using efficient algorithms but then an experienced programmer would do that anyway. If you did it right first time then you're only going to squeeze a few percent worth of performance out at the end and that really isn't worth it commercially: extra development cost vs bigger server, delivery deadlines, simplicity->maintainability/ease of testing, etc.
Re:Just contributes to that mountain in China
on
Pentium 4 2.8GHz
·
· Score: 1
Doesn't it? I mean, instead of optimising software, and making better use of existing systems, the trend is to put faster processors on the market, and write sloppy software.
For bespoke solutions it's cheaper to buy better hardware to run the solution on than to pay software engineers to optimize it.
No, I'm still using an MMX-200 with 128 megs of RAM for all of my work, and it's not a limitation.... writing PHP and MySQL based applications.
The basic edit and unit testing, sure, but you'd struggle to perform any useful stress, scalability or performance testing on that rig.
Training and usability aside (dealt with by someone else), you really think consulting companies are going to develop and support OSS for free?
One size does not fit all. Government contracts, even when based around commercial off-the-shelf software, usually need significant development/integration work to get the system right.
If you're using closed-source software, there's some inherent risks that aren't there with open source.
So find a couple of smart employees at the contractor who pass NSA vetting as upright, patriotic citizens and put *them* in charge of the government codebase/release.
Isn't this what keeps happening with sucessive versions of gcc? We're already seeing binary issues with 3.1.x and 3.2 compiled programs.
Only in C++ programs (and C++-compiled runtime libraries, such as libgcj). This is because there were bugs/omissions in the C++ ABI which they couldn't fix in a compatible way. They're not breaking compatibility for the sake of it.
The only plain C per-version issue is the libgcc interface but I think they've largely stabilised that now.
You're not likely to have both 3.1.x and (the not yet released) 3.2 on a (GNU/)Linux system anyway unless you've got a build-from-source distribution - and in that case you can just rebuild everything with 3.2 and be happy.
Since binary incompatibility only affects *C++ programs*
In practical terms, it only affects programs that load dynamic libraries with C++ interfaces. As long as you stick to C-interfaced libraries and you have the correct version of libstdc++ around (which is pretty much tied to a version of g++ so will have the right ABI pretty much automatically) then you should be OK. In the worst case, you just need a separate copy of the libraries built with an old GCC and a wrapper script to set LD_LIBRARY_PATH.
Java compiled to native with gcj may also break since its runtime is built with g++.
Re:Notes from a 6-month MFC coder
on
Qt vs MFC
·
· Score: 1
Then it spits out this hulk of code
with// TODO comments where you should put your code if you don't want to delve too deeply
that has all these weird constants and macros in them with names like '__AFX_DEFINED_DDLXCI_AXWEC_UBER_MACRO_EXCHANGE_DD FC' scattered all over it.
They're the header include guards - which are sensibly long (they contain a GUID) and easily recognizable.
And you can just pull values out of a dialog box; you have to use this thing called "Direct Data Exchange" that I never really figured out,
Yes you can; you can call 'GetWindowText()' on any control. If you didn't associate a control variable with your dialog then you can call a method on the CDialog object to get an MFC you can call these methods on.
DDX is just a convenience:
you associate a simple variable with a control (easiest with the ClassWizard0
before you start reading data you call UpdateData(TRUE)
you access data in your DDX-associated simple variables
you call UpdateData(FALSE) if you changed values and want to reflect them back to the display.
It's that simple.
and you have all these magic cookies that get defined in some header file somewhere
The Win32 API is constant-heavy. You can't completely escape it and MFC does well to not try.
and you don't even get to write main()
You use InitInstance() in your CWinApp derived object if you need a main() alike. Alternatively, just write UI response code.
all the classes start with the letter 'C' and everything is in hungarian notation
Such is the Microsoft coding convention.
WHERE DO I DRAW STUFF IN MY WINDOW?!
Override OnPaint() in your view object if you really need to - this exactly corresponds to WM_PAINT in non-MFC apps.
I agree, there's also ATL i think that's even worse!!!
There's a learning curve, agreed, but ATL is very powerful if you want a COM implementation that covers all corner-cases and configuration properly. The ATL with VS7 has been beefed up with MFC-style helper classes (CATLStringW, etc.) and is an absolute dream to use. Honest.
MFC might look good in comparison to Visuial Studio which must be one of the worst Dev environments I've ever used
What's wrong with it? IMO, it's a nice editor with a well-integrated (and useful!) source debugger.
All the information is there (if you can find it), but it's highly scatterbrained and disorganized.
The index and search are usually good. You very rarely have to browse the contents for stuff.
Grepping the windows API headerfiles is also very useful.
The API documentations frequently don't explain what parameters are supposed to (or allowed to) contain, and even if they do their frequently listed on a seperate page without any explanation of the meanings for the various values.
I've always found them good in that respect - often equal or better than Solaris man pages, say. (IMO, at first glance the QT docs don't look quite as good, but I will give them a better look.)
Oh, and good, standardised documentation about those COM/COM+ error codes located in a single and easily accessible location? Forget.
You can get most of them from winerror.h (with some description). Alternatively, there's always the error lookup util installed with Visual Studio.
Re:"MFC programming", what the heck?
on
Qt vs MFC
·
· Score: 1
And what is it with those API's on Windows, do they have to typedef _everything_ for every different occasions...
Could it be to support more than a single machine architecture?
I think also to support both 16-bit Windows and Win32 together, although that's more relevant for the base windows headers than MFC.
I don't mind a little opacity on the OS interface. And you often gain meaningful type names too.
(There are a number of examples on Unix, too: e.g. uid_t, pthread_t, etc. But certainly not to the same degree.)
Re:Why is this on slashdot?
on
Qt vs MFC
·
· Score: 1
One of Qt's strengths (and a tribute to its design) is how its learning curve is really quite low.
For simple applications, MFC's learning curve is also low - the wizard will generate all the glue code and provide// TODO comments where you plumb in your own code. You can have a simple, fucntional MFC-dialog-application up and running very easily, invoking the MFC API only a few times yourself.
For an experienced Win32 programmer, MFC's learning curve is pretty much zero (flat?).
Addressing some MFC points in article
on
Qt vs MFC
·
· Score: 1
I've some experience with MFC but not QT. I don't think you've correctly understood the MFC model. (Colleages recommend Prosise's book by Microsoft Press but it's been a long time since I've seen a copy.)
The Microsoft Foundation Class (MFC) is a graphical toolkit for the windows operating system. It is a more or less object oriented wrapper of the win32 API, which causes the API to be sometimes C, sometimes C++, and usually an awful mix.
The only non-C++ you could complain about in MFC is the use of some Win32 API structures without containing classes/accessors. Under the circumstances (given the number of them!) I don't think this is too big a deal.
MFC programming requires the use of Document/View model and templates.
No, it doesn't. If you don't want Doc/View, you can just use the MFC-dialog-application template.
I've never seen the other problems you mention:
you can probably ditch the document/view model (I've never tried) but you can easily bury it if you don't like it and I've never found it inflexible enough to be a hinderance. Cite an example?
I wouldn't be surprised if splitting a window to show two different documents probably violates the windows UI design guidelines. You can get equivalent function using an MDI app (although I think the guides have deprecated those) or implement a 'document container' class or something. You probably don't need too much imagination.
MFC is a kind of object wrapper allowing access to the windows API,
I'd consider this a plus - lean (or as lean C++ as you'll get), efficient (ditto) and feature-complete.
And there are nasty tricks, without any consistency. For example, if you create a graphical object, it is not created until the Create() methods has been called. For dialogs, you must wait for OnInitDialog, for views, you wait for OnInitialUpdate,... So if you create an object manually and call its methods, your program crashes.
No. This *is* consistent and logical. And OO.
When you create a CDialog, you create a container class for a window handle with dialog-like methods. You may set up the initial state of the dialog, member variables of the container class, etc. But because you have an empty handle you can't actually play with the dialog yet.
You Create() or DoModal() your CDialog object. Now the windows is actually generated on the desktop and the window handle is filled.
You're called back in the OnInit* method to set any state on the window as it is created. You may now call methods that require a window handle.
I don't think MFC will crash - I think it'll give you a useful debug assert. But I haven't fallen into that trap for a while.
MFC is full of these nasty tricks. And it is hard to debug.
'nasty tricks' is a little extreme. MFC integrates very well with Visual Studio's debugger and is relatively simple to debug. You're provided with the source code to step through if you need it. I've never had any trouble.
Qt is based upon a powerful callback mechanism based on signal emission and reception inside slots.
This sounds exactly like the Windows message model that you've just slammed (!). I don't see any problems with the windows message model - but then I'm familiar with the API.
The interface creation section: DDX and IMPLEMENT_DYNCREATE (why do you need that for your UI?) are relatively easy to understand - maybe try Prosise's book if you need enlightenment. You don't need to touch the message loop - it's buried in the MFC DLL and covers all cases. You can quite happily manufacture dialogs at run-time by calling Create() on control objects in the OnInitDialog() method.
Qt designer lets you do things that are not possible in MFC, like creating a listview with pre-filled fields, or using a tab control with different views on each tab.
Pre-filling a list view should be done in OnInitDialog(); the interface is quite simple.
Tabs are a different matter; you need to create child dialogs for each separate pane. This closely reflects what's going on in the OS API. It's not too difficult and there are good sample applications. Alternatively, there's a very simple interface to create complex property pages already provided.
Visual's documentation, MSDN (for which you must pay separately) is huge, on 10 CDROM.
It's no more than 3 CDs. It's bundled with Visual Studio. It's available online at http://msdn.microsoft.com/library/. And it's very good, complete documentation.
MFC's unicode is very easy. If you need to change the entry point of your application then you're doing it wrong; you probably need to change/D_MBCS to/D_UNICODE and it should happen automatically. The _T() is to tell the compiler to generate unicode character constants. It's a MFC/Win32API macro that emits syntax for the compiler. There must be a similar mechanism in QT or you won't be able to pass it unicode constant strings. If you build your application with the correct Unicode defines then the CString class will be Unicode internally automatically (but will still support some char* functions). If you build your application ground-up Unicode (and you should be doing this - NT is natively unicode) then you'll have no problems; Unicode converting an existing app isn't as hard as you portray.
If you're given non-unicode third party library then the third party ought to be able to supply a unicode version by changing a few flags and rebuilding. I'd be surprised if many vendors couldn't supply Unicode libraries if you asked them.
Resources and string-tables are part of the Win32 API. I find them useful and easy to program for. You have to try quite hard to load resources from the wrong DLL; all resources are indexed on exe/dll module handle as well as resource ID.
Latest MFC DLL: you should always ship the one you develop and test against! Win2K+ allows you to install a copy of the DLL local for your application. Alteratively, there are simple-ish mechanisms to auto-download the latest MFC from Microsoft.
To address some of your list of QT advantages,
Controls... MFC uses native OS widgets which is arguably an advantage for Win32 programs: correct look and feel and always do exactly what a Windows user would expect.
MFC does provide classes for network and database access
Memory management shouldn't be a problem; if you create controls as members of the containing dialog class then they'll be destroyed automatically too. MFC's debug memory allocator is good, too.
And yes: it is true that CVS-style revision numbers implicitly show you branch points. But they're on a per-file basis. In SVN, you can say at a high-level "branch FOO was created from revision 1234 of/trunk".
Yes: I was suggesting that on a branch level, i.e. you then number revisions on branch FOO 1234.1, 1234.2, etc.
On the other hand, I can see the 'simpler is better' argument too. And I'd (somehow) mistakenly thought I'd have to check branches with 'svn log' individually per file rather than per repository.
Greg points out that branches can live under a '/branch/' root - which goes some way to addressing this if everyone's working against trunk, but if we're working on a branch as a matter of course (e.g. stabilising a release) then it doesn't really help.
except I now see that this is a filesystem recommendation rather than server enforced, so I can happily keep my stuff under '/xbranch/rup/' or something, well out of everyone's way. Excellent.
I'm now far more sold on subversion than I was this time yesterday - although my other issues in parent post still stand.
Slashdot Mirror
YHBT YHL HAND DS
:-p
unless, of course, that was a serious question about chipset support / compatibility and drivers for the on-board video and audio
There's a Linux section in the FAQ so it should run fine.
I assume that there's some good reason(s) to run the intel compiler vs gcc. I would guess that it involves specific optimizations for Intel chip(set)s. Am I wrong? Is there more(or less) to it than that?
Yeah, that's about it. GCC continues to produce mediocre code for the P4 and Itanium. (The latter's very significant - some reports of 50% slower.) There are efforts to fix this but Intel has a significant lead.
The other advantage is vectorization - Intel's compiler makes much better use of MMX/SSE/SSE2 than GCC does. I don't know how ICC compares to VectorC but I'd guess they'd have the edge back by now.
The lack of an snprintf method in the DevStudio standard C lib causes MS developers to use the unbounded sprintf instead, potentially resulting in buffer overruns.
It's called _snprintf.
I presume they adopted it before ANSI did, hence the underscore prefix.
Does rapid improvement in processor technology cancel out the need for developers to learn how to write better code on a particular platform in order to achieve the maximum possible benefit from Information Technology?
No, that's
It's no longer practical to hand-code assembler for speed: chances are your C compiler will do it much better than you can and in a fraction of time, too. Nowadays if you get the basic algorithms right your compiler should do all the rest. (And if it doesn't, go contribute to gcc until that does.)
Anyone who does the slightest bit of physics knows that Windows and Microsoft Fortran is the standard operating environment in professional research anyway.
Physicists/mathematicians I know use Fortran on miscellaneous unices, but yeah. *However* that's just for the number crunching. They use other tools for data presentation, and that's really what's needed here. Fortran is not the answer here.
Once encryption is wide spread, you will know something is spam by the fact that it wont be encrypted... Your friends and people you want to email you will have your public key to encrypt...
What's to stop spammers trawling public keyservers? (Good source of addresses! I don't think GPG matches anti-spam mangled addresses... yet?)
If they encrypt everybody's spam with the same symmetric key then they only need one asymmetric operation per bulk mail. Yes, that's relatively expensive compared to the effort they take now but it's still not a huge barrier. And the sell-you-a-CD spammers can sell you these precomputed for a given symmetric key.
(And then people start implementing symmetric key blacklists, etc. - except they'll have to be downloadable or you've just let the NSA read your message, etc. I forsee much fun.)
We can GPG sign each megabyte of the files to be downloaded.
GPG signed by whom?
You can't use a one-time key because there's no trust. The poisoners could just make their own keys and spam with those.
You can't use a valuable key (or reuse an anonymous key to build trust in it) because if you the lawyers ever do catch up with you, they have a non-repudiatable record of everything you've done.
This doesn't gain over posting per-megabyte checksums. You still have to trust the source.
You say:
"We're a Linux development company and we'd like to partner with you to port your product X to Linux.
"We're willing to pay you up-front for your developers' time to get us up to speed with your codebase and we'll take Y% of profit on sales of the Linux product.
"In other words, we're taking all the risk and you can't lose."
If they're not likely to make money from it so they can't afford to do it.
He doesn't need the power for writing that kind of stuff.
He needs power to run php and MySQL with a setup of any complexity. He needs power to perform any sort of useful testing on his finished application.
Besides, having a full compile take ~15 mins encourages programmers to write code well instead of just compile-and-see-what-the-errors are.
No, that's the first line of defence. No-one sets out to write bugged code. Self-review is a good idea but it's pointless duplicating the effort the basic syntactic sanity check compiler can do for you automatically. Once it compiles cleanly *then* you review.
Having slower processors also encourages them to optimise the app that bit more.
Yes and no - the only real win is using efficient algorithms but then an experienced programmer would do that anyway. If you did it right first time then you're only going to squeeze a few percent worth of performance out at the end and that really isn't worth it commercially: extra development cost vs bigger server, delivery deadlines, simplicity->maintainability/ease of testing, etc.
Doesn't it? I mean, instead of optimising software, and making better use of existing systems, the trend is to put faster processors on the market, and write sloppy software.
... writing PHP and MySQL based applications.
For bespoke solutions it's cheaper to buy better hardware to run the solution on than to pay software engineers to optimize it.
No, I'm still using an MMX-200 with 128 megs of RAM for all of my work, and it's not a limitation.
The basic edit and unit testing, sure, but you'd struggle to perform any useful stress, scalability or performance testing on that rig.
Abandoning your morals to follow pointless traditions is not an act of love, but an act of sheer cowardice.
No, it's forcing *your* opinion on her.
If she felt as strongly as you do, she might not want to wear a diamond. But that's her decision.
If you try to tell an intelligent girl how she should think then you're going to have problems.
Approach the subject in a subtle, sensitive way: you might find she agrees with you! But do be willing to back down.
government has no property it is not given by the people
Philosophically or constitutionally?
Huh? Another distro? What could Sun's edge over the others be is what I'm wondering.
I'd imagine they'd tweak available apps and APIs to be as compatible with Solaris as possible.
GNU/Linux: $0/computer
Training and usability aside (dealt with by someone else), you really think consulting companies are going to develop and support OSS for free?
One size does not fit all. Government contracts, even when based around commercial off-the-shelf software, usually need significant development/integration work to get the system right.
If you're using closed-source software, there's some inherent risks that aren't there with open source.
So find a couple of smart employees at the contractor who pass NSA vetting as upright, patriotic citizens and put *them* in charge of the government codebase/release.
Isn't this what keeps happening with sucessive versions of gcc? We're already seeing binary issues with 3.1.x and 3.2 compiled programs.
Only in C++ programs (and C++-compiled runtime libraries, such as libgcj). This is because there were bugs/omissions in the C++ ABI which they couldn't fix in a compatible way. They're not breaking compatibility for the sake of it.
The only plain C per-version issue is the libgcc interface but I think they've largely stabilised that now.
You're not likely to have both 3.1.x and (the not yet released) 3.2 on a (GNU/)Linux system anyway unless you've got a build-from-source distribution - and in that case you can just rebuild everything with 3.2 and be happy.
Since binary incompatibility only affects *C++ programs*
In practical terms, it only affects programs that load dynamic libraries with C++ interfaces. As long as you stick to C-interfaced libraries and you have the correct version of libstdc++ around (which is pretty much tied to a version of g++ so will have the right ABI pretty much automatically) then you should be OK. In the worst case, you just need a separate copy of the libraries built with an old GCC and a wrapper script to set LD_LIBRARY_PATH.
Java compiled to native with gcj may also break since its runtime is built with g++.
with
that has all these weird constants and macros in them with names like '__AFX_DEFINED_DDLXCI_AXWEC_UBER_MACRO_EXCHANGE_D
They're the header include guards - which are sensibly long (they contain a GUID) and easily recognizable.
And you can just pull values out of a dialog box; you have to use this thing called "Direct Data Exchange" that I never really figured out,
Yes you can; you can call 'GetWindowText()' on any control. If you didn't associate a control variable with your dialog then you can call a method on the CDialog object to get an MFC you can call these methods on.
DDX is just a convenience:
- you associate a simple variable with a control (easiest with the ClassWizard0
- before you start reading data you call UpdateData(TRUE)
- you access data in your DDX-associated simple variables
- you call UpdateData(FALSE) if you changed values and want to reflect them back to the display.
It's that simple.and you have all these magic cookies that get defined in some header file somewhere
The Win32 API is constant-heavy. You can't completely escape it and MFC does well to not try.
and you don't even get to write main()
You use InitInstance() in your CWinApp derived object if you need a main() alike. Alternatively, just write UI response code.
all the classes start with the letter 'C' and everything is in hungarian notation
Such is the Microsoft coding convention.
WHERE DO I DRAW STUFF IN MY WINDOW?!
Override OnPaint() in your view object if you really need to - this exactly corresponds to WM_PAINT in non-MFC apps.
I agree, there's also ATL i think that's even worse!!!
There's a learning curve, agreed, but ATL is very powerful if you want a COM implementation that covers all corner-cases and configuration properly. The ATL with VS7 has been beefed up with MFC-style helper classes (CATLStringW, etc.) and is an absolute dream to use. Honest.
MFC might look good in comparison to Visuial Studio which must be one of the worst Dev environments I've ever used
What's wrong with it? IMO, it's a nice editor with a well-integrated (and useful!) source debugger.
All the information is there (if you can find it), but it's highly scatterbrained and disorganized.
The index and search are usually good. You very rarely have to browse the contents for stuff.
Grepping the windows API headerfiles is also very useful.
The API documentations frequently don't explain what parameters are supposed to (or allowed to) contain, and even if they do their frequently listed on a seperate page without any explanation of the meanings for the various values.
I've always found them good in that respect - often equal or better than Solaris man pages, say. (IMO, at first glance the QT docs don't look quite as good, but I will give them a better look.)
Oh, and good, standardised documentation about those COM/COM+ error codes located in a single and easily accessible location? Forget.
You can get most of them from winerror.h (with some description). Alternatively, there's always the error lookup util installed with Visual Studio.
And what is it with those API's on Windows, do they have to typedef _everything_ for every different occasions...
Could it be to support more than a single machine architecture?
I think also to support both 16-bit Windows and Win32 together, although that's more relevant for the base windows headers than MFC.
I don't mind a little opacity on the OS interface. And you often gain meaningful type names too.
(There are a number of examples on Unix, too: e.g. uid_t, pthread_t, etc. But certainly not to the same degree.)
One of Qt's strengths (and a tribute to its design) is how its learning curve is really quite low.
// TODO comments where you plumb in your own code. You can have a simple, fucntional MFC-dialog-application up and running very easily, invoking the MFC API only a few times yourself.
For simple applications, MFC's learning curve is also low - the wizard will generate all the glue code and provide
For an experienced Win32 programmer, MFC's learning curve is pretty much zero (flat?).
The Microsoft Foundation Class (MFC) is a graphical toolkit for the windows operating system. It is a more or less object oriented wrapper of the win32 API, which causes the API to be sometimes C, sometimes C++, and usually an awful mix.
The only non-C++ you could complain about in MFC is the use of some Win32 API structures without containing classes/accessors. Under the circumstances (given the number of them!) I don't think this is too big a deal.
MFC programming requires the use of Document/View model and templates.
No, it doesn't. If you don't want Doc/View, you can just use the MFC-dialog-application template.
I've never seen the other problems you mention:
- you can probably ditch the document/view model (I've never tried) but you can easily bury it if you don't like it and I've never found it inflexible enough to be a hinderance. Cite an example?
- I wouldn't be surprised if splitting a window to show two different documents probably violates the windows UI design guidelines. You can get equivalent function using an MDI app (although I think the guides have deprecated those) or implement a 'document container' class or something. You probably don't need too much imagination.
MFC is a kind of object wrapper allowing access to the windows API,I'd consider this a plus - lean (or as lean C++ as you'll get), efficient (ditto) and feature-complete.
And there are nasty tricks, without any consistency. For example, if you create a graphical object, it is not created until the Create() methods has been called. For dialogs, you must wait for OnInitDialog, for views, you wait for OnInitialUpdate,
No. This *is* consistent and logical. And OO.
- When you create a CDialog, you create a container class for a window handle with dialog-like methods. You may set up the initial state of the dialog, member variables of the container class, etc. But because you have an empty handle you can't actually play with the dialog yet.
- You Create() or DoModal() your CDialog object. Now the windows is actually generated on the desktop and the window handle is filled.
- You're called back in the OnInit* method to set any state on the window as it is created. You may now call methods that require a window handle.
I don't think MFC will crash - I think it'll give you a useful debug assert. But I haven't fallen into that trap for a while.MFC is full of these nasty tricks. And it is hard to debug.
'nasty tricks' is a little extreme. MFC integrates very well with Visual Studio's debugger and is relatively simple to debug. You're provided with the source code to step through if you need it. I've never had any trouble.
Qt is based upon a powerful callback mechanism based on signal emission and reception inside slots.
This sounds exactly like the Windows message model that you've just slammed (!). I don't see any problems with the windows message model - but then I'm familiar with the API.
The interface creation section: DDX and IMPLEMENT_DYNCREATE (why do you need that for your UI?) are relatively easy to understand - maybe try Prosise's book if you need enlightenment. You don't need to touch the message loop - it's buried in the MFC DLL and covers all cases. You can quite happily manufacture dialogs at run-time by calling Create() on control objects in the OnInitDialog() method.
Qt designer lets you do things that are not possible in MFC, like creating a listview with pre-filled fields, or using a tab control with different views on each tab.
Pre-filling a list view should be done in OnInitDialog(); the interface is quite simple.
Tabs are a different matter; you need to create child dialogs for each separate pane. This closely reflects what's going on in the OS API. It's not too difficult and there are good sample applications. Alternatively, there's a very simple interface to create complex property pages already provided.
Visual's documentation, MSDN (for which you must pay separately) is huge, on 10 CDROM.
It's no more than 3 CDs. It's bundled with Visual Studio. It's available online at http://msdn.microsoft.com/library/. And it's very good, complete documentation.
MFC's unicode is very easy. If you need to change the entry point of your application then you're doing it wrong; you probably need to change
If you're given non-unicode third party library then the third party ought to be able to supply a unicode version by changing a few flags and rebuilding. I'd be surprised if many vendors couldn't supply Unicode libraries if you asked them.
Resources and string-tables are part of the Win32 API. I find them useful and easy to program for. You have to try quite hard to load resources from the wrong DLL; all resources are indexed on exe/dll module handle as well as resource ID.
Latest MFC DLL: you should always ship the one you develop and test against! Win2K+ allows you to install a copy of the DLL local for your application. Alteratively, there are simple-ish mechanisms to auto-download the latest MFC from Microsoft.
To address some of your list of QT advantages,
- Controls... MFC uses native OS widgets which is arguably an advantage for Win32 programs: correct look and feel and always do exactly what a Windows user would expect.
- MFC does provide classes for network and database access
- Memory management shouldn't be a problem; if you create controls as members of the containing dialog class then they'll be destroyed automatically too. MFC's debug memory allocator is good, too.
I've never used CodeJock.And yes: it is true that CVS-style revision numbers implicitly show you branch points. But they're on a per-file basis. In SVN, you can say at a high-level "branch FOO was created from revision 1234 of /trunk".
Yes: I was suggesting that on a branch level, i.e. you then number revisions on branch FOO 1234.1, 1234.2, etc.
On the other hand, I can see the 'simpler is better' argument too. And I'd (somehow) mistakenly thought I'd have to check branches with 'svn log' individually per file rather than per repository.
I think that answers all your questions/concerns!
Pretty much. Thanks for all your trouble!
Greg points out that branches can live under a '/branch/' root - which goes some way to addressing this if everyone's working against trunk, but if we're working on a branch as a matter of course (e.g. stabilising a release) then it doesn't really help.
except I now see that this is a filesystem recommendation rather than server enforced, so I can happily keep my stuff under '/xbranch/rup/' or something, well out of everyone's way. Excellent.
I'm now far more sold on subversion than I was this time yesterday - although my other issues in parent post still stand.