Click here to Skip to main content
13,002,133 members (77,233 online)
Rate this:
Please Sign up or sign in to vote.
When programming in C/C++ you will need to store some data for the use of your application, obviously. For this you'll use the RAM. If the size of your data will be increased or decreased, you will use different data structures like linked lists, trees, hatches...etc.

Everything is just fine up to that point. But when your program terminates, that data, which is stored in the RAM will be cleared. To load your data back, you'll need to save it to a disk.

My Question Is:

If you want to write your program's data to a file, how can you achieve this ? What are the basics of designing a file type ? The data can be ;

~ A single data-structure (maybe a linked list..)
~ Many data-structures (maybe 4 tree-structures)

How do the programs like MS Word, PowerPoint, Photoshop... achieve this ?
Posted 21-May-13 21:42pm
Updated 22-May-13 5:51am
Richard MacCutchan 22-May-13 12:47pm
You have edited this question to move it up the priority list, but I don't see any significant changes from the original. What further information are you expecting?
Pravinda Ama. 22-May-13 12:59pm
Oh, yes I did. I'm looking for some tutorials or any other guidance ! Any help with that pls ?
Richard MacCutchan 22-May-13 13:08pm
I hate to tell you this, but I have just compared the two versions, and apart from highlighting "designing a file type", there is no difference. If you want some articles or tutorials then you should make use of Google, although the information I gave you earlier should be ebnough to get you thinking. If you want to see a very complex structured file then look at Adobe's PDF Reference.
Rate this: bad
Please Sign up or sign in to vote.

Solution 1

You just need to design a structure for your file that will allow you to write the data such that you can read it back and re-create the memory content. If your data is fixed size then you can just write in fixed length blocks, if it is variable then you need to write control fields at the beginning of each record to show how long it is. For example a simple structure would be something like:
Word0 : record type, some value indicating the content of this record.
Word1 : length, the size of the following data in bytes, or words as appropriate.
Word2 to N : data content
// repeated for all data

Then to write your file you just need to go through all the data in memory and for each item, write the control word, followed by the length, followed by the actual data. The last record should be followed by a control word that indicates end of data. Reading it back into memory is just the reverse of this process.
Pravinda Ama. 22-May-13 4:49am
You are saying, the data should be stored as a sequence. If the size of a one record is constant, then the case is very easy. If not you have to do something like marking an end of a record. Isn't it ?
Richard MacCutchan 22-May-13 5:20am
No, as I said above, you specify the record length at the beginning, so you know how much data to write to, or read from, the file.
JackDingler 22-May-13 17:02pm
It's a good idea to mark the beginning of the record with the size, and some code to describe the record type.

A header record at the beginning with some basic info and a padded reserved area is a good idea too.

You'll be glad later that you did these things.
Richard MacCutchan 23-May-13 2:56am
Isn't that what I said in my answer?
JackDingler 23-May-13 10:50am
You mentioned that if the record length is variable, to do this.
I think it's a good idea regardless, because even fixed length records may need updating later.
Richard MacCutchan 23-May-13 11:23am
Then they wouldn't be fixed length would they?
JackDingler 23-May-13 11:44am
They could start as fixed length, then be difficult to maintain later.
Richard MacCutchan 23-May-13 11:54am
Yes, but that means they are not fixed length. Fixed length records never change their size, only their content.
JackDingler 23-May-13 12:10pm
Never change their size? Like fixed length DBF records?

I've been down the rabbit hole of maintaining fixed length records in file formats. Adding additional fields and playing games with fitting multiple structure types into the same record length, leads to difficult to maintain code.

So my advice is the same, don't use them unless you have a good reason to.

DBF files are a good implementation of fixed length records, that are defined in a file header.
Richard MacCutchan 23-May-13 13:34pm
But that's my whole point; if the size ever changes then the records are not fixed length.
JackDingler 23-May-13 15:12pm
They never change until requirements change...
Then they change. But until they change, they don't change....

This is why the Microsoft API contains fixed length structures with a size member for versioning, because the the API needs to be backwards compatible with older applications.
Rate this: bad
Please Sign up or sign in to vote.

Solution 2

While processing with files, maintain following thumb rules
1. collect all the data required in your own defined data structure like, linked list or structures etc.
2. Before exiting the program, open the file
3. dump all the data to the file.
4. close the file

make sure that you open the file only once for writing and close it immediately.

Generally when we do file operations it is also important to write Checksum at the end of file, so whenever file contents changes update the checksum. it could be CRC or MD5 checksum.

Generally if you are working with windows based applications you can define your own type and load the files of your type with your can refer MSDN for more details on this

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month

Advertise | Privacy | Mobile
Web02 | 2.8.170624.1 | Last Updated 23 May 2013
Copyright © CodeProject, 1999-2017
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100