1
Return-Path: <boost-admin@lists.boost.org>
2
Received: from mx04.mrf.mail.rcn.net ([207.172.4.53] [207.172.4.53])
3
by mta01.mrf.mail.rcn.net with ESMTP
4
id <20020403190104.CHE29566.mta01.mrf.mail.rcn.net@mx04.mrf.mail.rcn.net>;
5
Wed, 3 Apr 2002 14:01:04 -0500
6
Received: from milliways.osl.iu.edu ([129.79.245.239])
7
by mx04.mrf.mail.rcn.net with esmtp (Exim 3.35 #5)
9
for david.abrahams@rcn.com; Wed, 03 Apr 2002 14:01:03 -0500
10
Received: from milliways.osl.iu.edu (localhost [127.0.0.1])
11
by milliways.osl.iu.edu (8.11.6/8.11.6/IUCS_2.44) with ESMTP id g33J11A07189;
12
Wed, 3 Apr 2002 14:01:01 -0500
13
Received: from mta446.mail.yahoo.com (mta446.mail.yahoo.com [216.136.129.101])
14
by milliways.osl.iu.edu (8.11.6/8.11.6/IUCS_2.44) with SMTP id g33J04A07150
15
for <boost-admin@lists.boost.org>; Wed, 3 Apr 2002 14:00:05 -0500
16
Date: Wed, 3 Apr 2002 14:00:05 -0500
17
Message-Id: <200204031900.g33J04A07150@milliways.osl.iu.edu>
18
From: MAILER-DAEMON@yahoo.com
19
To: boost-admin@lists.boost.org
20
X-Loop: MAILER-DAEMON@yahoo.com
21
Subject: Delivery failure
22
Sender: boost-owner@lists.boost.org
23
Errors-To: boost-owner@lists.boost.org
24
X-BeenThere: boost@lists.boost.org
25
X-Mailman-Version: 2.0.8
27
List-Help: <mailto:boost-request@lists.boost.org?subject=help>
28
List-Post: <mailto:boost@lists.boost.org>
29
List-Subscribe: <http://lists.boost.org/mailman/listinfo.cgi/boost>,
30
<mailto:boost-request@lists.boost.org?subject=subscribe>
31
List-Id: Boost mailing list <boost.lists.boost.org>
32
List-Unsubscribe: <http://lists.boost.org/mailman/listinfo.cgi/boost>,
33
<mailto:boost-request@lists.boost.org?subject=unsubscribe>
34
List-Archive: <http://lists.boost.org/MailArchives/boost/>
36
Message from yahoo.com.
37
Unable to deliver message to the following address(es).
39
<hankel_o_fung@yahoo.com>:
40
Sorry your message to hankel_o_fung@yahoo.com cannot be delivered. This account has been disabled or discontinued.
42
<ultravirus2001@yahoo.com>:
43
Sorry your message to ultravirus2001@yahoo.com cannot be delivered. This account has been disabled or discontinued.
45
--- Original message follows.
47
The original message is over 5K. Message truncated.
50
Return-Path: <boost-admin@lists.boost.org>
51
Received: from milliways.osl.iu.edu (129.79.245.239)
52
by mta446.mail.yahoo.com with SMTP; 03 Apr 2002 10:59:57 -0800 (PST)
53
Received: from milliways.osl.iu.edu (localhost [127.0.0.1])
54
by milliways.osl.iu.edu (8.11.6/8.11.6/IUCS_2.44) with ESMTP id g33HexA27227;
55
Wed, 3 Apr 2002 12:40:59 -0500
56
Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113])
57
by milliways.osl.iu.edu (8.11.6/8.11.6/IUCS_2.44) with SMTP id g33HcwA27186
58
for <boost@lists.boost.org>; Wed, 3 Apr 2002 12:38:58 -0500
59
Received: from ppp-1-53.chel-5800-8.access.uk.tiscali.com (HELO albert) (RaoulGough@212.159.169.53 with login)
60
by smtp.mail.vip.sc5.yahoo.com with SMTP; 3 Apr 2002 17:38:54 -0000
61
Message-ID: <001601c1db36$6da28950$0100a8c0@albert>
62
From: "Raoul Gough" <RaoulGough@yahoo.co.uk>
63
To: <boost@lists.boost.org>
64
References: <200204011702.g31H2eA04494@milliways.osl.iu.edu>
66
Content-Type: text/plain;
68
Content-Transfer-Encoding: 7bit
70
X-MSMail-Priority: Normal
71
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
72
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
73
Subject: [boost] Re: boost::weak_ptr suggestions
74
Sender: boost-admin@lists.boost.org
75
Errors-To: boost-admin@lists.boost.org
76
X-BeenThere: boost@lists.boost.org
77
X-Mailman-Version: 2.0.8
79
Reply-To: boost@lists.boost.org
80
List-Help: <mailto:boost-request@lists.boost.org?subject=help>
81
List-Post: <mailto:boost@lists.boost.org>
82
List-Subscribe: <http://lists.boost.org/mailman/listinfo.cgi/boost>,
83
<mailto:boost-request@lists.boost.org?subject=subscribe>
84
List-Id: Boost mailing list <boost.lists.boost.org>
85
List-Unsubscribe: <http://lists.boost.org/mailman/listinfo.cgi/boost>,
86
<mailto:boost-request@lists.boost.org?subject=unsubscribe>
87
List-Archive: <http://lists.boost.org/MailArchives/boost/>
88
Date: Wed, 3 Apr 2002 18:37:55 +0100
90
> From: "Peter Dimov" <pdimov@mmltd.net>
91
> To: <boost@lists.boost.org>
92
> Subject: Re: [boost] boost::weak_ptr suggestions
93
> Date: Mon, 1 Apr 2002 17:31:05 +0300
94
> Organization: Multi Media Ltd.
95
> Reply-To: boost@lists.boost.org
97
> From: "Raoul Gough" <RaoulGough@yahoo.co.uk>
99
> > Secondly, I believe it would be better for the get() method to throw or
100
> > assert when called on an invalidated pointer, instead of transparently
101
> > returning 0. In my opinion, there is a fundamental difference between
103
> > two states (null and invalid) which is not observable with the current
104
> > interface. The addition of a member function like "bool is_valid()
106
> > would also allow the user code to decide how to deal with an invalid
107
> > pointer, instead of merging the two distinct states into the one (null)
110
> Right again. However, the primary methods of accessing a weak_ptr are (1)
111
> constructing a shared_ptr (which does throw) and (2) make_shared. get()
113
> been retained for efficiency but is not recommended (in multithreaded
116
So why the difference in error semantics between the single and
117
multi-threaded idioms? For example, if I converted single-threaded code that
118
uses get() to thread-safe code using make_shared, I also get changed
119
semantics for the invalid pointer case.
121
Incidentally, it looks like the use_count member function can determine
122
indirectly whether the target still exists or not. It seems a bit obscure
123
though, seeing as the reference count is really an implementation detail and
124
distinct from the concept of null/valid/invalid.
127
> > The big advantage of considering invalid.get() an error is that code
129
> > then works without error using weak_ptr would have *exactly* unchanged
130
> > semantics using a plain pointer replacement. This allows (for example) a
131
> > debug build/release build choice between weak_ptr<T> and T* for
133
> > reasons. If weak_ptr<T> silently returns null on invalid pointers, then
135
> > guarantee cannot be made - what would be undefined use on a plain
138
> > not detected by the weak_ptr.
140
> Interesting point. You can write your own get() that does what you want:
142
> T * get(weak_ptr<T> const & p)
144
> return shared_ptr<T>(p).get();
147
> but it's not as efficient as a throwing get(). Most people seem to prefer
148
> the current get() semantics, though, where 0 is returned.
150
Well, I can understand that point of view as well - either the weak pointer
151
has a valid target object or not (in which case null or deleted doesn't
152
really matter). However, my use of a smart weak pointer is really as a
153
debugging aid, so I would like the error to be detected as soon as possible
154
(and distinguished from a null-pointer assertion or SEGV). Short of adding a
155
policy class template parameter, it would be easy to add a new member
156
function which does get() with severe checking - along the lines of
157
vector.at versus vector.operator[]. Just an idea.
159
BTW, am I right in thinking that sharede_ptr always maintains an extra weak
160
reference counter? I mean, even if my code doesn't use weak_ptr, shared_ptr
161
still has to maintain the extra counter, right? That, combined with the
162
*** MESSAGE TRUNCATED ***
added
removed
tests/bounces/yahoo_09.txt
