A horrible alternative would be to use `alias` on `size_t` to
make up a new pseudo-type that is more aligned with the code
logic.
```
alias integer = size_t;
import std.stdio : writefln;
void main() {
auto arr = [
[5, 15], // 20
[2, 3, 2, 3], // 10
[3, 6, 2,
Well all these proposals to `int` index like `size_t` and `const
typeof(arr.length)` are cryptic and less readable and less
straightforward in comparison to how it used to be. Feels like
horrible decision if the language is suppose to be somewhat
futureproof. The `int` was simple,
On Friday, 3 May 2024 at 15:19:13 UTC, user1234 wrote:
On Friday, 3 May 2024 at 14:59:57 UTC, BoQsc wrote:
On Friday, 3 May 2024 at 13:18:02 UTC, user1234 wrote:
[...]
So how would you update this example, what is the right index
type here to choose?
```
import std.stdio : writefln;
On Friday, 3 May 2024 at 14:59:57 UTC, BoQsc wrote:
On Friday, 3 May 2024 at 13:18:02 UTC, user1234 wrote:
On Friday, 3 May 2024 at 10:50:03 UTC, BoQsc wrote:
[...]
**You can specify the index type, just choose the right one.**
For now there's a deprecation message but after some while
On Friday, 3 May 2024 at 13:18:02 UTC, user1234 wrote:
On Friday, 3 May 2024 at 10:50:03 UTC, BoQsc wrote:
Why am I forced to visit this D Lang thread, why this
deprecation warning still appears in my console window in the
latest version of DMD. Does not make any sense from the
developer's
On Friday, 3 May 2024 at 10:50:03 UTC, BoQsc wrote:
Why am I forced to visit this D Lang thread, why this
deprecation warning still appears in my console window in the
latest version of DMD. Does not make any sense from the
developer's perspective to show this warning and pollute the
already
Why am I forced to visit this D Lang thread, why this deprecation
warning still appears in my console window in the latest version
of DMD. Does not make any sense from the developer's perspective
to show this warning and pollute the already polluted logging
entries of the compiler. How am I
On Monday, 9 January 2023 at 00:19:39 UTC, thebluepandabear wrote:
Fixing this will improve the quality of the language for
newcomers such as myself greatly.
This not only confuses newcomers but it gave a false illusion
of a bug within the code :/
It doesn't confuse newcomers only, also
: create a copy of the value that is currently present in one
particular iteration of the `foreach` by creating a function
literal that takes your `struct` as a paramter. This works
because structs are value types, so passing it to the function
creates a copy.
Thanks, your solution seems to
Fixing this will improve the quality of the language for
newcomers such as myself greatly.
This not only confuses newcomers but it gave a false illusion of
a bug within the code :/
A nested function (or perhaps an inline lambda) is needed to
force the allocation of a dynamic context for the capture.
This is an embarrassment. Why hasn't this been fixed yet? :-(
T
I agree that this needs to get fixed immediately, it seems to be
bugging me another time as well.
I
On Thursday, 5 January 2023 at 22:49:01 UTC, thebluepandabear
wrote:
Have fun reading this :
https://issues.dlang.org/show_bug.cgi?id=21929
Thanks for the code suggestion although it still doesn't fix
the bug. I am curious as to what those brackets do as well.
Okay, my bad for writing the
On Thu, Jan 05, 2023 at 10:46:07PM +, thebluepandabear via
Digitalmars-d-learn wrote:
> On Thursday, 5 January 2023 at 17:36:55 UTC, H. S. Teoh wrote:
[...]
> > ```D
> > foreach (BoardSize boardSize; arr) {
> > Button button = new Button();
> > button.text = format("%sx%s",
```
These two solutions should compile to approximately the same
runtime code, with optimizations enabled. So, it's really down
to personal preference; the former is more explicit about what
the computer is to do, while the latter is more concise.
Thanks! Works great.
Have fun reading this :
https://issues.dlang.org/show_bug.cgi?id=21929
Thanks for the code suggestion although it still doesn't fix the
bug. I am curious as to what those brackets do as well.
On Thursday, 5 January 2023 at 17:36:55 UTC, H. S. Teoh wrote:
On Thu, Jan 05, 2023 at 11:55:33AM +, thebluepandabear via
Digitalmars-d-learn wrote: [...]
```D
foreach (BoardSize boardSize; arr) {
Button button = new Button();
button.text = format("%sx%s", boardSize[0],
On Thu, Jan 05, 2023 at 11:55:33AM +, thebluepandabear via
Digitalmars-d-learn wrote:
[...]
> ```D
> foreach (BoardSize boardSize; arr) {
> Button button = new Button();
> button.text = format("%sx%s", boardSize[0], boardSize[1]);
> button.onButtonClick = {
>
On Thursday, 5 January 2023 at 11:55:33 UTC, thebluepandabear
wrote:
I am using CSFML D bindings and I have created my own sort of
UI library for drawing elements onto the screen.
One of the classes I've created is a `Button` class, which
contains a delegate called `onButtonClick` which is
On Thursday, 5 January 2023 at 13:05:46 UTC, thebluepandabear
wrote:
Update some time later: the only way (oof!) around this seems
to be using a `static foreach` with arrays:
```D
Button[3] b;
static foreach (indx, BoardSize boardSize; arr) {
b[indx] = new Button();
b[indx].text =
On Thursday, 5 January 2023 at 11:55:33 UTC, thebluepandabear
wrote:
```D
foreach (BoardSize boardSize; arr) {
Button button = new Button();
button.text = format("%sx%s", boardSize[0], boardSize[1]);
button.onButtonClick = {
Update some time later: the only way (oof!) around this seems to
be using a `static foreach` with arrays:
```D
Button[3] b;
static foreach (indx, BoardSize boardSize; arr) {
b[indx] = new Button();
b[indx].text = format("%sx%s", boardSize[0], boardSize[1]);
b[indx].onButtonClick
I am using CSFML D bindings and I have created my own sort of UI
library for drawing elements onto the screen.
One of the classes I've created is a `Button` class, which
contains a delegate called `onButtonClick` which is called when
the button is clicked on by the user.
Up until now,
On Monday, 8 August 2022 at 02:45:54 UTC, Steven Schveighoffer
wrote:
And now, you tried to read it again! Which means you are trying
to read more data from an empty stream.
You need to either a) reopen the file, or b) do both in the
same loop.
-Steve
Steve! You are Legend!
**Thank
On 8/7/22 10:11 PM, ikelaiah wrote:
Hi,
I'm writing a program that reads a text file and launch my work URLs in it.
It worked fine, and very happy.
Then I added another `foreach` loop to count total number of lines.
After this, the main `foreach` won't work.
Does anyone know as to why
Hi,
I'm writing a program that reads a text file and launch my work
URLs in it.
It worked fine, and very happy.
Then I added another `foreach` loop to count total number of
lines.
After this, the main `foreach` won't work.
Does anyone know as to why this happens?
I might have missed
On Thursday, 20 January 2022 at 01:14:51 UTC, Adam Ruppe wrote:
On Thursday, 20 January 2022 at 00:55:33 UTC, Jack Stouffer
wrote:
static foreach(member; __traits(allMembers,
Manager))
member here is a string, not the member. I prefer to call it
memberName.
Then you
On Thursday, 20 January 2022 at 00:55:33 UTC, Jack Stouffer wrote:
static foreach(member; __traits(allMembers,
Manager))
member here is a string, not the member. I prefer to call it
memberName.
Then you __traits(getMember, Manager, memberName) to actually get
the alias you can
On Wednesday, 19 January 2022 at 21:49:12 UTC, Adam D Ruppe wrote:
I never use most of std.traits, they just complicate things.
Bleh idk, I wouldn't bother with it and loop through the
__traits instead.
Unless I'm missing something obvious this has to be a DMD bug,
because this prints
On Wednesday, 19 January 2022 at 21:44:57 UTC, Jack Stouffer
wrote:
The error is actually coming from trying to use the result of
getSymbolsByUDA in the right part of the `static foreach`
huh..
I never use most of std.traits, they just complicate things. Bleh
idk, I wouldn't bother with
On Wednesday, 19 January 2022 at 20:53:29 UTC, Adam D Ruppe wrote:
So you want to `__traits(child, system, this).run()` and it
should work - the traits child will re-attach a this value.
The error is actually coming from trying to use the result of
getSymbolsByUDA in the right part of the
On Wednesday, 19 January 2022 at 20:46:17 UTC, Jack Stouffer
wrote:
static foreach(system; getSymbolsByUDA!(Manager,
Runnable))
{
system.run();
onlineapp.d(16): Error: value of `this` is not known at compile
time
The getSymbols returns aliases, meaning you hit
I'm trying to use getSymbolsByUDA in order to loop over all of
the members in a struct with a certain UDA, and then call a
function on the member. The plan is to use this to avoid looping
over an array of function pointers.
However, the compiler is giving a strange error and the
On Thursday, 9 September 2021 at 05:37:35 UTC, Tejas wrote:
On Thursday, 9 September 2021 at 05:32:29 UTC, Tejas wrote:
On Tuesday, 7 September 2021 at 17:47:15 UTC, james.p.leblanc
wrote:
[...]
writeln([0]);
scope(exit) AlignedMallocator.instance.deallocate(buffer);
//...
}
```
On Thursday, 9 September 2021 at 05:32:29 UTC, Tejas wrote:
On Tuesday, 7 September 2021 at 17:47:15 UTC, james.p.leblanc
wrote:
[...]
from what I understand you want to change the aligned data that
you're referring to at runtime.
```d
void main()
{
import
On Tuesday, 7 September 2021 at 17:47:15 UTC, james.p.leblanc
wrote:
On Tuesday, 7 September 2021 at 17:33:31 UTC, Adam D Ruppe
wrote:
On Tuesday, 7 September 2021 at 17:24:34 UTC, james.p.leblanc
wrote:
If you want to do a runtime lookup, you need to separate the
two pieces. This pattern
On Tuesday, 7 September 2021 at 17:24:34 UTC, james.p.leblanc
wrote:
```d
/*…*/
// this is fine (notice that 'val' is never used
foreach( i, val ; u.tupleof ){
ptr = u.tupleof[i].x.ptr;
writeln("ptr: ", ptr);
}
// this fails with: "Error: variable 'i' cannot be read at
On Tuesday, 7 September 2021 at 17:47:15 UTC, james.p.leblanc
wrote:
What I mean by "dig out" the needed "x" is: if I could
alias/enum/
or someother trick be then able just to use that "x" as a
simple static array.
You might be able to just cast the struct to a static array of
the same
On Tuesday, 7 September 2021 at 17:33:31 UTC, Adam D Ruppe wrote:
On Tuesday, 7 September 2021 at 17:24:34 UTC, james.p.leblanc
wrote:
If you want to do a runtime lookup, you need to separate the
two pieces. This pattern works:
switch(runtime_index) {
foreach(i, val; item.tupleof)
On Tuesday, 7 September 2021 at 17:24:34 UTC, james.p.leblanc
wrote:
// this fails with: "Error: variable 'i' cannot be read at
compile time
//
// foreach( i ; 0 .. 3 ){
//ptr = u.tupleof[i].x.ptr;
tuples only exist at compile time, so you'd have to make sure the
indexing is
Dear All,
In playing with some reflection and meta programming, this
curiosity
appeared.
Does someone understand what is happening? I would appreciate
learning
about it if possible. Enclosed code snippet tells the story:
```d
import std.stdio;
import std.traits;
import std.meta;
struct
On Sunday, 29 August 2021 at 11:09:28 UTC, Steven Schveighoffer
wrote:
This is exactly the opposite!
Sorry about that. I can't believe I mixed those up.
On 8/29/21 5:02 AM, Mike Parker wrote:
On Sunday, 29 August 2021 at 08:55:44 UTC, realhet wrote:
Is it safe, or do I have to take a snapsot of the keys range like
this? ->
You shouldn't remove anything when iterating over `.keys` or `.values`.
Use `.byKey` and `.byValue` instead to get
On Sunday, 29 August 2021 at 09:02:52 UTC, Mike Parker wrote:
On Sunday, 29 August 2021 at 08:55:44 UTC, realhet wrote:
Is it safe, or do I have to take a snapsot of the keys range
like this? ->
You shouldn't remove anything when iterating over `.keys` or
`.values`. Use `.byKey` and
On Sunday, 29 August 2021 at 08:55:44 UTC, realhet wrote:
Is it safe, or do I have to take a snapsot of the keys range
like this? ->
You shouldn't remove anything when iterating over `.keys` or
`.values`. Use `.byKey` and `.byValue` instead to get ranges that
are independent of the aa.
Hi,
//remap the result blobs
foreach(k; res.blobs.keys){
int p = map(k);
if(p!=k){
res.blobs[p].weight += res.blobs[k].weight;
res.blobs.remove(k);
}
}
It boils down to:
foreach(k; aa.keys) aa.remove(k);
Is it safe, or do I have to take a snapsot of the keys
On Sunday, 31 January 2021 at 16:50:15 UTC, methonash wrote:
What confuses me, at this point, is this: I originally wrote
the D code using foreach in this style:
foreach( i, ref parentString; strings )
foreach( j, ref childString; strings[ i + 1 .. $ ] )
Essentially, the value of j
On Sunday, 31 January 2021 at 00:53:05 UTC, Steven Schveighoffer
wrote:
I'd suggest trying it in reverse. If you have the sequence
"cba", "ba", "a", then determining "a" is in "ba" is probably
cheaper than determining "a" is in "cba".
I have user requirements that this application track
typically be an O(n^2)
approach.
However, due to subsetting the input dataset to unique strings
and then sorting in descending length, one might notice that
the inner foreach loop does not iterate over all of n, only on
the iterator value i+1 through the end of the array.
Thus, I believe
On 1/30/21 6:13 PM, methonash wrote:
Greetings all,
Many thanks for sharing your collective perspective and advice thus far!
It has been very helpful and instructive. I return bearing live data and
a minimally complete, compilable, and executable program to experiment
with and potentially
Greetings all,
Many thanks for sharing your collective perspective and advice
thus far! It has been very helpful and instructive. I return
bearing live data and a minimally complete, compilable, and
executable program to experiment with and potentially optimize.
The dataset can be pulled
On 1/27/21 10:14 AM, Paul Backus wrote:
On Wednesday, 27 January 2021 at 15:12:32 UTC, Paul Backus wrote:
Maybe it's to avoid invalidating the result of `key in aa` when adding
or removing entries? The spec doesn't say anything about it either way
[1], but allowing invalidation would make
On Wednesday, 27 January 2021 at 14:15:26 UTC, FeepingCreature
wrote:
Associative arrays allocate per entry added?!
https://github.com/dlang/druntime/blob/master/src/rt/aaA.d#L205
Oh God, associative arrays allocate per entry added!
Maybe it's to avoid invalidating the result of `key in aa`
On Wednesday, 27 January 2021 at 15:12:32 UTC, Paul Backus wrote:
Maybe it's to avoid invalidating the result of `key in aa` when
adding or removing entries? The spec doesn't say anything about
it either way [1], but allowing invalidation would make AAs
much more difficult to use in @safe
On Wednesday, 27 January 2021 at 02:14:39 UTC, H. S. Teoh wrote:
Yes, definitely try this. This will completely eliminate the
overhead of using an AA, which has to allocate memory (at
least) once per entry added. Especially since the data has to
be sorted eventually anyway, you might as well
On Wed, Jan 27, 2021 at 01:28:33AM +, Paul Backus via Digitalmars-d-learn
wrote:
> On Tuesday, 26 January 2021 at 23:57:43 UTC, methonash wrote:
> > > Using AA's may not necessarily improve performance. It depends on
> > > what your code does with it. Because AA's require random access
> >
On Tuesday, 26 January 2021 at 23:57:43 UTC, methonash wrote:
Using AA's may not necessarily improve performance. It
depends on what your code does with it. Because AA's require
random access to memory, it's not friendly to the CPU cache
hierarchy, whereas traversing linear arrays is more
how to improve this algorithm.
Nice observation, and yes, this would typically be an O(n^2)
approach.
However, due to subsetting the input dataset to unique strings
and then sorting in descending length, one might notice that the
inner foreach loop does not iterate over all of n, only
On Tuesday, 26 January 2021 at 21:55:47 UTC, mw wrote:
On Tuesday, 26 January 2021 at 17:40:36 UTC, methonash wrote:
foreach( i, ref pStr; sortedArr )
{
foreach( j, ref cStr; sortedArr[ i + 1 .. $ ] )
{
if( indexOf( pStr, cStr ) > -1 )
{
// ... yourInnerOp
On Tuesday, 26 January 2021 at 17:40:36 UTC, methonash wrote:
foreach( i, ref pStr; sortedArr )
{
foreach( j, ref cStr; sortedArr[ i + 1 .. $ ] )
{
if( indexOf( pStr, cStr ) > -1 )
{
// ...
}
}
}
Before adding the code excerpt above, the Dlang
On 1/26/21 12:40 PM, methonash wrote:
My first attempt to solve this problem space used a small Perl program
to perform steps 1 through 3, which would then pipe intermediate output
to a small Dlang program handling only step #4 using dynamic arrays (no
use of AAs) of ubyte[][] with use of
On Tue, Jan 26, 2021 at 06:13:54PM +, methonash via Digitalmars-d-learn
wrote:
[...]
> I cannot post the full source code.
Then we are limited in how much we can help you.
> Regarding a reduced version reproducing the issue: well, that's
> exactly what the nested foreach loop does
for is .release, not .array.
[...]
> With the formally returned array, I then attempted to construct a
> double foreach loop to iterate through the sorted array of unique
> strings and find substring matches.
>
> foreach( i, ref pStr; sortedArr )
> {
> foreach( j, ref cStr; sortedArr[ i
On Tuesday, 26 January 2021 at 17:40:36 UTC, methonash wrote:
Greetings Dlang wizards,
I seek knowledge/understanding of a very frustrating phenomenon
I've experienced over the past several days.
[...]
Source please
, it is quite likely that
some part of the code you do not suspect is actually to blame.
I cannot post the full source code.
Regarding a reduced version reproducing the issue: well, that's
exactly what the nested foreach loop does. Without it, the
program reaches that point quickly.
With the nested
On Tuesday, 26 January 2021 at 17:40:36 UTC, methonash wrote:
foreach( i, ref pStr; sortedArr )
{
foreach( j, ref cStr; sortedArr[ i + 1 .. $ ] )
{
if( indexOf( pStr, cStr ) > -1 )
{
// ...
}
}
}
Before adding the code excerpt above, the Dlang
to convert the returned SortedRange
into an array of type string[]. This appeared to work, and
neither DMD nor LDC threw any warnings/errors for doing this.
With the formally returned array, I then attempted to construct a
double foreach loop to iterate through the sorted array of unique
On Saturday, 27 June 2020 at 07:51:21 UTC, adnan338 wrote:
On Saturday, 27 June 2020 at 07:31:56 UTC, Kagamin wrote:
std.concurrency is for noninteractive appications, the
approach with gui timer was the correct one.
Thank you. That works but my progress bar is sometimes getting
stuck
On Saturday, 27 June 2020 at 07:31:56 UTC, Kagamin wrote:
std.concurrency is for noninteractive appications, the approach
with gui timer was the correct one.
Thank you. That works but my progress bar is sometimes getting
stuck because of a possible data race.
See
std.concurrency is for noninteractive appications, the approach
with gui timer was the correct one.
I have a list of files to download, and I want to download them
in parallel. At the end of each of those parallel download I want
to send the main thread a message from the parallel loop.
import std.concurrency, std.parallelism;
string[] files = ["a", "b", "c"];
void download(string[] links)
On Tuesday, 31 March 2020 at 04:00:28 UTC, User wrote:
I'd like to convert the following program to 2020 standards
(i.e, replace the foreach block with a one-line code). I've
tried much and I failed.
Here is how I'd do it.
Because the program downloads and then reads the local file
I'd like to convert the following program to 2020 standards (i.e,
replace the foreach block with a one-line code). I've tried much
and I failed.
This is the code that works (1990s style)
--
import std;
void main()
{
immutable URL =
On Wednesday, 4 September 2019 at 06:20:00 UTC, berni wrote:
On Tuesday, 3 September 2019 at 20:06:27 UTC, Ferhat Kurtulmuş
wrote:
I know, it is foreach loop in question. How about using a
reverse for loop like:
for (size_t i = arr.length ; i-- > 0 ; ){
arr.remove(i);
}
This wo
On Tuesday, 3 September 2019 at 20:06:27 UTC, Ferhat Kurtulmuş
wrote:
I know, it is foreach loop in question. How about using a
reverse for loop like:
for (size_t i = arr.length ; i-- > 0 ; ){
arr.remove(i);
}
This would be good, if it where for slices. But with associative
arr
you agree? Or is there a better way to achieve this?
I know, it is foreach loop in question. How about using a reverse
for loop like:
for (size_t i = arr.length ; i-- > 0 ; ){
arr.remove(i);
}
On Thursday, 29 August 2019 at 10:11:58 UTC, berni wrote:
Iterating of some structure and removing elements thereby is
always errorprone and should be avoided. But: In case of AA,
I've got the feeling, that it might be safe:
foreach (k,v;ways)
if (v.empty)
ways.remove(k);
Do
reshold, the AA will
> > be resized [1], and its original memory will be freed [2].
>
> It could still work, depending on how the foreach loop is implemented.
> If the keys were stored away before starting the loop it would work.
> But for one thing, it isn't implemented that way and fo
the foreach loop is
implemented. If the keys were stored away before starting the
loop it would work. But for one thing, it isn't implemented that
way and for the other, one shouldn't rely on it, because the
implementation could change. What I hoped for, was, that the
specs enforce somewhere
On Friday, 30 August 2019 at 13:43:54 UTC, XavierAP wrote:
On Thursday, 29 August 2019 at 10:11:58 UTC, berni wrote:
Iterating of some structure and removing elements thereby is
always errorprone and should be avoided. But: In case of AA,
I've got the feeling, that it might be safe:
foreach
On Thursday, 29 August 2019 at 10:11:58 UTC, berni wrote:
Do you agree? Or is there a better way to achieve this?
An alternative would be to reassign the AAA to the output of
std.algorithm.filter()... but assignment between AAs and Ranges
isn't so type-direct.
On Thursday, 29 August 2019 at 10:11:58 UTC, berni wrote:
Iterating of some structure and removing elements thereby is
always errorprone and should be avoided. But: In case of AA,
I've got the feeling, that it might be safe:
foreach (k,v;ways)
if (v.empty)
ways.remove(k);
Do
On Thursday, August 29, 2019 4:11:58 AM MDT berni via Digitalmars-d-learn
wrote:
> Iterating of some structure and removing elements thereby is
> always errorprone and should be avoided. But: In case of AA, I've
>
> got the feeling, that it might be safe:
> > foreach (k,v;ways)
> >
> > if
Iterating of some structure and removing elements thereby is
always errorprone and should be avoided. But: In case of AA, I've
got the feeling, that it might be safe:
foreach (k,v;ways)
if (v.empty)
ways.remove(k);
Do you agree? Or is there a better way to achieve this?
Ok, thanks for explaining. Nice idea.
On Tuesday, 28 May 2019 at 13:43:45 UTC, Nick Treleaven wrote:
Hi,
Last week's TWiD had a tip that didn't make sense:
http://dpldocs.info/this-week-in-d/Blog.Posted_2019_05_20.html#tip-of-the-week
template Locals(int i) {
alias Whatever = int;
}
static foreach(i; [1, 2, 3]) {
Hi,
Last week's TWiD had a tip that didn't make sense:
http://dpldocs.info/this-week-in-d/Blog.Posted_2019_05_20.html#tip-of-the-week
template Locals(int i) {
alias Whatever = int;
}
static foreach(i; [1, 2, 3]) {
Locals!i.Whatever;
}
The body is just `int;`. Not sure how to reach Adam.
On Friday, January 18, 2019 8:34:22 AM MST Michael via Digitalmars-d-learn
wrote:
> On Friday, 18 January 2019 at 13:29:29 UTC, Adam D. Ruppe wrote:
> > On Friday, 18 January 2019 at 12:27:17 UTC, Michael wrote:
> >> This, to be, looks like quite the explicit conversion, no?
> >
> > Yeah, I
On Friday, 18 January 2019 at 13:29:29 UTC, Adam D. Ruppe wrote:
On Friday, 18 January 2019 at 12:27:17 UTC, Michael wrote:
This, to be, looks like quite the explicit conversion, no?
Yeah, I agree. But the language is silly. I just leave the type
out of foreach and explicitly cast it inside
On Friday, 18 January 2019 at 12:27:17 UTC, Michael wrote:
This, to be, looks like quite the explicit conversion, no?
Yeah, I agree. But the language is silly. I just leave the type
out of foreach and explicitly cast it inside the body.
On Friday, 18 January 2019 at 12:27:17 UTC, Michael wrote:
Hello all,
I am getting this deprecation warning when compiling using
DMD64 D Compiler v2.084.0 on Linux. I'm a little unsure what
the problem is, however, because the code producing these
warnings tends to be of the form:
foreach
On 1/18/19 7:27 AM, Michael wrote:
Hello all,
I am getting this deprecation warning when compiling using DMD64 D
Compiler v2.084.0 on Linux. I'm a little unsure what the problem is,
however, because the code producing these warnings tends to be of the form:
foreach (int i, ref prop; props)
Hello all,
I am getting this deprecation warning when compiling using DMD64
D Compiler v2.084.0 on Linux. I'm a little unsure what the
problem is, however, because the code producing these warnings
tends to be of the form:
foreach (int i, ref prop; props)
This, to be, looks like quite
On 8/9/17 9:08 PM, Steven Schveighoffer wrote:
Right, but this is not a limitation of the API, just the implementation.
It could be improved.
https://issues.dlang.org/show_bug.cgi?id=17736
Based on H.S. Teoh's comment in the bug report, this actually is invalid.
That's a tough requirement.
;key < limit;++key)
{
// use x
}
That's enough to know that the foreach loop does not reuse the space
for the iteration variable. That was what I cared about.
Note that using BigInt as iteration variable will probably cause a
BigInt allocation per iteration, because operations on Big
x = key;key < limit;++key)
> > {
> > // use x
> > }
>
> That's enough to know that the foreach loop does not reuse the space
> for the iteration variable. That was what I cared about.
Note that using BigInt as iteration variable will probably cause a
BigInt allo
On Friday, 4 August 2017 at 16:40:08 UTC, Stefan Koch wrote:
[..]
foreach(x;A .. B)
it's lowerd to
auto limit = B;
auto key = A;
for(auto x = key;key < limit;++key)
{
// use x
}
That's enough to know that the foreach loop does not reuse the
space for the iteration variable. That was wha
On Friday, 4 August 2017 at 13:09:55 UTC, Steven Schveighoffer
wrote:
Any foreach range statement like this:
foreach(var; A .. B)
is treated as if you wrote:
for(auto var = A; var < B; ++var)
So it's pretty much exactly like what you wrote, just the
initializer is different but the result
On 8/4/17 8:49 AM, Q. Schroll wrote:
One can do
BigInt n = returnsBigInt();
foreach (i; BigInt(0) .. n)
{ .. }
How is this implemented? The code for BigInt is very large and I didn't
find it.
And is it more efficient than
for (BigInt i = 0; i < n; ++i)
{ .. }
Any foreach range
On Friday, 4 August 2017 at 12:49:30 UTC, Q. Schroll wrote:
One can do
BigInt n = returnsBigInt();
foreach (i; BigInt(0) .. n)
{ .. }
How is this implemented? The code for BigInt is very large and
I didn't find it.
And is it more efficient than
for (BigInt i = 0; i < n; ++i)
{ .. }
One can do
BigInt n = returnsBigInt();
foreach (i; BigInt(0) .. n)
{ .. }
How is this implemented? The code for BigInt is very large and I
didn't find it.
And is it more efficient than
for (BigInt i = 0; i < n; ++i)
{ .. }
as incrementing is a costly operation?
1 - 100 of 173 matches
Mail list logo
