diff options
Diffstat (limited to '')
| -rw-r--r-- | tests/bounces/yahoo_09.txt | 127 |
1 files changed, 5 insertions, 122 deletions
diff --git a/tests/bounces/yahoo_09.txt b/tests/bounces/yahoo_09.txt index f8067a5b..b081e703 100644 --- a/tests/bounces/yahoo_09.txt +++ b/tests/bounces/yahoo_09.txt @@ -36,130 +36,13 @@ List-Archive: <http://lists.boost.org/MailArchives/boost/> Message from yahoo.com. Unable to deliver message to the following address(es). -<hankel_o_fung@yahoo.com>: -Sorry your message to hankel_o_fung@yahoo.com cannot be delivered. This account has been disabled or discontinued. +<userx@example.com>: +Sorry your message to userx@example.com cannot be delivered. This account has been disabled or discontinued. -<ultravirus2001@yahoo.com>: -Sorry your message to ultravirus2001@yahoo.com cannot be delivered. This account has been disabled or discontinued. +<usery@example.com>: +Sorry your message to usery@example.com cannot be delivered. This account has been disabled or discontinued. --- Original message follows. -The original message is over 5K. Message truncated. +Message removed -X-Track: 1: 100 -Return-Path: <boost-admin@lists.boost.org> -Received: from milliways.osl.iu.edu (129.79.245.239) - by mta446.mail.yahoo.com with SMTP; 03 Apr 2002 10:59:57 -0800 (PST) -Received: from milliways.osl.iu.edu (localhost [127.0.0.1]) - by milliways.osl.iu.edu (8.11.6/8.11.6/IUCS_2.44) with ESMTP id g33HexA27227; - Wed, 3 Apr 2002 12:40:59 -0500 -Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) - by milliways.osl.iu.edu (8.11.6/8.11.6/IUCS_2.44) with SMTP id g33HcwA27186 - for <boost@lists.boost.org>; Wed, 3 Apr 2002 12:38:58 -0500 -Received: from ppp-1-53.chel-5800-8.access.uk.tiscali.com (HELO albert) (RaoulGough@212.159.169.53 with login) - by smtp.mail.vip.sc5.yahoo.com with SMTP; 3 Apr 2002 17:38:54 -0000 -Message-ID: <001601c1db36$6da28950$0100a8c0@albert> -From: "Raoul Gough" <RaoulGough@yahoo.co.uk> -To: <boost@lists.boost.org> -References: <200204011702.g31H2eA04494@milliways.osl.iu.edu> -MIME-Version: 1.0 -Content-Type: text/plain; - charset="iso-8859-1" -Content-Transfer-Encoding: 7bit -X-Priority: 3 -X-MSMail-Priority: Normal -X-Mailer: Microsoft Outlook Express 6.00.2600.0000 -X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 -Subject: [boost] Re: boost::weak_ptr suggestions -Sender: boost-admin@lists.boost.org -Errors-To: boost-admin@lists.boost.org -X-BeenThere: boost@lists.boost.org -X-Mailman-Version: 2.0.8 -Precedence: bulk -Reply-To: boost@lists.boost.org -List-Help: <mailto:boost-request@lists.boost.org?subject=help> -List-Post: <mailto:boost@lists.boost.org> -List-Subscribe: <http://lists.boost.org/mailman/listinfo.cgi/boost>, - <mailto:boost-request@lists.boost.org?subject=subscribe> -List-Id: Boost mailing list <boost.lists.boost.org> -List-Unsubscribe: <http://lists.boost.org/mailman/listinfo.cgi/boost>, - <mailto:boost-request@lists.boost.org?subject=unsubscribe> -List-Archive: <http://lists.boost.org/MailArchives/boost/> -Date: Wed, 3 Apr 2002 18:37:55 +0100 - -> From: "Peter Dimov" <pdimov@mmltd.net> -> To: <boost@lists.boost.org> -> Subject: Re: [boost] boost::weak_ptr suggestions -> Date: Mon, 1 Apr 2002 17:31:05 +0300 -> Organization: Multi Media Ltd. -> Reply-To: boost@lists.boost.org -> -> From: "Raoul Gough" <RaoulGough@yahoo.co.uk> -[snip] -> > Secondly, I believe it would be better for the get() method to throw or -> > assert when called on an invalidated pointer, instead of transparently -> > returning 0. In my opinion, there is a fundamental difference between -the -> > two states (null and invalid) which is not observable with the current -> > interface. The addition of a member function like "bool is_valid() -const;" -> > would also allow the user code to decide how to deal with an invalid -> > pointer, instead of merging the two distinct states into the one (null) -> > state. -> -> Right again. However, the primary methods of accessing a weak_ptr are (1) -> constructing a shared_ptr (which does throw) and (2) make_shared. get() -has -> been retained for efficiency but is not recommended (in multithreaded -> programs.) - -So why the difference in error semantics between the single and -multi-threaded idioms? For example, if I converted single-threaded code that -uses get() to thread-safe code using make_shared, I also get changed -semantics for the invalid pointer case. - -Incidentally, it looks like the use_count member function can determine -indirectly whether the target still exists or not. It seems a bit obscure -though, seeing as the reference count is really an implementation detail and -distinct from the concept of null/valid/invalid. - -> -> > The big advantage of considering invalid.get() an error is that code -which -> > then works without error using weak_ptr would have *exactly* unchanged -> > semantics using a plain pointer replacement. This allows (for example) a -> > debug build/release build choice between weak_ptr<T> and T* for -> performance -> > reasons. If weak_ptr<T> silently returns null on invalid pointers, then -> this -> > guarantee cannot be made - what would be undefined use on a plain -pointer -> is -> > not detected by the weak_ptr. -> -> Interesting point. You can write your own get() that does what you want: -> -> T * get(weak_ptr<T> const & p) -> { -> return shared_ptr<T>(p).get(); -> } -> -> but it's not as efficient as a throwing get(). Most people seem to prefer -> the current get() semantics, though, where 0 is returned. - -Well, I can understand that point of view as well - either the weak pointer -has a valid target object or not (in which case null or deleted doesn't -really matter). However, my use of a smart weak pointer is really as a -debugging aid, so I would like the error to be detected as soon as possible -(and distinguished from a null-pointer assertion or SEGV). Short of adding a -policy class template parameter, it would be easy to add a new member -function which does get() with severe checking - along the lines of -vector.at versus vector.operator[]. Just an idea. - -BTW, am I right in thinking that sharede_ptr always maintains an extra weak -reference counter? I mean, even if my code doesn't use weak_ptr, shared_ptr -still has to maintain the extra counter, right? That, combined with the -*** MESSAGE TRUNCATED *** - - -. |