Library proposal: STL with custom pointer objects

Library proposal: STL with custom pointer objects

Post by Samee Zahu » Tue, 17 May 2005 20:19:36


I'd like to know everyone's opinion about adding (yet) another template
parameter to the STL container classes - one which will determine the
kind of pointer objects the classes will use for handling contained
objects. Something like this will change the vector class from
template< class T,class A=allocator<T> > class vector;
to this:

template< class T,class A=allocator<T>,class P=ordinary_ptr<T> > class
vector

Why?

Whenever I go for writing an allocator class of my own,
I feel like I should have something to do about the memory pool getting
fragmented. A defrag attempt, however, will make all existing pointers
invalid, and there will be no way for me to change the value of each
and every pointer pointing to a certain place. That can be made
possible if I could somehow instruct STL to use my own pointer objects
to handle all the data they contain.

And not just that, things like copy-on-write would be much simpler to
code if it was implemented. With the different kinds of pointer objects
now emerging out of libraries like boost, this can largely increase the
choice of users of STL.

But the question is, would we *all* like something like this? Or is it
already there or something?

Samee

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.yqcomputer.com/ ]
 
 
 

Library proposal: STL with custom pointer objects

Post by pjp » Wed, 18 May 2005 03:09:40


No and yes. The C++ Standard encourages, but does not require, a
library implementation to accommodate allocators with funny
pointer types. (In other words, for the type T the pointer type
is not necessarily T*.) The Dinkumware implementation is the only
one I know of that actually does so -- each of our STL containers
uses the supplied allocator template to allocate, construct, and
destroy pointers as needed.

So what you want is already there, kinda.

P.J. Plauger
Dinkumware, Ltd.
http://www.yqcomputer.com/


---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.yqcomputer.com/ ]

 
 
 

Library proposal: STL with custom pointer objects

Post by yecri » Thu, 19 May 2005 08:30:49


Uzytkownik "Samee Zahur" < XXXX@XXXXX.COM > napisal w wiadomosci


Heap fragmentation is only an issue when you cannot fit a large objects
between two small ones. How can you get this effect with standard template
data structures? I thought all your objects should be of equal size.
Chris



---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.yqcomputer.com/ ]
 
 
 

Library proposal: STL with custom pointer objects

Post by cppljevan » Thu, 19 May 2005 08:32:56


AFAICT, it would also enable refcounted pointers to be garbage collected
even when cycles are present. The existing boost shared_ptr has a
proposed garbage collector for collecting cycles in the pointer graph:

http://www.yqcomputer.com/

however, IIUC, it cannot collect cycles when the smart pointers are in
something like an stl collection, e.g. vector<shared_ptr<T> >, because
the "root" pointer of the vector (i.e. that returned by begin() ) is not
registered as a pointer by the function:

boost::sp_scalar_constructor_hook

WARNING: The above reasoning is just a guess, but I remember
discussing this somewhere either here or on the boost new group.
Hopefully Peter Dimov will give a more definite answer.

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.yqcomputer.com/ ]
 
 
 

Library proposal: STL with custom pointer objects

Post by Samee Zahu » Fri, 20 May 2005 06:13:09


objects
template


Well, if everyone is using the same heap, different map<int> and
map<bigclass> can easily keep on allocating/deallocating elements to
create fragmentation ... and many many other classes totally unrelated
to STL!

P.J. Plauger wrote
So the only thing that's not there is the 'manditory' part ... so if I
write a code here, it might not be acceptable everywhere ... hmm ...
but I think I can live with that!

Thanks!

Sanee


---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.yqcomputer.com/ ]
 
 
 

Library proposal: STL with custom pointer objects

Post by cppljevan » Sun, 22 May 2005 07:01:34


[snip]

I've needed a specialized smart pointer for use in stl containers
to allow precise garbage collection. A prototype created several
years ago is at:

http://www.yqcomputer.com/

I'm currently working on a newer version of the precise gc which
I hope to upload soon to:

http://www.yqcomputer.com/

Does the Dinkumware implementation allow something that shown in
the vault file referenced above? IOW, does it allow something like:

allocator_type::root_pointer

where root_pointer is a pointer as described in the above file as:

typedef
prox_children::prox_indirect_typed<Value>
root_pointer
/**@variable root_pointer
* @brief
* The proxy from which all elements of
* the container may be reached.
*/
;

For the existing stl containers, instead of:

prox_children::prox_indirect_typed<Value>

this would simply be:

Value*

-regards
Larry

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.yqcomputer.com/ ]
 
 
 

Library proposal: STL with custom pointer objects

Post by cppljevan » Wed, 29 Jun 2005 03:31:56


[snip]

The newer version is currently at:

http://www.yqcomputer.com/ #dirlist

It's use in an stl-like container is shown in vector.hpp in the same
directory. The specialization for allowing traversal of the elements
is in:

prox_indirect_registrar_heirarchy.hpp

Actual use in precise garbage collection is demonstrated by:


http://www.yqcomputer.com/

when the Jamfile.v2 in that director is used (or when macro
USE_CONTAINER_INTERN is defined).

Adapting Dinkumware's stl library to use this type of pointer, i.e.
prox_indirect, wouldn't pose any problems, would it?
adapting

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.yqcomputer.com/ ]