On Wednesday, 26 February 2020 at 01:10:07 UTC, H. S. Teoh wrote:
On Wed, Feb 26, 2020 at 12:50:35AM +, Basile B. via
Digitalmars-d-learn wrote: [...]
#!dmd -boundscheck=off -O -release -inline
[...]
TBH, I'm skeptical of any performance results using dmd. I
wouldn't pay attention to
On Wed, Feb 26, 2020 at 12:50:35AM +, Basile B. via Digitalmars-d-learn
wrote:
[...]
> #!dmd -boundscheck=off -O -release -inline
[...]
TBH, I'm skeptical of any performance results using dmd. I wouldn't pay
attention to performance numbers obtained this way, and rather look at
the
So after reading the translation of RYU I was interested too see
if the decimalLength() function can be written to be faster, as
it cascades up to 8 CMP.
After struggling with bad ideas I finally find something that
looks nice:
- count the leading zero of the input
- switch() this count to
On Tuesday, 25 February 2020 at 22:35:07 UTC, Steven
Schveighoffer wrote:
On 2/25/20 5:26 PM, Marcel wrote:
I can't give you the actual error messages right now, but both
libraries have packages that define modules with the same
name. For example, both libraries have packages with a module
On Tuesday, 25 February 2020 at 22:26:48 UTC, Marcel wrote:
For example, both libraries have packages with a module called
"utility.d".
This is why I now have a strict policy that ALL modules must have
at least a two part name; company.utility or whatever.
alas not everyone follows that :(
On Tue, Feb 25, 2020 at 10:26:48PM +, Marcel via Digitalmars-d-learn wrote:
[...]
> I can't give you the actual error messages right now, but both
> libraries have packages that define modules with the same name. For
> example, both libraries have packages with a module called
> "utility.d".
On 2/25/20 5:26 PM, Marcel wrote:
I can't give you the actual error messages right now, but both libraries
have packages that define modules with the same name. For example, both
libraries have packages with a module called "utility.d". Unfortunately,
this isn't the only thing that causes
On Tuesday, 25 February 2020 at 21:48:00 UTC, Steven
Schveighoffer wrote:
On 2/25/20 4:31 PM, Marcel wrote:
Hello!
I have two libraries, where library B depends on library A,
where both libraries consist of multiple packages. Say my
project (I'm using VisualD) folder layout is the following:
On 2/25/20 4:31 PM, Marcel wrote:
Hello!
I have two libraries, where library B depends on library A, where both
libraries consist of multiple packages. Say my project (I'm using
VisualD) folder layout is the following:
C/:
libA
A_Package1
A_Package2
A_Package3
Hello!
I have two libraries, where library B depends on library A, where
both libraries consist of multiple packages. Say my project (I'm
using VisualD) folder layout is the following:
C/:
libA
A_Package1
A_Package2
A_Package3
libB
B_Package1 - Imports from
On Tuesday, 25 February 2020 at 15:30:19 UTC, Ali Çehreli wrote:
On 2/25/20 3:02 AM, wjoe wrote:> Lets say I've got 3 overloads
of opIndexAssign:
>
> auto opIndexAssign(T t);
> an internet search which didn't find any useful
> information.
I have examples for non-templatized and templatized
On Saturday, 22 February 2020 at 08:29:32 UTC, 9il wrote:
[snip]
Maybe mir.series [1] can work for you.
I had a few other thoughts after looking at septc's solution of
using
y[0..$, 0] *= 100;
to do the calculation.
1) There is probably scope for an additional select function to
handle
On 2/25/20 3:02 AM, wjoe wrote:> Lets say I've got 3 overloads of
opIndexAssign:
>
> auto opIndexAssign(T t);
> an internet search which didn't find any useful
> information.
I have examples for non-templatized and templatized versions of
opIndexAssign here:
On Tuesday, 25 February 2020 at 11:49:50 UTC, Petar Kirov
[ZombineDev] wrote:
On Tuesday, 25 February 2020 at 11:02:40 UTC, wjoe wrote:
[...]
opIndexAssign is the operator used in the following code:
arr[1] = 8;
It returns the element at index 1 (so 8 in this case) by
reference.
This
On Tuesday, 25 February 2020 at 11:02:40 UTC, wjoe wrote:
Lets say I've got 3 overloads of opIndexAssign:
auto opIndexAssign(T t);
auto opIndexAssign(T t, size_t i); and
auto opIndexAssign(T t, size_t[2] i);
I would assume to return what I would return with opIndex but
I'd rather not act upon
Lets say I've got 3 overloads of opIndexAssign:
auto opIndexAssign(T t);
auto opIndexAssign(T t, size_t i); and
auto opIndexAssign(T t, size_t[2] i);
I would assume to return what I would return with opIndex but I'd
rather not act upon assumptions.
But if yes is it supposed to be the newly
16 matches
Mail list logo
