Well, Marc, I'm sure you figured someone would bring this up at some point. I printed out the code and tried to figure it out, hoping to quickly get it into a project I'm working on.
Its pretty hard to figure out how everything works together - got any docs in the works? In fact its hard to determine exactly what it does do, and how it works. I wanted to try to port it to sun, but with no luck (so far) since the STL is pretty messed up that comes with it, and I havent tried STLport yet, although it runs great on my Linux box at home and I develop with it. Its hard to determine from the code what the entry points would be for customization - for example suppose I want to use the allocator with a single-threaded application - then all the thread-safe stuff could be left out, probably also making it a bit easier to port. Any ideas about this?
PS Anyhow why the dependency on STPORT? Won't any STL do?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Its pretty hard to figure out how everything works together - got any
> docs in the works? In fact its hard to determine exactly what it does
> do, and how it works.
First, Im assuming that you are working with the posted version 1.03.
In that version, the allocator/src/main.cc file is an example/test
file which illustrates how the package is used. The first thing that
you will want to do is to get that file to compile and run properly.
I would start by installing the STLPORT package from www.stlport.org
on your local machine. This package does not come with STLPORT; it
needs to be retrieved from their website. You will need to adjust the
STLHOME env variable in the allocator/src/Makfile file to properly
point to your STLPORT installation. Once this is done try compiling
it with the gcc compiler. You may also need to change the paths to
gcc and ld in the CC and LD variables to get them to properly point to
your copies of gcc and ld. At a UNIX command line, do a "which gcc"
to see where that compiler resides or just remove the hard coded path
names in the Makefile. (ie /usr/local/bin/gcc => gcc).
In my installation I have newer a version of gcc and glibc installed
in /usr/local and I need the compiler and ld to point to the correct
libraries and compiler versions so everything is spelled out in the
Makefile. Ill need to correct this Makefile in future versions.
You can see what the package does by exploring the
allocator/src/main.cc file. There you will see a line which appears
as:
stl::vector<int,allocator::Pool_alloc<int> > w;
This declaration instantiates a vector of ints called w using the
pooled, shared memory allocator to place the vector values into shared
memory. Therefore, any new values inserted into w, will be placed
into shared memory where other independent, processes may gain access
to them. So, for instance, you could create a vector and then fork
off a child process and both parent and child can access the shared
vector structure.
To use the package all you need to do is call the stl classes and just
insert the allocator in the correct allocator position. Additionally,
the #include allocator.h line should be included at the top of any
file using the allocator. The allocator has been successfully tested
with vector, map, multi-map, set, multi-set, etc, classes.
I developed this allocator because I couldn't find one on the web
which met my needs and I am sharing it because if I needed it, I
figure others might need it as well. Its easier for all of us to just
focus on and perfect one allocator and having to continually re-invent
them.
My application consists of two forked processes which share data
through structures allocated by this allocator. The first process
generates a background map as an Xwindows display. This first process
also keeps track of all user actions, clicks, resizes, etc. The
second process draws dynamic objects in the shared data-structure
causing animation to flow through the map drawn by the first process.
Splitting the task into two processes provides enhanced response time
for the user.
So far this code has only been developed and tested with single
threaded processes. To port the code to other Operating Systems, the
calls to shmget, and attach and the semaphore calls will need to be
replaced by the appropriate OS calls. These calls, however should be
similar if not identical on SunOS.
To set up documentation, I am currently under the impression that I
will need to improve the web site and setup web based documentation.
Let me know in an enumerated list by order of importance what you want
to see documented. Meanwhile, I encourage you to read section 19.4 of
Bjarne Stroutrup's 3rd C++ edition. I will document the code as time
permits. There are comments within the code itself and I did try to
keep the mnemonics readable.
Hope this response helps :). thanks very much for the interest and
valuable feedback.
marc
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, Marc, I'm sure you figured someone would bring this up at some point. I printed out the code and tried to figure it out, hoping to quickly get it into a project I'm working on.
Its pretty hard to figure out how everything works together - got any docs in the works? In fact its hard to determine exactly what it does do, and how it works. I wanted to try to port it to sun, but with no luck (so far) since the STL is pretty messed up that comes with it, and I havent tried STLport yet, although it runs great on my Linux box at home and I develop with it. Its hard to determine from the code what the entry points would be for customization - for example suppose I want to use the allocator with a single-threaded application - then all the thread-safe stuff could be left out, probably also making it a bit easier to port. Any ideas about this?
PS Anyhow why the dependency on STPORT? Won't any STL do?
Eric,
> Its pretty hard to figure out how everything works together - got any
> docs in the works? In fact its hard to determine exactly what it does
> do, and how it works.
First, Im assuming that you are working with the posted version 1.03.
In that version, the allocator/src/main.cc file is an example/test
file which illustrates how the package is used. The first thing that
you will want to do is to get that file to compile and run properly.
I would start by installing the STLPORT package from www.stlport.org
on your local machine. This package does not come with STLPORT; it
needs to be retrieved from their website. You will need to adjust the
STLHOME env variable in the allocator/src/Makfile file to properly
point to your STLPORT installation. Once this is done try compiling
it with the gcc compiler. You may also need to change the paths to
gcc and ld in the CC and LD variables to get them to properly point to
your copies of gcc and ld. At a UNIX command line, do a "which gcc"
to see where that compiler resides or just remove the hard coded path
names in the Makefile. (ie /usr/local/bin/gcc => gcc).
In my installation I have newer a version of gcc and glibc installed
in /usr/local and I need the compiler and ld to point to the correct
libraries and compiler versions so everything is spelled out in the
Makefile. Ill need to correct this Makefile in future versions.
You can see what the package does by exploring the
allocator/src/main.cc file. There you will see a line which appears
as:
stl::vector<int,allocator::Pool_alloc<int> > w;
This declaration instantiates a vector of ints called w using the
pooled, shared memory allocator to place the vector values into shared
memory. Therefore, any new values inserted into w, will be placed
into shared memory where other independent, processes may gain access
to them. So, for instance, you could create a vector and then fork
off a child process and both parent and child can access the shared
vector structure.
To use the package all you need to do is call the stl classes and just
insert the allocator in the correct allocator position. Additionally,
the #include allocator.h line should be included at the top of any
file using the allocator. The allocator has been successfully tested
with vector, map, multi-map, set, multi-set, etc, classes.
I developed this allocator because I couldn't find one on the web
which met my needs and I am sharing it because if I needed it, I
figure others might need it as well. Its easier for all of us to just
focus on and perfect one allocator and having to continually re-invent
them.
My application consists of two forked processes which share data
through structures allocated by this allocator. The first process
generates a background map as an Xwindows display. This first process
also keeps track of all user actions, clicks, resizes, etc. The
second process draws dynamic objects in the shared data-structure
causing animation to flow through the map drawn by the first process.
Splitting the task into two processes provides enhanced response time
for the user.
So far this code has only been developed and tested with single
threaded processes. To port the code to other Operating Systems, the
calls to shmget, and attach and the semaphore calls will need to be
replaced by the appropriate OS calls. These calls, however should be
similar if not identical on SunOS.
To set up documentation, I am currently under the impression that I
will need to improve the web site and setup web based documentation.
Let me know in an enumerated list by order of importance what you want
to see documented. Meanwhile, I encourage you to read section 19.4 of
Bjarne Stroutrup's 3rd C++ edition. I will document the code as time
permits. There are comments within the code itself and I did try to
keep the mnemonics readable.
Hope this response helps :). thanks very much for the interest and
valuable feedback.
marc