Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: C++ C file file-system
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 22:42pm
Edited 22-May-13 6:51am
v2
Comments
Richard MacCutchan at 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. at 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 at 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
good
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.
  Permalink  
Comments
Pravinda Ama. at 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 at 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 at 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 at 23-May-13 2:56am
   
Isn't that what I said in my answer?
JackDingler at 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 at 23-May-13 11:23am
   
Then they wouldn't be fixed length would they?
JackDingler at 23-May-13 11:44am
   
They could start as fixed length, then be difficult to maintain later.
Richard MacCutchan at 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 at 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 at 23-May-13 13:34pm
   
But that's my whole point; if the size ever changes then the records are not fixed length.
JackDingler at 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
good
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 application.you can refer MSDN for more details on this
  Permalink  
v2

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

  Print Answers RSS
0 Sergey Alexandrovich Kryukov 504
1 Maciej Los 349
2 Kornfeld Eliyahu Peter 325
3 DamithSL 196
4 OriginalGriff 188
0 OriginalGriff 6,303
1 DamithSL 4,764
2 Maciej Los 4,306
3 Kornfeld Eliyahu Peter 3,914
4 Sergey Alexandrovich Kryukov 3,538


Advertise | Privacy | Mobile
Web04 | 2.8.141220.1 | Last Updated 23 May 2013
Copyright © CodeProject, 1999-2014
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