wilson@cs.utexas.edu (Paul Wilson) wrote:

>You might want to just use the Texas Persistent store, a free (GPL)
>and fairly portable persistent store.  (Runs under Linux, SunOS, Solaris,
>Mach, and soon to be released for OS/2.  Should be easy to port to
>NT, Windows95, or Copland.)  Have a look at the ftp site mentioned in
>my .sig, below.

Looks like ideal for light standalone applications. Do the Texas use
any run-time components and what is size of those components?
How much executable program will grow, when the Texas is linked
statically?

Mika Holkeri
Pragmasoft Oy

In article <3r4ihj$1flk@news.doit.wisc.edu>,
Mumit Khan <khan@xraylith.wisc.edu> wrote:
>This is a good discussion and I hope people with more experience than I on
>this would jump in.
>
>I've been playing with custom allocators in STL (with varying degrees of
>success, since I've been condemned to work with less than optimal compiler
>technologies), and one of the things I'd like to get done first is a memory
>mapped file based heap manager. I have it somewhat working now and it
>doesn't look too hard (famous last words?) to add some form of
>persistence. For persistence, I'm probably going to use a catalogue based
>technique that I'd borrowed from Unidraw and have used sucessfully before
>in a C++ CAD library; with compilers supporting RTTI, it might be a bit
>simpler this time around. I'm more than open to alternatives, so please
>feel free to make suggestions if you have any.

You might want to just use the Texas Persistent store, a free (GPL)
and fairly portable persistent store.  (Runs under Linux, SunOS, Solaris,
Mach, and soon to be released for OS/2.  Should be easy to port to
NT, Windows95, or Copland.)  Have a look at the ftp site mentioned in
my .sig, below.

Texas uses pointer swizzling at page fault time, so you don't have to
map your data into the same place in the address space every time.
Persistence is orthogonal to type, so you don't have to have a tacky
class hierarchy with a "persistent" class that you have to inhierit
from to get persistence.

Texas provides checkpointing.  It swizzles virtual function table pointers
specially, so that you can save objects with virtual functions and they
work when you reload them (by transparent page faulting) later.

And it's fast.  There's zero overhead for accessing in-memory data.

>As for writing custom allocators, there is (at least there was late last
>year) precious little info on how to do it and you really had to dig thru
>STL to figure it out. Now that I have ObjectSpace STL<ToolKit>, I'm
>probably going to switch to their dynamic allocators, which seem to have
>quite a bit of built-in support for what I need to do; unfortunately the
>code then would work only with their STL implementation. They have an
>example allocator in the manual that looks a lot easier than mine, so
>that's a big incentive.
>
>> if all you need is persistance then STL is also alot cheaper than
>>an object database.

Texas is free.

>No kidding! We gave up on a project last year because of the cost of OODB.
>Most of what we need could be done with STL, but existing compilers have
>trouble compiling just straight STL, let alone any fancy extensions built
>on top of it.

We'd be interesting in getting STL running on top of Texas.  It should
be pretty easy, from what I know of STL.

>regards,
>mumit -- khan@xraylith.wisc.edu
>http://www.xraylith.wisc.edu/~khan/


--
Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (wilson@cs.utexas.edu)
Recent papers on garbage collection, memory hierarchies, persistence and
Scheme interpreters and compilers available via ftp from ftp.cs.utexas.edu
(128.83.120.44), in pub/garbage or http://www.cs.utexas.edu/users/oops/)

In article <1995Jun6.220718@opal.tufts.edu>,
Jonathan Borden <jkauer@opal.tufts.edu> wrote:
>In article <empathD9rt27.Gts@netcom.com>, empath@netcom.com (Tim Triemstra) writes:
>> I'm not really familiar with the STL as yet (other than what it's purpose
>> is.)  However, I'm curious about the potential for its applications.
>> Since it seems to have adequate support for persistent objects and good
>> data structure manipulation (even to storage) it seems as though it could
>> suffice with a little extra code to serve as a full database system.  The
>> interrelationships could be maintained with some sort of a key system
>> generated from memory addresses.
>>
> this is a good point. you CAN create an "object" database using
>STL if you create allocators for you containers. for example, your custom
>allocator might allocate memory from a private heap which is actually a
>memory mapped file. if your container is a set or multiset, then you can index
>the objects.

This is a good discussion and I hope people with more experience than I on
this would jump in.

I've been playing with custom allocators in STL (with varying degrees of
success, since I've been condemned to work with less than optimal compiler
technologies), and one of the things I'd like to get done first is a memory
mapped file based heap manager. I have it somewhat working now and it
doesn't look too hard (famous last words?) to add some form of
persistence. For persistence, I'm probably going to use a catalogue based
technique that I'd borrowed from Unidraw and have used sucessfully before
in a C++ CAD library; with compilers supporting RTTI, it might be a bit
simpler this time around. I'm more than open to alternatives, so please
feel free to make suggestions if you have any.

As for writing custom allocators, there is (at least there was late last
year) precious little info on how to do it and you really had to dig thru
STL to figure it out. Now that I have ObjectSpace STL<ToolKit>, I'm
probably going to switch to their dynamic allocators, which seem to have
quite a bit of built-in support for what I need to do; unfortunately the
code then would work only with their STL implementation. They have an
example allocator in the manual that looks a lot easier than mine, so
that's a big incentive.

> if all you need is persistance then STL is also alot cheaper than
>an object database.

No kidding! We gave up on a project last year because of the cost of OODB.
Most of what we need could be done with STL, but existing compilers have
trouble compiling just straight STL, let alone any fancy extensions built
on top of it.

regards,
mumit -- khan@xraylith.wisc.edu
http://www.xraylith.wisc.edu/~khan/

I'm not really familiar with the STL as yet (other than what it's purpose
is.)  However, I'm curious about the potential for its applications.
Since it seems to have adequate support for persistent objects and good
data structure manipulation (even to storage) it seems as though it could
suffice with a little extra code to serve as a full database system.  The
interrelationships could be maintained with some sort of a key system
generated from memory addresses.

I don't want to get too detailed because I'm on a line of not knowing
what I'm talking about here :)  However, I'm currently porting an
application away from an old platform using an Object database (in C++)
and would like to use standard data structures rather than its own when I
port it to WindowsNT later this year.  I could use MFC (yeah, right...)
but would much rather use a portable system that is likely to be around
for a while and STL looks to fit the bill.

If I could mimick my OODB in STL structures this could potentially save
me huge headaches in the future.

Also, if anyone want to respond my email (for appropriateness purposes)
what is the story behind the RogueWave DBTools++, I've heard that RW was
moving towards STL compliance so I assume that DBTools++ may be linked to
this issue.

Thanks.

--
Tim Triemstra ... empath@netcom.com ... Detroiter at Heart
The RED WINGS rule!
2 down, 2 to go (I think that mean 2 octopi too!)

In article <empathD9rt27.Gts@netcom.com>, empath@netcom.com (Tim Triemstra) writes:
> I'm not really familiar with the STL as yet (other than what it's purpose
> is.)  However, I'm curious about the potential for its applications.
> Since it seems to have adequate support for persistent objects and good
> data structure manipulation (even to storage) it seems as though it could
> suffice with a little extra code to serve as a full database system.  The
> interrelationships could be maintained with some sort of a key system
> generated from memory addresses.
>
 this is a good point. you CAN create an "object" database using
STL if you create allocators for you containers. for example, your custom
allocator might allocate memory from a private heap which is actually a
memory mapped file. if your container is a set or multiset, then you can index
the objects.

> I don't want to get too detailed because I'm on a line of not knowing
> what I'm talking about here :)  However, I'm currently porting an
> application away from an old platform using an Object database (in C++)
> and would like to use standard data structures rather than its own when I
> port it to WindowsNT later this year.  I could use MFC (yeah, right...)
> but would much rather use a portable system that is likely to be around
> for a while and STL looks to fit the bill.
>
 if all you need is persistance then STL is also alot cheaper than
an object database.

> If I could mimick my OODB in STL structures this could potentially save
> me huge headaches in the future.
>
 correct.

jon borden
jabr technology corporation
component medical software