[RESOLVED] fwrite not working

Hi,
I am trying to create a file using fwrite. I am using VS2008 & Vista,

Code:

---

#include "stdafx.h"
#include <stdio.h>
#include <conio.h>
struct lib{
        char bname[30];
        int id;
        float price;
};

int _tmain(int argc, _TCHAR* argv[])
{
       

 

        FILE* fp;

        struct lib libVar;
        int k;

       
        fp=fopen("data.tmp", "wb+");
        if(fp==NULL)
                printf("Error");
        printf("Enter book name\n");
                gets(libVar.bname);
        printf("Enter id\n");
        scanf("%d", &libVar.id);
        printf("Enter price\n");
        scanf("%f",&libVar.price);
        k=fwrite(&libVar,sizeof(libVar), 1, fp);
        printf("k=%d\n", k);
        fclose(fp);

        return 0;
}

---

I CANT SEE THE FILE. k=1 printed. Can somebody plz help me to find out the problem why this file is not being created???

Zulfi.

The file is being written to, so it must exist. Where did you look for the file?

I made a search. I checked in the project folder. I ran the same program with Turbo C also. Its creating file in TC folder but its 0 bytes.

Kindly guide me.


Zulfi.

the file will be created in the current working directory, so it depends where the program is run from...

I just ran your code. it made a file with non-zero size. You must be looking at the wrong file.

Quote:

---

Originally Posted by Zulfi Khan2

I made a search. I checked in the project folder. I ran the same program with Turbo C also. Its creating file in TC folder but its 0 bytes.

---

Why not remove all doubts, and use full path names?

Code:

---

fp=fopen("c:/some_directory/data.tmp", "wb+");

---

Now you know where the file will be created.

Regards,

Paul McKenzie

Hi,
Thanks for your help. I was using wrong slashes and the code for TC also misses the fwrite command. fwrite is returning 1 maybe because its 1 record.

Quote:

---

fread() and fwrite() return the number of items successfully read or
written (i.e., not the number of characters).

---

If I check the properties file size is 40 bytes.

Code:

---

struct lib{
        char bname[30];
        int id;
        float price;
};

---

For the above structure, it should be 36.

Zulfi.

doesnt structure size depend on padding?

The size of a structure is not obviously equal to the sum of its member sizes because they are aligned on a given boundary.
See Structure Alignment.

Quote:

---

Originally Posted by Zulfi Khan2

Hi,
For the above structure, it should be 36.

---

No.

The size of that struct is this:

Code:

---

sizeof( lib )

---

Regards,

Paul McKenzie

Quote:

---

Originally Posted by Paul McKenzie

No.

The size of that struct is this:

Code:

---

sizeof( lib )

---

---

Yes. For that reason the sizeof operator has been invented. ;)

Hi,
Thanks for your attention. I dont know how this sizeof works in VC but in turboc its giving me 36.

Zulfi.

I would guess that sizeof(int) = 2 for turboc.

Most compilers will align on 4 or 8 byte boundaries, unless
the programmer specifies otherwise.

Quote:

---

Originally Posted by Zulfi Khan2

Hi,
Thanks for your attention. I dont know how this sizeof works in VC but in turboc its giving me 36.

---

The sizeof() works as its supposed to work.

The number of bytes that structure takes up is sizeof(that struct). It isn't 36, 38, 40, or whatever other "hard-coded" number you can think up. If you get an interview question, and the interviewer shows you a struct or class and asks you "how big is this struct s, in bytes?", there is only one right answer -- sizeof( s ). If you sit there and start counting the members and adding up a number, a competent interviewer will clearly see you're either a beginner or not a very good C or C++ programmer.

The compiler is free to add whatever space in-between and/or after the members. Usually, the compiler will attempt to align the members in memory so that it is advantageous for the underlying OS to access that member. Therefore the total number of bytes that the struct takes up is whatever the compiler says it is, because it is the compiler that is responsible for laying out the members in memory in whichever way it sees fit.

Last, as Philip pointed out, ints, floats, doubles, etc. can be different sizes depending on compiler and environment. Unlike Java, C++ has no set size for data types (except for char). There are rules in C++ stating which types must be at least as large as another type, but no concrete number as to how large an individual data type should be (again, except for char, which must be 1 byte).

Regards,

Paul McKenzie

Once, I was asked at an interview "Which is the size of char, short, int, and long".
My answer was "I don't care because I have the sizeof operator".
"Hmmm... depends..." said the interviewer and I didn't get the job. :D ;)

Resuming by short what Paul already stated:
The only one C/C++ type for which the sizeof is guaranteed known is (signed, unsigned) char.
The rest are implementation-defined, i.e. depend on each particular compiler.

sizeof(char) = 1
But there is nothing to say how many bits are used to define it.
On some processors this may be more than 8, so a 'char' may be larger than the common understanding of a 'byte'.
(This is not very common, but may be true for some embedded processors or DSPs.)

[ off-topic ]

AFAIK, French programmers use octet instead of byte.
However, ISO is not a French standard: :)

Quote:

---

C++0x Draft
The fundamental storage unit in the C++ memory model is the byte. A byte is at least large enough to contain
any member of the basic execution character set (2.3) and the eight-bit code units of the Unicode UTF-8
encoding form and is composed of a contiguous sequence of bits, the number of which is implementation-defined.

---

<The compiler is free to add whatever space in-between and/or after the members. Usually, the compiler will attempt to align the members in memory so that it is advantageous for the underlying OS to access that member. Therefore the total number of bytes that the struct takes up is whatever the compiler says it is, because it is the compiler that is responsible for laying out the members in memory in whichever way it sees fit.>

Okay, thanks for your guidance on this. I thought there are definite rules for calculation of size of struct. So it maybe possible that its value can vary in different programs for the same struct or even in the same program for same struct(ural) composition (i.e if we have another struct with similar fields).

Zulfi.

Yes, although it's reasonably safe to assume that two structs in the same program which have members of the same type in the same order will have the same memory layout, even if their fields have different names.

There are (nonstandard) compiler options you can use to explicitly disable padding in struct layouts. This can be useful for networking, for instance.