On Tuesday, Sep 2, 2003, at 05:42 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
On Monday, Sep 1, 2003, at 14:48 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
Conforming containers had better use them.
I'm sorry, but I think
On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
I think part of my point was that *nobody* needs what they offer, if
you include construct/destroy.
Or rather that some implementations have failed to use what they
offer, and our
On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
...
Dave:
I think I would rather see a MPL lambda expression or metafunction
class interface for allocator type parameters. It makes little sense
for the allocator's user
On Tuesday, Sep 2, 2003, at 11:22 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams
wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
I think part of my point was that *nobody* needs what they offer
On Tuesday, Sep 2, 2003, at 11:39 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams
wrote:
...
I think you're missing my point. There's no reason that a stateful
allocatorT should have access
On Tuesday, Sep 2, 2003, at 12:27 America/Denver, Peter Dimov wrote:
Gregory Colvin wrote:
You are assuming that there was no good reason to allow an allocator
to hook construct and destroy, for instance to do some bookkeeping.
I'm curious. Have you ever seen such an allocator? I've always
On Tuesday, Sep 2, 2003, at 13:00 America/Denver, Peter Dimov wrote:
Gregory Colvin wrote:
On Tuesday, Sep 2, 2003, at 12:27 America/Denver, Peter Dimov wrote:
Then again, the Dinkumware implementation
dutifully calls construct and destroy, paying (and forcing me to pay)
the abstraction penalty
On Tuesday, Sep 2, 2003, at 12:51 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
On Tuesday, Sep 2, 2003, at 11:22 America/Denver, David Abrahams
wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
So you would rather use this than use construct?
template
On Tuesday, Sep 2, 2003, at 13:18 America/Denver, E. Gladyshev wrote:
--- Gregory Colvin [EMAIL PROTECTED] wrote:
Yep. I still think UserAllocator is a good default, and that where it
doesn't suffice there is some value to playing nicely with STL.
So even when we come up with some beautiful new
On Tuesday, Sep 2, 2003, at 15:00 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
Also, if shared_ptr only needs to allocate at construction time (I'm
not sure of this) we can avoid storing the allocator at all.
Then how to deallocate?
Using the custom deleter
On Monday, Sep 1, 2003, at 11:31 America/Denver, Joel de Guzman wrote:
Fernando Cacciola [EMAIL PROTECTED] wrote:
vector::begin returns an object with operators * and -,
yet these objects are not pointers, and once that is learned,
people do not think they are pointers.
Huh? pointer semantics
On Sunday, Aug 31, 2003, at 13:13 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
But indeed allocate/construct/deallocate/destroy is more work than
^^^^
Oyeah. These two absolutely don't belong in allocator, period
On Sunday, Aug 31, 2003, at 13:51 America/Denver, Peter Dimov wrote:
Gregory Colvin wrote:
[...]
Two small corrections:
shared_ptr currently uses std::allocator to allocate counts
regardless.
No, it uses plain new/delete by default. It is possible to get it to
use
std::allocator via a #define
On Friday, Aug 29, 2003, at 18:05 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
* use the standard parameterization mechanisms (Allocator) when
choosing to parameterize
I'm not sure about this one. std::allocator are a mess, and almost
everyone knows
On Friday, Aug 29, 2003, at 18:16 America/Denver, E. Gladyshev wrote:
I'd like to start a new thread with Gregory's suggestion
and my comments.
Gregory Colvin wrote:
...
* use the standard mechanisms (::operator new or std::allocator)
when it is necessary
Boost already has boost::allocator
On Thursday, Aug 28, 2003, at 16:54 America/Denver, E. Gladyshev wrote:
--- Gregory Colvin [EMAIL PROTECTED] wrote:
And I have no objection myself to adding an allocator parameter
to the shared_ptr constructor, or to making some other change that
serves the purpose. So if you need a change, why
On Thursday, Aug 28, 2003, at 16:26 America/Denver, E. Gladyshev wrote:
--- Gregory Colvin [EMAIL PROTECTED] wrote:
How will I even know it, the documentation is completely
ignorant on the memory issues.
Perhaps because you work with the authors of the documentation to
make it sure it says what
On Thursday, Aug 28, 2003, at 19:40 America/Denver, E. Gladyshev wrote:
--- Gregory Colvin [EMAIL PROTECTED] wrote:
shared_ptr doesn't allocate the data, it only deletes it, which is
the job of the
current deleter parameter. And the counter type is by design not
part of the
shared_ptr type, so
On Thursday, Aug 28, 2003, at 23:48 America/Denver, E. Gladyshev wrote:
--- Gregory Colvin [EMAIL PROTECTED] wrote:
[...]
In this solution, there are some issues with who
controls the instances of the allocator that allocates
Data and instances that delete the Data.
Which issues concern you
On Friday, Aug 29, 2003, at 00:52 America/Denver, E. Gladyshev wrote:
--- Gregory Colvin [EMAIL PROTECTED] wrote:
On Thursday, Aug 28, 2003, at 23:48 America/Denver, E. Gladyshev
wrote:
*pseudo-code*
template typename T
sturct my_allocator
{
my_heap_control _heap;
T* create
On Friday, Aug 29, 2003, at 12:33 America/Denver, E. Gladyshev wrote:
--- Gregory Colvin [EMAIL PROTECTED] wrote:
[...]
It's still not obvious to me. But I suspect I have yet to understand
your example.
Perhaps Peter can help me here. In his sample solution before, in this
thread,
he addresses
On Friday, Aug 29, 2003, at 13:34 America/Denver, E. Gladyshev wrote:
...
All I am trying to say is that shared_ptr doesn't specify
any requirements on its Deleter parameter.
Bullshit:
templateclass Y, class D shared_ptr(Y * p, D d);
Requirements: p must be convertible to T *. D must be
On Friday, Aug 29, 2003, at 13:57 America/Denver, Gregory Colvin wrote:
On Friday, Aug 29, 2003, at 13:34 America/Denver, E. Gladyshev wrote:
...
All I am trying to say is that shared_ptr doesn't specify
any requirements on its Deleter parameter.
Bullshit:
Please excuse my rude language
On Friday, Aug 29, 2003, at 15:14 America/Denver, E. Gladyshev wrote:
...
People are adopted to follow similar
requirements for STL allocators anyway.
I guess they can be recommended to all boost
authors who wants to make memory management
data types.
Perhaps they can be added to the Guidlines
On Thursday, Aug 28, 2003, at 10:46 America/Denver, E. Gladyshev wrote:
--- Peter Dimov [EMAIL PROTECTED] wrote:
You can use all smart pointers except shared_ptr and shared_array as
they do
not allocate any memory. In particular, intrusive_ptr is a good
candidate if
memory is a concern as it has
On Tuesday, Aug 26, 2003, at 10:41 America/Denver, E. Gladyshev wrote:
--- Gregory Colvin [EMAIL PROTECTED] wrote:
For shared_ptr the count is allocated by the following line in the
shared_count
constructor:
new sp_counted_base_implP, D(p, d);
So it might be possible to make the allocation
On Monday, Aug 25, 2003, at 11:46 America/Denver, David Abrahams wrote:
Daniel Frey [EMAIL PROTECTED] writes:
Mohamed Iqbal wrote:
For now I will cnvert three or four libraries for academia purposes
but a
bigger number of libraries will be ported to my new language when the
commercial release
On Wednesday, Aug 6, 2003, at 17:36 America/Denver, Brock Peabody wrote:
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Gregory Colvin
Sent: Wednesday, August 06, 2003 4:48 PM
To: Boost mailing list
Subject: Re: [boost] GUI/GDI template library
Why the S?
On Wednesday, Aug 6, 2003
Perhaps Perseus, who slew the Medusa, the snake-haired monster of
so frightful an aspect that no living thing could behold her without
being turned into stone.
Perseus avoid being turned to stone by clever use of indirection --
he avoided looking directly at Medusa, instead looking only at her
On Tuesday, Jul 29, 2003, at 12:25 America/Denver, Brock Peabody wrote:
...
I don't think custom resource files would be any easier to edit that
inline C++ code. I think they would be much less easy to edit and
read.
It's been a few years, but the last time I was writing a GUI application
for an
On Tuesday, Jul 29, 2003, at 16:24 America/Denver, Bohdan wrote:
Brock Peabody [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Tuesday, Jul 29, 2003, at 12:25 America/Denver, Brock Peabody
wrote:
...
I don't think custom resource files would be any easier to edit that
inline C++
On Tuesday, Jul 29, 2003, at 16:02 America/Denver, Brock Peabody wrote:
On Behalf Of Gregory Colvin
[...]
For this kind of localization loading the localized resources at
runtime
is essential. Regenerating C++ code and rebuilding the application is
not an option.
Why would it be necessary
On Tuesday, Jul 22, 2003, at 05:56 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
I'm generally less afraid of automatic conversions than many others,
and dropped them from auto_ptr, and later from shared_ptr, only under
duress. I like them for wrapper classes
I'm generally less afraid of automatic conversions than many others, and
dropped them from auto_ptr, and later from shared_ptr, only under
duress.
I like them for wrapper classes because they make it possible to drop
the
wrappers directly into existing code that uses the wrapped types. I
like
On Saturday, Jul 19, 2003, at 17:16 America/Denver, Ross Smith wrote:
...
(Of course all of these could easily be unified into a single
policy-based type; unfortunately the Powers That Be seem to have
decided that policies are too complicated for us mere mortals to be
trusted with.)
There are no
On Saturday, Jul 19, 2003, at 20:52 America/Denver, Ross Smith wrote:
On Sunday 20 July 2003 11:46, Gregory Colvin wrote:
On Saturday, Jul 19, 2003, at 17:16 America/Denver, Ross Smith wrote:
...
(Of course all of these could easily be unified into a single
policy-based type; unfortunately
On Friday, Jul 18, 2003, at 15:21 America/Denver, John Madsen wrote:
Eugene Lazutkin [EMAIL PROTECTED] wrote:
I have a few comments in no particular order.
1) I cannot imaging someone programming in C++ and using FILE*s,and
file
descriptors instead of iostream Co. You've must be talking about
On Tuesday, Jul 1, 2003, at 14:38 America/Denver, Boost wrote:
I did a search in the archives and found nothing on this:
Why is there no strict-ownership smart-pointer in boost? Just curious
to
know what the reasons are. Thanks,
What do want beyond what boost::scoped_ptr and std::auto_ptr
On Tuesday, Jul 1, 2003, at 17:36 America/Denver, Schoenborn, Oliver
wrote:
On Tuesday, Jul 1, 2003, at 14:38 America/Denver, Boost wrote:
I did a search in the archives and found nothing on this:
Why is there no strict-ownership smart-pointer in boost?
Just curious
to
know what the reasons
On Thursday, Jun 26, 2003, at 07:53 America/Denver, William E. Kempf
wrote:
...
But it would be nice to just refer to the license instead of repeating
it
in every single file.
Though this license is brief enough that inclusion is no big deal.
It seems that doing it by reference to a web page
It's worth noting that libxml2 is itself open source with what appears
to be
Boost compatible license:
http://www.opensource.org/licenses/mit-license.html
On Tuesday, Jun 3, 2003, at 20:21 America/Denver, Darryl Green wrote:
From: William E. Kempf [mailto:[EMAIL PROTECTED]
Vladimir Prus
On Wednesday, Jun 4, 2003, at 08:22 America/Denver, Philippe A.
Bouchard wrote:
Greetings Boost,
I am not that much familiar with garbage collection techniques so
please
excuse me if the technique I am thinking of is already used somewhere.
Let's say:
- you can easily detect weither an
On Friday, May 30, 2003, at 09:56 America/Denver, Chuck Messenger wrote:
...
What I'm trying to develop (or even better, find) is a workable C++
library which supports cyclic structures, handling garbage collection
for you, without resorting to a systemic (and non-portable) approach
like the
On Friday, May 30, 2003, at 10:18 America/Denver, Larry Evans wrote:
Gregory Colvin wrote:
On Friday, May 30, 2003, at 09:56 America/Denver, Chuck Messenger
wrote:
...
What I'm trying to develop (or even better, find) is a workable C++
[snip]
their relative advantages and disadvantages
discovery method.
On Friday, May 30, 2003, at 11:56 America/Denver, Chuck Messenger wrote:
Gregory Colvin wrote:
On Friday, May 30, 2003, at 09:56 America/Denver, Chuck Messenger
wrote:
...
What I'm trying to develop (or even better, find) is a workable C++
library which supports cyclic structures
On Friday, May 30, 2003, at 11:58 America/Denver, Larry Evans wrote:
Gregory Colvin wrote:
On Friday, May 30, 2003, at 10:18 America/Denver, Larry Evans wrote:
[snip]
http://groups.yahoo.com/group/boost/files/shared_cyclic_ptr/
draft-compare.zip might be a good starting point. It
doesn't
On Friday, May 30, 2003, at 12:38 America/Denver, Chuck Messenger wrote:
Gregory Colvin wrote:
Thanks, but your description of cyclic_ptr is pretty far off the mark.
Sorry -- hopefully you'll forgive my ignorance. I'm just throwing out
what I understand to be the case, in the hopes that someone
On Thursday, May 29, 2003, at 08:45 America/Denver, Chuck Messenger
wrote:
...
And so, sp_collector suffers the same problem as shared_cyclic_ptr,
and requires the same remedy: that is, it is necessary to be able to
tag a container as being one which might hold internal
shared_ptr's.
Any
On Thursday, May 29, 2003, at 09:57 America/Denver, Larry Evans wrote:
Gregory Colvin wrote:
[snip]
It seems that rather than take the route of modifying all the
standard containers one might as well just provide a special
operator new(gc) and gc_allocator that can track all the memory
blocks
[](size_t n, const gc_t) { return GC_malloc(n); }
void operator delete (void* ptr, const gc_t) {}
void operator delete[](void* ptr, const gc_t) {}
Much easier than hacking shared_ptr.
On Thursday, May 29, 2003, at 19:57 America/Denver, Larry Evans wrote:
Gregory Colvin wrote:
[snip
Also check out
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc_cpph.txt
for a gc base clase to inherit from.
On Thursday, May 29, 2003, at 20:20 America/Denver, Gregory Colvin
wrote:
Check out
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcinterface.html
which provides
On Thursday, May 29, 2003, at 20:52 America/Denver, Larry Evans wrote:
Gregory Colvin wrote:
Check out
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcinterface.html
[snip]
On Thursday, May 29, 2003, at 19:57 America/Denver, Larry Evans wrote:
Gregory Colvin wrote:
[snip]
It is not that hard
On Thursday, May 29, 2003, at 21:25 America/Denver, Larry Evans wrote:
Gregory Colvin wrote:
[snip]
Do you really need a precise collector? Boehm's collector works just
fine.
Most people don't, but some do. In Jones and Lins _Garbage Collection_
there's mention of misidentification or false
On Wednesday, May 28, 2003, at 13:04 America/Denver, Chuck Messenger
wrote:
Larry Evans wrote:
Chuck Messenger wrote:
[snip]
collections, put them in object heirarchies, etc). This freedom
should ideally apply both internally (within library L code) and
most importantly, externally (in the
My experience tuning our java VM is similar, and it runs on a lot of
different CPUs. Still, there is reason to be suspicious of very small
changes, which might be repeatable for our benchmark set, yet have no
real meaning for normal use. And there is reason to be careful not to
waste time
On Thursday, May 8, 2003, at 11:07 America/Denver, Beman Dawes wrote:
At 11:11 AM 5/8/2003, Darin Adler wrote:
On Thursday, May 8, 2003, at 07:04 AM, Beman Dawes wrote:
A 2-3% timing difference probably isn't reliably repeatable in real
code.
How code and data happens to land in hardware
Somewhere in this thread I lost track of this -- but just how
do out and in differ from ref and cref?
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
57 matches
Mail list logo
