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 cus
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 be
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?
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: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'
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
allocator should ha
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 wha
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
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, a
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 s
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 that's flat wrong. What do you suppose that
entry in column 2 of the allocator requirements tabl
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 semantic
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 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 alloca
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:
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
everyo
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" se
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 lan
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:
template shared_ptr(Y * p, D d);
Requirements: p must be convertible to T *. D must be
CopyConstructible.
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,
h
On Friday, Aug 29, 2003, at 10:48 America/Denver, E. Gladyshev wrote:
--- Gregory Colvin <[EMAIL PROTECTED]> wrote:
[...]
Does it make sense?
Not to me. Sounds like a very broken allocator design.
If I assume that I going to have a full control over my allocator
instances (not a very u
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;
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 yo
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
shar
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 say
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
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 ha
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_impl(p, d);
So it might be possible to make the allo
For shared_ptr the count is allocated by the following line in the
shared_count
constructor:
new sp_counted_base_impl(p, d);
So it might be possible to make the allocation customizable by
specializing
sp_counted_base_impl.
___
Unsubscribe & other
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
re
Why the S?
On Wednesday, Aug 6, 2003, at 16:37 America/Denver, E. Gladyshev wrote:
--- Brock Peabody <[EMAIL PROTECTED]>
wrote:
That sounds good. What if we called the lower layer
boost::gui and the
upper layer boost::sgtl?
Agreed.
__
Do you Yahoo!?
Yahoo! Site
Been there, done that, twice, and don't care to do it again ;->
On Wednesday, Jul 30, 2003, at 13:53 America/Denver, David Abrahams
wrote:
Has anyone given thought to the design of a domain-specific
sublanguage for dialog layout specification?
--
Dave Abrahams
Boost Consulting
www.boost-consulti
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 to
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++ c
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 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 wrap
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
t
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 the
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 Po
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
On Wednesday, Jul 2, 2003, at 02:42 America/Denver, Paul A. Bristow
wrote:
| In non-Boost code, I've seen wording something like "See the attached
| license; if it is missing see www.foo.org/license." Maybe something
like
| that is what will be recommended.
|
| They've already signed off on the c
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 are.
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 provi
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 amo
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 obj
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 said:
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 th
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
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 struc
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 are
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 Boe
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 "misident
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 t
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 a
new[](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 wrot
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 on
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 i
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 cod
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
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 har
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 pursuin
On Wednesday, Apr 23, 2003, at 16:07 America/Denver, Justin M. Lewis
wrote:
Sorry if the explanation is a bit confusing. The whole idea here is to
make it explicit at the function invocation that a parameter being
passed will be used to return a value.
A good example of where this would be useful
On Wednesday, Apr 23, 2003, at 12:04 America/Denver, Terje Slettebø
wrote:
From: "Justin M. Lewis" <[EMAIL PROTECTED]>
Well, I guess, based on all the code I've been reading at work it
didn't
seem so small, chasing down all kinds of functions across 100's of
files
to see why exactly values are
65 matches
Mail list logo
