On Thursday, 6 April 2023 at 01:44:15 UTC, H. S. Teoh wrote:
D ranges are conceptually sequential, but the actual underlying
memory access patterns depends on the concrete type at runtime.
An array's elements are stored sequentially in memory, and
arrays are ranges. But a linked-list can
On Tuesday, 4 April 2023 at 16:22:29 UTC, Steven Schveighoffer
wrote:
On 4/4/23 11:34 AM, Salih Dincer wrote:
On Tuesday, 4 April 2023 at 14:20:20 UTC, Steven Schveighoffer
wrote:
parallel is a shortcut to `TaskPool.parallel`, which is
indeed a foreach-only construct, it does not return a
On Thu, Apr 06, 2023 at 01:20:28AM +, Paul via Digitalmars-d-learn wrote:
[...]
> Yes I understand, basically, what's going on in hardware. I just
> wasn't sure if the access type was linked to the container type. It
> seems obvious now, since you've both made it clear, that it also
>
On Wednesday, 5 April 2023 at 23:06:54 UTC, H. S. Teoh wrote:
So your data structures and algorithms should be designed in a
way that takes advantage of linear access where possible.
T
Yes I understand, basically, what's going on in hardware. I just
wasn't sure if the access type was
On Wed, Apr 05, 2023 at 10:34:22PM +, Paul via Digitalmars-d-learn wrote:
> On Tuesday, 4 April 2023 at 22:20:52 UTC, H. S. Teoh wrote:
>
> > Best practices for arrays in hot loops:
[...]
> > - Where possible, prefer sequential access over random access (take
> > advantage of the CPU cache
On 4/5/23 6:34 PM, Paul wrote:
On Tuesday, 4 April 2023 at 22:20:52 UTC, H. S. Teoh wrote:
Best practices for arrays in hot loops:
- Avoid appending if possible; instead, pre-allocate outside the loop.
- Where possible, reuse existing arrays instead of discarding old ones
and allocating new
On Tuesday, 4 April 2023 at 22:20:52 UTC, H. S. Teoh wrote:
Best practices for arrays in hot loops:
- Avoid appending if possible; instead, pre-allocate outside
the loop.
- Where possible, reuse existing arrays instead of discarding
old ones
and allocating new ones.
- Use slices where
On Tue, Apr 04, 2023 at 09:35:29PM +, Paul via Digitalmars-d-learn wrote:
[...]
> Well Steven just making the change you said reduced the execution time
> from ~6-7 secs to ~3 secs. Then, including the 'parallel' in the
> foreach statement took it down to ~1 sec.
>
> Boy lesson learned in
On Monday, 3 April 2023 at 23:50:48 UTC, Steven Schveighoffer
wrote:
So what you need is inside `createSpansOfNoBeacons`, take as a
reference a `ref Span[MAX_SPANS]`, and have it return a
`Span[]` that is a slice of that which was "alocated".
See if this helps.
Well Steven just making the
On 4/4/23 11:34 AM, Salih Dincer wrote:
On Tuesday, 4 April 2023 at 14:20:20 UTC, Steven Schveighoffer wrote:
parallel is a shortcut to `TaskPool.parallel`, which is indeed a
foreach-only construct, it does not return a range.
I think what you want is `TaskPool.map`:
```d
// untested, just
On Tuesday, 4 April 2023 at 14:20:20 UTC, Steven Schveighoffer
wrote:
parallel is a shortcut to `TaskPool.parallel`, which is indeed
a foreach-only construct, it does not return a range.
I think what you want is `TaskPool.map`:
```d
// untested, just looking at the
taskPool.map!(/* your map
On 4/4/23 5:24 AM, Salih Dincer wrote:
Is it necessary to enclose the code in `foreach()`? I invite Ali to tell
me! Please explain why parallel isn't running.
parallel is a shortcut to `TaskPool.parallel`, which is indeed a
foreach-only construct, it does not return a range.
I think what
On 4/4/23 02:24, Salih Dincer wrote:
> I don't understand what `foreach()` does :)
Hm. I forgot whether 'parallel' works only with 'foreach'. But there are
various other algorithms in std.parallelism that may be more useful with
range algorithm chains:
On Monday, 3 April 2023 at 22:24:18 UTC, Steven Schveighoffer
wrote:
So for example, if you have:
```d
foreach(i; iota(0, 2_000_000).parallel)
{
runExpensiveTask(i);
}
```
The foreach is run on the main thread, gets a `0`, then hands
off to a task thread `runExpensiveTask(0)`. Then it gets
On 4/3/23 7:22 PM, Paul wrote:
```d
// Timed main()
vvv
void main(string[] args) {
auto progStartTime = MonoTime.currTime;
//-
string filename =
On Monday, 3 April 2023 at 23:13:58 UTC, Steven Schveighoffer
wrote:
Yeah, please post.
```d
module aoc2215b2;
import std.stdio;
import std.file: readText;
import std.conv: to;
import std.math: abs;
import std.traits;
import std.parallelism;
import std.range;
import core.time: MonoTime;
//
On 4/3/23 6:56 PM, Paul wrote:
On Monday, 3 April 2023 at 22:24:18 UTC, Steven Schveighoffer wrote:
If your `foreach` body takes a global lock (like `writeln(i);`),
then it's not going to run any faster (probably slower actually).
**Ok I did have some debug writelns I commented out.**
And
On Monday, 3 April 2023 at 22:24:18 UTC, Steven Schveighoffer
wrote:
If your `foreach` body takes a global lock (like
`writeln(i);`), then it's not going to run any faster
(probably slower actually).
**Ok I did have some debug writelns I commented out.**
And did it help?
**No**
My
On 4/3/23 6:02 PM, Paul wrote:
On Sunday, 2 April 2023 at 15:32:05 UTC, Steven Schveighoffer wrote:
It's important to note that parallel doesn't iterate the range in
parallel, it just runs the body in parallel limited by your CPU count.
**?!?**
So for example, if you have:
```d
On Sunday, 2 April 2023 at 15:32:05 UTC, Steven Schveighoffer
wrote:
It's important to note that parallel doesn't iterate the range
in parallel, it just runs the body in parallel limited by your
CPU count.
**?!?**
If your `foreach` body takes a global lock (like
`writeln(i);`), then it's
On 4/1/23 6:32 PM, Paul wrote:
On Saturday, 1 April 2023 at 18:30:32 UTC, Steven Schveighoffer wrote:
On 4/1/23 2:25 PM, Paul wrote:
```d
import std.range;
foreach(i; iota(0, 2_000_000).parallel)
```
Is there a way to tell if the parallelism actually divided up the work?
Both versions of
On Sunday, 2 April 2023 at 04:34:40 UTC, Salih Dincer wrote:
I haven't seen rsFirst256 until now...
**Edit:** I saw, I saw :)
I am struck with consternation! I've never seen these results
before. Interesting, there is such a thing as parallel threading
:)
Here are my skipPoints:
```d
On Saturday, 1 April 2023 at 22:48:46 UTC, Ali Çehreli wrote:
On 4/1/23 15:30, Paul wrote:
> Is there a way to verify that it split up the work in to
tasks/threads
> ...?
It is hard to see the difference unless there is actual work in
the loop that takes time.
I always use the Rowland
On 4/1/23 15:30, Paul wrote:
> Is there a way to verify that it split up the work in to tasks/threads
> ...?
It is hard to see the difference unless there is actual work in the loop
that takes time. You can add a Thread.sleep call. (Commented-out in the
following program.)
Another option is
On Saturday, 1 April 2023 at 18:30:32 UTC, Steven Schveighoffer
wrote:
On 4/1/23 2:25 PM, Paul wrote:
```d
import std.range;
foreach(; iota(0, 2_000_000).parallel)
```
-Steve
Is there a way to tell if the parallelism actually divided up the
work? Both versions of my program run in the
```d
import std.range;
foreach(; iota(0, 2_000_000).parallel)
```
-Steve
Is there a way to verify that it split up the work in to
tasks/threads ...? The example you gave me works...compiles w/o
errors but the execution time is the same as the non-parallel
version. They both take about 6
Thanks Steve.
On 4/1/23 2:25 PM, Paul wrote:
Thanks in advance for any assistance.
As the subject line suggests can I do something like? :
```d
foreach (i; taskPool.parallel(0..2_000_000))
```
Obviously this exact syntax doesn't work but I think it expresses the
gist of my challenge.
```d
import
On Wednesday, 1 March 2023 at 19:05:10 UTC, DLearner wrote:
```
Error: variable `wk_Idx` is shadowing variable
`for3.main.wk_Idx`
```
Why is this usage wrong?
Or use the `each` template which is almost the same as `foreach`
to avoid the shadowing variable issue.
```d
import
On Wednesday, 1 March 2023 at 19:05:10 UTC, DLearner wrote:
(1) & (2) compile and run with the expected results.
But (3) fails with:
```
Error: variable `wk_Idx` is shadowing variable
`for3.main.wk_Idx`
```
Why is this usage wrong?
With `foreach`, you can't reuse an existing variable as the
On Thursday, 23 September 2021 at 00:30:45 UTC, Ruby The Roobster
wrote:
I figured out something weird. The variable 'i' is passed by
reference, yet the variable 'i' of the loop isn't being
incremented by posfunc. I assume foreach creates a new i
variable at the start of each new loop.
Yep:
On Thursday, 23 September 2021 at 00:17:49 UTC, jfondren wrote:
On Thursday, 23 September 2021 at 00:06:42 UTC, Ruby The
Roobster wrote:
So, I have the following function:
```d
writeln(tempcolor); //For this matter, the program
correctly reports tempcolor as 1...
for(ubyte j = 0;j <
On Thursday, 23 September 2021 at 00:06:42 UTC, Ruby The Roobster
wrote:
So, I have the following function:
```d
writeln(tempcolor); //For this matter, the program
correctly reports tempcolor as 1...
for(ubyte j = 0;j < tempcolor; j++ /*trying ++j has same
effect*/ ) { //tempcolor
On Wednesday, 25 August 2021 at 11:02:23 UTC, Steven
Schveighoffer wrote:
On 8/25/21 4:31 AM, frame wrote:
On Tuesday, 24 August 2021 at 21:15:02 UTC, Steven
Schveighoffer wrote:
I'm surprised you bring PHP as an example, as it appears
their foreach interface works EXACTLY as D does:
Yeah,
On Wednesday, 25 August 2021 at 19:51:36 UTC, H. S. Teoh wrote:
What I understand from what Andrei has said in the past, is
that a range is merely a "view" into some underlying storage;
it is not responsible for the contents of that storage. My
interpretation of this is that .save will only
On Wed, Aug 25, 2021 at 04:46:54PM +, Joseph Rushton Wakeling via
Digitalmars-d-learn wrote:
> On Wednesday, 25 August 2021 at 10:59:44 UTC, Steven Schveighoffer wrote:
> > structs still provide a mechanism (postblit/copy ctor) to properly
> > save a forward range when copying, even if the
On Wednesday, 25 August 2021 at 17:01:54 UTC, Steven
Schveighoffer wrote:
In a world where copyability means it's a forward range? Yes.
We aren't in that world, it's a hypothetical "if we could go
back and redesign".
OK, that makes sense.
Technically this is true. In practice, it rarely
On 8/25/21 12:46 PM, Joseph Rushton Wakeling wrote:
On Wednesday, 25 August 2021 at 10:59:44 UTC, Steven Schveighoffer wrote:
structs still provide a mechanism (postblit/copy ctor) to properly
save a forward range when copying, even if the guts need copying
(unlike classes). In general, I
On Wednesday, 25 August 2021 at 10:59:44 UTC, Steven
Schveighoffer wrote:
structs still provide a mechanism (postblit/copy ctor) to
properly save a forward range when copying, even if the guts
need copying (unlike classes). In general, I think it was a
mistake to use `.save` as the mechanism,
On 8/25/21 7:26 AM, Alexandru Ermicioi wrote:
On Wednesday, 25 August 2021 at 11:04:35 UTC, Steven Schveighoffer wrote:
It never has called `save`. It makes a copy, which is almost always
the equivalent `save` implementation.
Really?
Then what is the use for .save method then?
The only
On Wednesday, 25 August 2021 at 11:04:35 UTC, Steven
Schveighoffer wrote:
It never has called `save`. It makes a copy, which is almost
always the equivalent `save` implementation.
-Steve
Really?
Then what is the use for .save method then?
The only reason I can find is that you can't declare
On 8/25/21 6:06 AM, Alexandru Ermicioi wrote:
On Wednesday, 25 August 2021 at 08:15:18 UTC, frame wrote:
I know, but foreach() doesn't call save().
Hmm, this is a regression probably, or I missed the time frame when
foreach moved to use of copy constructor for forward ranges.
Do we have a
On 8/25/21 4:31 AM, frame wrote:
On Tuesday, 24 August 2021 at 21:15:02 UTC, Steven Schveighoffer wrote:
I'm surprised you bring PHP as an example, as it appears their foreach
interface works EXACTLY as D does:
Yeah, but the point is, there is a rewind() method. That is called every
time on
On 8/25/21 6:06 AM, Joseph Rushton Wakeling wrote:
On Tuesday, 24 August 2021 at 09:15:23 UTC, bauss wrote:
A range should be a struct always and thus its state is copied when
the foreach loop is created.
That's quite a strong assumption, because its state might be a reference
type, or it
On Tuesday, 24 August 2021 at 09:15:23 UTC, bauss wrote:
A range should be a struct always and thus its state is copied
when the foreach loop is created.
That's quite a strong assumption, because its state might be a
reference type, or it might not _have_ state in a meaningful
sense --
On Wednesday, 25 August 2021 at 08:15:18 UTC, frame wrote:
I know, but foreach() doesn't call save().
Hmm, this is a regression probably, or I missed the time frame
when foreach moved to use of copy constructor for forward ranges.
Do we have a well defined description of what input, forward
On Wednesday, 25 August 2021 at 06:51:36 UTC, bauss wrote:
Of course it doesn't disallow classes but it's generally
advised that you use structs and that's what you want in 99% of
the cases. It's usually a red flag when a range starts being a
reference type.
Well, sometimes you can't avoid
On Tuesday, 24 August 2021 at 21:15:02 UTC, Steven Schveighoffer
wrote:
If you have a for loop:
```d
int i;
for(i = 0; i < someArr.length; ++i)
{
if(someArr[i] == desiredValue) break;
}
```
You are saying, "compiler, please execute the `++i` when I
break from the loop because I already
On Tuesday, 24 August 2021 at 18:52:19 UTC, Alexandru Ermicioi
wrote:
Forward range exposes also capability to create save points,
which is actually used by foreach to do, what it is done in
java by iterable interface for example.
I know, but foreach() doesn't call save().
On Tuesday, 24 August 2021 at 19:06:44 UTC, Alexandru Ermicioi
wrote:
On Tuesday, 24 August 2021 at 09:15:23 UTC, bauss wrote:
A range should be a struct always and thus its state is copied
when the foreach loop is created.
Actually the range contracts don't mention that it needs to be
a
On 8/24/21 1:44 PM, Ferhat Kurtulmuş wrote:
> Just out of curiosity, if a range implementation uses malloc in save, is
> it only possible to free the memory with the dtor?
Yes but It depends on the specific case. For example, if the type has a
clear() function that does clean up, then one
On 8/24/21 2:12 PM, frame wrote:
You can call `popFront` if you need to after the loop, or just before
the break. I have to say, the term "useless" does not even come close
to describing ranges using foreach in my experience.
I disagree, because foreach() is a language construct and therefore
On Tuesday, 24 August 2021 at 19:06:44 UTC, Alexandru Ermicioi
wrote:
On Tuesday, 24 August 2021 at 09:15:23 UTC, bauss wrote:
[...]
Actually the range contracts don't mention that it needs to be
a by value type. It can also be a reference type, i.e. a class.
[...]
True for any forward
On Tuesday, 24 August 2021 at 09:15:23 UTC, bauss wrote:
A range should be a struct always and thus its state is copied
when the foreach loop is created.
Actually the range contracts don't mention that it needs to be a
by value type. It can also be a reference type, i.e. a class.
Which
On Tuesday, 24 August 2021 at 08:36:18 UTC, frame wrote:
How do you handle that issue? Are your ranges designed to have
this bug or do you implement opApply() always?
This is expected behavior imho. I think what you need is a
forward range, not input range. By the contract of input range,
it
On Tuesday, 24 August 2021 at 16:45:27 UTC, H. S. Teoh wrote:
In some cases, you *want* to retain the same element between
loops, e.g., if you're iterating over elements of some category
and stop when you encounter something that belongs to the next
category -- you wouldn't want to consume
On Tuesday, 24 August 2021 at 13:02:38 UTC, Steven Schveighoffer
wrote:
On 8/24/21 4:36 AM, frame wrote:
Consider a simple input range that can be iterated with
empty(), front() and popFront(). That is comfortable to use
with foreach() but what if the foreach loop will be cancelled?
If a
On Tue, Aug 24, 2021 at 08:36:18AM +, frame via Digitalmars-d-learn wrote:
> Consider a simple input range that can be iterated with empty(),
> front() and popFront(). That is comfortable to use with foreach() but
> what if the foreach loop will be cancelled? If a range isn't depleted
> yet
On 8/24/21 4:36 AM, frame wrote:
Consider a simple input range that can be iterated with empty(), front()
and popFront(). That is comfortable to use with foreach() but what if
the foreach loop will be cancelled? If a range isn't depleted yet and
continued it will supply the same data twice on
On Tuesday, 24 August 2021 at 09:26:20 UTC, jfondren wrote:
I think you strayed from the beaten path, in a second way, as
soon as your range's lifetime escaped a single expression, to
be possibly used in two foreach loops. With ranges, as you do
more unusual things, you're already encouraged
On Tuesday, 24 August 2021 at 09:15:23 UTC, bauss wrote:
A range should be a struct always and thus its state is copied
when the foreach loop is created.
This is not conform with the aggregate expression mentioned in
the manual where a class object would be also allowed.
Which means the
On Tuesday, 24 August 2021 at 08:36:18 UTC, frame wrote:
Consider a simple input range that can be iterated with
empty(), front() and popFront(). That is comfortable to use
with foreach() but what if the foreach loop will be cancelled?
If a range isn't depleted yet and continued it will supply
On Tuesday, 24 August 2021 at 08:36:18 UTC, frame wrote:
Consider a simple input range that can be iterated with
empty(), front() and popFront(). That is comfortable to use
with foreach() but what if the foreach loop will be cancelled?
If a range isn't depleted yet and continued it will supply
On Wednesday, 2 June 2021 at 15:49:36 UTC, Marcone wrote:
But I don't want it starts with 0, but other number. How can I
do it?
Easiest way is to just add the starting number:
size_t start = 5;
foreach (n, i; glob("*")) {
print("{} DATA {}".format(n, start + i));
}
You
On 6/2/21 8:49 AM, Marcone wrote:
> But I don't want it starts with 0, but other number. How can I do it?
It is not configurable but is trivial by adding a base value:
import std.stdio;
enum base = 17;
void main() {
auto arr = [ "hello", "world" ];
foreach (i, str; arr) {
const count
On Monday, 18 January 2021 at 18:57:04 UTC, vitamin wrote:
You need something like RefCountedRange with methods popFront,
front, empty.
Thanks! refRange from std.range does the trick, indeed.
On Sunday, 17 January 2021 at 12:15:00 UTC, Fynn Schröder wrote:
I'm puzzled why RefCounted and foreach do not work well
together, i.e.:
```
auto range = refCounted(nonCopyableRange); // ok
foreach(e; range) // Error: struct is not copyable because it
is annotated with @disable
// do
On Tuesday, 27 October 2020 at 08:00:55 UTC, Imperatorn wrote:
On Monday, 26 October 2020 at 19:05:04 UTC, Vino wrote:
[...]
Some comments:
1. You're missing a comma (,) after the first item in your
apidata
2. You're creating a string[int][string] instead of
string[][string] (your
On Monday, 26 October 2020 at 19:05:04 UTC, Vino wrote:
Hi All,
Request your help on the below on how to store the output to
a multi dimensional associative array.
Code:
import std.stdio: writeln;
import asdf: parseJson;
import std.conv: to;
void main()
{
string[int][string] aa;
string
To keep this reply brief, I'll just summarize:
Lots of great takeaways from both of your posts, and a handful of
topics you mentioned that I need to dig into further now. This is
great (I too like D :)
I very much appreciate the extra insight into how things work and
why certain design
On 6/28/20 9:07 AM, Denis wrote:
> * foreach is the actual iterator,
Yes. foreach is "lowered" to the following equivalent:
for ( ; !range.empty; range.popFront()) {
// Use range.front here
}
A struct can support foreach iteration through its opCall() member
function as well.
Many thanks: your post has helped me get past the initial
stumbling blocks I was struggling with. I do have a followup
question.
First, here are my conclusions up to this point, based on your
post above, some additional experimentation, and further research
(for future reference, and for any
On 6/27/20 8:19 PM, Denis wrote:
> Is it possible to write an iterator
It is arguable whether D's ranges are iterators but if nouns are useful,
we call them ranges. :) (Iterators can be written in D as well and then
it would really be confusing.)
>struct letters {
> string str;
>
On 06.08.2018 14:37, Steven Schveighoffer wrote:
On 8/5/18 11:40 AM, Timon Gehr wrote:
On 05.08.2018 16:07, Steven Schveighoffer wrote:
So is this a bug? Is it expected?
It's a bug. The two copies of 'item' are not supposed to be the same
symbol. (Different types -> different symbols.)
On 8/5/18 11:40 AM, Timon Gehr wrote:
On 05.08.2018 16:07, Steven Schveighoffer wrote:
So is this a bug? Is it expected?
It's a bug. The two copies of 'item' are not supposed to be the same
symbol. (Different types -> different symbols.)
Yep. I even found it has nothing to do with foreach
On 8/5/18 10:48 AM, Alex wrote:
void main()
{
Foo foo;
assert(isFoo!foo);
static struct X { int i; Foo foo; }
X x;
static foreach(i, item; typeof(x).tupleof)
static if(is(typeof(item) == Foo)) // line A
static assert(isFoo!item); // line B
On 05.08.2018 16:07, Steven Schveighoffer wrote:
I have found something that looks like a bug to me, but also looks like
it could simply be a limitation of the foreach construct.
Consider this code:
struct Foo {}
enum isFoo(alias x) = is(typeof(x) == Foo);
void main()
{
Foo foo;
On Sunday, 5 August 2018 at 14:07:30 UTC, Steven Schveighoffer
wrote:
I have found something that looks like a bug to me, but also
looks like it could simply be a limitation of the foreach
construct.
Consider this code:
struct Foo {}
enum isFoo(alias x) = is(typeof(x) == Foo);
void main()
On 2018-06-25 15:29:23 +, Robert M. Münch said:
I have two foreach loops where the inner should change the iterator
(append new entries) of the outer.
foreach(a, candidates) {
foreach(b, a) {
if(...) candidates ~= additionalCandidate;
}
}
The foreach docs
On Monday, June 25, 2018 17:29:23 Robert M. Münch via Digitalmars-d-learn
wrote:
> I have two foreach loops where the inner should change the iterator
> (append new entries) of the outer.
>
> foreach(a, candidates) {
> foreach(b, a) {
> if(...) candidates ~= additionalCandidate;
> }
> }
On Mon, Jun 25, 2018 at 05:29:23PM +0200, Robert M. Münch via
Digitalmars-d-learn wrote:
> I have two foreach loops where the inner should change the iterator
> (append new entries) of the outer.
>
> foreach(a, candidates) {
> foreach(b, a) {
> if(...) candidates ~=
On Thursday, 14 June 2018 at 11:31:50 UTC, Robert M. Münch wrote:
I have a simple tree C data-structure that looks like this:
node {
node parent:
vector[node] children;
}
I would like to create two foreach algorthims, one follwing the
breadth first search pattern and one the
On Thursday, 14 June 2018 at 11:31:50 UTC, Robert M. Münch wrote:
I have a simple tree C data-structure that looks like this:
node {
node parent:
vector[node] children;
}
I would like to create two foreach algorthims, one follwing the
breadth first search pattern and one the
On 6/14/18 8:35 AM, Robert M. Münch wrote:
On 2018-06-14 11:46:04 +, Dennis said:
On Thursday, 14 June 2018 at 11:31:50 UTC, Robert M. Münch wrote:
Is this possible? I read about Inputranges, took a look at the RBTree
code etc. but don't relly know/understand where to start.
You can
On 2018-06-14 11:46:04 +, Dennis said:
On Thursday, 14 June 2018 at 11:31:50 UTC, Robert M. Münch wrote:
Is this possible? I read about Inputranges, took a look at the RBTree
code etc. but don't relly know/understand where to start.
You can also use opApply to iterate over a tree using
On Thursday, 14 June 2018 at 11:31:50 UTC, Robert M. Münch wrote:
Is this possible? I read about Inputranges, took a look at the
RBTree code etc. but don't relly know/understand where to start.
You can also use opApply to iterate over a tree using foreach,
see:
On 14/06/2018 11:31 PM, Robert M. Münch wrote:
I have a simple tree C data-structure that looks like this:
node {
struct Node {
node parent:
Node* parent;
vector[node] children;
Node[] children;
}
I would like to create two foreach algorthims, one follwing the breadth
On Sunday, 10 December 2017 at 02:31:47 UTC, Jonathan M Davis
wrote:
On Sunday, December 10, 2017 02:02:31 Dave Jones via
Digitalmars-d wrote:
https://issues.dlang.org/show_bug.cgi?id=14984
Honestly, it would have never occurred to me to try and modify
the variables declared in the foreach
On Sunday, December 10, 2017 02:02:31 Dave Jones via Digitalmars-d wrote:
> Foreach ignores modification to the loop variable...
>
> import std.stdio;
>
> void main() {
> int[10] foo = 10;
>
> foreach (i; 0..10) // writes '10' ten times
> {
> writeln(foo[i]);
> if
On Thursday, 6 July 2017 at 08:49:33 UTC, Stefan Koch wrote:
I'd say this is not often encoutered.
One should avoid using a different type then size_t for the
index, as it can have negative performance implications.
I thought size_t was what it lowered down to using if you used
something
On Thursday, 6 July 2017 at 09:06:18 UTC, Guillaume Chatelet
wrote:
ubyte[256] data;
foreach(ubyte i; 0..256) {
ubyte x = data[i];
}
Yes. Much better. What's the rewrite in this case? Using a
size_t internally and casting to ubyte?
I was just wondering
On Thursday, 6 July 2017 at 09:11:44 UTC, Ola Fosheim Grøstad
wrote:
ubyte[256] data;
if (data.length > 0) {
ubyte i = 0;
do {
writeln(i);
} while ((++i) != cast(ubyte)data.length);
}
Here is another version that will work ok on CPUs that can issue
many instructions in
On Thursday, 6 July 2017 at 09:11:44 UTC, Ola Fosheim Grøstad
wrote:
ubyte[256] data;
if (data.length > 0) {
ubyte i = 0;
do {
writeln(i);
} while ((++i) != cast(ubyte)data.length);
}
You also need to add an assert before the if to check that the
last index can be
On Thursday, 6 July 2017 at 08:26:42 UTC, Guillaume Chatelet
wrote:
A correct lowering would be:
ubyte[256] data;
for(ubyte i = 0;;++i) {
ubyte x = data[i];
...
if(i==255) break;
}
That could lead to two branches in machine language, try to think
about it in terms of if and
On Thursday, 6 July 2017 at 09:00:47 UTC, Andrea Fontana wrote:
On Thursday, 6 July 2017 at 08:26:42 UTC, Guillaume Chatelet
wrote:
From the programmer's point of view the original code makes
sense.
A correct lowering would be:
ubyte[256] data;
for(ubyte i = 0;;++i) {
ubyte x = data[i];
On Thursday, 6 July 2017 at 08:57:42 UTC, Nemanja Boric wrote:
On Thursday, 6 July 2017 at 08:49:33 UTC, Stefan Koch wrote:
On Thursday, 6 July 2017 at 08:26:42 UTC, Guillaume Chatelet
wrote:
[...]
I'd say this is not often encoutered.
One should avoid using a different type then size_t for
On Thursday, 6 July 2017 at 08:26:42 UTC, Guillaume Chatelet
wrote:
From the programmer's point of view the original code makes
sense.
A correct lowering would be:
ubyte[256] data;
for(ubyte i = 0;;++i) {
ubyte x = data[i];
...
if(i==255) break;
}
or:
ubyte[256] data;
On Thursday, 6 July 2017 at 08:49:33 UTC, Stefan Koch wrote:
On Thursday, 6 July 2017 at 08:26:42 UTC, Guillaume Chatelet
wrote:
[...]
I'd say this is not often encoutered.
One should avoid using a different type then size_t for the
index, as it can have negative performance implications.
On Thursday, 6 July 2017 at 08:26:42 UTC, Guillaume Chatelet
wrote:
I stumbled upon https://issues.dlang.org/show_bug.cgi?id=12685
In essence:
[...]
`ubyte` can clearly hold a value from 0 to 255 so it should be
ok. No need for 256 ?!
So I decided to fix it
On 6/14/17 6:02 PM, Ali Çehreli wrote:
On 06/14/2017 12:22 PM, Steven Schveighoffer wrote:
foreach(i, v; hashmap) => i is counter, v is value
Later hashmap adds support for iterating key and value. Now i is key, v
is value. Code means something completely different.
Compare with
foreach(i,
1 - 100 of 811 matches
Mail list logo
