Writing a struct to file

[Clattaclism]

Lets say i had a structure named student with thier name, age, id number and grade..

typedef struct student
{//for name
char fname[20];
char lname[20];

int age;
char id[20];
int grade[20];
}STUDENT;

how do i write this to file?

[death_knight]

you wanna write the struct it self to a txt file. i guess you gotta use the fopen function with the proper switches (rw) and push the data in. you could probably store the struct as a string if you like. then write the string to the file after fopen.

[Clattaclism]

Yes, i wanna write it to a file. I used the below function to do the saving but its giving probs

#include<stdio.h>
#include<stdlib.h> //to do the exiting

//function to save
void save(STUDENT info){
FILE *savedfile; //pointer

savedfile=fopen("c:/database.txt","w"); //creates a file on drive "c" named "database.txt" to be written to

if(savedfile == NULL) //testing if file is opened
{printf(" Error opening output file");
exit(0);} //from the library stdlib.h. will exit if file is already opened

fprintf(savedfile,"%s", info);/writes struct info to file
fclose(savedfile);//closes file after writing
}

what av i done?

[Clattaclism]

i managed to manipulate it somehow. wudnt mind some suggestion none-the-less.

[Billerg]

i managed to manipulate it somehow. wudnt mind some suggestion none-the-less.

I have not had any real need to code in c for a while so I did what u prolly should have done google it . URl is here. The example they gave is below:

/* Writing */
void write_data( struct user* data )
{
int fd = 0;
/* open the file in append mode */
fd = open( "data.dat", O_RDWR|O_CREAT|O_APPEND );

/* write the binary structure right to the file */
write( fd, (struct user*) user, sizeof( struct user ));
close( fd );
}

you could use it as an example and ur program should be leaner and faster.

[Clattaclism]

This should make it a bit easy and trust mi, i've been googling all day and night. Nuff respect.

[pogi_2nr]

That example billerg gave causes you to lose portability.

Say you use a 32bit little endian machine to write the data.dat file, you wouldnt
be able to load the file later on a big endian machine or a 64bit machine

[Billerg]

c'mon pogi teach mi. What would you suggest a change could be to make it portable?

[crosswire]

That example billerg gave causes you to lose portability.

Say you use a 32bit little endian machine to write the data.dat file, you wouldnt
be able to load the file later on a big endian machine or a 64bit machine

You might have to write two versions of the C code - one for bigindian and little indian

I think the 32 bit version of the program, that is complied from the C code, would run the same on 32 bit machine as it would on a or 64 bit one because the 64 bit would either run it in 32 bit mode or it would not run the code. I would have to compare the assembly instuctions, but if the 32 bit program runs then the size of the data types would change.

If the C code was compiled again on a 64 bit system, then the program would run differently because the data types might have different sizes, eg int may be natively 64bit on a 64 bit machine but it really depends on the compiler and the hardware. Thus the version of the C code, that is compiled on 64 bit machine, must have special implimentation to keep the program it produces compatibly for the 64 bit machine

What is interesting to think about it what would hapens when binary mode is not set (for Windows). The '\n' character is translated to '\r' followed by '\n'. Therefore set binary mode because this byte may occur in the stream that is read or witten and it would be a mistake to let it be translate to cariage return.

Likewise, using fprintf("\n") would give "\r\n" in text mode and just "\n" in binary mode

'/n' = 0x0A
'/r' = 0x0D

I said a mistake about text character set for text mode in the other post, it is the translation of just the '\n' charater that occurs in text mode

A total different topic is the encoding, fprint and fwprintf do two different encodings. fwprintf uses a string in which each character exists as two byte, this is Unicode characters. fprintf use a string in which each character is represented by a byte. This might have lead to my confusion

fwrite is an appropriate function to use instead of fprinft because it writes byte by byte but it still suffers from text mode translation. fprintf can write binary using the format string and some casting but it looks a bit indirect.

[pogi_2nr]

c'mon pogi teach mi. What would you suggest a change could be to make it portable?

Portability isnt a real concern for most people. It bothers me greatly as the C
programs I write normally have to compile and run on windows and a slew of
other unices. Getting the code to compile and run isnt really much trouble but
having it read data files from other platforms is always a concern.

For the scenario presented in this thread I would suggest using unsigned 16bit integers
along with the following function to save the data before writing.

uint16_t htons(uint16_t hostshort)

htons stands for host to network short, basically a function used for packing data for network traffic.

and when you are ready to read the file again unpack it via ntohs()