Re: Nomenclature for interger size in C/C++
"Giuliano Bertoletti" <gbe32241@libero.it>
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...