Re: Efficient idiom for fastest code

2018-05-22 Thread IntegratedDimensions via Digitalmars-d-learn
On Wednesday, 23 May 2018 at 03:00:17 UTC, Nicholas Wilson wrote: On Wednesday, 23 May 2018 at 02:24:08 UTC, IntegratedDimensions wrote: Many times in expensive loops one must make decisions. Decisions must be determined and the determination costs. for(int i = 0; i < N; i++) {

Re: Efficient idiom for fastest code

2018-05-22 Thread Nicholas Wilson via Digitalmars-d-learn
On Wednesday, 23 May 2018 at 02:24:08 UTC, IntegratedDimensions wrote: Many times in expensive loops one must make decisions. Decisions must be determined and the determination costs. for(int i = 0; i < N; i++) { if(decision(i)) A; else B; } the if statement costs N times the cycle

Efficient idiom for fastest code

2018-05-22 Thread IntegratedDimensions via Digitalmars-d-learn
Many times in expensive loops one must make decisions. Decisions must be determined and the determination costs. for(int i = 0; i < N; i++) { if(decision(i)) A; else B; } the if statement costs N times the cycle cost. In some cases the decision holds for continuous ranges. For some 0

Re: Locking data

2018-05-22 Thread IntegratedDimensions via Digitalmars-d-learn
On Tuesday, 22 May 2018 at 23:09:24 UTC, Sjoerd Nijboer wrote: On Tuesday, 22 May 2018 at 22:17:05 UTC, IntegratedDimensions wrote: On Tuesday, 22 May 2018 at 22:10:52 UTC, Alex wrote: On Tuesday, 22 May 2018 at 21:45:07 UTC, IntegratedDimensions wrote: an idea to lock data by removing the

Re: try & catch / repeating code - DRY

2018-05-22 Thread Meta via Digitalmars-d-learn
On Tuesday, 22 May 2018 at 18:20:43 UTC, Robert M. Münch wrote: I see that I'm writing try { ... different code ... } catch (myException e) { ... same handling code ... } over and over again. Of course I can put the exception handling code into a function to not duplicate it.

Re: Locking data

2018-05-22 Thread Sjoerd Nijboer via Digitalmars-d-learn
On Tuesday, 22 May 2018 at 22:17:05 UTC, IntegratedDimensions wrote: On Tuesday, 22 May 2018 at 22:10:52 UTC, Alex wrote: On Tuesday, 22 May 2018 at 21:45:07 UTC, IntegratedDimensions wrote: an idea to lock data by removing the reference: class A { Lockable!Data data; } The idea is that

Re: Locking data

2018-05-22 Thread IntegratedDimensions via Digitalmars-d-learn
On Tuesday, 22 May 2018 at 22:10:52 UTC, Alex wrote: On Tuesday, 22 May 2018 at 21:45:07 UTC, IntegratedDimensions wrote: an idea to lock data by removing the reference: class A { Lockable!Data data; } The idea is that when the data is going to be used, the user locks the data. The trick

Re: Locking data

2018-05-22 Thread Alex via Digitalmars-d-learn
On Tuesday, 22 May 2018 at 21:45:07 UTC, IntegratedDimensions wrote: an idea to lock data by removing the reference: class A { Lockable!Data data; } The idea is that when the data is going to be used, the user locks the data. The trick here is that data is a pointer to the data and the

Locking data

2018-05-22 Thread IntegratedDimensions via Digitalmars-d-learn
an idea to lock data by removing the reference: class A { Lockable!Data data; } The idea is that when the data is going to be used, the user locks the data. The trick here is that data is a pointer to the data and the pointer is set to null when locked so no other data can use it(they see

Vibe.d Future.getResult blocks others tasks?

2018-05-22 Thread Denis Feklushkin via Digitalmars-d-learn
Hi! Simple question to understand logic of quazi-multithreading: Is Future.getResult blocks other tasks for end of "futured" task? Or, another words, task.getResult causes task to ignore `yeilds` inside of this task?

Re: ldc2 and dmd

2018-05-22 Thread Johan Engelen via Digitalmars-d-learn
On Tuesday, 22 May 2018 at 16:17:48 UTC, Russel Winder wrote: Hi, I have a shared object (of DInotify) compiled with ldc2. I have a program (me-tv) which seems to work when compiled with ldc2. If I compile the program (me-tv) with dmd then it throws a SIGSEGV seemingly in

Re: try & catch / repeating code - DRY

2018-05-22 Thread Ali Çehreli via Digitalmars-d-learn
On 05/22/2018 11:20 AM, Robert M. Münch wrote: I see that I'm writing try { ... different code ... } catch (myException e) { ... same handling code ... } over and over again. Of course I can put the exception handling code into a function to not duplicate it. However, I still need to

Re: try & catch / repeating code - DRY

2018-05-22 Thread Jacob Carlborg via Digitalmars-d-learn
On 2018-05-22 20:20, Robert M. Münch wrote: I see that I'm writing try { ... different code ... } catch (myException e) { ... same handling code ... } over and over again. Of course I can put the exception handling code into a function to not duplicate it. However, I still need to write

try & catch / repeating code - DRY

2018-05-22 Thread Robert M. Münch via Digitalmars-d-learn
I see that I'm writing try { ... different code ... } catch (myException e) { ... same handling code ... } over and over again. Of course I can put the exception handling code into a function to not duplicate it. However, I still need to write this construct over and over again. Is

Re: ldc2 and dmd

2018-05-22 Thread Basile B. via Digitalmars-d-learn
On Tuesday, 22 May 2018 at 16:17:48 UTC, Russel Winder wrote: Hi, I have a shared object (of DInotify) compiled with ldc2. I have a program (me-tv) which seems to work when compiled with ldc2. If I compile the program (me-tv) with dmd then it throws a SIGSEGV seemingly in

ldc2 and dmd

2018-05-22 Thread Russel Winder via Digitalmars-d-learn
Hi, I have a shared object (of DInotify) compiled with ldc2. I have a program (me-tv) which seems to work when compiled with ldc2. If I compile the program (me-tv) with dmd then it throws a SIGSEGV seemingly in _D3std4file15DirIteratorImpl5frontMFNdNfZSQBoQBn8DirEntry in DInotify. Is this

Re: UFCS syntax I never saw before.

2018-05-22 Thread Jonathan M Davis via Digitalmars-d-learn
On Tuesday, May 22, 2018 13:48:16 aliak via Digitalmars-d-learn wrote: > On Monday, 21 May 2018 at 18:53:19 UTC, Jonathan M Davis wrote: > > writeln = "foo"; > > > > is legal, and it's dumb, but it hasn't mattered much in > > practice. So, causing a bunch of code breakage in order to > > disallow

Re: UFCS syntax I never saw before.

2018-05-22 Thread Steven Schveighoffer via Digitalmars-d-learn
On 5/22/18 9:48 AM, aliak wrote: On Monday, 21 May 2018 at 18:53:19 UTC, Jonathan M Davis wrote: writeln = "foo"; is legal, and it's dumb, but it hasn't mattered much in practice. So, causing a bunch of code breakage in order to disallow it is unlikely to go over well. It would also then

Re: auto & class members

2018-05-22 Thread Steven Schveighoffer via Digitalmars-d-learn
On 5/22/18 4:40 AM, Robert M. Münch wrote: On 2018-05-21 18:55:36 +, Steven Schveighoffer said: When you use the alias, both are using the same exact lambda. Ok. I didn't expect that the name is relevant in this case, instead assumed that only the types need to match. The type is the

Re: UFCS syntax I never saw before.

2018-05-22 Thread aliak via Digitalmars-d-learn
On Monday, 21 May 2018 at 18:53:19 UTC, Jonathan M Davis wrote: writeln = "foo"; is legal, and it's dumb, but it hasn't mattered much in practice. So, causing a bunch of code breakage in order to disallow it is unlikely to go over well. It would also then make getters and setters

Re: auto & class members

2018-05-22 Thread Jonathan M Davis via Digitalmars-d-learn
On Tuesday, May 22, 2018 10:40:55 Robert M. Münch via Digitalmars-d-learn wrote: > This would require one wrap function per different lambda, right? > Assume I have 50-100 of these. Maybe the myMessage value can be given > as parameter and with this becomes more like a "filter factory". Not >

Re: auto & class members

2018-05-22 Thread Jonathan M Davis via Digitalmars-d-learn
On Tuesday, May 22, 2018 10:43:38 Robert M. Münch via Digitalmars-d-learn wrote: > On 2018-05-21 20:17:04 +, Jonathan M Davis said: > > On Monday, May 21, 2018 16:05:00 Steven Schveighoffer via Digitalmars-d- > > > > learn wrote: > >> Well one thing that seems clear from this example -- we

Re: UFCS syntax I never saw before.

2018-05-22 Thread aliak via Digitalmars-d-learn
On Monday, 21 May 2018 at 14:19:35 UTC, Steven Schveighoffer wrote: On 5/21/18 8:15 AM, SrMordred wrote: Right, so this should´n be working I think. struct SomeStruct {     void foo(int); } SomeStruct s; s.foo = 10; I thought that only with @property this will work. That was the plan,

Re: UFCS syntax I never saw before.

2018-05-22 Thread ANtlord via Digitalmars-d-learn
On Monday, 21 May 2018 at 18:53:19 UTC, Jonathan M Davis wrote: On Monday, May 21, 2018 14:00:55 ANtlord via Digitalmars-d-learn wrote: If someone wrote an good DIP on the subject, I expect that things could be accelerated, but it's not much a real paint point in practice, and the chances of

Re: auto & class members

2018-05-22 Thread Robert M. Münch via Digitalmars-d-learn
On 2018-05-21 18:55:36 +, Steven Schveighoffer said: So the issue here is that the lambda function inside myFunc is DIFFERENT than the one inside b. They are both the same function, but with essentially different names. Aha... that explains it pretty good. When you use the alias, both

Re: auto & class members

2018-05-22 Thread Robert M. Münch via Digitalmars-d-learn
On 2018-05-21 20:17:04 +, Jonathan M Davis said: On Monday, May 21, 2018 16:05:00 Steven Schveighoffer via Digitalmars-d- learn wrote: Well one thing that seems clear from this example -- we now have __traits(isSame) to tell if lambdas are the same, but it looks like the compiler doesn't

Re: auto & class members

2018-05-22 Thread Robert M. Münch via Digitalmars-d-learn
On 2018-05-21 18:13:16 +, Ali ‡ehreli said: Templatized range types work well when they are used as template arguments themselves. When you need to keep a single type like 'b' (i.e. b is not a template), and when you need to set a variable like mySubStream to a dynamic object, the