[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c++

class initialization problem, please help

zl2k

9/26/2008 3:04:00 AM

hi, there
Here is a simplified piece of code of my program, it compiles and runs
fine. However, valgrind shows it has uninitialized problem. What I am
doing wrong?

#ifndef DATA2_H
#define DATA2_H

class Data2{
public:
int regionId;
bool isLandscape;
double parameters[16];
Data2();

~Data2();
};
#endif

#include "data2.h"
#include <iomanip>
#include <fstream>

using namespace std;

Data2::Data2(): regionId(-1), isLandscape(false)
{
for (int i = 0; i < 16; i++)
parameters[i] = 1;
}

Data2::~Data2()
{
}

int main(){
char buffer[512] = "abc.bin";
ofstream myfile;
Data2 *dataArray = new Data2[10];

myfile.open (buffer, ios::out | ios::binary);
int *num = new int(10);
myfile.write((char*)num, sizeof(int));
myfile.write ((char*)dataArray, sizeof (Data2) * *num);
myfile.close();
delete num;
delete [] dataArray;
return 1;
}

valgrind error message:
==16557== 1 errors in context 1 of 1:
==16557== Syscall param writev(vector[...]) points to uninitialised
byte(s)
==16557== at 0x40007F2: (within /lib/ld-2.7.so)
==16557== by 0x5A70707: std::__basic_file<char>::xsputn_2(char
const*, int, char const*, int) (in /usr/lib/libstdc++.so.6.0.9)
==16557== by 0x5A171E9: std::basic_filebuf<char,
std::char_traits<char> >::xsputn(char const*, int) (in /usr/lib/libstdc
++.so.6.0.9)
==16557== by 0x5A42DE0: std::ostream::write(char const*, int) (in /
usr/lib/libstdc++.so.6.0.9)
==16557== by 0x81535AD: main (data2.cpp:36)
==16557== Address 0x61540b9 is 9 bytes inside a block of size 1,364
alloc'd
==16557== at 0x4022F14: operator new[](unsigned)
(vg_replace_malloc.c:268)
==16557== by 0x81534AE: main (data2.cpp:31)
--16557--
--16557-- supp: 131 dl-hack3-1
==16557==
==16557== IN SUMMARY: 1 errors from 1 contexts (suppressed: 131 from
1)
==16557==
==16557== malloc/free: in use at exit: 528 bytes in 10 blocks.
==16557== malloc/free: 534 allocs, 524 frees, 49,265 bytes allocated.
==16557==
==16557== searching for pointers to 10 not-freed blocks.
==16557== checked 1,449,340 bytes.
==16557==
==16557== LEAK SUMMARY:
==16557== definitely lost: 0 bytes in 0 blocks.
==16557== possibly lost: 0 bytes in 0 blocks.
==16557== still reachable: 528 bytes in 10 blocks.
==16557== suppressed: 0 bytes in 0 blocks.

Thanks for your comments.

zl2k
11 Answers

Triple-DES

9/26/2008 6:18:00 AM

0

On 26 Sep, 05:04, zl2k <kdsfin...@gmail.com> wrote:
> hi, there
> Here is a simplified piece of code of my program, it compiles and runs
> fine. However, valgrind shows it has uninitialized problem. What I am
> doing wrong?
>
> #ifndef DATA2_H
> #define DATA2_H
>
> class Data2{
> public:
>         int regionId;
>         bool isLandscape;
>         double parameters[16];
>   Data2();
>
>   ~Data2();};
>
> #endif
>
> #include "data2.h"
> #include <iomanip>
> #include <fstream>
>
> using namespace std;
>
> Data2::Data2(): regionId(-1), isLandscape(false)
> {
>         for (int i = 0; i < 16; i++)
>                 parameters[i] = 1;
>
> }
>
> Data2::~Data2()
> {
>
> }
>
> int main(){
>         char buffer[512] = "abc.bin";
>         ofstream myfile;
>         Data2 *dataArray = new Data2[10];
>
>         myfile.open (buffer, ios::out | ios::binary);
>         int *num = new int(10);
>         myfile.write((char*)num, sizeof(int));
>         myfile.write ((char*)dataArray, sizeof (Data2) * *num);
>         myfile.close();
>         delete num;
>         delete [] dataArray;
>         return 1;
>
> }
>

Try the following:
int data2size = sizeof(Data2);
int membersize = sizeof(int) + sizeof(bool) + sizeof(double)*16;

What are these values on your system?
Does that tell you anything ? :)

DP

James Kanze

9/26/2008 8:01:00 AM

0

On Sep 26, 5:04 am, zl2k <kdsfin...@gmail.com> wrote:

> Here is a simplified piece of code of my program, it compiles
> and runs fine. However, valgrind shows it has uninitialized
> problem. What I am doing wrong?

You're misusing reinterpret_cast.

> #ifndef DATA2_H
> #define DATA2_H

> class Data2{
> public:
> int regionId;
> bool isLandscape;
> double parameters[16];
> Data2();
> ~Data2();
> };

> #endif

> #include "data2.h"
> #include <iomanip>
> #include <fstream>

> using namespace std;

> Data2::Data2(): regionId(-1), isLandscape(false)
> {
> for (int i = 0; i < 16; i++)
> parameters[i] = 1;
> }

> Data2::~Data2()
> {
> }

> int main(){
> char buffer[512] = "abc.bin";
> ofstream myfile;
> Data2 *dataArray = new Data2[10];

> myfile.open (buffer, ios::out | ios::binary);
> int *num = new int(10);
> myfile.write((char*)num, sizeof(int));
> myfile.write ((char*)dataArray, sizeof (Data2) * *num);

The casts in the two statements above are reinterpret_cast's;
you shouldn't be using them unless you really know what you are
doing. And you shouldn't be too surprised that valgrind finds
errors if you do use them.

In this particular case, the standard does guarantee that the
write's will work, despite the uninitialized memory reads, but
only because ofstream is guaranteed to access the data as bytes.
On the other hand, it doesn't say anything about what will
actually be written, and it doesn't guarantee that you will be
able to reread it---in practice, you may encounter problems
rereading it if you recompile the program with different
compiler options, or with a newer version of the compiler, and
you will almost certainly encouter problems trying to reread it
if you run the program on another machine.

Dumping bit images to disk doesn't work, except for temporary
files that you will reread later in the same program run.

--
James Kanze (GABI Software) email:james.kanze@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

zl2k

9/26/2008 11:38:00 AM

0

On Sep 26, 2:17 am, Triple-DES <DenPlettf...@gmail.com> wrote:
> On 26 Sep, 05:04, zl2k <kdsfin...@gmail.com> wrote:
>
>
>
> > hi, there
> > Here is a simplified piece of code of my program, it compiles and runs
> > fine. However, valgrind shows it has uninitialized problem. What I am
> > doing wrong?
>
> > #ifndef DATA2_H
> > #define DATA2_H
>
> > class Data2{
> > public:
> >         int regionId;
> >         bool isLandscape;
> >         double parameters[16];
> >   Data2();
>
> >   ~Data2();};
>
> > #endif
>
> > #include "data2.h"
> > #include <iomanip>
> > #include <fstream>
>
> > using namespace std;
>
> > Data2::Data2(): regionId(-1), isLandscape(false)
> > {
> >         for (int i = 0; i < 16; i++)
> >                 parameters[i] = 1;
>
> > }
>
> > Data2::~Data2()
> > {
>
> > }
>
> > int main(){
> >         char buffer[512] = "abc.bin";
> >         ofstream myfile;
> >         Data2 *dataArray = new Data2[10];
>
> >         myfile.open (buffer, ios::out | ios::binary);
> >         int *num = new int(10);
> >         myfile.write((char*)num, sizeof(int));
> >         myfile.write ((char*)dataArray, sizeof (Data2) * *num);
> >         myfile.close();
> >         delete num;
> >         delete [] dataArray;
> >         return 1;
>
> > }
>
> Try the following:
>   int data2size = sizeof(Data2);
>   int membersize = sizeof(int) + sizeof(bool) + sizeof(double)*16;
>
> What are these values on your system?
> Does that tell you anything ? :)
>
> DP

It's different! To make it simpler, the Data2 will only contains an
int and a bool, the data2size is 8 and membersize is 5. I am fine if
using 5 for output. The sizeof(ClassType) is bad, is it? Thanks a lot.
zl2k

Triple-DES

9/26/2008 12:23:00 PM

0

On 26 Sep, 13:37, zl2k <kdsfin...@gmail.com> wrote:
> On Sep 26, 2:17 am, Triple-DES <DenPlettf...@gmail.com> wrote:
> > On 26 Sep, 05:04, zl2k <kdsfin...@gmail.com> wrote:
>
> > > hi, there
> > > Here is a simplified piece of code of my program, it compiles and runs
> > > fine. However, valgrind shows it has uninitialized problem. What I am
> > > doing wrong?
>
> > > #ifndef DATA2_H
> > > #define DATA2_H
>
> > > class Data2{
> > > public:
> > >         int regionId;
> > >         bool isLandscape;
> > >         double parameters[16];
> > >   Data2();
>
> > >   ~Data2();};
>
> > > #endif
>
> > > #include "data2.h"
> > > #include <iomanip>
> > > #include <fstream>
>
> > > using namespace std;
>
> > > Data2::Data2(): regionId(-1), isLandscape(false)
> > > {
> > >         for (int i = 0; i < 16; i++)
> > >                 parameters[i] = 1;
>
> > > }
>
> > > Data2::~Data2()
> > > {
>
> > > }
>
> > > int main(){
> > >         char buffer[512] = "abc.bin";
> > >         ofstream myfile;
> > >         Data2 *dataArray = new Data2[10];
>
> > >         myfile.open (buffer, ios::out | ios::binary);
> > >         int *num = new int(10);
> > >         myfile.write((char*)num, sizeof(int));
> > >         myfile.write ((char*)dataArray, sizeof (Data2) * *num);
> > >         myfile.close();
> > >         delete num;
> > >         delete [] dataArray;
> > >         return 1;
>
> > > }
>
> > Try the following:
> >   int data2size = sizeof(Data2);
> >   int membersize = sizeof(int) + sizeof(bool) + sizeof(double)*16;
>
> > What are these values on your system?
> > Does that tell you anything ? :)
>
> > DP
>
> It's different! To make it simpler, the Data2 will only contains an
> int and a bool, the data2size is 8 and membersize is 5. I am fine if
> using 5 for output. The sizeof(ClassType) is bad, is it? Thanks a lot.
> zl2k

You're onto something, but your conclusion is wrong I think. What I
wanted to show you was that the Data2 class may very well be larger
than the sum of its members (sizeof returns the number of bytes of the
object). So what are those extra bytes?

Put simply, they are "padding" inserted by the compiler so that it may
access the members of the class more efficiently. This is commonly
referred to as _alignment_. Naturally when you take the address of the
object and interpret it as a char*, you will expose the padding bytes.

Data2 possible object layout:
[ 0 ][ 1 ][ 2 ][ 3 ][ 4 ][ 5 ][ 6 ][ 7 ]
[ int (4 bytes) ][bool][ padding ]

The padding could be set to a special value by the compiler to
correspond to "uninitialized memory", or it could simply be garbage.
Hence, your binary file will have bytes with an unspecified value
written to it.

Class member alignment may vary depending on architecture and compiler
version, and even the settings of the compiler. This is covered by
James Kanze's post.

DP

zl2k

9/26/2008 12:41:00 PM

0

On Sep 26, 8:23 am, Triple-DES <DenPlettf...@gmail.com> wrote:
> On 26 Sep, 13:37, zl2k <kdsfin...@gmail.com> wrote:
>
>
>
> > On Sep 26, 2:17 am, Triple-DES <DenPlettf...@gmail.com> wrote:
> > > On 26 Sep, 05:04, zl2k <kdsfin...@gmail.com> wrote:
>
> > > > hi, there
> > > > Here is a simplified piece of code of my program, it compiles and runs
> > > > fine. However, valgrind shows it has uninitialized problem. What I am
> > > > doing wrong?
>
> > > > #ifndef DATA2_H
> > > > #define DATA2_H
>
> > > > class Data2{
> > > > public:
> > > >         int regionId;
> > > >         bool isLandscape;
> > > >         double parameters[16];
> > > >   Data2();
>
> > > >   ~Data2();};
>
> > > > #endif
>
> > > > #include "data2.h"
> > > > #include <iomanip>
> > > > #include <fstream>
>
> > > > using namespace std;
>
> > > > Data2::Data2(): regionId(-1), isLandscape(false)
> > > > {
> > > >         for (int i = 0; i < 16; i++)
> > > >                 parameters[i] = 1;
>
> > > > }
>
> > > > Data2::~Data2()
> > > > {
>
> > > > }
>
> > > > int main(){
> > > >         char buffer[512] = "abc.bin";
> > > >         ofstream myfile;
> > > >         Data2 *dataArray = new Data2[10];
>
> > > >         myfile.open (buffer, ios::out | ios::binary);
> > > >         int *num = new int(10);
> > > >         myfile.write((char*)num, sizeof(int));
> > > >         myfile.write ((char*)dataArray, sizeof (Data2) * *num);
> > > >         myfile.close();
> > > >         delete num;
> > > >         delete [] dataArray;
> > > >         return 1;
>
> > > > }
>
> > > Try the following:
> > >   int data2size = sizeof(Data2);
> > >   int membersize = sizeof(int) + sizeof(bool) + sizeof(double)*16;
>
> > > What are these values on your system?
> > > Does that tell you anything ? :)
>
> > > DP
>
> > It's different! To make it simpler, the Data2 will only contains an
> > int and a bool, the data2size is 8 and membersize is 5. I am fine if
> > using 5 for output. The sizeof(ClassType) is bad, is it? Thanks a lot.
> > zl2k
>
> You're onto something, but your conclusion is wrong I think. What I
> wanted to show you was that the Data2 class may very well be larger
> than the sum of its members (sizeof returns the number of bytes of the
> object). So what are those extra bytes?
>
> Put simply, they are "padding" inserted by the compiler so that it may
> access the members of the class more efficiently. This is commonly
> referred to as _alignment_. Naturally when you take the address of the
> object and interpret it as a char*, you will expose the padding bytes.
>
> Data2 possible object layout:
> [ 0 ][ 1 ][ 2 ][ 3 ][ 4 ][ 5 ][ 6 ][ 7 ]
> [  int (4 bytes)   ][bool][  padding   ]
>
> The padding could be set to a special value by the compiler to
> correspond to "uninitialized memory", or it could simply be garbage.
> Hence, your binary file will have bytes with an unspecified value
> written to it.
>
> Class member alignment may vary depending on architecture and compiler
> version, and even the settings of the compiler. This is covered by
> James Kanze's post.
>
> DP

So both implements are correct and the valgrind is false alarming,
right? Basically, as long as my reading of the file using the same
sizeof() as the writting, I'll be fine. But I am still facing risk if
the file is going to be read by other systems later on if using
sizeof(ClassType). The conclusion is draw is telling the system the
exact length of the ClassType "manually". Hope I get it right. Thanks
again and this forum helps me a lot.
zl2k

Triple-DES

9/26/2008 1:03:00 PM

0

On 26 Sep, 14:40, zl2k <kdsfin...@gmail.com> wrote:
> On Sep 26, 8:23 am, Triple-DES <DenPlettf...@gmail.com> wrote:
> > On 26 Sep, 13:37, zl2k <kdsfin...@gmail.com> wrote:
> > > On Sep 26, 2:17 am, Triple-DES <DenPlettf...@gmail.com> wrote:
> > > > On 26 Sep, 05:04, zl2k <kdsfin...@gmail.com> wrote:
> > > > > hi, there
> > > > > Here is a simplified piece of code of my program, it compiles and runs
> > > > > fine. However, valgrind shows it has uninitialized problem. What I am
> > > > > doing wrong?

[snip]

> > > > Try the following:
> > > >   int data2size = sizeof(Data2);
> > > >   int membersize = sizeof(int) + sizeof(bool) + sizeof(double)*16;
>
> > > > What are these values on your system?
> > > > Does that tell you anything ? :)
>
> > > > DP
>
> > > It's different! To make it simpler, the Data2 will only contains an
> > > int and a bool, the data2size is 8 and membersize is 5. I am fine if
> > > using 5 for output. The sizeof(ClassType) is bad, is it? Thanks a lot.
> > > zl2k
>
> > You're onto something, but your conclusion is wrong I think. What I
> > wanted to show you was that the Data2 class may very well be larger
> > than the sum of its members (sizeof returns the number of bytes of the
> > object). So what are those extra bytes?
>
> > Put simply, they are "padding" inserted by the compiler so that it may
> > access the members of the class more efficiently. This is commonly
> > referred to as _alignment_. Naturally when you take the address of the
> > object and interpret it as a char*, you will expose the padding bytes.
>
> > Data2 possible object layout:
> > [ 0 ][ 1 ][ 2 ][ 3 ][ 4 ][ 5 ][ 6 ][ 7 ]
> > [  int (4 bytes)   ][bool][  padding   ]
>
> > The padding could be set to a special value by the compiler to
> > correspond to "uninitialized memory", or it could simply be garbage.
> > Hence, your binary file will have bytes with an unspecified value
> > written to it.
>
> > Class member alignment may vary depending on architecture and compiler
> > version, and even the settings of the compiler. This is covered by
> > James Kanze's post.
>
> > DP
>
> So both implements are correct and the valgrind is false alarming,
> right? Basically, as long as my reading of the file using the same
> sizeof() as the writting, I'll be fine. But I am still facing risk if
> the file is going to be read by other systems later on if using
> sizeof(ClassType). The conclusion is draw is telling the system the
> exact length of the ClassType "manually". Hope I get it right. Thanks
> again and this forum helps me a lot.
> zl2k

Not quite. Manually calculating the size of the members won't help if
there is padding _between_ the members. Note also that valgrind is not
really giving a false alarm since the padding bytes are in fact
uninitialized.

DP

James Kanze

9/26/2008 1:44:00 PM

0

On Sep 26, 2:23 pm, Triple-DES <DenPlettf...@gmail.com> wrote:
> On 26 Sep, 13:37, zl2k <kdsfin...@gmail.com> wrote:

[...]
> Class member alignment may vary depending on architecture and
> compiler version, and even the settings of the compiler. This
> is covered by James Kanze's post.

Except that I explicitly avoided talking about padding (although
I'm sure that that's the immediate problem), since there's a lot
more to it than just padding. The representation of basic types
varies a lot, and at least in one case, it changed from one
version of the compiler to the next. If you want your data to
be readable in the future, you have to define a format, and use
it.

--
James Kanze (GABI Software) email:james.kanze@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

zl2k

9/26/2008 1:45:00 PM

0

On Sep 26, 9:02 am, Triple-DES <DenPlettf...@gmail.com> wrote:
> On 26 Sep, 14:40, zl2k <kdsfin...@gmail.com> wrote:
>
> > On Sep 26, 8:23 am, Triple-DES <DenPlettf...@gmail.com> wrote:
> > > On 26 Sep, 13:37, zl2k <kdsfin...@gmail.com> wrote:
> > > > On Sep 26, 2:17 am, Triple-DES <DenPlettf...@gmail.com> wrote:
> > > > > On 26 Sep, 05:04, zl2k <kdsfin...@gmail.com> wrote:
> > > > > > hi, there
> > > > > > Here is a simplified piece of code of my program, it compiles and runs
> > > > > > fine. However, valgrind shows it has uninitialized problem. What I am
> > > > > > doing wrong?
>
> [snip]
>
>
>
> > > > > Try the following:
> > > > >   int data2size = sizeof(Data2);
> > > > >   int membersize = sizeof(int) + sizeof(bool) + sizeof(double)*16;
>
> > > > > What are these values on your system?
> > > > > Does that tell you anything ? :)
>
> > > > > DP
>
> > > > It's different! To make it simpler, the Data2 will only contains an
> > > > int and a bool, the data2size is 8 and membersize is 5. I am fine if
> > > > using 5 for output. The sizeof(ClassType) is bad, is it? Thanks a lot.
> > > > zl2k
>
> > > You're onto something, but your conclusion is wrong I think. What I
> > > wanted to show you was that the Data2 class may very well be larger
> > > than the sum of its members (sizeof returns the number of bytes of the
> > > object). So what are those extra bytes?
>
> > > Put simply, they are "padding" inserted by the compiler so that it may
> > > access the members of the class more efficiently. This is commonly
> > > referred to as _alignment_. Naturally when you take the address of the
> > > object and interpret it as a char*, you will expose the padding bytes.
>
> > > Data2 possible object layout:
> > > [ 0 ][ 1 ][ 2 ][ 3 ][ 4 ][ 5 ][ 6 ][ 7 ]
> > > [  int (4 bytes)   ][bool][  padding   ]
>
> > > The padding could be set to a special value by the compiler to
> > > correspond to "uninitialized memory", or it could simply be garbage.
> > > Hence, your binary file will have bytes with an unspecified value
> > > written to it.
>
> > > Class member alignment may vary depending on architecture and compiler
> > > version, and even the settings of the compiler. This is covered by
> > > James Kanze's post.
>
> > > DP
>
> > So both implements are correct and the valgrind is false alarming,
> > right? Basically, as long as my reading of the file using the same
> > sizeof() as the writting, I'll be fine. But I am still facing risk if
> > the file is going to be read by other systems later on if using
> > sizeof(ClassType). The conclusion is draw is telling the system the
> > exact length of the ClassType "manually". Hope I get it right. Thanks
> > again and this forum helps me a lot.
> > zl2k
>
> Not quite. Manually calculating the size of the members won't help if
> there is padding _between_ the members. Note also that valgrind is not
> really giving a false alarm since the padding bytes are in fact
> uninitialized.
>
> DP

The valgrind does give error message when I put the double[] back even
I "manually" tell the length of the ClassType. I can write each
element sequentially and manually for the ClassType, is that what I am
expected to do? It doesn't look like a smart way. Is there a standard
way to output the structure to the binary file? The c++ document of
microsoft uses myfile.write((char*) classPointer,
sizeof(ClassType)*LengthOfArray). But I am using gun c++ in linux.
What is the correct way to do this safe that the output file can be
correctly read in any system? I am confused again.
zl2k

James Kanze

9/26/2008 1:49:00 PM

0

On Sep 26, 2:40 pm, zl2k <kdsfin...@gmail.com> wrote:
> On Sep 26, 8:23 am, Triple-DES <DenPlettf...@gmail.com> wrote:

[...]
> So both implements are correct and the valgrind is false
> alarming, right?

Correct in what sense? Both implementations are legal according
to the standard. Neither guarantees that you'll be able to
reread the data in the future. And valgrind is correct in that
you're using uninitialized data.

> Basically, as long as my reading of the file using the same
> sizeof() as the writing, I'll be fine.

No. You need to define a format, and use it.

> But I am still facing risk if the file is going to be read by
> other systems later on if using sizeof(ClassType).

The problem is that other systems (or your system, after an
upgrade) will not agree on the size of an int, or its byte
order, or even (unlikely, but not impossible) its
representation.

--
James Kanze (GABI Software) email:james.kanze@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

zl2k

9/26/2008 2:49:00 PM

0

On Sep 26, 9:48 am, James Kanze <james.ka...@gmail.com> wrote:
> On Sep 26, 2:40 pm, zl2k <kdsfin...@gmail.com> wrote:
>
> > On Sep 26, 8:23 am, Triple-DES <DenPlettf...@gmail.com> wrote:
>
>     [...]
>
> > So both implements are correct and the valgrind is false
> > alarming, right?
>
> Correct in what sense?  Both implementations are legal according
> to the standard.  Neither guarantees that you'll be able to
> reread the data in the future.  And valgrind is correct in that
> you're using uninitialized data.
>
> > Basically, as long as my reading of the file using the same
> > sizeof() as the writing, I'll be fine.
>
> No.  You need to define a format, and use it.
>
> > But I am still facing risk if the file is going to be read by
> > other systems later on if using sizeof(ClassType).
>
> The problem is that other systems (or your system, after an
> upgrade) will not agree on the size of an int, or its byte
> order, or even (unlikely, but not impossible) its
> representation.
>
> --
> James Kanze (GABI Software)             email:james.ka...@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

Ok, now I use a function to write the "basic" elements and the
valgrind seems happy with that now. As long as the compiler does not
re-define the length of "basic" elements, I am safe. Hope I get it
correct this time.

void Data2::write(ofstream& myfile){
myfile.write((char*)& regionId, sizeof(int));
myfile.write((char*)& isLandscape, sizeof(bool));
myfile.write((char*)& parameters, sizeof(double)*ArralyLength);
}

And I'll use a similar read function to read in. I searched the binary
output file for a while and seems the (char*) cast is not a good way.

zl2k