I'm working on the new range stuff and the range-based algorithm. In all
likelihood, you all might be pleased with the results.
I wanted to gauge opinions on a couple of issues. One is, should the
empty() member function for ranges be const? On the face of it it
should, but I don't want that t
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> I'm working on the new range stuff and the range-based algorithm. In all
> likelihood, you all might be pleased with the results.
> I wanted to gauge opinions on a couple of issues. One is, should the
> empty() member fun
On 2009-01-24 20:09:07 -0500, Andrei Alexandrescu
said:
I'm working on the new range stuff and the range-based algorithm. In
all likelihood, you all might be pleased with the results.
I wanted to gauge opinions on a couple of issues. One is, should the
empty() member function for ranges be
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
I'm working on the new range stuff and the range-based algorithm. In all
likelihood, you all might be pleased with the results.
I wanted to gauge opinions on a couple of issues. One is, should the
empty()
Michel Fortin wrote:
On 2009-01-24 20:09:07 -0500, Andrei Alexandrescu
said:
I'm working on the new range stuff and the range-based algorithm. In
all likelihood, you all might be pleased with the results.
I wanted to gauge opinions on a couple of issues. One is, should the
empty() member f
Andrei Alexandrescu wrote:
> dsimcha wrote:
>> == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
>> article
>>> I'm working on the new range stuff and the range-based algorithm. In all
>>> likelihood, you all might be pleased with the results.
>>> I wanted to gauge opinions on a
Sat, 24 Jan 2009 17:09:07 -0800, Andrei Alexandrescu wrote:
> I'm working on the new range stuff and the range-based algorithm. In all
> likelihood, you all might be pleased with the results.
>
> I wanted to gauge opinions on a couple of issues. One is, should the
> empty() member function for
Sergey Gromov wrote:
Sat, 24 Jan 2009 17:09:07 -0800, Andrei Alexandrescu wrote:
I'm working on the new range stuff and the range-based algorithm. In all
likelihood, you all might be pleased with the results.
I wanted to gauge opinions on a couple of issues. One is, should the
empty() member
Andrei Alexandrescu:
You can take a look at my dlibs, they may give you ideas, because contain all
such lazy functions and some more.
I presume you have chosen to not tell apart the lazy functions from the eager
ones.
> 2. take(n, range) => takes at most n elements out of a range (very
> usef
Andrei Alexandrescu wrote:
Sergey Gromov wrote:
Sat, 24 Jan 2009 17:09:07 -0800, Andrei Alexandrescu wrote:
I'm working on the new range stuff and the range-based algorithm. In
all likelihood, you all might be pleased with the results.
I wanted to gauge opinions on a couple of issues. One is
On Sun, 25 Jan 2009 23:32:13 +0300, Christopher Wright
wrote:
Andrei Alexandrescu wrote:
Sergey Gromov wrote:
Sat, 24 Jan 2009 17:09:07 -0800, Andrei Alexandrescu wrote:
I'm working on the new range stuff and the range-based algorithm. In
all likelihood, you all might be pleased with the
Christopher Wright wrote:
Andrei Alexandrescu wrote:
Sergey Gromov wrote:
Sat, 24 Jan 2009 17:09:07 -0800, Andrei Alexandrescu wrote:
I'm working on the new range stuff and the range-based algorithm. In
all likelihood, you all might be pleased with the results.
I wanted to gauge opinions on
"Andrei Alexandrescu" wrote
> I'm working on the new range stuff and the range-based algorithm. In all
> likelihood, you all might be pleased with the results.
>
> I wanted to gauge opinions on a couple of issues. One is, should the
> empty() member function for ranges be const? On the face of it
Steven Schveighoffer wrote:
"Andrei Alexandrescu" wrote
I'm working on the new range stuff and the range-based algorithm. In all
likelihood, you all might be pleased with the results.
I wanted to gauge opinions on a couple of issues. One is, should the
empty() member function for ranges be co
bearophile wrote:
Andrei Alexandrescu: You can take a look at my dlibs, they may give
you ideas, because contain all such lazy functions and some more.
You mean the libs in my signature? Sure. :o)
In http://www.fantascienza.net/leonardo/so/dlibs/func.html, I like
functions such as any and all
"Andrei Alexandrescu" wrote
> Steven Schveighoffer wrote:
>> "Andrei Alexandrescu" wrote
>>> I'm working on the new range stuff and the range-based algorithm. In all
>>> likelihood, you all might be pleased with the results.
>>>
>>> I wanted to gauge opinions on a couple of issues. One is, should
Andrei Alexandrescu:
> You mean the libs in my signature? Sure. :o)
:-]
> I like frequency a
> lot, would be very useful for my NLP code (although probably I'd replace
> it with counts and let the user normalize).
It doesn't perform a normalization (I can add to it few more functionalities
bearophile:
> and sometimes not even much intelligent.
I meant: "sometimes not even much interesting."
bearophile wrote:
Andrei Alexandrescu:
I like frequency a lot, would be very useful for my NLP code
(although probably I'd replace it with counts and let the user
normalize).
It doesn't perform a normalization (I can add to it few more
functionalities can be added, but not this one), I'll impr
Steven Schveighoffer wrote:
"Andrei Alexandrescu" wrote
If Retro.empty is const and Range.empty is not, that won't compile. If
Retro.empty is non-const and Range.empty is const, it will compile, but
passing a const Retro won't work as well as passing a const Range.
Hm... you need the template
Steven Schveighoffer Wrote:
> "Andrei Alexandrescu" wrote
> > I'm working on the new range stuff and the range-based algorithm. In all
> > likelihood, you all might be pleased with the results.
> >
> > I wanted to gauge opinions on a couple of issues. One is, should the
> > empty() member functi
On Mon, 26 Jan 2009 23:37:25 +0300, Denis Koroskin <2kor...@gmail.com> wrote:
Steven Schveighoffer Wrote:
"Andrei Alexandrescu" wrote
> I'm working on the new range stuff and the range-based algorithm. In
all
> likelihood, you all might be pleased with the results.
>
> I wanted to gauge opi
Sun, 25 Jan 2009 13:53:43 -0800, Andrei Alexandrescu wrote:
> Christopher Wright wrote:
>> Andrei Alexandrescu wrote:
>>> Sergey Gromov wrote:
Sat, 24 Jan 2009 17:09:07 -0800, Andrei Alexandrescu wrote:
> I'm working on the new range stuff and the range-based algorithm. In
> all
"Denis Koroskin" wrote
> On Mon, 26 Jan 2009 23:37:25 +0300, Denis Koroskin <2kor...@gmail.com>
> wrote:
>> Checking if a range is empty() prior to accessing its head is useful. If
>> empty() is const, you can't do that.
>
> Err.. if empty() is not const and you have a const range reference.
emp
"Andrei Alexandrescu" wrote
> Probably many people would expect to just write this:
>
> void foo(in SomeRange range) { ... }
>
> and have foo look at the range and its elements no problem, without
> actually iterating through the range.
Consider that some type const Range!(T), where T is a refer
Sergey Gromov wrote:
Sun, 25 Jan 2009 13:53:43 -0800, Andrei Alexandrescu wrote:
Christopher Wright wrote:
Andrei Alexandrescu wrote:
Sergey Gromov wrote:
Sat, 24 Jan 2009 17:09:07 -0800, Andrei Alexandrescu wrote:
I'm working on the new range stuff and the range-based algorithm. In
all li
Andrei Alexandrescu:
>Probably array and assign will make the cut as well.<
assign() of my libs is an ugly hack, I'd like such feature to be built-in in
the language, with the comma syntax:
a, b = foo(...)
I use such syntax all the time in Python and it's quite handy.
Something like my Record/r
I was forgetting, Clojure (the nice lisp variant that works on the JavaVM) also
has pmap(), a parallel map() function, that executes the functions in parallel,
on different CPU cores. Such stuff can become quite useful in D2 too:
http://clojure.org/api#toc571
Bye,
bearophile
On Tue, 27 Jan 2009 05:13:31 +0300, Steven Schveighoffer
wrote:
"Denis Koroskin" wrote
On Mon, 26 Jan 2009 23:37:25 +0300, Denis Koroskin <2kor...@gmail.com>
wrote:
Checking if a range is empty() prior to accessing its head is useful.
If
empty() is const, you can't do that.
Err.. if empt
Denis Koroskin wrote:
My point is, if empty() returns false (and you can't know it because
empty() is not const) you may get either an invalid result, access
violation or an exception on member access:
void foo(Range)(const Range r)
{
// is r empty? can I /safely/ access its head?
// let
"Denis Koroskin" wrote
> On Tue, 27 Jan 2009 05:13:31 +0300, Steven Schveighoffer
> wrote:
>
>> "Denis Koroskin" wrote
>>> On Mon, 26 Jan 2009 23:37:25 +0300, Denis Koroskin <2kor...@gmail.com>
>>> wrote:
Checking if a range is empty() prior to accessing its head is useful.
If
emp
31 matches
Mail list logo
