dcsimg
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 6 of 6

Thread: [RESOLVED] Converting FILE to Serialize()

  1. #1

    [RESOLVED] Converting FILE to Serialize()

    I have an application that uses standard C fopen() to read and write the files to disk. I am wanting to convert lots of classes to Serialization, primarily for the option of storing the classes in memory, so that I can implement an undo/redo function.

    1) To use serialization, do I have to derive from CObject to use serialization? My main document class and subclasses have large arrays and lists of structures, (primarily vertex lists and arrays) that I don't want to derive from CObject, because it will add a lot of memory overhead on each instance of a vertex.

    2) Is there a simple way to convert existing FILE code to streams, or do I have to rewrite everything as streams?

    3) Is there a way to memcpy to a stream? The stream code needs to be fast, as it will be used to store a memory copy of the document every time the user changes anything. I have some large blocks of structures(structs/arrays) that will be simplest, and I would expect most efficient, to memcopy a block of data straight into the stream if this is possible.

    4) I am thinking of leaving the normal text format load/save code in place, and adding the serialization code purely for in-memory saves during run. Is this OK, or is this an abomination to OO code?
    I am thinking this way, because the stream code needs to be fast, and the existing text-format saving code already handles many old file format versions, and mechanisms are in place to seamlessly handle new versions, and it would be a pain to redo all of this into the streams code. It's also nicer to keep the existing text file formats for load/save, while using faster binary formats for the undo/redo. So, is this normal and OK to do this?

    Thanks for your help! (I hope this is not too many questions for one post)

  2. #2
    Lindley is offline Elite Member Power Poster
    Join Date
    Oct 2007
    Location
    Seattle, WA
    Posts
    10,895

    Re: Converting FILE to Serialize()

    Quote Originally Posted by surfdabbler View Post
    1) To use serialization, do I have to derive from CObject to use serialization? My main document class and subclasses have large arrays and lists of structures, (primarily vertex lists and arrays) that I don't want to derive from CObject, because it will add a lot of memory overhead on each instance of a vertex.
    I don't see why that would be necessary. I assume by the name that CObject is an MFC thing? Plenty of non-MFC classes use serialization.

    2) Is there a simple way to convert existing FILE code to streams, or do I have to rewrite everything as streams?
    For the most part, everything you can do when writing to a FILE* can be mapped directly to a corresponding ostream method. *Reading* from a FILE* is a bit trickier-----so far as I know, there is no obvious way to match a specific literal string on read like you can with the scanf functions except by reading the appropriate number of characters and checking them. But most everything else maps directly.

    3) Is there a way to memcpy to a stream?
    Unformatted IO, which I believe is done via ostream::write and istream::read. Best you can do.

    4) I am thinking of leaving the normal text format load/save code in place, and adding the serialization code purely for in-memory saves during run. Is this OK, or is this an abomination to OO code?
    I am thinking this way, because the stream code needs to be fast, and the existing text-format saving code already handles many old file format versions, and mechanisms are in place to seamlessly handle new versions, and it would be a pain to redo all of this into the streams code. It's also nicer to keep the existing text file formats for load/save, while using faster binary formats for the undo/redo. So, is this normal and OK to do this?
    It's a bit unusual to support both iostreams and FILE*s, but supporting both a fast binary format and a robust ASCII format is both a good idea and fairly common.

  3. #3
    Join Date
    Sep 2004
    Location
    Holland (land of the dope)
    Posts
    4,123

    Re: Converting FILE to Serialize()

    Serialization is a bad concept (in my opinion). It loads data usually from disk as soon as your document window is opened. This is the problem, because it means that you have to open a window to load a document. It may look fine, but what are you going to do when you want to open a file WITHOUT opening a window ? Sometimes you want to do something with the file that doesn't need user interaction.

    A better way of handling is pre-loading the data somewhere in your app and as soon as the user needs a document window, you create the window and pass some sort of pointer to the window so it can use the pre-loaded data. This way you can also use the data when there is no window active.

  4. #4
    GCDEF is offline Elite Member Power Poster
    Join Date
    Nov 2003
    Location
    Florida
    Posts
    12,561

    Re: Converting FILE to Serialize()

    Quote Originally Posted by Skizmo View Post
    Serialization is a bad concept (in my opinion). It loads data usually from disk as soon as your document window is opened. This is the problem, because it means that you have to open a window to load a document. It may look fine, but what are you going to do when you want to open a file WITHOUT opening a window ? Sometimes you want to do something with the file that doesn't need user interaction.

    A better way of handling is pre-loading the data somewhere in your app and as soon as the user needs a document window, you create the window and pass some sort of pointer to the window so it can use the pre-loaded data. This way you can also use the data when there is no window active.
    If you're talking about MFC serialization, the framework does create a view and deserialize a document when you open a document using the framework it, but you can open, close and serialize files directly yourself without any views or windows involved.

  5. #5

    Re: Converting FILE to Serialize()

    Quote Originally Posted by Lindley View Post
    I don't see why that would be necessary. I assume by the name that CObject is an MFC thing? Plenty of non-MFC classes use serialization.
    Cool. I am using MFC for most of my application, so I'm kind of tied to that anyway, but I won't be deriving from CObject for my own classes. The trick is getting the standard MFC collection classes to work with my non-CObject item classes.

    Currently, I process all my text files with fgets, and then use sscanf to process each line. I am using CFile/CMemFile for my new serialization operations, it doesn't look like there is any way to make these handle line-by-line processing of a file, which is pretty lame. Is there a way?

    Quote Originally Posted by Lindley View Post
    It's a bit unusual to support both iostreams and FILE*s, but supporting both a fast binary format and a robust ASCII format is both a good idea and fairly common.
    Good to know. Now once again, the trick is getting the two to work together in something that fits with MFC.

    I think the binary and ascii formats will be implemented totally seperately anyway, so I think I'll just write a completely new set of functions for binary saving to a CArchive, and throw an CMemFile at it. Would be nice to make use of some of the ASCII code in the short term, but I think it's just going to get messy if I don't keep them totally seperate. It's a mild annoyance maintaining 2 seperate serialization codes, but I think the benefits are there, so it's probably the better solution.

    Thanks for your help! It's resolved far enough that I can get on with it now.

  6. #6

    Re: [RESOLVED] Converting FILE to Serialize()

    Yep, it does work. CArchive works with a CFile, and you can give it a derived CFile class, such as CMemFile, and the serialize function will then write to the CMemFile. Keith Rule's CUndo class at codeproject uses this method, and I just got the basics of it working in my app.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width




On-Demand Webinars (sponsored)