On 10/10/23 10:54 PM, mw wrote:
Hi,
I want to confirm: in the following loop, is the array literal `a` vs.
`b` stack or heap allocated? and how many times?
ask the compiler:
```d
void main() @nogc {
int[2] a;
int[] b;
int i;
while(++i <=100) {
a = [i, i+1]; // array literal
//b =
On Wednesday, 11 October 2023 at 02:54:53 UTC, mw wrote:
Hi,
I want to confirm: in the following loop, is the array literal
`a` vs. `b` stack or heap allocated? and how many times?
void main() {
int[2] a;
int[] b;
int i;
While(++i <=100) {
a = [i, i+1]; // array literal
b = [i,
On Wednesday, 11 October 2023 at 03:15:30 UTC, H. S. Teoh wrote:
On Wed, Oct 11, 2023 at 02:54:53AM +, mw via
Digitalmars-d-learn wrote:
Hi,
I want to confirm: in the following loop, is the array literal
`a` vs. `b` stack or heap allocated? and how many times?
void main() {
int[2
On Wednesday, 11 October 2023 at 02:54:53 UTC, mw wrote:
Hi,
I want to confirm: in the following loop, is the array literal
`a` vs. `b` stack or heap allocated? and how many times?
void main() {
int[2] a;
int[] b;
int i;
While(++i <=100) {
a = [i, i+1]; // array literal
b = [i,
On Wed, Oct 11, 2023 at 02:54:53AM +, mw via Digitalmars-d-learn wrote:
> Hi,
>
> I want to confirm: in the following loop, is the array literal `a` vs.
> `b` stack or heap allocated? and how many times?
>
> void main() {
>
> int[2] a;
This is stack-allocated. Once
Hi,
I want to confirm: in the following loop, is the array literal
`a` vs. `b` stack or heap allocated? and how many times?
void main() {
int[2] a;
int[] b;
int i;
While(++i <=100) {
a = [i, i+1]; // array literal
b = [i, i+1];
}
}
Thanks.
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
> _boardSizeRow.addChild(button);
> > }
> > ```
[...]
> Your code with the variable capture doesn't seem to work.
Argh, apparently locals inside the loop body are subject to the same
quirky behaviour. >:-( Here's a workaround that works:
foreach (BoardSize boardSiz
```
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.
oardSize[1]);
button.onButtonClick = {
eventHandler.settingsWindow_onBoardSizeButtonClick(boardSize);
};
button.onButtonClick();
_boardSizeRow.addChild(button);
}
```
This is a classic D trap: the loop variable is only allocated
once, and the closure captures the single loca
button.onButtonClick = {
> eventHandler.settingsWindow_onBoardSizeButtonClick(boardSize);
> };
> button.onButtonClick();
> _boardSizeRow.addChild(button);
> }
> ```
This is a classic D trap: the loop variable is only allocated once, and
the closure captures the single location where the loop
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
= format("%sx%s", boardSize[0], boardSize[1]);
b[indx].onButtonClick = {
eventHandler.settingsWindow_onBoardSizeButtonClick(boardSize);
};
_boardSizeRow.addChild(b[indx]);
}
```
This is semantically equivalent to copying and pasting the loop
body `arr.length` numbe
ch is gets iterated last.
The problem is twofold:
1. Closures in D capture their environment by reference.
2. D (incorrectly, in my opinion) considers loop-local variables
to have the same identity across each iteration of the loop
within a single function call.
So, `boardSize` in your eve
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 30/08/2022 8:16 AM, Gavin Ray wrote:
It must have been the "writing at end of file" bit?
I don't know.
It read like it should work.
The offsets were correct, it just didn't work *shrug*.
On Monday, 29 August 2022 at 15:52:31 UTC, rikki cattermole wrote:
After a bunch of playing around I managed to determine that it
is as simple as the mode.
exists(dbFileName) ? "r+" : "w+"
Will fix it.
Of course you shouldn't delete the file like that method is
doing. It should probably
On Monday, 29 August 2022 at 16:21:53 UTC, ag0aep6g wrote:
You never change `pageId`. So as far as I can tell, you're
always `seek`-ing to the same position, and you just overwrite
the same piece of the file again and again.
Whoops. I guess I missed the point of the question there.
On Sunday, 28 August 2022 at 22:46:17 UTC, Gavin Ray wrote:
I've put the code, stripped to a minimal example here:
- https://ldc.godbolt.org/z/fzsx3Tnnn
[...]
But if the same code is placed inside of a `for` loop, suddenly
no writes occur:
[...]
Does anyone know what is happening here
After a bunch of playing around I managed to determine that it is as
simple as the mode.
exists(dbFileName) ? "r+" : "w+"
Will fix it.
Of course you shouldn't delete the file like that method is doing. It
should probably reinitialize the FILE* descriptor.
On Monday, 29 August 2022 at 07:04:49 UTC, bauss wrote:
Does anyone know what is happening here? It's really puzzling.
You probably need to flush the output.
That's a good idea. I gave it a shot, and the following doesn't
seem to change anything unfortunately:
```d
void writePage(PageId
]
```
Where here, `pageData` is the data to be written to a file, and
`readData` is the result of trying to read the freshly written
file data.
But if the same code is placed inside of a `for` loop, suddenly
no writes occur:
```d
pageData[0..4] = [0, 0, 0, 0]
readData[0..4] = [0, 0, 0, 0
to a file, and
`readData` is the result of trying to read the freshly written
file data.
But if the same code is placed inside of a `for` loop, suddenly
no writes occur:
```d
pageData[0..4] = [0, 0, 0, 0]
readData[0..4] = [0, 0, 0, 0]
pageData[0..4] = [0, 0, 0, 1]
readData[0..4] = [0, 0, 0, 0
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 you
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, 14 July 2022 at 13:00:24 UTC, ryuukk_ wrote:
On Thursday, 14 July 2022 at 05:30:58 UTC, Siarhei Siamashka
wrote:
On Tuesday, 12 July 2022 at 13:23:36 UTC, ryuukk_ wrote:
I wonder if DMD/LDC/GDC have built in tools to profile and
track performance
Linux has a decent system wide
On Thursday, 14 July 2022 at 05:30:58 UTC, Siarhei Siamashka
wrote:
On Tuesday, 12 July 2022 at 13:23:36 UTC, ryuukk_ wrote:
I wonder if DMD/LDC/GDC have built in tools to profile and
track performance
Linux has a decent system wide profiler:
https://perf.wiki.kernel.org/index.php/Main_Page
: https://godbolt.org/z/GcznbjEaf
From what I gather at the view linked above, DMD does not use
XMM registers for speedup, and does not unroll the loop either.
Switching between 32bit and 64bit doesn't help either.
However, I recall in the past it was capable of at least some
On Tuesday, 12 July 2022 at 13:23:36 UTC, ryuukk_ wrote:
I wonder if DMD/LDC/GDC have built in tools to profile and
track performance
Linux has a decent system wide profiler:
https://perf.wiki.kernel.org/index.php/Main_Page
And there are other useful tools, such as callgrind. To take
On Tuesday, 12 July 2022 at 12:47:26 UTC, bauss wrote:
Of course if you're alone it doesn't matter, but if it's a
larger project that will have multiple maintainers then it will
never work and will tarnish the project entirely.
That's true, i work solo on my project so it doesn't bother me
On Monday, 11 July 2022 at 21:46:10 UTC, IGotD- wrote:
Just depreciate the the DMD backend, it's just not up to the
task anymore.
Just deprecate LDC and GDC. They compile slowly and are unlikely
to ever deliver fast compile times, due to their design.
Some people say they like it because
On Tuesday, 12 July 2022 at 10:32:36 UTC, ryuukk_ wrote:
How do i achieve fast compile speed (results above were on
windows, on linux i get much faster results):
I maintain healthy project management:
This
- Imports of std: i simply don't, and i copy/paste functions i
need
- I avoid
How do i achieve fast compile speed (results above were on
windows, on linux i get much faster results):
I maintain healthy project management:
- Templates ONLY when necessary and when the cost is worth the
time saved in the long term
- this is why i try to lobby for builtin tagged union
On Tuesday, 12 July 2022 at 07:58:44 UTC, bauss wrote:
You don't think this difference is huge? DMD is over 2x as fast.
I think that DMD having more than 10x faster compilation speed in
ryuukk_'s project shows that there is likely either a
misconfiguration in DUB build setup or some other
On Tuesday, 12 July 2022 at 07:06:37 UTC, Siarhei Siamashka wrote:
```
real0m34.371s
user0m32.883s
sys 0m1.488s
```
```
real0m14.078s
user0m12.941s
sys 0m1.129s
```
Is there an open source DUB package, which can be used to
reproduce a huge build time difference
On Monday, 11 July 2022 at 22:16:05 UTC, ryuukk_ wrote:
LDC clean full rebuild
```
$ time dub build -f --compiler=ldc2
Performing "debug" build using ldc2 for x86_64.
game ~master: building configuration "desktop"...
Linking...
real0m18.033s
user0m0.000s
sys 0m0.015s
```
DMD clean
On Monday, 11 July 2022 at 22:16:05 UTC, ryuukk_ wrote:
I use D because DMD compiles my huge project in ~1 second (full
clean rebuild)
It is a competitive advantage that many languages doesn't have
The other programming languages typically use an interpreter for
quick iterations and rapid
On Monday, 11 July 2022 at 21:46:10 UTC, IGotD- wrote:
On Monday, 11 July 2022 at 18:19:41 UTC, max haughton wrote:
The dmd backend is ancient, it isn't really capable of these
kinds of loop optimizations.
I've said it several times before. Just depreciate the the DMD
backend, it's just
On Monday, 11 July 2022 at 18:19:41 UTC, max haughton wrote:
The dmd backend is ancient, it isn't really capable of these
kinds of loop optimizations.
I've said it several times before. Just depreciate the the DMD
backend, it's just not up to the task anymore. This is not
criticism against
: https://godbolt.org/z/GcznbjEaf
From what I gather at the view linked above, DMD does not use
XMM registers for speedup, and does not unroll the loop either.
[snip]
Specifying a SIMD capable target will reveal an even wider gap in
capability. (LDC -mcpu=x86-64-v3 or gdc -march=x86-64-v3).
: https://godbolt.org/z/GcznbjEaf
From what I gather at the view linked above, DMD does not use
XMM registers for speedup, and does not unroll the loop either.
Switching between 32bit and 64bit doesn't help either.
However, I recall in the past it was capable of at least some
linked above, DMD does not use XMM
registers for speedup, and does not unroll the loop either.
Switching between 32bit and 64bit doesn't help either. However,
I recall in the past it was capable of at least some of these
optimizations. So, how do I enable them for such a function?
Ivan
uld cause an infinite loop?
I am not experienced with vibe.d.
'static this' is executed per thread. If requestHTTP starts a
new thread, then I can see how you would be in an infinite
loop. I wonder whether it should be 'shared static this' (which
is executed once per program, not per thread).
Ali
Ve
uld cause an infinite loop?
I am not experienced with vibe.d.
'static this' is executed per thread. If requestHTTP starts a
new thread, then I can see how you would be in an infinite
loop. I wonder whether it should be 'shared static this' (which
is executed once per program, not per thread).
Ali
On 5/19/22 16:44, Vijay Nayar wrote:
> If I remove the call from `static this()`, then the web call works as
> normal. Any idea why calling vibe.d's `requestHTTP` function inside of a
> module's static construction would cause an infinite loop?
I am not experienced with vibe.d.
ot;);
string data = res.bodyReader.readAllUTF8();
logInfo("Log point 2: %s", data);
});
}
static this() {
logInfo("--- static this() ---");
doThing();
}
void main(string[] args) {
logInfo("--- main() ---");
doThing();
}
```
The output of
On Wednesday, 11 May 2022 at 10:01:18 UTC, Johan wrote:
Any function call (inside the loop) for which it cannot be
proven that it never modifies your memory variable will work.
That's why I'm pretty sure that mutex lock/unlock will work.
I think the common semantics ought
On Wednesday, 11 May 2022 at 10:01:18 UTC, Johan wrote:
Any function call (inside the loop) for which it cannot be
proven that it never modifies your memory variable will work.
That's why I'm pretty sure that mutex lock/unlock will work.
Thank you, in C I would not have been surprised
impact
on multithreading. Instead, single-thread execution is assumed,
and thus the optimization is valid.
Your solution with `volatileLoad` is correct.
Access through atomic function would prevent the compiler from
optimising this away as well, but if I were to use a Mutex
inside the loop, there is
Compiler optimizations should not be defined by a programming language
specification.
This will be on LLVM.
Access through atomic function would
prevent the compiler from optimising this away as well, but if I
were to use a Mutex inside the loop, there is no way for the
compiler to tell *what* that Mutex is protecting and it might
still decide to optimise the test away (assuming that is what is
hap
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
with it and loop through the __traits
instead.
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
On Thursday, 23 December 2021 at 16:13:49 UTC, Stanislav Blinov
wrote:
You're comparing apples and oranges.
When benchmarking, at least look at
the generated assembly first.
I looked now and you're right. Insomuch that it should be
eggplant not apple, banana not orange...:)
Because it's an
On Thursday, 23 December 2021 at 07:14:35 UTC, Salih Dincer wrote:
It seems faster than algorithms in Phobos. We would love to see
this in our new Phobos.
Replace: 436 msecs
Malloc : 259 msecs
*/
It seems because MallocReplace is cheating a lot:
- it is not called through another function
On Thursday, 23 December 2021 at 07:14:35 UTC, Salih Dincer wrote:
It seems faster than algorithms in Phobos. We would love to see
this in our new Phobos.
```d
void mallocReplace()
void normalReplace()
string result = str.replace(';',"");
}/* Console Out:
Replace: 436 msecs
Malloc
On Monday, 13 December 2021 at 09:36:57 UTC, Ola Fosheim Grøstad
wrote:
```d
@safe:
string prematureoptimizations(string s, char stripchar)
@trusted {
import core.memory;
immutable uint flags =
GC.BlkAttr.NO_SCAN|GC.BlkAttr.APPENDABLE;
char* begin =
On Friday, 10 December 2021 at 18:47:53 UTC, Stanislav Blinov
wrote:
Threshold could be relative for short strings and absolute for
long ones. Makes little sense reallocating if you only waste a
couple bytes, but makes perfect sense if you've just removed
pages and pages of semicolons ;)
On Monday, 13 December 2021 at 05:46:06 UTC, forkit wrote:
On Saturday, 11 December 2021 at 09:25:37 UTC, Ola Fosheim
Grøstad wrote:
```putchar(…)``` is too slow!
On planet Mars maybe, but here on earth, my computer can do
about 4 billion ticks per second, and my entire program (using
On Saturday, 11 December 2021 at 09:25:37 UTC, Ola Fosheim
Grøstad wrote:
```putchar(…)``` is too slow!
On planet Mars maybe, but here on earth, my computer can do about
4 billion ticks per second, and my entire program (using putchar)
takes only 3084 ticks.
Of course, since it is easy to mess up and use ranges in the
wrong way, you might want to add ```assert```s. That is most
likely *helpful* to newbies that might want to use your kickass
library function:
```
auto helpfuldeatheater(char stripchar)(string str) {
struct voldemort {
On Sunday, 12 December 2021 at 08:58:29 UTC, Ola Fosheim Grøstad
wrote:
this(string s)@trusted{
begin = s.ptr;
end = s.ptr + s.length;
}
}
Bug, it fails if the string ends or starts with ';'.
Fix:
```
this(string s)@trusted{
On Saturday, 11 December 2021 at 19:50:55 UTC, russhy wrote:
you need to import a 8k lines of code module that itself
imports other modules, and then the code is hard to read
I agree.
```
@safe:
auto deatheater(char stripchar)(string str) {
struct voldemort {
immutable(char)*
On Saturday, 11 December 2021 at 18:51:12 UTC, Rumbu wrote:
On Saturday, 11 December 2021 at 14:42:53 UTC, russhy wrote:
Here is mine
- 0 allocations
- configurable
- let's you use it how you wish
- fast
You know that this is already in phobos?
```
"abc;def;ghi".splitter(';').joiner
On Saturday, 11 December 2021 at 14:42:53 UTC, russhy wrote:
Here is mine
- 0 allocations
- configurable
- let's you use it how you wish
- fast
You know that this is already in phobos?
```
"abc;def;ghi".splitter(';').joiner
```
Here is mine
- 0 allocations
- configurable
- let's you use it how you wish
- fast
```D
import std;
void main()
{
string a = "abc;def;ab";
writeln("a => ", a);
foreach(item; split(a, ';'))
writeln("\t", item);
string b = "abc;def ;ab";
writeln("a => ",
On Saturday, 11 December 2021 at 09:40:47 UTC, Stanislav Blinov
wrote:
On Saturday, 11 December 2021 at 09:34:17 UTC, Ola Fosheim
Grøstad wrote:
void donttrythisathome(string s, char stripchar) @trusted {
import core.stdc.stdlib;
char* begin = cast(char*)alloca(s.length);
A
On Saturday, 11 December 2021 at 09:34:17 UTC, Ola Fosheim
Grøstad wrote:
void donttrythisathome(string s, char stripchar) @trusted {
import core.stdc.stdlib;
char* begin = cast(char*)alloca(s.length);
A function with that name, and calling alloca to boot, cannot be
@trusted ;)
On Saturday, 11 December 2021 at 09:34:17 UTC, Ola Fosheim
Grøstad wrote:
@system
Shouldn't be there. Residual leftovers… (I don't want to confuse
newbies!)
On Saturday, 11 December 2021 at 08:46:32 UTC, forkit wrote:
On Saturday, 11 December 2021 at 08:05:01 UTC, Ola Fosheim
Grøstad wrote:
Using libraries can trigger hidden allocations.
ok. fine. no unnecessary, hidden allocations then.
// --
module test;
import
On Saturday, 11 December 2021 at 09:26:06 UTC, Stanislav Blinov
wrote:
What you're showing is... indeed, don't do this, but I fail to
see what that has to do with my suggestion, or the original
code.
You worry too much, just have fun with differing ways of
expressing the same thing.
On Friday, 10 December 2021 at 23:53:47 UTC, Ola Fosheim Grøstad
wrote:
```d
char[] dontdothis(string s, int i=0, int skip=0){
if (s.length == i) return new char[](i - skip);
if (s[i] == ';') return dontdothis(s, i+1, skip+1);
auto r = dontdothis(s, i+1, skip);
r[i-skip] =
On Saturday, 11 December 2021 at 08:46:32 UTC, forkit wrote:
On Saturday, 11 December 2021 at 08:05:01 UTC, Ola Fosheim
Grøstad wrote:
Using libraries can trigger hidden allocations.
ok. fine. no unnecessary, hidden allocations then.
// --
module test;
import
On Saturday, 11 December 2021 at 08:05:01 UTC, Ola Fosheim
Grøstad wrote:
Using libraries can trigger hidden allocations.
ok. fine. no unnecessary, hidden allocations then.
// --
module test;
import core.stdc.stdio : putchar;
nothrow @nogc void main()
{
string str =
On Friday, 10 December 2021 at 18:47:53 UTC, Stanislav Blinov
wrote:
Threshold could be relative for short strings and absolute for
long ones. Makes little sense reallocating if you only waste a
couple bytes, but makes perfect sense if you've just removed
pages and pages of semicolons ;)
On Saturday, 11 December 2021 at 00:39:15 UTC, forkit wrote:
On Friday, 10 December 2021 at 22:35:58 UTC, Arjan wrote:
"abc;def;ghi".tr(";", "", "d" );
I don't think we have enough ways of doing the same thing yet...
so here's one more..
"abc;def;ghi".substitute(";", "");
Using
On Friday, 10 December 2021 at 22:35:58 UTC, Arjan wrote:
"abc;def;ghi".tr(";", "", "d" );
I don't think we have enough ways of doing the same thing yet...
so here's one more..
"abc;def;ghi".substitute(";", "");
On Friday, 10 December 2021 at 18:47:53 UTC, Stanislav Blinov
wrote:
Oooh, finally someone suggested to preallocate storage for all
these reinventions of the wheel :D
```
import std.stdio;
char[] dontdothis(string s, int i=0, int skip=0){
if (s.length == i) return new char[](i - skip);
On Friday, 10 December 2021 at 06:24:27 UTC, Rumbu wrote:
On Wednesday, 8 December 2021 at 11:23:45 UTC, BoQsc wrote:
Let's say I want to skip characters and build a new string.
The character I want to skip: `;`
Expected result:
```
abcdefab
```
Since it seems there is a contest here:
```d
On Friday, 10 December 2021 at 12:15:18 UTC, Rumbu wrote:
I thought it's a beauty contest.
Well, if it's a beauty contest, then i got a beauty..
char[("abc;def;ab".length - count("abc;def;ab", ";"))] b =
"abc;def;ab".replace(";", "");
Yes it will. You can use lazy templates instead, like splitter and joiner,
which splits and joins lazily, respectively. LDC can optimize those templates
fairly well and avoid too much lazy calls and pretty much constructs the logic
equivalent to for loop.
On 10 December 2021 11:06:21 WET
On Friday, 10 December 2021 at 18:47:53 UTC, Stanislav Blinov
wrote:
Be interesting to see if this thread does evolve into a SIMD
http://lemire.me/blog/2017/01/20/how-quickly-can-you-remove-spaces-from-a-string/
On Friday, 10 December 2021 at 13:22:58 UTC, Matheus wrote:
My C way of thinking while using D:
import std;
string stripsemicolons(string input){
char[] s = input.dup;
int j=0;
for(int i=0;i
Oooh, finally someone suggested to preallocate storage for all
these reinventions of
On Wednesday, 8 December 2021 at 11:23:45 UTC, BoQsc wrote:
...
The character I want to skip: `;`
My C way of thinking while using D:
import std;
string stripsemicolons(string input){
char[] s = input.dup;
int j=0;
for(int i=0;i
On Friday, 10 December 2021 at 11:06:21 UTC, IGotD- wrote:
On Friday, 10 December 2021 at 06:24:27 UTC, Rumbu wrote:
Since it seems there is a contest here:
```d
"abc;def;ghi".split(';').join();
```
:)
Would that become two for loops or not?
I thought it's a beauty contest.
```d
string
On Friday, 10 December 2021 at 06:24:27 UTC, Rumbu wrote:
Since it seems there is a contest here:
```d
"abc;def;ghi".split(';').join();
```
:)
Would that become two for loops or not?
On Wednesday, 8 December 2021 at 11:23:45 UTC, BoQsc wrote:
Let's say I want to skip characters and build a new string.
The character I want to skip: `;`
Expected result:
```
abcdefab
```
Since it seems there is a contest here:
```d
"abc;def;ghi".split(';').join();
```
:)
On Thursday, 9 December 2021 at 18:00:42 UTC, kdevel wrote:
PRO:
- saves two lines of boilerplate code
CONS:
- raw loop
- postinc ++ is only permitted in ++C
- inconsistent spacing around "="
- mixing tabs and spaces for indentation
- arrow code
more PROs:
- You become less
1 - 100 of 559 matches
Mail list logo
