readme.htm

完全免费的邮件发送程序。delphi 6.0

<TR><TD><A HREF = "testspat.cxx">testspat.cxx</A></TD>
    <TD>rectangle, R-tree, hash table</TD></TR>
<TR><TD><A HREF = "testperf.cxx">testperf.cxx</A></TD>
    <TD>T-tree insert, find and remove operations</TD></TR>
</TABLE><P>


<H2><A NAME = "stl">Using STL classes with POST++</A></H2>
It is possible to store and retrieve STL classes from the POST++ storage.
POST++ provides special STL allocator and redefined operators new/delete
for making STL objects persistent. There are several models of making STL 
classes persistent, controlled by the following macros:

<DL>
<DT><CODE>USE_MICROSOFT_STL</CODE>
<DD>Uses Microsoft STL classes, which are shipped with Microsoft Visual C++ 
compiler. This library is not fully complaint with C++ STL standard.
<DD><DT><CODE>USE_STD_ALLOCATORS</CODE>
<DD>Implements allocators as specified in the C++ standard. 
Allocator object is included in the STL object and instance methods of
the allocator object are used for space allocation/deallocation.
So it is possible to implement "smart" allocators: allocator will 
allocate space for the object in the POST++ storage only when the object 
containing this allocator was also placed in the storage. Otherwise, space
for the object will be allocated in the normal way by standard 
<code>malloc()<code> function. 
This option can be used with SGI STL library as well as with 
Microsoft STL library. Note that standard-conforming allocators in SGI
STL use many language features that are not yet widely implemented.  
In particular, they rely on
member templates, partial specialization, partial ordering of function
templates, the typename keyword, and the use of the template keyword
to refer to a template member of a dependent type. So only few C++ compilers
will be able to compile SGI STL library when this macro is defined.
If this macro is not set, then POST provides allocator with static member 
functions and all objects are allocated in the POST++ storage. Only one POST++ 
storage can be opened at each moment of time by the application which uses such
allocator. 
<DD><DT><CODE>REDEFINE_DEFAULT_ALLOCATOR</CODE>
<DD>
There two ways of making STL object persistent.
One way is to introduce new type:
<PRE>
typedef basic_string&lt;char, char_traits&lt;char&gt;, post_alloc&lt;char&gt; &gt; post_string;
</PRE>
Another way is to made all classes persistent capable. When 
<code>REDEFINE_DEFAULT_ALLOCATOR</code> macro is defined, any STL class can be allocated in the POST++ storage. To create new object in
the persistent storage, you should specify the storage as extra parameter of 
new operator. If storage is omitted, then object will be allocated using 
standard <code>malloc()</code> function.
</DL><P>

POST++ interface to STL do not require any changes in STL classes so you can 
use any STL implementation you want. But as a result, STL classes don't 
contain type descriptors and so POST++ has no information about format of STL 
objects. So POST++ is not able to perform garbage collection and references 
adjustment. When STL interface is used POST++ storage should be always mapped 
to the same virtual address. If you pass <code>storage::fixed</code> flag 
to the <code>storage::open(int flags)</code> method, then POST++ will report
error and <code>open</code> will return <code>false</code> if it is not 
possible to map the storage to the same memory address. But if your 
application is working only with one storage and do not map other object on
virtual memory, then in almost all operating it will be possible to map the
storage to the same memory address.<P>

POST++ interface to STL library is defined in 
<A HREF="post_stl.h">post_stl.h</A> header file. This file should be included
before any STL include file. Also macros <code>REDEFINE_DEFAULT_ALLOCATOR</code>
, <code>USE_STD_ALLOCATORS</code> and <code>USE_MICROSOFT_STL</code> should
be defined before <code>post_stl.h</code>.<P>

POST++ contains example of working with STL++ classes 
<A HREF="stltest.cxx">stltest.cxx</A>. This example uses two STL classes - 
<code>string</code> and <code>vector</code>. The lines readen from standard 
input are pushed in the vector and when program is started once again all 
elements of the vector are printed to the standard output. 
This example is included in default target of the makefile for 
Microsoft Visual C++ (it uses Microsoft  STL classes shipped with VC). 
You can also try to build this test with
some other version of STL library but do not forget about
<code>REDEFINE_DEFAULT_ALLOCATOR</code> and <code>USE_STD_ALLOCATORS</code> 
macros. This example was also tested with SGI STLport 3.12 and GCC 2.8.1.<P>


<H2><A NAME = "new">Replacing of standard allocators</A></H2>

In previous section I explain how to use POST++ with STL library.
But there are a lot of other C++ and C libraries and application which
you can want to use, but which don't provide such flexible allocators
mechanism as STL. In this case the only possible solution (if you do not want
or can not change sources of these libraries) is replacing of 
standard allocation mechanism with one provided by POST++. So any
dynamically allocated object will be created in POST++ storage 
(only one storage can be used in this case).<P>

POST++ distribution contains file
<code>postnew.cxx</code> which redefines standard <code>malloc, free, 
realloc</code> and <code>calloc</code> functions. When storage is opened, 
all objects are allocated in this storage. Otherwise <code>sbrk()</code>
function is used for allocating objects (space allocated for such 
object is not reclaimed). It is possible not to touch this standard C 
allocation functions and redefine only default C++ operator new and delete.
To do it defined <code>DO_NOT_REDEFINE_MALLOC</code> macro when compiling
<code>postnew.cxx</code>. Object file produced from <code>postnew.cxx</code>
should be passed to the linker before standard C library.<P>

As an example of such POST++ usage you can look at <code>testnew.cxx</code>
and <code>testqt.cxx</code>. First one illustrate how standard C++
arrays are made persistent. And second one illustrate how POST++ can be used
with Qt class library.<P>

As far as POST++ has no information about format of stored classes
there are some restrictions on POST++ usage:<P>

<OL>
<LI>Classes with virtual functions are not supported (POST++ is not able to 
properly initialize pointers to virtual function tables).
<LI>Implicit memory deallocation (garbage collection) is not possible - POST++
has no information about location of pointers inside objects.
<LI>Storage should always be mapped to the same virtual address because POST++
is not able to adjust pointers if base address is changed. 
</OL>

If all these restrictions are not critical for your application, you can 
made it persistent without almost any code modification. This approach can be
used both for C and C++ programs.<P>


<H2><A NAME = "usage">How to use POST++</A></H2>

There are some examples of classes and application for POST++. 
The simplest of them is game <I>"Guess an animal"</I>. Algorithm of
this game is very simple and the result looks rather impressive 
(something like artificial intelligence). Moreover this game is very good 
example, illustrating benefits of persistent object storage. 
Sources of this game are in file <A HREF = "guess.cxx">guess.cxx</A>. 
Building of this game is included in default make target. 
To run it just execute <CODE>guess</CODE>.
<P>

<B><I>Unix specific: </I></B> 
When you will link your Unix application with POST++ library 
and persisent objects in application contain virtual functions, please do not 
forget to recompile <A HREF = "comptime.cxx">comptime.cxx</A> file and include
it in the linker's list. This file is necessary for POST++ to
provide executable file timestamp, which is placed in the storage and 
used to determine when application is changed and reinitialization
of virtual function table pointers in objects is needed. 
<B><I>Attention!</I></B> This file should be recompiled each time your are 
relinking your application. I suggest you to make compiler to call linker for
you and include <CODE>comptime.cxx</CODE> source file in the list of object 
files for the target of building executable image 
(see <A HREF = "makefile">makefile</A>).<P>


<H2><A NAME = "debugging">Specific of debugging POST++ applications</A></H2>

Information in this section is meaningful only for application using
transactions. POST++ uses page protection mechanism to provide creation of 
shadow page on the original page modification, After storage opening or
transaction commit all mapped on file pages are read-only protected.
So any attempt to modify contents of the object allocated at this page will
cause access violation exception. This exception is handled by 
special POST++ handler. But if you are using debugger, it will 
catch this exception first and stop application. If you want to debug
your application you should do some preparations:

<UL>
<LI> In Unix it is enough to tell debugger not to catch SIGSEGV signal.
For example for GDB it can be done with command: 
<CODE>handle SIGSEGV nostop noprint pass</CODE>. If SIGSEGV signal
is not caused by storage page protection violation, but due to a bug
in your program, POST++ exception handler will "understand" that it is
not his exception and send SIGABRT signal to the self process, which
can be normally catched by debugger.

<LI> In Windows POST++ uses unhandled exception filter to
handle storage page protection violations. Unfortunately it is impossible
to make Microsoft Debugger to ignore unhandled exceptions. If you
are going to debug your application, you should enclose all your program code 
(<CODE>main</CODE> or <CODE>WinMain</CODE> function) with structured 
exception block. You should always use structured exception handling 
with Borland C++, because Unhandled Exception Filter is not correctly called 
in Borland. Please use two macros <CODE>SEN_TRY</CODE> and 
<CODE>SEN_ACCESS_VIOLATION_HANDLER()</CODE> to enclose body of main 
(or WinMain) function:

<PRE>
      main() { 
          SEN_TRY { 
               ...
          } SEN_ACCESS_VIOLATION_HANDLER();
          return 0;
      }
</PRE>

Be sure that Debugger behavior for this exception is "Stop if not handled"
and not "Stop always" (you can check it in Debug/Exceptions menu).
In file <A HREF = "testrans.cxx">testrans.cxx</A> you can find example of
using structured exception handling.
</UL>


<H2><A NAME = "PS">Some more information about POST++</A></H2>

POST++ is freeware. It is distributed in hope of been useful. You can do
with it anything you want (with no limitation on distributing products
using POST++). I will be glad to help you in using POST++ and receive
all kind of information (bug reports, suggestions...) about POST++.
Freeware status of POST++ doesn't mean lack of support. I promice you to
do my best to fix all reported bugs. Also e-mail support is guaranteed.
POST++ can be used for various purposes: storing information between session,
storing object system in file, snapshots, informational systems...
But if you fill that you need more serious object oriented database for your
application supporting concurrency, distribution and transactions,
please visit <A HREF = "http://www.ispras.ru/~knizhnik/goods.html">
GOODS (Generic Object Oriented Database System) home page</A>. 

<HR>
<P ALIGN="CENTER"><A HREF="http://www.ispras.ru/~knizhnik">
<B>Look for new version at my homepage</B></A><B> | </B>
<A HREF="mailto:[e-mail]">
<B>E-mail me about bugs and problems</B></A></P>
</BODY>
</HTML>