Data sizes, VC++ 6.0 vs VC++.NET

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Here is a chunk of data

float m_fStrtTime, m_fTRise, m_fT0
float m_fFO20, m_fFO2M, m_fFO2F
float m_fFCO20, m_fFCO2M, m_fFCO2F
float m_fFHeF, m_fFHeFF;
float m_fR2Hel, m_fR2Acet, m_fR2DME, m_fR2CO
float m_fIHel, m_fKHel, m_fIAcet, m_fKAcet, m_fIDME, m_fKDME, m_fICO, m_fKCO
float m_fAcetCardOut, m_fAcetVtis
float m_fAcetCardOut1, m_fAcetVtis1
float m_fAcetWagnCardOut
float m_fDMECardOut, m_fDMEVtis
float m_fDMECardOut1, m_fDMEVtis1
float m_fDMEWagnCardOut
float m_fDCOr, m_fOCDCO, m_fOCDCOVA
float xFGas0[RDI_END_POS+1]
float xFGasLung[RDI_END_POS+1]
float m_fFresp, m_fMeanVT, m_fTotVE
float m_fEELV, m_fVRtot, m_fVDeff, m_fVAeff, m_fVR, m_fVENTeff
float m_fOCVA, m_fOCVSD, m_fOCVSDI
float m_fAcetCOfac
float m_fDMECOfac
double m_daSolnHe[RD_SOLNHE_PARAMS+1]
unsigned m_uLungDataPos
double m_dVO2, m_dVCO2
float m_fDNO, m_fKNO, m_fINO, m_fR2NO
short __gxrcFinData

And here is a little method to get the size of this set of data
size_t sz=(char *)&__gxrcFinData-(char *)&m_fStrtTime;
return sz
In VC++ v6.0, this returns 408 bytes. In VC++.NET, it returns 412 bytes. In debugging some code that reads/writes a binary file with this data chunk in it, I can tell there is no problem up to the array m_daSolnHe. The array size is reported as 32 by both compileres. The size of the unsigned is 4 in both. I can NOT put my finger on the problem here -- does anyone know of a problem with fundamental data types in the more recent compiler version?
 
CaseyB said:
Here is a chunk of data:

float m_fStrtTime, m_fTRise, m_fT0;
float m_fFO20, m_fFO2M, m_fFO2F;
float m_fFCO20, m_fFCO2M, m_fFCO2F;
float m_fFHeF, m_fFHeFF;
float m_fR2Hel, m_fR2Acet, m_fR2DME, m_fR2CO;
float m_fIHel, m_fKHel, m_fIAcet, m_fKAcet, m_fIDME, m_fKDME,
m_fICO, m_fKCO; float m_fAcetCardOut, m_fAcetVtis;
float m_fAcetCardOut1, m_fAcetVtis1;
float m_fAcetWagnCardOut;
float m_fDMECardOut, m_fDMEVtis;
float m_fDMECardOut1, m_fDMEVtis1;
float m_fDMEWagnCardOut;
float m_fDCOr, m_fOCDCO, m_fOCDCOVA;
float xFGas0[RDI_END_POS+1];
float xFGasLung[RDI_END_POS+1];
float m_fFresp, m_fMeanVT, m_fTotVE;
float m_fEELV, m_fVRtot, m_fVDeff, m_fVAeff, m_fVR, m_fVENTeff;
float m_fOCVA, m_fOCVSD, m_fOCVSDI;
float m_fAcetCOfac;
float m_fDMECOfac;
double m_daSolnHe[RD_SOLNHE_PARAMS+1];
unsigned m_uLungDataPos;
double m_dVO2, m_dVCO2;
float m_fDNO, m_fKNO, m_fINO, m_fR2NO;
short __gxrcFinData;

And here is a little method to get the size of this set of data:
size_t sz=(char *)&__gxrcFinData-(char *)&m_fStrtTime;
return sz;
In VC++ v6.0, this returns 408 bytes. In VC++.NET, it returns 412
bytes. In debugging some code that reads/writes a binary file with
this data chunk in it, I can tell there is no problem up to the array
m_daSolnHe. The array size is reported as 32 by both compileres. The
size of the unsigned is 4 in both. I can NOT put my finger on the
problem here -- does anyone know of a problem with fundamental data
types in the more recent compiler version?
Click to expand...

See #pragma pack

Your problem is not with the size of the members, but with the padding
between them. I'm assuming you have all these members in a struct. If you
don't, you're simply relying on undefined behavior & need to change your
code.

-cd
 
Hi,

What is the value of RDI_END_POS ?

I guess RD_SOLNHE_PARAMS is 3

Thanks,
Mohamed


CaseyB said:
Here is a chunk of data:

float m_fStrtTime, m_fTRise, m_fT0;
float m_fFO20, m_fFO2M, m_fFO2F;
float m_fFCO20, m_fFCO2M, m_fFCO2F;
float m_fFHeF, m_fFHeFF;
float m_fR2Hel, m_fR2Acet, m_fR2DME, m_fR2CO;
float m_fIHel, m_fKHel, m_fIAcet, m_fKAcet, m_fIDME, m_fKDME, m_fICO, m_fKCO;
float m_fAcetCardOut, m_fAcetVtis;
float m_fAcetCardOut1, m_fAcetVtis1;
float m_fAcetWagnCardOut;
float m_fDMECardOut, m_fDMEVtis;
float m_fDMECardOut1, m_fDMEVtis1;
float m_fDMEWagnCardOut;
float m_fDCOr, m_fOCDCO, m_fOCDCOVA;
float xFGas0[RDI_END_POS+1];
float xFGasLung[RDI_END_POS+1];
float m_fFresp, m_fMeanVT, m_fTotVE;
float m_fEELV, m_fVRtot, m_fVDeff, m_fVAeff, m_fVR, m_fVENTeff;
float m_fOCVA, m_fOCVSD, m_fOCVSDI;
float m_fAcetCOfac;
float m_fDMECOfac;
double m_daSolnHe[RD_SOLNHE_PARAMS+1];
unsigned m_uLungDataPos;
double m_dVO2, m_dVCO2;
float m_fDNO, m_fKNO, m_fINO, m_fR2NO;
short __gxrcFinData;

And here is a little method to get the size of this set of data:
size_t sz=(char *)&__gxrcFinData-(char *)&m_fStrtTime;
return sz;
In VC++ v6.0, this returns 408 bytes. In VC++.NET, it returns 412 bytes.
Click to expand...
In debugging some code that reads/writes a binary file with this data chunk
in it, I can tell there is no problem up to the array m_daSolnHe. The array
size is reported as 32 by both compileres. The size of the unsigned is 4 in
both. I can NOT put my finger on the problem here -- does anyone know of a
problem with fundamental data types in the more recent compiler version?
 
Wow, this is news -- I have tons of code where i use the same trick, which I could swear i got from a C++ text somewhere, but maybe not. So I guess you are saying that if the vars are not neatly tucked into a struct, there could be gaps in where they get stored in memory. But wait -- these are data members of a class, which I guess I didnt menton in the original message. Does that change things? A class is same as struct in this regard, right?
 
CaseyB said:
Wow, this is news -- I have tons of code where i use the same trick,
which I could swear i got from a C++ text somewhere, but maybe not.
So I guess you are saying that if the vars are not neatly tucked into
a struct, there could be gaps in where they get stored in memory. But
wait -- these are data members of a class, which I guess I didnt
menton in the original message. Does that change things? A class is
same as struct in this regard, right?
Click to expand...

Yes.

See #pragma pack - that'll take care of your problem.

-cd
 
Back
Top