On Thursday, 15 May 2014 at 13:10:29 UTC, Dicebot wrote:
If compiler lacks contextual knowledge, than only means that
range is not actually semantically equivalent to a loop.
Not really. Here is a simple example, a sawtooth generator that
goes from 1 to 0 with a cycle length >=2 (nyquist).
i
On Thursday, 15 May 2014 at 13:01:34 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 15 May 2014 at 12:34:49 UTC, Dicebot wrote:
I think it is your turn to make a counter-example ;)
I've given 2 examples that no compiler can get at… because they
lack contextual knowledge. ;)
If compiler lacks
On Thursday, 15 May 2014 at 12:34:49 UTC, Dicebot wrote:
I think it is your turn to make a counter-example ;)
I've given 2 examples that no compiler can get at… because they
lack contextual knowledge. ;)
Basically anything that involves guards at the end is an issue,
most things that involv
On Wednesday, 14 May 2014 at 14:00:18 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 14 May 2014 at 13:29:35 UTC, Dicebot wrote:
9 int foo1(int max)
10 {
11 int sum = 0;
12 for (auto i = 0; i < max; ++i)
13 {
14 sum += i*2;
15 }
16 return sum;
17 }
This isn't really
On Wednesday, 14 May 2014 at 19:32:57 UTC, Marc Schütz wrote:
Compile this with:
ldc2 -O3 -release -output-s demo.d
and have a look a the generated assembly code for the
Filter.sum() functions. All of them have been inlined as much
as possible, and in particular the variable `is_initializ
On Wednesday, 14 May 2014 at 11:23:16 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 14 May 2014 at 09:47:56 UTC, Marc Schütz wrote:
I wouldn't say never, because optimizers have become damn good.
Well, "never" without a proof is of course a too strong claim.
:-) I agree with that, but I don't
On Wednesday, 14 May 2014 at 13:29:35 UTC, Dicebot wrote:
9 int foo1(int max)
10 {
11 int sum = 0;
12 for (auto i = 0; i < max; ++i)
13 {
14 sum += i*2;
15 }
16 return sum;
17 }
This isn't really a loop. It is an expression: n*(n+1)
Try something more real
On Wednesday, 14 May 2014 at 06:00:33 UTC, Ola Fosheim Grøstad
wrote:
Besides, D ranges will never perform as well as an optimized
explicit loop, so you might as well aim for usability over
speed.
There is no single reason why this should be true. Actually
ranges of medium complexity are alre
On Wednesday, 14 May 2014 at 09:47:56 UTC, Marc Schütz wrote:
I wouldn't say never, because optimizers have become damn good.
Well, "never" without a proof is of course a too strong claim.
:-) I agree with that, but I don't think optimizers are that good
yet even though some of my troubles ha
On Wednesday, 14 May 2014 at 06:00:33 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 13 May 2014 at 17:32:21 UTC, H. S. Teoh via
Digitalmars-d wrote:
Lastly, since the range API is an *abstraction*, it should not
dictate
any concrete implementation details such as whether .empty can
do
non-trivial
On Tuesday, 13 May 2014 at 17:32:21 UTC, H. S. Teoh via
Digitalmars-d wrote:
Lastly, since the range API is an *abstraction*, it should not
dictate
any concrete implementation details such as whether .empty can
do
non-trivial initialization work. Properly-written range-based
code
should be able
On 13.5.2014. 19:40, H. S. Teoh via Digitalmars-d wrote:
> On Tue, May 13, 2014 at 01:29:32PM -0400, Steven Schveighoffer via
> Digitalmars-d wrote:
> [...]
> Even in this case, I'd put an in-contract on f2 that verifies that the
> range is indeed non-empty:
>
> ...
> void f2(
On Tuesday, 13 May 2014 at 16:38:43 UTC, Benjamin Thaut wrote:
I know that there was a recent discussion about how the methods
of ranges should behave.
E.g.
- Does empty always have to be called before calling front or
popFront?
- Is it allowed to call front multiple times between two calls
On Tue, 13 May 2014 13:40:55 -0400, H. S. Teoh via Digitalmars-d
wrote:
On Tue, May 13, 2014 at 01:29:32PM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
[...]
In any case, I think generic code for an unknown range type in an
unknown condition should have to call empty, since it ca
On Tue, 13 May 2014 13:29:32 -0400
Steven Schveighoffer via Digitalmars-d
wrote:
> On Tue, 13 May 2014 12:58:09 -0400, Jonathan M Davis via
> Digitalmars-d wrote:
>
> > On Tue, 13 May 2014 18:38:44 +0200
> > Benjamin Thaut via Digitalmars-d
> > wrote:
> >
> >> I know that there was a recent dis
On Tue, 13 May 2014 10:30:47 -0700
"H. S. Teoh via Digitalmars-d" wrote:
> Of course, for efficiency purposes range-based code (esp. Phobos code)
> should try their best to only call .front once. But it should be
> perfectly permissible to call .front multiple times.
Oh, but that's part of the fu
On Tue, May 13, 2014 at 01:29:32PM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
[...]
> I don't agree there was a consensus. I think empty should not have to
> be called if it's already logically known that the range is not empty.
I only partially agree with this, up to the point where .e
On Tue, May 13, 2014 at 09:58:09AM -0700, Jonathan M Davis via Digitalmars-d
wrote:
> On Tue, 13 May 2014 18:38:44 +0200
> Benjamin Thaut via Digitalmars-d wrote:
>
> > I know that there was a recent discussion about how the methods of
> > ranges should behave.
> >
> > E.g.
> >
> > - Does empty
On Tue, 13 May 2014 12:58:09 -0400, Jonathan M Davis via Digitalmars-d
wrote:
On Tue, 13 May 2014 18:38:44 +0200
Benjamin Thaut via Digitalmars-d wrote:
I know that there was a recent discussion about how the methods of
ranges should behave.
E.g.
- Does empty always have to be called bef
On Tue, 13 May 2014 18:38:44 +0200
Benjamin Thaut via Digitalmars-d wrote:
> I know that there was a recent discussion about how the methods of
> ranges should behave.
>
> E.g.
>
> - Does empty always have to be called before calling front or
> popFront?
Certainly, ranges are pretty much always
I know that there was a recent discussion about how the methods of
ranges should behave.
E.g.
- Does empty always have to be called before calling front or popFront?
- Is it allowed to call front multiple times between two calls to popFront?
Was there a result of that discussion? Is it documen
21 matches
Mail list logo
