TBuffer help

ROOT
1

Hello Rooters,

I am trying to write an binary file with the help of TBuffer as a buffer. Unfortunatly it doesn’t work as I thought it does. Here is what I am trying to do:

myFile.open("filename", ios::out | ios::binary);

TBuffer buffer(TBuffer::kWrite);
buffer << (char) 0xFF;
buffer << (long) 1234;
.
.
.
buffer.writeArray((char *)data,length);

myFile.write(buffer.Buffer(),buffer.Length());

if(myFile.is_open()) myFile.close();

this is the stripped code. I want to fill the buffer with doubles, longs, and char *s in no given order. What I thougth TBuffer will do is flatten all things to a char *, wich I than can write using ofstream::write.

Where is the problem with my code? If I look at the output file with an Hex-Editor I don’t see what I expect to see. There are lots of 0s where there should be the longs and doubles.

Thank you

Lutz

2

Hi,

The only important factor that I can think of is the fact that TBuffer saves its data in a platform independent manner (little endian). On linux this is different from the in-memory format.

Can you give more specific information? (i.e. working example to reproduce a possible error) or (details printout of what you got and what you expected).

Cheers,
Philippe.

3

Hi,

ok, here is a bit more enhanced code:

int main(int argc,char *argv[])
{
	ofstream myFileWriteTBuffer;

	myFileWriteTBuffer.open("testTBuffer.hex", ios::out | ios::binary);

	TBuffer tbuffer(TBuffer::kWrite);

	tbuffer << (char)0xff;
	tbuffer << (char)0x00;
	tbuffer << (double) 1e-9; // HEX: 0x3e112e0be826d695
	tbuffer << (char)0x00;
	tbuffer << (long)0x12345678;

	myFileWriteTBuffer.write(tbuffer.Buffer(),tbuffer.Length());
	
	if(myFileWriteTBuffer.is_open()) myFileWriteTBuffer.close();

What I expect the output to be is (in HEX):
ff 00 95 d6 26 e8 0b 2e 11 3e 00 78 56 34 12

What I see when i look at testTBuffer.hex:
ff 00 3e 11 2e 0b e8 26 d6 95 00 00 00 00 00 12 34 56 78

As you said it switches the bytes around. (What I don’t need because when reading them back from the file one has to switch them again), but you see that instead of a char 0x00, it puts in a zero of 4bytes length.

Cheers,

Lutz

4

Hi,

For various reason (including portability) we selected to store 'long’s as an 8 bytes entiry. Hence you output is correct and would be read back properly (00 00 00 00 12 34 56 78 is the stored value of (long)0x12345678)

Cheers,
Philippe.