Click here to Skip to main content
Click here to Skip to main content

Memory mapped files and flat table primitives.

By , 6 Apr 2003
 

Introduction

Let's say you need to store and read an array of some structures to or from the hard drive in your application.

For instance: you may have a structure like this:

struct record {
  char first_name[32];
  char last_name[64];
  
  record() { first_name[0] = 0; last_name[0] = 0; }
  void set(const char* first, const char *last)
  {
    strncpy(first_name, first, sizeof(first_name)-1);
    strncpy(last_name, last, sizeof(last_name)-1);
  }
};

And you would like to persist an array of them.

Instead of using expensive (in many senses) classical database solution, you may write the following:

#include "tl_mm_file.h"

int main(int argc, char* argv[])
{
  tool::table<record> tbl;

/* writing/creating table of "record"s */
  tbl.open("c:/test.tbl",true);

  tbl[0].set("Andrew","Fedoniouk");
  tbl[1].set("Allan","Doe");
  tbl[2].set("Monica","Lester");

  tbl.close();

/* reading it */
  tbl.open("c:/test.tbl");
  for(unsigned int i = 0; i < tbl.total(); i++)
    printf("%s %s\n",
      tbl(i).first_name, 
      tbl(i).last_name );

  tbl.close();
 return 0;
}

You just need to include mm_file.h and mm_file.cpp in your project and you are done.

Pros

  1. Easy and fast. This method of accessing persistent data has nearly zero time overload for opening/closing datasets and eliminates need of intermediate buffers a.k.a. "current record".
  2. It provides direct access to the records in the table in a random manner.
  3. Compact and self-sufficient implementation.

Cons

  1. Only fixed size structures are supported.
  2. Access by key (hash-table, b-tree, etc.) should be implemented separately (if needed).

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

About the Author

c-smile
Founder Terra Informatica Software
Canada Canada
Member
Andrew Fedoniouk.
 
MS in Physics and Applied Mathematics.
Designing software applications and systems since 1991.
 
W3C HTML5 Working Group, Invited Expert.
 
Terra Informatica Software, Inc.
http://terrainformatica.com

Sign Up to vote   Poor Excellent
Add a reason or comment to your vote: x
Votes of 3 or less require a comment

Comments and Discussions

 
Hint: For improved responsiveness ensure Javascript is enabled and choose 'Normal' from the Layout dropdown and hit 'Update'.
You must Sign In to use this message board.
Search this forum  
    Spacing  Noise  Layout  Per page   
GeneralVery Good StuffmemberAbhishekBK28 Apr '06 - 0:08 
QuestionCan you add multi-table support?member任远科9 Jan '04 - 20:13 
AnswerRe: Can you add multi-table support?memberc-smile9 Jan '04 - 21:22 
GeneralRe: Can you add multi-table support?member任远科10 Jan '04 - 6:10 
GeneralGood approach but...memberDimitris Vassiliades9 Apr '03 - 11:51 
GeneralRe: Good approach but...memberc-smile9 Apr '03 - 12:34 
GeneralRe: Good approach but...memberraminx14 Apr '03 - 21:54 
GeneralRe: Good approach but...memberc-smile15 Apr '03 - 8:12 
raminx wrote:
what features have you used that CMemFile wouldn't provide?
 
OK, here goes sacred knowledge about mm files:
 
MFC::CMemFile creates file ALIKE temporary memory buffer. After "closing" it all information is gone. It just frees memory.
 
mm_file (memory mapped file) on the contrary, it physically creates file and maps a section of the file to memory (RAM). It use plain memory pointers to access file data "directly". After closing such file you will have your data stored on the disk automatically (persisted). And you can reopen it and access your data in the next app. session in the same manner.
 
Therefore you'll have persistent table data with random access like an array in memory.
With near zero time for opening/closing/access operations and amount of code.
 
Pretty much as DBF file engine implementation. But in 80 lines of code.
 
raminx wrote:
why did you use different operators for reading & writing
 
It is possible to change "()" on to " const& [] const".
But for explicit call of "read-only []" you need to declare your table variable as
const table myTableReadOnly;
Without const modifier C++ will always use "writing []".
 
My personal preference is to use separate operator () just to be sure that I am calling right function.
 
Cheers!
 
Andrew Fedoniouk.
Terra Informatica Consulting.
GeneralRecommendationsmemberpeterchen7 Apr '03 - 1:21 
GeneralThanksmemberjhaga7 Apr '03 - 0:30 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Permalink | Advertise | Privacy | Mobile
Web01 | 2.6.130516.1 | Last Updated 7 Apr 2003
Article Copyright 2003 by c-smile
Everything else Copyright © CodeProject, 1999-2013
Terms of Use
Layout: fixed | fluid