On Wednesday, 23 May 2018 at 03:12:52 UTC, IntegratedDimensions
wrote:
I knew someone was going to say that and I forgot to say DON'T!
Saying to profile when I clearly said these ARE cases where
they are slow is just moronic. Please don't use default answers
to arguments.
This was a general
On Wednesday, 23 May 2018 at 10:55:02 UTC, Malte wrote:
On Wednesday, 23 May 2018 at 02:24:08 UTC, IntegratedDimensions
wrote:
[...]
I would just do
[...]
[...]
Thanks, I didn't think about using a for loop like that. While it
is not the most general it does solve the specific case for
On 5/23/18 3:53 PM, Dr.No wrote:
On Wednesday, 23 May 2018 at 19:49:27 UTC, Jonathan M Davis wrote:
On Wednesday, May 23, 2018 19:36:07 Dr.No via Digitalmars-d-learn wrote:
[...]
As the template constraint in the error message says, read requires an
input range. Static arrays are not
On Wednesday, 23 May 2018 at 19:49:27 UTC, Jonathan M Davis wrote:
On Wednesday, May 23, 2018 19:36:07 Dr.No via
Digitalmars-d-learn wrote:
[...]
As the template constraint in the error message says, read
requires an input range. Static arrays are not input ranges.
You need to give it
On Wednesday, May 23, 2018 19:36:07 Dr.No via Digitalmars-d-learn wrote:
> read fails with both uint and ulong on 64bit platform:
>
> Error: template std.bitmanip.read cannot deduce function from
> argument types !(ulong)(ubyte[8]), candidates are:
>
read fails with both uint and ulong on 64bit platform:
Error: template std.bitmanip.read cannot deduce function from
argument types !(ulong)(ubyte[8]), candidates are:
C:\ldc2-1.9.0-windows-x64\bin\..\import\std\bitmanip.d(3213,3):
std.bitmanip.read(T, Endian endianness =
On Wednesday, 23 May 2018 at 13:36:20 UTC, rikki cattermole wrote:
On 24/05/2018 1:29 AM, Malte wrote:
On Wednesday, 23 May 2018 at 13:24:35 UTC, rikki cattermole
wrote:
On 24/05/2018 1:20 AM, Malte wrote:
On Tuesday, 22 May 2018 at 21:45:07 UTC,
IntegratedDimensions wrote:
an idea to lock
On Monday, 7 May 2018 at 18:10:14 UTC, Matthias Klumpp wrote:
On Saturday, 5 May 2018 at 09:32:32 UTC, Brian wrote:
On Thursday, 3 May 2018 at 10:27:47 UTC, Pasqui23 wrote:
Last commit on https://github.com/buggins/hibernated
was almost a year ago
So what is the status of HibernateD?Should I
On Wednesday, 23 May 2018 at 14:24:18 UTC, Alex wrote:
Ah... ok. Then, let me file a bug...
Bug filed.
https://issues.dlang.org/show_bug.cgi?id=18898
On Wednesday, 23 May 2018 at 14:19:31 UTC, Steven Schveighoffer
wrote:
On 5/23/18 9:59 AM, Alex wrote:
On Wednesday, 23 May 2018 at 13:49:45 UTC, Steven
Schveighoffer wrote:
Right, but not foreach(el1, el2; c), which is the equivalent
of your each call.
Yes. I tried this in the first place
On 5/23/18 9:59 AM, Alex wrote:
On Wednesday, 23 May 2018 at 13:49:45 UTC, Steven Schveighoffer wrote:
Right, but not foreach(el1, el2; c), which is the equivalent of your
each call.
Yes. I tried this in the first place and get a compiler error. But it
seemed logical to me, that if I
On Wednesday, 23 May 2018 at 13:49:45 UTC, Steven Schveighoffer
wrote:
Right, but not foreach(el1, el2; c), which is the equivalent of
your each call.
Yes. I tried this in the first place and get a compiler error.
But it seemed logical to me, that if I define two opApply
overloads, which
On 05/23/2018 06:49 AM, Steven Schveighoffer wrote:
Apparently, but that's not very good. IMO, it should use the same rules
as foreach. In which case, BOTH lines should fail to compile.
-Steve
I think this is a compiler bug (limitation), which I think has been
reported already (or similar
On 5/23/18 9:37 AM, Alex wrote:
This is a question is about usage of
´each´
https://dlang.org/phobos/std_algorithm_iteration.html#each
with a type where different opApply overloads are defined. Say, I have
something like this:
´´´
void main()
{
import std.stdio : writeln;
import
This is a question is about usage of
´each´
https://dlang.org/phobos/std_algorithm_iteration.html#each
with a type where different opApply overloads are defined. Say, I
have something like this:
´´´
void main()
{
import std.stdio : writeln;
import std.algorithm : each;
On 24/05/2018 1:29 AM, Malte wrote:
On Wednesday, 23 May 2018 at 13:24:35 UTC, rikki cattermole wrote:
On 24/05/2018 1:20 AM, Malte 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;
}
On Wednesday, 23 May 2018 at 13:24:35 UTC, rikki cattermole wrote:
On 24/05/2018 1:20 AM, Malte 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;
}
[...]
This sounds like you are
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;
}
[...]
This sounds like you are looking for is an atomic swap. Afaik it
doesn't exist in the standard library. You could use asm for the
On 24/05/2018 1:20 AM, Malte 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;
}
[...]
This sounds like you are looking for is an atomic swap. Afaik it doesn't
exist in the standard
On Monday, 21 May 2018 at 19:44:17 UTC, Jonathan M Davis wrote:
Walter wants to use assertions to then have the compiler make
assumptions about the code and optimized based on it, but he
hasn't implemented anything like that, and there are a number
of arguments about why it's a very bad idea -
On Wednesday, May 23, 2018 04:07:25 Ali Çehreli via Digitalmars-d-learn
wrote:
> On 05/23/2018 12:47 AM, Robert M. Münch wrote:
> > On 2018-05-22 18:34:34 +, Ali ‡ehreli said:
> >> An idiom known in C++ circles is a Lippincott function:
> >>
> >>
> >>
On 05/23/2018 12:47 AM, Robert M. Münch wrote:
On 2018-05-22 18:34:34 +, Ali ‡ehreli said:
An idiom known in C++ circles is a Lippincott function:
https://cppsecrets.blogspot.ca/2013/12/using-lippincott-function-for.html
Just wanted to mention that it can be a part of a clean
On Wednesday, 23 May 2018 at 02:24:08 UTC, IntegratedDimensions
wrote:
In some cases the decision holds for continuous ranges. For
some 0 <= n <= N the decision is constant, but n is
arbitrary(determined by unknown factors at compile time).
One can speed up the routine by using something akin
On 2018-05-22 18:34:34 +, Ali ehreli said:
An idiom known in C++ circles is a Lippincott function:
https://cppsecrets.blogspot.ca/2013/12/using-lippincott-function-for.html
Just wanted to mention that it can be a part of a clean solution.
Thanks, and I assume that D has the same
24 matches
Mail list logo
