[auto-reply] Re: [boost] Re: range processing extensions

From: x.lsi.maillard_at_[hidden]
Date: 2001-12-25 17:56:24

                THIS IS AN AUTOMATICALLY GENERATED REPLY
                   Your mail to me has been discarded

Hi! You have reached the mail filter of one Richard Gooch. I'm sorry
to have to do this to you, but I am now filtering my email to combat
the flood of junk email (spam) that I receive. I'm fed up with having
to waste my time sifting through junk email. This filter also protects
me from certain types of mailbombing attacks.

I received an email from you, but my mail filter doesn't think you
sent it to me personally. This may be because I am on some mailing
list I'm not aware of. It may also have come from a mailing list I
*am* subscribed to, but the list adminstrators have started fiddling
with (breaking) the listserver.
APOLOGIES if the mailing list is genuine (i.e. not a spam list). If
you receive this reply because of a message you sent to a genuine
mailing list, please send me a message (telling me which mailing list
I'm on) with the following in the subject line:

293977

This is my password of the week. My mail filter will then let me see
the message. NOTE: the password MUST be in the subject, not the body.
I will then add a rule for the mailing list (or unsubscribe myself if
I don't wish to be subscribed) so that this won't happen again. I
apologise to people subscribed to mailing lists if this message is
sent to the whole list; I have taken considerable care to make sure
that mailing lists I want to be subscribed to are not affected by my
spam filter.

NOTE TO BULK EMAIL ADVERTISERS, SPAMMERS AND OTHER PARASITES: if you
manage to break through my filtering, rest assured that I will ignore
your message on principle. Future mails will be automatically deleted.
Unsolicited commercial email is unwelcome and costs *me* time to deal
with.

The message you apparently sent to me follows:

>From fxgs  Tue Dec 25 23:56:23 2001
Return-Path: <sentto-1234907-19304-1009199672-x.lsi.maillard=wanadoo.fr_at_[hidden]>
Delivered-To: fxgs_at_localhost.hometranet.home
Received: from 192.168.1.2 [192.168.1.2]
        by localhost with POP3 (fetchmail-5.9.0)
        for fxgs_at_localhost (single-drop); Tue, 25 Dec 2001 23:56:23 +0100 (CET)
Received: from localhost (localhost.localdomain [127.0.0.1])
        by mail.hometranet.home (Postfix) with ESMTP id DA6572B075
        for <fxgs_at_localhost>; Tue, 25 Dec 2001 18:50:02 -0500 (EST)
Received: from pop.wanadoo.fr
        by localhost with POP3 (fetchmail-5.7.4)
        for fxgs_at_localhost (single-drop); Tue, 25 Dec 2001 18:50:02 -0500 (EST)
Received: from tamaris.wanadoo.fr (192.168.156.27) by ms4-2.wanadoo.fr; 24 Dec 2001 14:27:20 +0100
Received: from n11.groups.yahoo.com (216.115.96.61) by tamaris.wanadoo.fr; 24 Dec 2001 14:27:10 +0100
X-eGroups-Return: sentto-1234907-19304-1009199672-x.lsi.maillard=wanadoo.fr_at_[hidden]
Received: from [216.115.97.162] by n11.groups.yahoo.com with NNFMP; 24 Dec 2001 13:14:32 -0000
Received: (qmail 61629 invoked from network); 24 Dec 2001 13:14:31 -0000
Received: from unknown (216.115.97.171)
  by m8.grp.snv.yahoo.com with QMQP; 24 Dec 2001 13:14:31 -0000
Received: from unknown (HELO n24.groups.yahoo.com) (216.115.96.74)
  by mta3.grp.snv.yahoo.com with SMTP; 24 Dec 2001 13:14:31 -0000
X-eGroups-Return: jimdesu_at_[hidden]
Received: from [216.115.96.164] by n24.groups.yahoo.com with NNFMP; 24 Dec 2001 13:14:30 -0000
X-eGroups-Approved-By: beman_d <bdawes_at_[hidden]> via web; 24 Dec 2001 13:14:28 -0000
X-Sender: jimdesu_at_[hidden]
X-Apparently-To: boost_at_[hidden]
Received: (EGP: mail-8_0_1_3); 23 Dec 2001 23:56:44 -0000
Received: (qmail 22172 invoked from network); 23 Dec 2001 23:56:43 -0000
Received: from unknown (216.115.97.171)
  by m6.grp.snv.yahoo.com with QMQP; 23 Dec 2001 23:56:43 -0000
Received: from unknown (HELO mta6.snfc21.pbi.net) (206.13.28.240)
  by mta3.grp.snv.yahoo.com with SMTP; 23 Dec 2001 23:56:43 -0000
Received: from black ([64.162.94.166])
 by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May  7 2001))
 with SMTP id <0GOT002MEMIIQD_at_[hidden]> for boost_at_[hidden];
 Sun, 23 Dec 2001 15:56:43 -0800 (PST)
To: boost_at_[hidden]
Message-id: <000c01c18c0d$29fe26f0$a65ea240_at_[hidden]>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-Priority: 3
X-MSMail-priority: Normal
References: <1009122996.527.38403.m12_at_[hidden]>
From: James Mitchell <jimdesu_at_[hidden]>
X-Yahoo-Profile: jimdesu
MIME-Version: 1.0
Mailing-List: list boost_at_[hidden]; contact boost-owner_at_[hidden]
Delivered-To: mailing list boost_at_[hidden]
Precedence: bulk
List-Unsubscribe: <mailto:boost-unsubscribe_at_[hidden]>
Date: Sun, 23 Dec 2001 15:54:30 -0800
Subject: [boost] Re: range processing extensions
Reply-To: boost_at_[hidden]
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status:  O

> For what it's worth, I still think incrementors and decrementors are
> beneficial.  (I'd prefer names like pop_front() and pop_back() to operator
> overloading. We ought to support bi-directional ranges as well as forward
So far as operator overloading goes for a range, I think it's important to
overload at least the increment and decrement operators because they provide
pre- and post- semantics.  I dislike the pop_front() and pop_back() because
that becomes too container-like for my tastes.  It also implies that you can
shorten a range but not extend it, although that might be a matter of
interpretation.  I definitely want to support both recursive and procedural
styles, and pop_front() & pop_back() raise the question: "are the
prior(last) elements still in the range?".  With operator++() and
operator--()(& their "int" buddies) and pointer-style dereference it's
blatantly obvious that you're operating via indirection to some container
somewhere, rather than dealing with stored values which may or may not
become removed.  The copy vs. reference semantics here are of paramount
importance.  I also think the pointer-like semantics make more sense with
generators and filters: by keeping with such, you could potentially pass
back to the user a functor of type range<char> returning {'a',...,'z'} or
somesuch, which would work automagically with the operators, but not with
other functions.  (Of course, operator*() would break, but in that case you
should know better than to use it!)  It's more compatible with the
generalized notion of a range not being a collection of indirected things,
per se, but a sequence of values(which may or may not be references to
things).  Granted that I've only skimmed the articles to which you and Darin
have pointed me(xmas things getting in the way of coding-related stuff!), so
this may have been all hashed out already.

James

Info: http://www.boost.org  Send unsubscribe requests to: <mailto:boost-unsubscribe_at_[hidden]> 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/