On Sunday 23 January 2011 07:12:34 Andrei Alexandrescu wrote:
> On 1/23/11 1:22 AM, Jim wrote:
> > Andrei Alexandrescu Wrote:
> >> I suspect there might be a simple and intuitive way to define a family
> >> of functions that give you whatever portions of the find you're
> >> interested in (before,
On 1/23/11 1:22 AM, Jim wrote:
Andrei Alexandrescu Wrote:
I suspect there might be a simple and intuitive way to define a family
of functions that give you whatever portions of the find you're
interested in (before, match, after, before and match, match and after).
That could be either a naming
On 01/23/2011 06:21 AM, Andrei Alexandrescu wrote:
On 1/22/11 10:59 PM, Jonathan M Davis wrote:
This will be a _fantastic_ function to have. I think that I probably even have
an enhancement request somewhere that includes such a function. It's far too
common that you have to find something and y
Andrei Alexandrescu Wrote:
> I suspect there might be a simple and intuitive way to define a family
> of functions that give you whatever portions of the find you're
> interested in (before, match, after, before and match, match and after).
> That could be either a naming convention or a templat
On 1/22/11 10:59 PM, Jonathan M Davis wrote:
This will be a _fantastic_ function to have. I think that I probably even have
an enhancement request somewhere that includes such a function. It's far too
common that you have to find something and you want both what is before and
after
the point tha
On 1/22/11 10:57 PM, spir wrote:
On 01/23/2011 05:30 AM, Andrei Alexandrescu wrote:
On 01/22/2011 10:16 PM, spir wrote:
On 01/22/2011 10:27 PM, Andrei Alexandrescu wrote:
The first abstraction is the takeExactly() function:
http://d-programming-language.org/cutting-edge/phobos/std_range.html#
On Saturday 22 January 2011 15:19:39 Andrei Alexandrescu wrote:
> On 1/22/11 5:14 PM, Nick Sabalausky wrote:
> > "Andrei Alexandrescu" wrote in message
> > news:ihfm34$jvb$1...@digitalmars.com...
> >
> >> On 1/22/11 4:16 PM, bearophile wrote:
> >>> Andrei:
> Back then people said that STL's
On 01/23/2011 05:30 AM, Andrei Alexandrescu wrote:
On 01/22/2011 10:16 PM, spir wrote:
On 01/22/2011 10:27 PM, Andrei Alexandrescu wrote:
The first abstraction is the takeExactly() function:
http://d-programming-language.org/cutting-edge/phobos/std_range.html#takeExactly
That function allo
On 01/22/2011 10:16 PM, spir wrote:
On 01/22/2011 10:27 PM, Andrei Alexandrescu wrote:
The first abstraction is the takeExactly() function:
http://d-programming-language.org/cutting-edge/phobos/std_range.html#takeExactly
That function allows you to pick a determined number of elements from a
On 01/23/2011 04:49 AM, Daniel Gibson wrote:
splitAt is simply a Good Name! (even better than "tripartite" ;-)
Also for finding it in list of funcs.
Denis
_
vita es estrany
spir.wikidot.com
To be honest, tripartite sounds kind of strange.
I don't know why, but I think of spide
On 01/22/2011 10:27 PM, Andrei Alexandrescu wrote:
The first abstraction is the takeExactly() function:
http://d-programming-language.org/cutting-edge/phobos/std_range.html#takeExactly
That function allows you to pick a determined number of elements from a
range, assuming the range is never sh
Am 23.01.2011 04:42, schrieb spir:
On 01/23/2011 12:40 AM, so wrote:
Yes, I'm absolutely in agreement with the naming (and thrilled too). I
imagine a putative user looking through std.algorithm ("let's see...
what find functions are out there?"). That makes findPieces easy to
get to, whereas "tr
On 01/23/2011 12:40 AM, so wrote:
Yes, I'm absolutely in agreement with the naming (and thrilled too). I
imagine a putative user looking through std.algorithm ("let's see...
what find functions are out there?"). That makes findPieces easy to
get to, whereas "trisect" would be oddly situated in th
On 01/23/2011 12:40 AM, so wrote:
Yes, I'm absolutely in agreement with the naming (and thrilled too). I
imagine a putative user looking through std.algorithm ("let's see...
what find functions are out there?"). That makes findPieces easy to
get to, whereas "trisect" would be oddly situated in th
On 01/22/2011 11:16 PM, bearophile wrote:
That function allows you to pick a determined number of elements from a
> range, assuming the range is never shorter than that. That sounds a bit
> obscure, but plays a pivotal role in findParts() (which is the name I
> settled on for the equivalent of
On 1/22/11 5:41 PM, Tomek Sowiński wrote:
Andrei Alexandrescu napisał:
On 1/22/11 5:14 PM, Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:ihfm34$jvb$1...@digitalmars.com...
On 1/22/11 4:16 PM, bearophile wrote:
Andrei:
Back then people said that STL's find() is better
Yes, I'm absolutely in agreement with the naming (and thrilled too). I
imagine a putative user looking through std.algorithm ("let's see...
what find functions are out there?"). That makes findPieces easy to get
to, whereas "trisect" would be oddly situated in the alphabetic list and
oddly
Andrei Alexandrescu napisał:
> On 1/22/11 5:14 PM, Nick Sabalausky wrote:
> > "Andrei Alexandrescu" wrote in message
> > news:ihfm34$jvb$1...@digitalmars.com...
> >> On 1/22/11 4:16 PM, bearophile wrote:
> >>> Andrei:
> >>>
> Back then people said that STL's find() is better than D's find()
On 1/22/11 5:14 PM, Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:ihfm34$jvb$1...@digitalmars.com...
On 1/22/11 4:16 PM, bearophile wrote:
Andrei:
Back then people said that STL's find() is better than D's find()
because the former returns
an iterator that can be combine
"Andrei Alexandrescu" wrote in message
news:ihfm34$jvb$1...@digitalmars.com...
> On 1/22/11 4:16 PM, bearophile wrote:
>> Andrei:
>>
>>> Back then people said that STL's find() is better than D's find()
>>> because the former returns
>>> an iterator that can be combined with either the first iter
On 1/22/11 4:16 PM, bearophile wrote:
Andrei:
Back then people said that STL's find() is better than D's find()
because the former returns
an iterator that can be combined with either the first iterator to get
the portion before the match, or with the last iterator to get the
portion starting a
Andrei:
> Back then people said that STL's find() is better than D's find()
> because the former returns
> an iterator that can be combined with either the first iterator to get
> the portion before the match, or with the last iterator to get the
> portion starting at the match. D's find() only
22 matches
Mail list logo
