Nomenclature for interger size in C/C++
Giuliano Bertoletti
Hello,
I was just wondering if there's a standard nomenclature which forces any
C/C++ compiler to instantiate integer variables of a givens size.
For example suppose my program wishes to deal with a 64-bit integer.
Assuming that a platform/compiler supports it, how shall I instantiate a
variable of that size.
I usually typedef under MSVC++ something like:
typedef __int64 WORD64;
and then instntiate
WORD64 v;
but I would like to have such a definition on a standard header file
which won't forces me to #ifdef depending on the platform and most
importantly not use WORD64 but something recognized universally.
Is there such a definition somewhere ?
Regards,
Giuliano Bertoletti.
Ian Collins
>
> Hello,
>
> I was just wondering if there's a standard nomenclature which forces any
> C/C++ compiler to instantiate integer variables of a givens size.
Use the widely supported C99 fixed width types (int64_t and friends)
from stdint.h.
--
Ian Collins
Giuliano Bertoletti
Thanks.
My MSVC++6.0 compiler is older than 1999 and doesn't know anything about
stdint.h. Anyway I found a portable stdint.h so at least types are standard.
By the way, is the suffix i64 standard for the 64-bit integer constant ?
For example, should I expect this to compile everywhere ?
int64_t v;
...
v |= (1i64 << 48); // set bit 48
Regards,
Giuliano Bertoletti.
Ian Collins
> Ian Collins ha scritto:
>> Giuliano Bertoletti wrote:
>>>
>>> Hello,
>>>
>>> I was just wondering if there's a standard nomenclature which forces
>>> any C/C++ compiler to instantiate integer variables of a givens size.
>>
>> Use the widely supported C99 fixed width types (int64_t and friends)
>> from stdint.h.
>>
>
> Thanks.
>
> My MSVC++6.0 compiler is older than 1999 and doesn't know anything about
> stdint.h. Anyway I found a portable stdint.h so at least types are
> standard.
It's older than C++98 as well. Well passed its use by date.
> By the way, is the suffix i64 standard for the 64-bit integer constant ?
No, the closest (again from C99) would be 'LL' (long long is at least 64
bits).
--
Ian Collins
Arne Mertz
"whithout resorting to undefined behaviour in terms of the 1998 C++
Standard."
http://www.boost.org/doc/libs/1_38_0/libs/integer/index.html
Arne
Vaclav Haisman
> Ian Collins ha scritto:
>> Giuliano Bertoletti wrote:
>>>
>>> Hello,
>>>
>>> I was just wondering if there's a standard nomenclature which forces
>>> any C/C++ compiler to instantiate integer variables of a givens size.
>>
>> Use the widely supported C99 fixed width types (int64_t and friends)
>> from stdint.h.
>>
>
> Thanks.
>
> My MSVC++6.0 compiler is older than 1999 and doesn't know anything about
> stdint.h. Anyway I found a portable stdint.h so at least types are
> standard.
Boost ships with cstdint.hpp header that is basically reimplentation of C99
stdint.h in C++. It has very little dependencies on the rest of the Boost,
you should be able to use it nearly stand alone.
>
> By the way, is the suffix i64 standard for the 64-bit integer constant ?
No, it is not.
>
> For example, should I expect this to compile everywhere ?
>
> int64_t v;
> ...
> v |= (1i64 << 48); // set bit 48
No, you should not.
--
VH
Giuliano Bertoletti
>>
>> My MSVC++6.0 compiler is older than 1999 and doesn't know anything about
> Throw it away and burn it.
>
I would but I cannot.
I've a lot of code which has been written with and for that compiler;
migrating it even to a new compiler of the same brand would mean a lot
of effort in re-compiling and testing.
Not to mention the time it takes to get you accustomed to the new
compiler/IDE interface.
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.
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.
Regards,
Giuliano Bertoletti.
Victor Bazarov
> Vaclav Haisman ha scritto:
>
>>>
>>> My MSVC++6.0 compiler is older than 1999 and doesn't know anything about
>> Throw it away and burn it.
>>
>
> I would but I cannot.
>
> I've a lot of code which has been written with and for that compiler;
> migrating it even to a new compiler of the same brand would mean a lot
> of effort in re-compiling and testing.
>
> Not to mention the time it takes to get you accustomed to the new
> compiler/IDE interface.
So, instead of learning to drive and operate a new, clean, fast,
spacious, and otherwise modern vehicle, you'd rather drive the old,
smoldering, slow, rusty, falling apart, not to mention incapable of
fulfilling some of your requirements, clunker? Good for you. And the
users of your program. I am guessing you've not got many, and the ones
you do have, keep their balls in your capable hands (NTTIAWWT).
> 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.
If they work fine, they would work just as fine compiled with a more
modern compiler. Why would you thing they are going to start failing?
Is that because they are held together with a piece of old twine and a
prayer?
> 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).
Nope. Why argue with you? You seem to have formed your opinion way
before you came here, and are not going to change it no matter how
logical or sensible our argument can be.
MFC is still supported by the most modern of Visual C++ incarnations.
Most of older programs don't require much attention. Yes, you need to
port (to straighten out the code you had to write to overcome the
deficiencies of the pre-Standard compiler and its library), yes, you
need testing. Are you sure you don't need all that with any change
you're trying to squeeze into your code made in and for that severely
out of date compiler?
> However MFC is badly supported by new compilers that are oriented to
> .NET framework.
Nonsense. You've apparently not been keeping up, so your opinion can't
really count, can it? Post your questions/concerns to the newsgroup
'microsoft.public.vc.language' or 'microsoft.public.vc.mfc' and see what
reaction you get.
Good luck!
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Victor Bazarov
Boost still suports VC6? Wow... Those guys *are* generous.
Arne Mertz
> Arne Mertz wrote:
>> Ian Collins schrieb:
>>> Giuliano Bertoletti wrote:
>>>>
>>>> Hello,
>>>>
>>>> I was just wondering if there's a standard nomenclature which forces
>>>> any C/C++ compiler to instantiate integer variables of a givens size.
>>>
>>> Use the widely supported C99 fixed width types (int64_t and friends)
>>> from stdint.h.
>>>
>> Or use boost::integers that is designed to do the same job "whithout
>> resorting to undefined behaviour in terms of the 1998 C++ Standard."
>>
>> http://www.boost.org/doc/libs/1_38_0/libs/integer/index.html
>
> Boost still suports VC6? Wow... Those guys *are* generous.
>
> V
prehistoric artifact. But yes, Boost kind of supports VC6, mainly by
disabling tons of features that rely on the parts of standard C++
VC6 is not capable to compile.
I have not dug deep enough into the boost::integer headers to find
out how much of the features will be turned off for VC6, but luckily
I have no need nor intention to ever use that compiler.
Arne
Giuliano Bertoletti
>
> So, instead of learning to drive and operate a new, clean, fast,
> spacious, and otherwise modern vehicle, you'd rather drive the old,
> smoldering, slow, rusty, falling apart, not to mention incapable of
> fulfilling some of your requirements, clunker? Good for you. And the
> users of your program. I am guessing you've not got many, and the ones
> you do have, keep their balls in your capable hands (NTTIAWWT).
>
You're making assumptions and jump to conclusion without enough information.
It's a matter of trade-offs. I've nothing against new compilers but the
question you may ask yourself is: should I invest time in learning how
to use that new compiler and then port my application or should I keep
developing features with what I have ?
In my opinion it weights much more in the decision the need for some
specific library that may not work with the current version used rather
than conformity to standards (I can easily bypass the int64_t issue, it
was just a curiosity).
When I speak of libraries I mean something substantial which is unlikely
you might develop or workaround easily (for example a library for
editing .pdf files which you would treat as a black-box).
>
> If they work fine, they would work just as fine compiled with a more
> modern compiler. Why would you thing they are going to start failing?
> Is that because they are held together with a piece of old twine and a
> prayer?
>
No, it's not a matter of code being brittle. It's that porting a project
costs and may expose you to problems with an otherwise working system.
If your software is mission critical and a failure (or even a delay in
delivery a new version) can cost you money, then you've better think
twice before upgrading. Unless of course you're forced to.
> MFC is still supported by the most modern of Visual C++ incarnations.
> Most of older programs don't require much attention. Yes, you need to
> port (to straighten out the code you had to write to overcome the
> deficiencies of the pre-Standard compiler and its library), yes, you
> need testing.
Porting and testing are not always minor nuissances. They're often major
stumbling blocks. Especially if you're working in a team and you've not
written yourself all the code.
>> However MFC is badly supported by new compilers that are oriented to
>> .NET framework.
>
> Nonsense. You've apparently not been keeping up, so your opinion can't
> really count, can it? Post your questions/concerns to the newsgroup
> 'microsoft.public.vc.language' or 'microsoft.public.vc.mfc' and see what
> reaction you get.
>
Modern MS compilers are implicitly discouraging the use of MFC. The GUIs
are heading toward managed code (C#, VB, etc.) which offer better
development time and features richness in exchange for bloated and
slower applications.
This may or may not be ok, but that's where MS is heading to.
In the VS9 presentation, they refer to the C++ compiler as a great tool
to develop games.
Back to MFC, they lack for example the ClassWizard which is an handy
tool for developing MFC based classes. Sure, you can write the code by
hand, define all the marco yourself and so on. Is it worth ?
Again, the anwser is not obvious.
Regards,
Giuliano Bertoletti.
Thomas J. Gritzan
> Victor Bazarov ha scritto:
>>> However MFC is badly supported by new compilers that are oriented to
>>> .NET framework.
>>
>> Nonsense. You've apparently not been keeping up, so your opinion
>> can't really count, can it? Post your questions/concerns to the
>> newsgroup 'microsoft.public.vc.language' or 'microsoft.public.vc.mfc'
>> and see what reaction you get.
>>
>
> Modern MS compilers are implicitly discouraging the use of MFC. The GUIs
> are heading toward managed code (C#, VB, etc.) which offer better
> development time and features richness in exchange for bloated and
> slower applications.
Microsoft noticed that MFC and native C++ is still widely used and
released an update to MFC a year ago:
"On April 7, 2008, Microsoft released an update to the MFC classes as an
out-of-band update to Visual Studio 2008 and MFC 9."
"The MFC application wizard has also been upgraded to support the new
features"
http://en.wikipedia.org/wiki/Microsoft_Foundation_Class_Library
> This may or may not be ok, but that's where MS is heading to.
> In the VS9 presentation, they refer to the C++ compiler as a great tool
> to develop games.
>
> Back to MFC, they lack for example the ClassWizard which is an handy
> tool for developing MFC based classes. Sure, you can write the code by
> hand, define all the marco yourself and so on. Is it worth ?
Q7: Where is ClassWizard in Visual Studio .NET and in Visual Studio 2005?
Answer:
http://support.microsoft.com/?scid=kb%3Ben-us%3B313981
When you still use VC6 from 10 years ago, you don't profit from the
better optimizations today's compiler can do for you.
--
Thomas
Giuliano Bertoletti
>
> Microsoft noticed that MFC and native C++ is still widely used and
> released an update to MFC a year ago:
>
> "On April 7, 2008, Microsoft released an update to the MFC classes as an
> out-of-band update to Visual Studio 2008 and MFC 9."
>
> "The MFC application wizard has also been upgraded to support the new
> features"
>
I'm not saying that MFC isn't updated or supported.
But, new Visual Studios are heading toward other directions and that's a
fact.
More than the library itself, the tools that support the development are
important. These tools are nowhere experiencing the steady development
and increase in functionality that other tools had.
> Q7: Where is ClassWizard in Visual Studio .NET and in Visual Studio 2005?
> Answer:
> http://support.microsoft.com/?scid=kb%3Ben-us%3B313981
>
It says that ClassWizard is not present and that *some* (but not all) of
the functionalities are carried out by other tools.
What if the missing are the ones you use most ?
> When you still use VC6 from 10 years ago, you don't profit from the
> better optimizations today's compiler can do for you.
>
Of course, what you guys seems not to realize is that this has a price
which may not be small.
Let's take another point view (I'm making up the story).
Suppose you're the boss of a small firm which delivers software in a
highly specialized field (say, structural engineering).
Your application has evolved over a decade and reached a steadly gross
revenue of $200,000 per year including new customers and maintenance.
The incomes allowed you to hire two programmes which work with you full
time. One day one of them comes up with the idea of upgrading the
compiler for increased benefits, although it's not immediately clear
which they are.
You perform a quick analysis and estimate the time in 3 months to
migrate the application and another 2 months for testing that everything
it's fine. It may be safe to account for another month due to Murphy's law.
Conclusion, you forecast a six months stop in development due to
code/environment migration and testing, which translates roughly in a
$100,000 cost.
You quickly realize that one or probably both programmers will loose
their job if you agree with the upgrade.
Would you still believe it's worth profitting the better optimization
today compilers can do for you ?
Regards,
Giuliano Bertoletti.
Balog Pal
>>> My MSVC++6.0 compiler is older than 1999 and doesn't know anything about
>> Throw it away and burn it.
>
> I would but I cannot.
>
> I've a lot of code which has been written with and for that compiler;
> migrating it even to a new compiler of the same brand would mean a lot of
> effort in re-compiling and testing.
I suggest it is well worth the effort. And unless you used weirdo code, make
it compile should not be a big deal. Certainly testing the results is an
effort if you don't have autotest coverage.
> Not to mention the time it takes to get you accustomed to the new
> compiler/IDE interface.
Come on, the interface is very similar, and if you're so addicted to the old
it can be even recreated. But it is completely intuituve and usable without
problem out of the box. And benefit from both the new features and the
compiler.
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.
And what is the problem here -- they keep working. I had to insert a
couple of 'typename'-s here and there. And remove my #define for hack
finally ;-).
> 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.
Ian Collins
>
> It's a matter of trade-offs. I've nothing against new compilers but the
> question you may ask yourself is: should I invest time in learning how
> to use that new compiler and then port my application or should I keep
> developing features with what I have ?
The time for that question is long past. If you had moved on sooner and
had decent validation tests, you wouldn't be in this mess.
--
Ian Collins
Giuliano Bertoletti
> "Giuliano Bertoletti" <gbe3...@libero.it>
>
>>>> My MSVC++6.0 compiler is older than 1999 and doesn't know anything about
>>> Throw it away and burn it.
>
> it compile should not be a big deal. Certainly testing the results is an
> effort if you don't have autotest coverage.
>
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);
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 ?
> 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. 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).
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.
>> 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.
Regards,
Giuliano Bertoletti
Vaclav Haisman
stop maintaining old code. This can be done in parallel with normal
development. What you do is that you create parallel projects for VC9 out of
the VC6 projects. Getting things to compile usually requires only very little
editing. Even huge projects with millions of lines of code usually take only
very little tweaking for the code to become compilable. This might take a
week or two, not months. In the mean time, you keep working on new features
and bug fixes using your old VC6 tools but you also keep checking that the
changes you have made do not break with the new tools. In fact, IME it is
even better to do new development in with the new tools and keep checking
that you do not break things because you have accidentally used some C++
feature that VC6 does not implement (for(;;) induction variable scoping
etc.). You can argue this can slow down your development, that's true, but
you do not need to switch big bang style all your tools at once and it
definitely does not take 6 months to convert. Moving to VC8+ has one huge
advantage from your employees point of view: You help your employees to keep
their sanity. I find it extremely hard to work with the VC6-not-C++ language.
It is as if becoming Tantalus. No developer deserves that.
--
VH
Giuliano Bertoletti
I'm not considering this a mess. The code compiles just fine and I've no
reason to believe that the machine code generated is buggy.
I might not be able to use the latest C++ constructs, but that's a price
I can afford (for now).
I disagree to blindly upgrade just because of new functionalities if you
don't need them or - even worse - you don't even know which they are.
On the other hand, if you're practicing, that's perfectly normal to
catch up with the latest available technology.
Regards,
Giuliano Bertoletti
Bo Persson
> Balog Pal ha scritto:
>> "Giuliano Bertoletti" <gbe3...@libero.it>
>>
>>>>> My MSVC++6.0 compiler is older than 1999 and doesn't know
>>>>> anything about Throw it away and burn it.
>>
>> I suggest it is well worth the effort. And unless you used weirdo
>> code, make it compile should not be a big deal. Certainly
>> testing the results is an effort if you don't have autotest
>> coverage.
>
> 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>'
>
So you have now found that the default compiler settings are not the
same as the ones you have used for the last 10 years. Is that enough
for you to give up?
Bo Persson
Balog Pal
> 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.
Giuliano Bertoletti
>> You quickly realize that one or probably both programmers will loose
>> their job if you agree with the upgrade.
>>
>> Would you still believe it's worth profitting the better optimization
>> today compilers can do for you ?
> This is total bullshit. You do not have to stop developing new features or
> stop maintaining old code. This can be done in parallel with normal
> development.
We may discuss whether my estimates are a bit too pessimistic, but once
we estabilish that it takes N days to upgrade and test (provided the
forecast is correct), that is the time (not less, possibly more).
It really doesn't matter how you interleave the upgrading with the
development time or even how you divide the work among programmers.
At the end of the year, N days (or more due to task switch overhead)
have been consumed for the upgrade.
> What you do is that you create parallel projects for VC9 out of
> the VC6 projects. Getting things to compile usually requires only very little
> editing. Even huge projects with millions of lines of code usually take only
> very little tweaking for the code to become compilable.
- First, compilable doesn't mean it'll work.
Suppose I somewhere serialize a structure to disk like this:
fwrite(&mys, 1, sizeof(mys), h1); // C struct serialization
are you sure the new compiler packs the structure in the same way ?
This is a potential problem which goes unnoticed at compile time.
You may object, I should have not serilized the struct that way in the
first place.
Maybe, but if for example I serialize each member I would probably loose
efficiency (repeated calls to the OS) which may or may not be critical.
Again, it's a choice.
- Second, troubles often come with automatically generated code which
makes heavy use of macros that I have ignored all along because it
worked as expected and never caused problems.
Once I realize the prototypes of the new compiler are different, I may
be forced to look at what that code really does and find proper workarounds.
- Third you may also consider potential problems in my code that never
showed up with the old compiler and may be triggered by the new (due for
example to a different memory layout).
Yes, I know that would be problems of my code and not the compiler.
But let's face reality: I wrote the code, I and my customers tested it
for a decade. It works and we're satisfied.
Then I change the compiler and hope... What for?
- Fourth, you're assuming that I'm mastering both the new and the old
tools and for every problem I face, I choose the best solution at
disposal. But the new compiler is new...
> This might take a
> week or two, not months. In the mean time, you keep working on new features
> and bug fixes using your old VC6 tools but you also keep checking that the
> changes you have made do not break with the new tools. In fact, IME it is
> even better to do new development in with the new tools and keep checking
> that you do not break things because you have accidentally used some C++
> feature that VC6 does not implement (for(;;) induction variable scoping
> etc.).
Until you give up compatibility you're working at the intersection of
functionalities with no real gain.
Once you give up compatibility you end up with bloated code that need to
be removed.
Better to stop and upgrade; this is the minimum effort path.
> You can argue this can slow down your development, that's true, but
> you do not need to switch big bang style all your tools at once and it
> definitely does not take 6 months to convert.
Even if you carry out all the work in just one month - tests included,
it would still cost $16,000 according to the example above.
I'm not saying it's never worth the effort, but I would like to see more
detailed statements about supporting the upgrade rather than simply:
"the compiler works better, has many more features and is compliant with
the standard".
Which features ? Do we need them ?
These are the first questions you face when you step that way.
> Moving to VC8+ has one huge
> advantage from your employees point of view: You help your employees to keep
> their sanity. I find it extremely hard to work with the VC6-not-C++ language.
> It is as if becoming Tantalus. No developer deserves that.
>
I would be much more worried about the lack of new substantial libraries
rather than the language standardization.
Regards,
Giuliano Bertoletti.
Vaclav Haisman
> Ian Collins ha scritto:
>> Giuliano Bertoletti wrote:
>>>
>>> It's a matter of trade-offs. I've nothing against new compilers but
>>> the question you may ask yourself is: should I invest time in
>>> learning how to use that new compiler and then port my application or
>>> should I keep developing features with what I have ?
>>
>> The time for that question is long past. If you had moved on sooner
>> and had decent validation tests, you wouldn't be in this mess.
>>
>>
>
> I'm not considering this a mess. The code compiles just fine and I've no
> reason to believe that the machine code generated is buggy.
>
> I might not be able to use the latest C++ constructs, but that's a price
> I can afford (for now).
constructs that are valid C++ about 10 years now. What is worse, you cannot
even use C++ constructs as simple assignment of std::string, since its
implementation is buggy wrt/ threads in VC6.
>
> I disagree to blindly upgrade just because of new functionalities if you
> don't need them or - even worse - you don't even know which they are.
>
> On the other hand, if you're practicing, that's perfectly normal to
> catch up with the latest available technology.
--
VH
Giuliano Bertoletti
> It is not that you cannot use latest C++ constructs. You cannot use C++
> constructs that are valid C++ about 10 years now.
I guess you're right. But what are these constructs ?
The ones presented in Alexandrescu's book: "Modern's Design Patterns in
C++" for example ?
Well, I highly respect that book and the author. I found its reading
very interesting and illuminating. I'm very happy that such a book exists.
Still I've never found a practical use for that code. Mostly because
it's difficult to fully master templates at such level and once you do,
you ask yourself: "...and now what?"
That book delivers the knowledge but not the experience which allows to
use such a constructs. One thing is to use them because they're cool,
another because you need them.
> What is worse, you cannot
> even use C++ constructs as simple assignment of std::string, since its
> implementation is buggy wrt/ threads in VC6.
>
I've never shared an std::string among multiple threads and I wasn't
aware of the problem. Anyway, I'm pretty sure that upon facing such a
scenario I would have asked myself: "Is STL thread safe ?".
It's difficult to prove, but I think I would have answered myself: "I've
never seen mentioning thread safety in STL, nor in C++" and then I would
have played on the safe side and synchronized the access myself.
Maybe my answer isn't satisfying, I understand, but frankly speaking I
would not consider that scenario a pitfall I were likely to fall in.
On the other hand, one strong point in which I will probably upgrade, is
when Win64 applications become the norm.
Regards,
Giuliano Bertoletti.
Giuliano Bertoletti
>
> So you have now found that the default compiler settings are not the
> same as the ones you have used for the last 10 years. Is that enough
> for you to give up?
>
Well, I actually never gave in. :-)
Jokes aside, that was just an example of how you can easily get in
troubles when you venture in a new path. And these were the first two
lines ever written in an MFC VC2005 project.
I swear I was not aware of such a problem until I got the error and in
no way I pushed the compiler toward a known pitfall.
I'm pretty sure there exist plenty of solutions: maybe a service pack,
maybe a compiler switch, etc.
My main objection is not that upgrading is always bad, I'm mainly
against the contrary, i.e.: upgrading is always good.
Regards,
Giuliano Bertoletti
Giuliano Bertoletti
>
> 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.
>
Compiled with VC2005 SP1. I'm not aware of the existence of any SP2.
I won't think it's a bug anyway. It would be far too obvious, a CString
is a foundamental component in MFC.
>
> 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.
Which doesn't mean necessarily the opposite either: i.e that they are
more than the lock-in.
As I suggested in a previous post, it has to be evaluated case by case.
>> 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.
>
I never tried newer features of MFC in VC8/9. I would have been happy if
they just kept compatibility with older system, but they didn't and
porting was required.
I've managed, just out of curiosity, to attempt to convert some basic
projects but the plethora of errors I received was enough to discourage
me to stand the effort. Plus I read somewhere (long ago) that MS was
slowly abandoning MFC framework and promoting .NET.
Frankly I do not think there can be only one verdict for everyone.
I only exposed my concerns regarding the upgrading, concerns that were
obviously related to my own projects. I never stated that everyone
should follow me.
Regards,
Giuliano Bertoletti.
Balog Pal
> Suppose I somewhere serialize a structure to disk like this:
>
> fwrite(&mys, 1, sizeof(mys), h1); // C struct serialization
>
> are you sure the new compiler packs the structure in the same way ?
This is conidered dangerous at original design phase for the very reason. If
a system choses that, it uses safeguards around (i.e. #pragma pack with
ensurance it has compiler support, test cases to verify sizes and read/write
known files with verification...)
Even with the same compiler the packing strategy can be adjusted by command
line switch (per file!) or a #pragma pack accidentally picked up from an
early include.
> This is a potential problem which goes unnoticed at compile time.
Your current project carries that danger if it is so. Porting adds little
new danger.
> You may object, I should have not serilized the struct that way in the
> first place.
Not *blindly*, hoping it will just work.
> Maybe, but if for example I serialize each member I would probably loose
> efficiency (repeated calls to the OS) which may or may not be critical.
Not likely measurable, unless your serialisation is ineffective to start
with, or extreme case dumping megabytes having directly in one structure.
Normally you want to serialize out to a buffered file, and the cost of more
function calls is way less than the actual i/o of the buffer flush.
> Again, it's a choice.
It is, but between what, as told before, bnary bump is not forbidden just
shall be reinforced.
> - Second, troubles often come with automatically generated code which
> makes heavy use of macros that I have ignored all along because it worked
> as expected and never caused problems.
>
> Once I realize the prototypes of the new compiler are different, I may be
> forced to look at what that code really does and find proper workarounds.
If those are MFC macros defined in MFC headers, they work the same
semantics, don't they.
Sure if you have a set of hand-crafted macros, they count like normal code.
But at least can be done at one place.
> - Third you may also consider potential problems in my code that never
> showed up with the old compiler and may be triggered by the new (due for
> example to a different memory layout).
You mean existing code has undefined behavior masked by black magic, and you
hope the actual behavior is 'just fine'? Unless you have a proof in
design of the behavior (what would trivially help porting) it is just unfair
(IMHSHO) to push such thing to production and end user.
> Yes, I know that would be problems of my code and not the compiler.
> But let's face reality: I wrote the code, I and my customers tested it for
> a decade. It works and we're satisfied.
Well, if they are truly satisfiesfied -- and not just suffering silently
form the same lock-in.
In my practice I met many situations where 'customer satisfection' brought
very different results if you asked a manager who paid for the stuff and the
users in everyday work.
Normally testing is activity made not by the customer either...
Balog Pal
> It is not that you cannot use latest C++ constructs. You cannot use C++
> constructs that are valid C++ about 10 years now. What is worse, you
> cannot
> even use C++ constructs as simple assignment of std::string, since its
> implementation is buggy wrt/ threads in VC6.
You don't use stl with VC6, so that is not a practical problem. (especially
not mixed with MFC)
Balog Pal
>> [CString direct vs copy init from "ss"]
>
> Compiled with VC2005 SP1. I'm not aware of the existence of any SP2.
> I won't think it's a bug anyway. It would be far too obvious, a CString is
> a foundamental component in MFC.
Then possibly as the other post mentioned, you may have unicode setting or
something. It is weird in any case, as either both ot neither forms should
compile for a copyable type as CString...
>> 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.
>
> Which doesn't mean necessarily the opposite either: i.e that they are more
> than the lock-in.
>
> As I suggested in a previous post, it has to be evaluated case by case.
Sure, definitely.
>>> 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.
>>
>
> I never tried newer features of MFC in VC8/9. I would have been happy if
> they just kept compatibility with older system, but they didn't and
> porting was required.
>
> I've managed, just out of curiosity, to attempt to convert some basic
> projects but the plethora of errors I received was enough to discourage me
> to stand the effort. Plus I read somewhere (long ago) that MS was slowly
> abandoning MFC framework and promoting .NET.
MS changes mind on such stuff. Around '96 they were decided to not support
C++ and go another way. (VC6.0 is the end-product of that era...) Then found
standard C++ is worth support after all, and made 7.0 approximatin, 7.1
pretty close. And on the same track ever since. While working on C++/CLI
top speed on another task.
MFC looks like a similar story, at least hard to understand OOB update any
other way.
> Frankly I do not think there can be only one verdict for everyone.
There isn;t and shouldn't. Just common observations suggest staying with
the past becomes increasingly painful. I am generally in the camp of 'stay
with what works' and don't even consider brand new stuff immediately, but
wait others to find the mines and join after a SP or too. And switch
versions jumping over several. (I.e I still use office'97, switched ftom
NT4 to XP around 2004 etc...)
And definitely would not suggest switching away from VS6 in 2004, when it
had all the same attributes. But by now it is aged too far, and the new
stuff went forward too much. And if your project will be around next year,
and planned live for a few more, and especially adding new featires, I'm
failry convinced you will lose out on staying, even without knowing many
details. (If you consider it by end of life, sure, why bother.)
> I only exposed my concerns regarding the upgrading, concerns that were
> obviously related to my own projects. I never stated that everyone should
> follow me.
Ok.
You know that VS2008 professional is available for DL as a 90 day trial? You
may try to install it as experiment and try conversion. I didn't use 2005
for a second, it may be far behind in addressing your kind of problem.
Vaclav Haisman
> <http://support.microsoft.com/kb/813810>.
More of fun reading on similar note: <http://support.microsoft.com/kb/172396>
--
VH
Vaclav Haisman
> Vaclav Haisman ha scritto:
>
>> It is not that you cannot use latest C++ constructs. You cannot use C++
>> constructs that are valid C++ about 10 years now.
>
> I guess you're right. But what are these constructs ?
::new can return NULL is terrible.
> The ones presented in Alexandrescu's book: "Modern's Design Patterns in
> C++" for example ?
>
> Well, I highly respect that book and the author. I found its reading
> very interesting and illuminating. I'm very happy that such a book exists.
>
> Still I've never found a practical use for that code. Mostly because
> it's difficult to fully master templates at such level and once you do,
> you ask yourself: "...and now what?"
>
> That book delivers the knowledge but not the experience which allows to
> use such a constructs. One thing is to use them because they're cool,
> another because you need them.
You do not have to use them yourself. You are limiting yourself from using
libraries that use them in their implementation.
>
>
>> What is worse, you cannot
>> even use C++ constructs as simple assignment of std::string, since its
>> implementation is buggy wrt/ threads in VC6.
>>
>
> I've never shared an std::string among multiple threads and I wasn't
> aware of the problem. Anyway, I'm pretty sure that upon facing such a
> scenario I would have asked myself: "Is STL thread safe ?".
You are apparently not aware of the bug. The scenario is like this: You have
a string A and you create a copy B = A, everything in a single thread. Now,
you would expect those two to be completely separate and that you can use
each in separate threads independently. Well, guess what, VC6 uses reference
counted std::string which does not lock the reference count
increment/decrement operation. Sooner or later (on boxes with multi core CPUs
sooner), VC6 compiled application will fuck up the reference count which
usually results in segfault and crash. See
<http://support.microsoft.com/kb/813810>.
>
> It's difficult to prove, but I think I would have answered myself: "I've
> never seen mentioning thread safety in STL, nor in C++" and then I would
> have played on the safe side and synchronized the access myself.
>
> Maybe my answer isn't satisfying, I understand, but frankly speaking I
> would not consider that scenario a pitfall I were likely to fall in.
>
> On the other hand, one strong point in which I will probably upgrade, is
> when Win64 applications become the norm.
--
VH
Giuliano Bertoletti
Why not ? With the latest service pack STL works just fine (at least on
a single thread) with MFC.
I also use multithreading, but did never stumble on the std::string
reference counting issue because the model adopted is the worker thread
doing a long job and the main thread responding to user inputs (usually
reacting on an abort request).
I do not remember having ever passed strings from one thread to another.
Multiple threads are also rare for my GUI applications which need to
react instantly on user input (except for long jobs as above).
A different scenario is for networking oriented services which higly
relay on threads to service multiple clients but they usually don't
share string based data among them. These would probably less
troublesome to port to new compiler.
But there may be applications which do and std::string is indeed a VC6
problem.
Alas, also newer compilers have bugs (especially in the latest and more
complex features) and they are possibly less known due to their lower age.
Compiler bugs are a double edged sword: is it better an old compiler
with known bugs and workarounds or a new compiler with possibly unknown
ones ?
Regards,
Giuliano Bertoletti
Giuliano Bertoletti
>
>> This is a potential problem which goes unnoticed at compile time.
>
> Your current project carries that danger if it is so. Porting adds little
> new danger.
>
Which may make the difference between standing on the edge of a cliff
and falling down. :-(
Anyway I did not write such a sloppy code, but sometime others do and
you have to take decisions with what you have. No use to complain it
shouldn't have been done that way.
>
> It is, but between what, as told before, bnary bump is not forbidden just
> shall be reinforced.
>
Yes, absolutely. Still when you decide to upgrade you have to take also
this in consideration.
>>
>> Once I realize the prototypes of the new compiler are different, I may be
>> forced to look at what that code really does and find proper workarounds.
>
> If those are MFC macros defined in MFC headers, they work the same
> semantics, don't they.
>
If a component like a CString is being replaced with something (a
template ?) with the same name but different interface, I would expect
the compiler tossing out the code with disgust.
>> - Third you may also consider potential problems in my code that never
>> showed up with the old compiler and may be triggered by the new (due for
>> example to a different memory layout).
>
> You mean existing code has undefined behavior masked by black magic, and you
> hope the actual behavior is 'just fine'? Unless you have a proof in
> design of the behavior (what would trivially help porting) it is just unfair
> (IMHSHO) to push such thing to production and end user.
>
Wait a minute. This is not intentional.
The fact is: you write the code, you believe it's correct. You and your
team test it several times and it always works.
Eventually you go into production, what else can you do ?
If the code is correct it works now and it will work on another compiler
too. If it is not it may crash now and also on another compiler, but
chances are that the current compiler won't trigger the defect while the
other does.
Consider for example the (wrong) assumption that global objects are
initialized in a particular order.
>
> Well, if they are truly satisfiesfied -- and not just suffering silently
> form the same lock-in.
>
> In my practice I met many situations where 'customer satisfection' brought
> very different results if you asked a manager who paid for the stuff and the
> users in everyday work.
>
What I mean is that software is buggy. Patches and service packs keep
being release to correct defects. A programmer should try to minimize
the impact of bugs, whatever the means.
As soon as they're spotted they must be corrected and a defensive
programming style is also preferable.
But you should also limit the risks of triggering dormant bugs if possible.
Regards,
Giuliano Bertoletti.
Balog Pal
>> "Vaclav Haisman" <v.ha...@sh.cvut.cz>
>>> It is not that you cannot use latest C++ constructs. You cannot use C++
>>> constructs that are valid C++ about 10 years now. What is worse, you
>>> cannot
>>> even use C++ constructs as simple assignment of std::string, since its
>>> implementation is buggy wrt/ threads in VC6.
>>
>> You don't use stl with VC6, so that is not a practical problem.
>> (especially not mixed with MFC)
>
> Why not ? With the latest service pack STL works just fine (at least on a
> single thread) with MFC.
Because
- std::string is an abomination in its own right
- you have CString around anyway that is superior in ALL respects
- having multiple kinds of strings withoin a project is a royap pain
For the other stuff you also have stock solutions in MFC, that were around
for long, much better documented, and with direct recognition/support in the
frameworks.
The STL version shipping with VC6 was something around CD2 (i.e. with the
completely broken auto_ptr). IIRC Dincum offered an update of the lib for
extra $$$ after the standard was out, but ....
> I also use multithreading, but did never stumble on the std::string
> reference counting issue because the model adopted is the worker thread
> doing a long job and the main thread responding to user inputs (usually
> reacting on an abort request).
Yeah, that looks more like a 'theoretical' problem where attention is put to
sharing objects between threads -- but if you just use CString you get more
without headache, don't you?
> I do not remember having ever passed strings from one thread to another.
>
> Multiple threads are also rare for my GUI applications which need to react
> instantly on user input (except for long jobs as above).
Depends on what you do. Most of my programs had threads for socket or COM
port communication... Or processing stuff on behalf of multiple clients,
using the GUI only mostly as visual feedback.
> Alas, also newer compilers have bugs (especially in the latest and more
> complex features) and they are possibly less known due to their lower age.
IMO the quality at MS improved vastly starting the 2000 security push
(starting fruits a few years later). And compilers are given out as
freebies (the Express versions, faurly long-timed trials), and early betas,
so have a good chance for less hitting bugs.
Certainly Murphy does not sleep. But VS6 was never such a stable, I recall
the IDE reutinely crashed after 24 hours of work, and all kinds on INTERNAL
COMPILER ERRORs were common visitors.
> Compiler bugs are a double edged sword: is it better an old compiler with
> known bugs and workarounds or a new compiler with possibly unknown ones ?
Depends on which hits YOU ;-) actually -- in this race I would not bet my
money on VC6 however old and spreadly used it is/was.
(I recall being hit by at leas one proved code-generation bug too. Had to
specificly disable some optimisations in all builds afterwards...)
Balog Pal
>>> It is not that you cannot use latest C++ constructs. You cannot use C++
>>> constructs that are valid C++ about 10 years now.
>>
>> I guess you're right. But what are these constructs ?
> for(;;) induction variable scoping is annoying enough.
#define for if(0); else for
cures it for good...
Balog Pal
>> <http://support.microsoft.com/kb/813810>.
> More of fun reading on similar note:
> <http://support.microsoft.com/kb/172396>
This has little to do with MS or a specific compiler version -- using
objects across DLL boundaries always had problems, and programmers shall be
aware of them.
The most kown problem is probably tied to memory allocation/deallocation
that is suggested to be done always at the same place.
With DLLs I always rtied to restrict to a pure C-stlye interface and
carefully packed structures. If that is not feasible, it's better to write
a COM object and pay the marshaling.
Giuliano Bertoletti
Congratulations! Brilliant disguise.
I knew of:
{for(;;) {
}}
but yours definitly outperforms this.
Regards,
Giuliano Bertoletti
Thomas J. Gritzan
> 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);
>
> 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 ?
No. You should check the project settings if the character set is UNICODE.
If it is, try the above with a L"unicode string literal" or just switch
Unicode off.
--
Thomas
Giuliano Bertoletti
>
> If it is, try the above with a L"unicode string literal" or just switch
> Unicode off.
>
Yes, prefixing L it works. As someone pointed out it was just a compiler
switch then. I've still to find where it is, but I'm confident I will
eventually :-)
Thank you.
Regards,
Giuliano Bertoletti.
Paavo Helde
>
> Hello,
>
> I was just wondering if there's a standard nomenclature which forces any
> C/C++ compiler to instantiate integer variables of a givens size.
>
> For example suppose my program wishes to deal with a 64-bit integer.
> Assuming that a platform/compiler supports it, how shall I instantiate a
> variable of that size.
>
> I usually typedef under MSVC++ something like:
>
> typedef __int64 WORD64;
>
> and then instntiate
>
> WORD64 v;
>
> but I would like to have such a definition on a standard header file
> which won't forces me to #ifdef depending on the platform and most
> importantly not use WORD64 but something recognized universally.
What beats me is why do you want to have something recognized universally
in your code which allegedly can be compiled only by MSVC++ 6.0? The
compiler has been considered obsolete for the past 6 years now, so no real
developers should be using it, and thus can't make use of your code anyway.
And for your programmers, it does little help for them if they can call 64-
bit int by its standard name, but otherwise be confined to the pre-standard
and buggy compiler.
Paavo
Jerry Coffin
[ ... ]
> > Not to mention the time it takes to get you accustomed to the new
> > compiler/IDE interface.
>
> Come on, the interface is very similar, and if you're so addicted to the old
> it can be even recreated. But it is completely intuituve and usable without
> problem out of the box. And benefit from both the new features and the
> compiler.
The new IDE is quite different, and a much worse design at that -- even
some of Microsoft's employees who work on it have admitted this. The
newer compilers are definitely improved, but the newer IDEs,
unfortunately, are not. Even when one does become accustomed to them,
they are far less functional -- some things that VC6 makes quite easy
are next to impossible with any newer version of the IDE (in one case,
they seem to have gone out of their way to ensure against your being
able to do something that used to be quite trivial).
[ ... ]
> > 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.
Quite the contrary -- the newer IDEs do not support MFC nearly as well
as VC6 does. Let me give one really trivial example. In VC6, creating a
database front end is quite trivial: in the AppWizard you tell it you
want (for example) ODBC support. You pick out a data source at that
point. It creates a database form view for you by default. You can then
drag and drop controls onto that form, and (the important part) when you
do a control-click on them, it brings up the usual dialog for connecting
the control to a member function, BUT with one important difference from
the usual: it has a drop-down list box, where you can select a database
field for that control.
This allows you to write simple database browser type of applications
just about as quickly and easily in VC6 as using something like MS
Access (in fact, if you're going to use a different form layout than
Access does by default, VC6 may be even quicker and easier).
The newer versions of the IDE don't provide the drop-down list box to
allow you to select the database field. Worse, if you attempt to enter
the correct member variable manually, it'll give an error message and
stop you from using that name. After several attempts (and talking with
a couple of MS employees) it's become apparent that the only way to do
this with a newer IDE is to write all the code by hand. Worse, you have
to prevent any of its wizard-like functionality from ever even trying to
parse that code, or it'll give you the same error and stop you from
doing your job.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Balog Pal
Wow, Jerry form FIDONET... ;-)
>> pa...@lib.hu says...
>> > Not to mention the time it takes to get you accustomed to the new
>> > compiler/IDE interface.
>>
>> Come on, the interface is very similar, and if you're so addicted to the
>> old
>> it can be even recreated. But it is completely intuituve and usable
>> without
>> problem out of the box. And benefit from both the new features and the
>> compiler.
>
> The new IDE is quite different, and a much worse design at that -- even
> some of Microsoft's employees who work on it have admitted this.
Interesting... I had absolutely no problems with the IDE (2008, didn't try
the ones between) in the transition, except being unable to pause or
intellisense.
And it is mush more resource-hungry. And the help system sucks still (last
good was in vs97, already blown in vs6... )
> The
> newer compilers are definitely improved, but the newer IDEs,
> unfortunately, are not. Even when one does become accustomed to them,
> they are far less functional -- some things that VC6 makes quite easy
> are next to impossible with any newer version of the IDE (in one case,
> they seem to have gone out of their way to ensure against your being
> able to do something that used to be quite trivial).
I'm just trying to think of something not doable, but fail. While
enhancements to navigation, browsing, debug info, hilighting are pretty
obvious.
>> > 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.
>
> Quite the contrary -- the newer IDEs do not support MFC nearly as well
> as VC6 does. Let me give one really trivial example. In VC6, creating a
> database front end is quite trivial: in the AppWizard you tell it you
> want (for example) ODBC support. You pick out a data source at that
> point. It creates a database form view for you by default. You can then
> drag and drop controls onto that form, and (the important part) when you
> do a control-click on them, it brings up the usual dialog for connecting
> the control to a member function, BUT with one important difference from
> the usual: it has a drop-down list box, where you can select a database
> field for that control.
You're right here, I made it as part of tutorial example. And that is it.
IMO a nice wizard feature, but mostly irrelevant for production code, where
you reorganise the members enough so CLW will not find them anyway. (btw I
recall deleting .clw and .aps as the most frequent activity, also the first
thing to de beyond restarting IDE and clean on 'weird' behavior, those were
routinely messed up by VS.)
Well, then I very fast wrote my own 'wizard' that created structs and more
from all the tables, usable with templated CRecordset-derivate, and any UI
worked with those fields.
And DoDataExchange needed serious rearrangements -- also writing to the DB
make use transactions, etc, the existing model was IIRC not fit for the real
task anyway. I mean in its wizard-created form, I did use CLW as kickstart.
> This allows you to write simple database browser type of applications
> just about as quickly and easily in VC6 as using something like MS
> Access (in fact, if you're going to use a different form layout than
> Access does by default, VC6 may be even quicker and easier).
Sure it was neat as a starter, but after I saw the included DaoView
sample -- that works like the said browser without even writing code... I
proceeded along that line.
> The newer versions of the IDE don't provide the drop-down list box to
> allow you to select the database field. Worse, if you attempt to enter
> the correct member variable manually, it'll give an error message and
> stop you from using that name. After several attempts (and talking with
> a couple of MS employees) it's become apparent that the only way to do
> this with a newer IDE is to write all the code by hand.
What means inserting that one line of DDX_* or RFX_* with the ID and the
member? Or something more sophisticated?
> Worse, you have
> to prevent any of its wizard-like functionality from ever even trying to
> parse that code, or it'll give you the same error and stop you from
> doing your job.
That was the general case with VS6 too, any tweaked stuff had to be moved
out of the wiz section -- and it was pretty far from supporting all the
message map macros, etc. So I;d think any serious use would need a fair
knowledge of the macros, and being able to read/write them regardless of the
wizard use. Possibly the decision on not caring about some functionality
was based on such thinking...
Sure I agree if someone got exactly what he needed from the old wiz and that
very feature for nuked or spread to unintuitive places, it hurts.
Ah, my merory starts ticking. You had to 'create' a recordset with CLV for
every of your tables, that defaulted to distinct .h and .cpp files. (I put
them all in one, but my collegaues polluted like hell.) And then if the DB
changed there was no sensible way for update... And if you didn't nuke the
.CLW file really bad things followed...
James Kanze
> Vaclav Haisman ha scritto:
> >> You quickly realize that one or probably both programmers
> >> will loose their job if you agree with the upgrade.
> >> Would you still believe it's worth profitting the better
> >> optimization today compilers can do for you ?
> > This is total bullshit. You do not have to stop developing
> > new features or stop maintaining old code. This can be done
> > in parallel with normal development.
> We may discuss whether my estimates are a bit too pessimistic,
> but once we estabilish that it takes N days to upgrade and
> test (provided the forecast is correct), that is the time (not
> less, possibly more).
> It really doesn't matter how you interleave the upgrading with
> the development time or even how you divide the work among
> programmers.
> At the end of the year, N days (or more due to task switch
> overhead) have been consumed for the upgrade.
Certainly. On the other hand, not upgrading has its costs as
well. In the case of VC++ 6.0, those costs are, IMHO, quite
high---the newer versions of the compilers are known to be
significantly better in terms of less bugs.
> > What you do is that you create parallel projects for VC9 out
> > of the VC6 projects. Getting things to compile usually
> > requires only very little editing. Even huge projects with
> > millions of lines of code usually take only very little
> > tweaking for the code to become compilable.
> - First, compilable doesn't mean it'll work.
> Suppose I somewhere serialize a structure to disk like this:
> fwrite(&mys, 1, sizeof(mys), h1); // C struct serialization
Then you're in deep trouble, regardless of what you do.
> are you sure the new compiler packs the structure in the same
> way ?
Given the same options, probably. Given different compiler
options, then even VC++ 6.0 will pack structures differently.
> This is a potential problem which goes unnoticed at compile
> time. You may object, I should have not serilized the struct
> that way in the first place.
> Maybe, but if for example I serialize each member I would
> probably loose efficiency (repeated calls to the OS) which may
> or may not be critical. Again, it's a choice.
Not really. Correct serialization isn't very expensive (except
for double), and is a lot easier to read, understand and
maintain. And it certainly doesn't involve any more called to
the OS---there should be exactly one (and only one) per
transactional record.
[...]
> I'm not saying it's never worth the effort, but I would like
> to see more detailed statements about supporting the upgrade
> rather than simply: "the compiler works better, has many more
> features and is compliant with the standard".
> Which features ? Do we need them ?
> These are the first questions you face when you step that way.
Certainly. In the case of VC++ 6.0: the compiler is known to be
very, very buggy with regards to templates. If your code makes
any use of templates, the slightest change in the code (or in
the compiler options) could cause the compiler to generate
incorrect code. Which is very expensive to debug. And
(partially because of the problems with templates) the library
delivered with VC++ 6.0 was fairly simplistic---the library
delivered with later versions has a lot of options which help
you find errors quicker. If you're using the standard library,
you should definitely upgrade.
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze
> Balog Pal ha scritto:
[...]
> Consider for example the (wrong) assumption that global
> objects are initialized in a particular order.
Consider that adding or removing a module in the link phase may
change that order, even if you don't upgrade. Not upgrading is
a very valid option is all you're doing is limited bug fixing;
i.e. the product's life is pretty much over. Otherwise, not
upgrading probably costs more (in cases where you're using a
compiler that old---not in every case, of course) than
upgrading.
> > Well, if they are truly satisfiesfied -- and not just
> > suffering silently form the same lock-in.
> > In my practice I met many situations where 'customer
> > satisfection' brought very different results if you asked a
> > manager who paid for the stuff and the users in everyday
> > work.
> What I mean is that software is buggy. Patches and service
> packs keep being release to correct defects. A programmer
> should try to minimize the impact of bugs, whatever the means.
> As soon as they're spotted they must be corrected and a
> defensive programming style is also preferable.
> But you should also limit the risks of triggering dormant bugs
> if possible.
One way of doing that is precisely by upgrading to a compiler
which is stricter in its interpretation of the language. The
more different compilers you've used, the greater the chance
that one of them triggers the bug in your test code, rather than
letting it sleep until the software is at the customer site.