Hi Dale,
If you want to produce data files that have certain content and structure, the
traditional (and usually best) approach is to have a program that contains code
for writing (and perhaps reading) such files.
In the example code you supplied, the most straight-forward approach to your
probem would be to write a function (or perhaps a method on the gFast struct)
that can write the struct's fields to a file (or more generally, some output
stream). For example:
// Returns 'true' if and only if the write operation was successful
bool write_gFast(ostream & s, const gFast & g) {
s << g.entries << g.size << g.cnt;
int bytesOfData = g.entries * g.size; // Is this formula right?
bool success = s.write(g.data, bytesOfData);
return success;
// Note: I *think* this is an ok way to check the status of a write
// operation, but you should double-checked the C++ documentation.
}
// Returns 'true' if and only if the read operation was successful
bool read_gFast(istream & s, const gFast & g) {
s >> g.entries >> g.size >> g.cnt;
int bytesOfData = g.entries * g.size; // Is this formula right?
g.data = new char[bytesOfData];
// (You should somehow ensure that the "new" command didn't return NULL)
bool success = s.read(g.data, bytesOfData);
return success;
// Note: I *think* this is an ok way to check the status of a read
// operation, but you should double-checked the C++ documentation.
}
Then your main code might look like this. (You should double check the C++ docs
on the header files needed for ifstream and ofstream.)
#include <iostream>
#include <fstream>
using namespace std;
...
// To write a data file. (Assumes you already have a gFast instance set up
// with the values you want to appear in the file...
ofstream outFile("someNewFile", "w");
bool success = write_gFast(outFile, someGfastInstance);
HTH,
Christian
Dale Walsh wrote:
I'm trying to generate data files however it seems to be prepending 244
bytes of data and I can't see how to prevent this.
The actual data files are very large and manually using a hex editor to
generate them isn't appealing considering there are about 300 of them.
Here is my test compile session with a reduced file with 2 rows of 10
bytes so the file should be 32 bytes in length.
test.c: (combined header and source)
___________________________
typedef struct
{
/* # of entries in data */
int entries;
/* entry size and count */
int size;
int cnt;
/* data; array of bytes, one row after another. */
char *data;
}
gFast;
/* Location functions take these. */
typedef gFast * gFastPtr;
char TestDATA[20];
gFast gFastTestRep = {
2,
2,
10,
TestDATA
};
gFastPtr gFastTest = &gFastTestRep;
/*
this is all the data
the file should be 32 bytes in length
20 bytes of data and 12 bytes for header
*/
char TestDATA[] = {
/* Entry 000 */
1,2,3,4,5,6,7,8,9,10,
/* Entry 001 */
11,12,13,14,15,16,17,18,19,20,
};
___________________________
compiled with:
gcc -pipe -static -c -o test.out test.c
___________________________
Here's the resulting file content, there are always 244 leading bytes
of data that I can't have, the stuff appended to the end would also be
nice to not have however it wont interfere with the file being valid to
the application and isn't as critical.
mustangrestomods:/temp2/clamav-0.80 root# hexdump -vC test.out
00000000 fe ed fa ce 00 00 00 12 00 00 00 00 00 00 00 01
|................|
00000010 00 00 00 02 00 00 00 d8 00 00 20 00 00 00 00 01 |..........
.....|
00000020 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 00
|................|
00000030 00 00 00 00 00 00 00 00 00 00 00 28 00 00 00 f4
|...........(....|
00000040 00 00 00 28 00 00 00 07 00 00 00 07 00 00 00 02 |...
(............|
00000050 00 00 00 00 5f 5f 74 65 78 74 00 00 00 00 00 00
|....__text......|
00000060 00 00 00 00 5f 5f 54 45 58 54 00 00 00 00 00 00
|....__TEXT......|
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f4
|................|
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
00000090 00 00 00 00 00 00 00 00 5f 5f 64 61 74 61 00 00
|........__data..|
000000a0 00 00 00 00 00 00 00 00 5f 5f 44 41 54 41 00 00
|........__DATA..|
000000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 28
|...............(|
000000c0 00 00 00 f4 00 00 00 02 00 00 01 1c 00 00 00 02
|................|
000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02
|................|
000000e0 00 00 00 18 00 00 01 2c 00 00 00 03 00 00 01 50
|.......,.......P|
000000f0 00 00 00 24 00 00 00 02 00 00 00 02 00 00 00 0a |...
$............|
00000100 00 00 00 14 00 00 00 00 01 02 03 04 05 06 07 08
|................|
00000110 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 00 00 00 10
|................|
00000120 00 00 02 40 00 00 00 0c 00 00 02 40 00 00 00 0f
|...@.......@....|
00000130 0f 02 00 00 00 00 00 14 00 00 00 19 0f 02 00 00
|................|
00000140 00 00 00 10 00 00 00 01 0f 02 00 00 00 00 00 00
|................|
00000150 00 5f 67 46 61 73 74 54 65 73 74 52 65 70 00 5f
|._gFastTestRep._|
00000160 54 65 73 74 44 41 54 41 00 5f 67 46 61 73 74 54 |
TestDATA._gFastT|
00000170 65 73 74 00 |est.|
00000174
-- Dale
--
Christian Convey
Computer Scientist,
Naval Undersea Warfare Centers
Newport, RI
