William E. Kempf wrote:
Chuck Messenger said:
I've been experimenting with the thread lib. I found a bug related in
some way to thread_specific_storage (tss). In particular, I #ifdef'd
all the tss stuff out, using native pthread calls instead, and
everything worked as expected.
So, I went back
Chuck Messenger wrote:
And so, can I assume that the following is guaranteed to
work?
static SomeType var1;
static AnotherType var2 = var1.something();
That is, is var1 guaranteed to be constructed before I initialize var2
from it?
Referring to TC++PL 3rd ed, I see that, indeed, statics
Schoenborn, Oliver wrote:
From: Chuck Messenger [mailto:[EMAIL PROTECTED]
No. A and B are completely symmetrical. They each equally
own the other.
Not possible. This has nothing to do with NoPtr or
boost::shared_ptr, it's even true for raw pointers. E.g.
...
Just look at my Node example
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, handling garbage collection
for you, without resorting to a systemic (and non-portable
ptr;
};
As I understand it, in order to discover 'ptr', you'd invoke operator=()
on each Image structure you came to. Correct, or incorrect?
- Chuck Messenger
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
definition of) perfect discovery is a worthy design
objective, if it can be done without significant overhead?
- Chuck Messenger
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I tried out sp_collector.cpp. Here's my code (the Network Simulation
Library):
#include iostream
#include set
#include boost/utility.hpp
#include boost/shared_ptr.hpp
using namespace std;
using namespace boost;
struct NodeImpl;
NodeImpl* NodeImpl_Create(int id);
. But it's way
too heavy-artillery for my needs here...
- Chuck Messenger
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
,
then you don't have that problem.
I looked at NoPtr, and quickly determined that it didn't implement
garbage collection, so it couldn't solve my problem. However, I don't
understand what NoPtr *does*.
- Chuck Messenger
___
Unsubscribe other
when
accessed
Note that I said simplistically.
OK, thanks for the explanation -- I think I understand.
- Chuck Messenger
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I've received a few suggestions for methods to achieve non-leaking
cyclic smart pointers (henceforth called uber pointers). I've looked
into some of them. Following is a report on what I've found.
Here is my context: I want to write a library L consisting of a set of
interconnected classes,
Larry Evans wrote:
Chuck Messenger wrote:
[snip]
Well, it's in too much flux right now -- perhaps if I ever finish it,
I'll post it. It's a concurrency library - an implementation of the
API described in Concurrent Programming in ML.
[snip]
Thanks -- that sounds interesting, too -- I've also
Schoenborn, Oliver wrote:
NoPtr lib -- noptrlib.sourceforge.net
...I saw no mention of detecting dead cyclic object pools.
Can you give me a short example of how NoPtr would even need to detect that
to work correctly? I suspect that if you end up with cyclic object pool you
are using NoPtr
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 code of users of library L). Crucially,
Would you require the users to use
Larry Evans wrote:
Chuck Messenger wrote:
[snip]
One big problem with this approach is that you end up having to scan
all of your memory. This could (and for me, would) be an outrageous
proposition, as only a tiny portion of memory relates to my object
set. Most of it will be raw data (e.g
doing is saying that the Node destructor
needs to run a garbage collection pass, which is exactly right. There's
no getting around it.
The point of a smart cyclic pointer is to perform this garbage
collection for you.
- Chuck Messenger
Peter Dimov wrote:
Chuck Messenger wrote:
boost/libs/smart_ptr/src/sp_collector.cpp:
There is no sample program to compile/run, so I have to guess somewhat
at how to use this one.
There is libs/smart_ptr/test/collector_test.cpp. You need to #define
BOOST_SP_ENABLE_DEBUG_HOOKS.
OK - thanks
I take back this suggestion -- intrusive_ptr does what I want.
- Chuck
Chuck Messenger wrote:
Suppose you have this:
struct X {
shared_ptrY y;
...
};
struct Y {
X x;
};
struct Z {
Z() : pimpl_(new Y()) { pimpl_-x.y = pimpl_
Peter Dimov wrote:
Chuck Messenger wrote:
Suppose you have this:
struct X {
shared_ptrY y;
...
};
struct Y {
X x;
};
struct Z {
Z() : pimpl_(new Y()) { pimpl_-x.y = pimpl_; }
shared_ptrY pimpl_;
...
};
I'm using
Peter Dimov wrote:
Chuck Messenger wrote:
For convenience, logical continuity, and consistency with other Boost
libraries, you should be able to include all the smart_ptr pieces with
#include boost/smart_ptr.hpp
Currently, only 4 are included:
#include boost/scoped_ptr.hpp
#include
Peter Dimov wrote:
Chuck Messenger wrote:
In general, the abstraction is: you have a group of intra-referential
objects. When any of the group is constructed, they are all
constructed (so that the master count is temporarily 1), and the
master count is
reset to 1. When the master count goes
Larry Evans wrote:
Chuck Messenger wrote:
[snip]
In general, the abstraction is: you have a group of intra-referential
objects. When any of the group is constructed, they are all
constructed (so that the master count is temporarily 1), and the
master count is reset to 1. When the master
Peter Dimov wrote:
Chuck Messenger wrote:
Consider that A and B may implement various interfaces (i.e. inherit
from 1+ abstract base classes w/o member variables). I can't just use
multiple inheritance (i.e. AB inherits from each interface that
either A
or B needs), because, for one thing
, though -- start with core capabilities, then
build on it over time.
I've love to take a gander at your code...
- Chuck Messenger
Scott Woods wrote:
Hi,
Is anyone interested in a persistence mechanism? Rather than dumping a bunch
of doc+code and finding that its just inappropriate, here is some
Vladimir Prus wrote:
Chuck Messenger wrote:
* Library-managed default values
I think it good idea. Need to flesh some details a bit.
See
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Library-Managed_Default_Values_-_Program_Options_Suggestion
Replace default_value
Rob Stewart wrote:
From: James Curran [EMAIL PROTECTED]
Chuck Messenger wrote:
* add_options() should use references rather than pointers
Pointer for return value is C semantics. In C++,
pointers denote optional values. Non-const references are for return
values.
I disagree *strongly
26 matches
Mail list logo
