Should I be using struct instead?
-
I'm writing an MFC app (the first large project I've ever done) and originally it was quite small, I was using only 1 dialog box. This app, in the end, creates a text file which is then used as input to another program... Anyway, when I first started this, I had the dialog box create a text file, storing all the information that was entered into it (ie. in the edit boxes, etc...) in it's OnOK() function. This text file was then later used to both restore the information if the user re-opened the dialog box, and as the final file produced by the app. Now, my app has grown in size, and I originally stuck to using these "intermediate" text files to store the information for each one. Then right before my app closes, it writes all the data from each of these intermediate files into one large file which is used as input to the other program. At first I didn't see this as being a problem, but yesterday I realized just how much file reading and writing I'm doing, and I began wondering if I should find another way to store the information between instances (if that's the right word?) of a dialog box. I came up with the idea of using a different structure for each dialog box, which will be used to hold all the information obtained by the dialog box. So, I guess my question is, should I switch from using all these little files, to using a bunch of structures? Something tells me that I should switch to using structures, but I want to be sure before I go ahead and do it.
-
I'm writing an MFC app (the first large project I've ever done) and originally it was quite small, I was using only 1 dialog box. This app, in the end, creates a text file which is then used as input to another program... Anyway, when I first started this, I had the dialog box create a text file, storing all the information that was entered into it (ie. in the edit boxes, etc...) in it's OnOK() function. This text file was then later used to both restore the information if the user re-opened the dialog box, and as the final file produced by the app. Now, my app has grown in size, and I originally stuck to using these "intermediate" text files to store the information for each one. Then right before my app closes, it writes all the data from each of these intermediate files into one large file which is used as input to the other program. At first I didn't see this as being a problem, but yesterday I realized just how much file reading and writing I'm doing, and I began wondering if I should find another way to store the information between instances (if that's the right word?) of a dialog box. I came up with the idea of using a different structure for each dialog box, which will be used to hold all the information obtained by the dialog box. So, I guess my question is, should I switch from using all these little files, to using a bunch of structures? Something tells me that I should switch to using structures, but I want to be sure before I go ahead and do it.
One option in MFC would be to create a serializable list of CString objects. Then you would serialize and de-serialize this list to and fro from the file. Serialization helps to decrease the file size a bit, so perhaps you'd want to consider that. If you would create a class which has CString objects and an ID field, you could keep track of what instance of the program each object of the class belongs to. I wouldn't recommend structures: like I said, use classes derived from CObject that have dynamic creation implemented and contain appropriate data members (CStrings & ID). Then just let serialization worry about saving/loading them. -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible.
-
One option in MFC would be to create a serializable list of CString objects. Then you would serialize and de-serialize this list to and fro from the file. Serialization helps to decrease the file size a bit, so perhaps you'd want to consider that. If you would create a class which has CString objects and an ID field, you could keep track of what instance of the program each object of the class belongs to. I wouldn't recommend structures: like I said, use classes derived from CObject that have dynamic creation implemented and contain appropriate data members (CStrings & ID). Then just let serialization worry about saving/loading them. -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible.
I've been reading a bit about serialization and I think you're right about me using that instead of my multiple files I've created or using structures. I've never used serialization before and I didn't even really know what it was until you mentioned it, so I have a couple questions. Would I be serializing the member variables within each dialog box? lets say I have 5 different dialog boxes... After all 5 of these dialogs have all been opened, had information put into them, then get closed (but the program itself is still running), am I still able to access the information that was put into them? (I still need to create one file at the end of program execution, I just wanted to get rid of all the little 'in between' files) Thanks.
-
I'm writing an MFC app (the first large project I've ever done) and originally it was quite small, I was using only 1 dialog box. This app, in the end, creates a text file which is then used as input to another program... Anyway, when I first started this, I had the dialog box create a text file, storing all the information that was entered into it (ie. in the edit boxes, etc...) in it's OnOK() function. This text file was then later used to both restore the information if the user re-opened the dialog box, and as the final file produced by the app. Now, my app has grown in size, and I originally stuck to using these "intermediate" text files to store the information for each one. Then right before my app closes, it writes all the data from each of these intermediate files into one large file which is used as input to the other program. At first I didn't see this as being a problem, but yesterday I realized just how much file reading and writing I'm doing, and I began wondering if I should find another way to store the information between instances (if that's the right word?) of a dialog box. I came up with the idea of using a different structure for each dialog box, which will be used to hold all the information obtained by the dialog box. So, I guess my question is, should I switch from using all these little files, to using a bunch of structures? Something tells me that I should switch to using structures, but I want to be sure before I go ahead and do it.
I am going to have to disagree with the other poster and say do NOT use serialization! What I would do (and have done) in your position is to make some general purpose classes. How specific is your data? You could make a class that knows how to read/write itself, and has members for all the data. Or you could write a more generic class, that can take name=value pairs (such as an INI file.) An example of a simple interface for a class that might look like something you'd use:
class MyData { public: bool ReadDataFromFile(CString filePath); bool WriteDataToFile(CString filePath); void SetSomePieceOfData(CString data); ... private: // Store data as private members, then the ReadDataFromFile and // WriteDataToFile will use them when accessing the text file. CString somePieceOfData; };The reasons I would avoid serialization: 1. It is a nightmare if you ever want to change your file format, or, heaven forbid, you need to access these files from some other non-MFC program. 2. It is difficult to debug. A text file, you can just open it in Notepad and figure out what is going on. Not as easy with serialized data. It is not impossible, there are tools to do it, but it is a pain. No single raindrop believes that it is responsible for the flood. -
I am going to have to disagree with the other poster and say do NOT use serialization! What I would do (and have done) in your position is to make some general purpose classes. How specific is your data? You could make a class that knows how to read/write itself, and has members for all the data. Or you could write a more generic class, that can take name=value pairs (such as an INI file.) An example of a simple interface for a class that might look like something you'd use:
class MyData { public: bool ReadDataFromFile(CString filePath); bool WriteDataToFile(CString filePath); void SetSomePieceOfData(CString data); ... private: // Store data as private members, then the ReadDataFromFile and // WriteDataToFile will use them when accessing the text file. CString somePieceOfData; };The reasons I would avoid serialization: 1. It is a nightmare if you ever want to change your file format, or, heaven forbid, you need to access these files from some other non-MFC program. 2. It is difficult to debug. A text file, you can just open it in Notepad and figure out what is going on. Not as easy with serialized data. It is not impossible, there are tools to do it, but it is a pain. No single raindrop believes that it is responsible for the flood.The data I'm using is fairly specific... it did cross my mind before to write some sort of generic file reading/writing class, but my only concern was the number of times that I actually end up reading and writing each file, not to mention the time taken to parse each of these files... For example: Say I have 5 dialog boxes. Each of these dialog boxes utilizes it's own file. The file is read from when it's initialized (unless it's the first time it's being initialized, in which case the file is just created), and written to when it's closed (only OnOK of the dialog though). Each dialog box will be opened at least once. When the user is done, they click on one of the menu items in the main menu bar and that causes another file to be created and written to, making our grand total of files 6. This last file is just all the other files combined into one large file, and after the large file is written, all the other 5 files are deleted. So, my next idea was to create one structure for each of the 5 dialog boxes. These strucures will all be member variables in the CMainFrame class. So now I'm avoiding creating, writing to/reading from & parsing each of those 5 files, but I'm still easily able to create the 1 large file at the end. So, I still could make the general-purpose file reading/writing class like you suggested, but I still would be performing all these file operations a whole bunch of time... and my little structure idea does seem to avoid all that, but I'm not sure if it's any better...
-
The data I'm using is fairly specific... it did cross my mind before to write some sort of generic file reading/writing class, but my only concern was the number of times that I actually end up reading and writing each file, not to mention the time taken to parse each of these files... For example: Say I have 5 dialog boxes. Each of these dialog boxes utilizes it's own file. The file is read from when it's initialized (unless it's the first time it's being initialized, in which case the file is just created), and written to when it's closed (only OnOK of the dialog though). Each dialog box will be opened at least once. When the user is done, they click on one of the menu items in the main menu bar and that causes another file to be created and written to, making our grand total of files 6. This last file is just all the other files combined into one large file, and after the large file is written, all the other 5 files are deleted. So, my next idea was to create one structure for each of the 5 dialog boxes. These strucures will all be member variables in the CMainFrame class. So now I'm avoiding creating, writing to/reading from & parsing each of those 5 files, but I'm still easily able to create the 1 large file at the end. So, I still could make the general-purpose file reading/writing class like you suggested, but I still would be performing all these file operations a whole bunch of time... and my little structure idea does seem to avoid all that, but I'm not sure if it's any better...
-
Unless you are talking about large quantities of data I would just go with the structure idea. Art
-
I've been reading a bit about serialization and I think you're right about me using that instead of my multiple files I've created or using structures. I've never used serialization before and I didn't even really know what it was until you mentioned it, so I have a couple questions. Would I be serializing the member variables within each dialog box? lets say I have 5 different dialog boxes... After all 5 of these dialogs have all been opened, had information put into them, then get closed (but the program itself is still running), am I still able to access the information that was put into them? (I still need to create one file at the end of program execution, I just wanted to get rid of all the little 'in between' files) Thanks.
After reading your answer to the other poster, I got a fairly good idea what you are doing. I assume that you have this one program (thread) running, which is responsible for creating the dialog boxes. This thread has the CMainFrame class, which is the parent of the dialogs. If this is the case, the most efficient way is, like you first theorized, to create one new class: CDialogData. This class would contain one or more CString members and if necessary, an ID variable of type UINT or similar. Then, you declare an array of pointers (5 sects) as a member variable of the parent class. As each dialog can access the parent class's members via cast-operators and
GetParent, each dialog can create anewobject of CDialogData on the heap and save it's address to the array of pointers. This method would require minimalistic changes to the code itself: only the CDialogData declaration and the necessary modifications to the OnOK methods in question to create an object of CDialogData instead of saving to a file. At the end of program execution, the CMainFrame could go through the list of pointers and attempt a save of the member variables into a file if the pointer is valid (non-NULL). I first thought that the dialog boxes are seperate programs running on seperate threads, in which case you would require inter-process communication or the file-saving technique. -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible.