Re: Nomenclature for interger size in C/C++
On Mar 29, 1:02 pm, Giuliano Bertoletti <gbe32...@libero.it> wrote:
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.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34