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

From: x.lsi.maillard_at_[hidden]
Date: 2001-12-25 17:57:07

                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:57:06 2001
Return-Path: <sentto-1234907-19315-1009220361-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:57:06 +0100 (CET)
Received: from localhost (localhost.localdomain [127.0.0.1])
        by mail.hometranet.home (Postfix) with ESMTP id 0148B2B075
        for <fxgs_at_localhost>; Tue, 25 Dec 2001 18:50:13 -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:14 -0500 (EST)
Received: from mel-rti17.wanadoo.fr (192.168.156.136) by ms4-2.wanadoo.fr; 24 Dec 2001 19:59:23 +0100
Received: from n20.groups.yahoo.com (216.115.96.70) by mel-rti17.wanadoo.fr; 24 Dec 2001 19:59:23 +0100
X-eGroups-Return: sentto-1234907-19315-1009220361-x.lsi.maillard=wanadoo.fr_at_[hidden]
Received: from [216.115.97.166] by n20.groups.yahoo.com with NNFMP; 24 Dec 2001 18:52:26 -0000
X-Sender: brangdon_at_[hidden]
X-Apparently-To: boost_at_[hidden]
Received: (EGP: mail-8_0_1_3); 24 Dec 2001 18:59:20 -0000
Received: (qmail 83602 invoked from network); 24 Dec 2001 18:59:20 -0000
Received: from unknown (216.115.97.167)
  by m12.grp.snv.yahoo.com with QMQP; 24 Dec 2001 18:59:20 -0000
Received: from unknown (HELO technetium.cix.co.uk) (194.153.0.53)
  by mta1.grp.snv.yahoo.com with SMTP; 24 Dec 2001 18:59:17 -0000
Received: (from cix_at_localhost)
        by technetium.cix.co.uk (8.11.2/8.11.2) id fBOIxEQ09534
        for boost_at_[hidden]; Mon, 24 Dec 2001 18:59:14 GMT
X-Envelope-From: brangdon_at_[hidden]
To: boost_at_[hidden]
Message-Id: <memo.451648_at_[hidden]>
X-Ameol-Version: 2.52.2000, Windows 98 4.90.3000 ( )
X-eGroups-From: brangdon_at_[hidden] (Dave Harris)
From: brangdon_at_[hidden]
X-Yahoo-Profile: brangdon
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: Mon, 24 Dec 2001 18:59 +0000 (GMT)
Subject: Re: [boost] Re: range processing extensions
Reply-To: boost_at_[hidden]
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status:  O

In-Reply-To: <000c01c18c0d$29fe26f0$a65ea240_at_[hidden]>
On Sun, 23 Dec 2001 15:54:30 -0800 James Mitchell (jimdesu_at_[hidden]) 
wrote:
> 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.

My personal view is that post- semantics are so rarely needed they need 
not be supported.

> I dislike the pop_front() and pop_back() because that becomes
> too container-like for my tastes.

I felt they were the clearest, most obvious names for what they did. Using 
a common terminology with containers seemed like a virtue. But then I see 
the semantics as being the same in both cases...

> It also implies that you can shorten a range but not extend it,
> although that might be a matter of interpretation.

I did indeed intend that ranges be shortened but not extended. I feel this 
is more robust. Making a non-empty range shorter is always a safe 
operation. Making it bigger is safe only if we do not make it bigger than 
its underlying container. That is a hard thing to tell by inspecting the 
code. Even enforcing it with assertions can mean carrying more data 
around.

I see this constraint as part of the extra value offered by ranges over 
plain iterators, part of what I mean when I say they are higher level 
objects.

> I definitely want to support both recursive and procedural
> styles, [...]

Me too. I don't see a problem.

> [...] and pop_front() & pop_back() raise the question: "are the
> prior(last) elements still in the range?".

They are not. That is why I see them as similar to the container 
operations. The elements might not actually be destroyed by the operation, 
but as far as this range is concerned they have become inaccessible.

We can make a copy of the range before popping it, if necessary. If we 
need to do a lot of to-ing and fro-ing, maybe the algorithm is more suited 
to iterators anyway?

> 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. 

Are you suggesting that a range be a model of the iterator concept? I 
think that is trying to make them be too many things at once.

One potential problem is that operator*() can reasonably get the element 
at either end. Consider code like:

    template <typename Range>
    void reverse( Range r ) {
        while (r.size() > 1) {
            swap( r.front(), r.back() );
            r.pop_front();
            r.pop_back();
        }
    }

I don't think operator overloading scales to bi-directional ranges, and I 
don't want to make too much of a special case for forward-ranges. If you 
want an iterator, use an iterator - r.begin() will probably do.

> (Of course, operator*() would break, but in that case you
> should know better than to use it!)

Why would it break? I hope my r.front() won't break in code like 
reverse(). It should be an l-value that we can assign to.

> 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.

Not really. Nobody other than me has been in favour of increment/decrement 
on ranges at all, so there hasn't been much discussion of what form they 
should take.

-- Dave Harris

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/