Re: Nomenclature for interger size in C/C++
"Giuliano Bertoletti" <gbe32241@libero.it>
Just started from scratch a dummy project with VC2005.
It appears that he has troubles compiling the following code:
CString msg = "Simple message box.";
AfxMessageBox(msg,MB_ICONINFORMATION);
complaining that:
testmfcdlg.cpp(158) : error C2440: 'initializing' : cannot convert from
'const char [20]' to 'ATL::CStringT<BaseType,StringTraits>'
Googling around I found that a CString in VC2005 is a completely different
beast respect to VC6.
With some trial and error, I found that put in this way it compiles:
CString msg("Simple message box.");
AfxMessageBox(msg,MB_ICONINFORMATION);
Copy-init was discouraged wrt direct init for like 15 years... Though this
suboptimal code should still compile.
In VS2008 it does without problem.
Did you apply the latest service pack to your VS2005? The error message
implies it is hit by an archaic defect report, it should be corrected.
Now the point is: shall I really dig into the new CString
code/documentation to see what it is and up to which point is reasonable
to expect the same behaviour as the old CString ?
If starting a port like this I'd certainly pick the latest version of the
compiler, not just one on the road. The work effort is about the same, and
I'd lose 3 years difference for the next such update, and the new features
too.
I had some fear too, and still have VC6 installed, but didn't feel like
launch it for some time.
Even new applications written from scratch benefit using my older
routines which have a lot of miles under their wheels and you know they
work fine.
No, they don't always do.
The example above suggests that a CString needs adaption.
I'd put that aside until we know it is a bug or a feature of that compiler
stepping.
Once adapted, you'd probably loose compatibility with the older compiler
(unless you work at the intersection of the two, meaning in that case
loosing functionality).
I don't recall such changes from the conversion. Certainly after you start
work differences will slip in. At a time we were using 5.0 and 6.0 side by
side, and I was fighting to keep 5.0 compatibility. Though they used almost
the same version of MFC it became a nuisance.
The new MFC is completely rewritten in form. So the applcation code will
devert. Guess you can still keep 'libraries' to compile both ways, if they
are not changing much.
Sacrificing compatibility means you either upgrade at once all the modules
relaying on that code or branch and keep two separate versions.
Both have negative ramifications that need to be evaluated before stepping
forth.
Sure, did I say it has no costs of any kind? But just listing the costs of
conversion does not mean necessarily they are less than the lock-in. The
price of which is easy to overlook or deny.
Learning how to program a GUI is also a very expensive task in terms of
time and I would stick to Windows-MFC if possible, which is a good
compromise in availability, functionality, compatibility and resources
requirements (that's of course only my personal opinion, I know many of
you would argue otherwise).
However MFC is badly supported by new compilers that are oriented to
.NET framework.
What you mean badly? Maybe badly comparing to their support of other
stuff, but not worse than VC6.
If this were true, I would opt for staying with the old, bad but known
stuff rather than diving in the old, equally bad and unknown stuff.
So you admit that your arguments are not really meand, just attempting to
fight cognitive dissonance? You have the verdict before listening the
witnesses.