On Friday, June 12, 2020 5:12:35 PM MDT claptrap via Digitalmars-d-learn
wrote:
> struct Foo
> {
> float* what;
> float opIndex(size_t idx) { return what[idx]; }
> }
>
> Foo* foo;
> float x = foo[idx]; // ***
>
>
> *** (68): Error: cannot implicitly convert expression
> `foo[cast(ulong)i
struct Foo
{
float* what;
float opIndex(size_t idx) { return what[idx]; }
}
Foo* foo;
float x = foo[idx]; // ***
*** (68): Error: cannot implicitly convert expression
`foo[cast(ulong)idx]` of type `Foo` to `float`
IE, pointer indexing of 'foo' takes precedence over the opIndex
of fo
On Fri, Jun 12, 2020 at 12:11:44PM +, duck_tape via Digitalmars-d-learn
wrote:
> On Friday, 12 June 2020 at 12:02:19 UTC, duck_tape wrote:
> > For speedups with getting my hands dirty:
> > - Does writef and company flush on every line? I still haven't found
> > the source of this.
writef, et
On Friday, 12 June 2020 at 19:21:46 UTC, kinke wrote:
On Friday, 12 June 2020 at 15:21:12 UTC, Guillaume Piolat wrote:
Any idea what could be causing this?
Mentioning at least the used LDC version would be helpful;
especially since the MSVC detection was completely overhauled
with the v1.22
I have a list of files to download from the internet. Each of
those downloads are a time consuming task.
What I want to do is download them concurrently and when each of
those downloads finish, I want to activate something in my main
thread, which will update a progressbar in the GUI thread.
On Thu, Jun 11, 2020 at 10:46:32AM +, Paul Backus via Digitalmars-d-learn
wrote:
> On Thursday, 11 June 2020 at 05:41:25 UTC, H. S. Teoh wrote:
> >
> > Ironically, just today I ran into this corner case where @property
> > actually became a solution to a real problem:
> >
> > //-modu
On Fri, Jun 12, 2020 at 09:29:06PM +, MoonlightSentinel via
Digitalmars-d-learn wrote:
> On Friday, 12 June 2020 at 18:18:25 UTC, Per Nordlöw wrote:
> > How do I most easily track down which unittest in which file that
> > causes the crash?
[...]
Compile your program with debugging symbols, a
On Friday, 12 June 2020 at 18:18:25 UTC, Per Nordlöw wrote:
How do I most easily track down which unittest in which file
that causes the crash?
You could try to reduce your code using Dustmite through dub.
This should do the job IIRC:
dub dustmite --compiler=dmd --build=unittest
--compile
On Friday, 12 June 2020 at 18:18:25 UTC, Per Nordlöw wrote:
When I build my project as
dub run --compiler=dmd --build=unittest
it crashes as
Performing "unittest" build using dmd for x86_64.
phobos-next ~master: building configuration "library"...
Segmentation fault (core dumped)
dmd faile
On Friday, 12 June 2020 at 15:21:12 UTC, Guillaume Piolat wrote:
Any idea what could be causing this?
Mentioning at least the used LDC version would be helpful;
especially since the MSVC detection was completely overhauled
with the v1.22 betas (and I think the previous
non-existing-LDC_VSDIR
On Friday, 12 June 2020 at 17:50:43 UTC, Arafel wrote:
All in all, I still think something like
`__traits(isRef,return)` would still be worth adding! After all
the compiler already has all the information, so it's just
about exposing it. I'm trying to think of a library solution,
but I find i
When I build my project as
dub run --compiler=dmd --build=unittest
it crashes as
Performing "unittest" build using dmd for x86_64.
phobos-next ~master: building configuration "library"...
Segmentation fault (core dumped)
dmd failed with exit code 139.
whereas
dub run --compiler=dmd --
On Friday, 12 June 2020 at 16:16:18 UTC, mw wrote:
--arch=x86_64 ?
check where this config is set? you said it’s for 32 bit
Indeed it's the other way around, it's with -a x86_64
On Friday, 12 June 2020 at 15:21:12 UTC, Guillaume Piolat wrote:
Any idea what could be causing this?
Please help. This was a living nightmare. I just want a working
setup...
I don't know if this is any help, as I don't use Visual Studio
myself, but:
You're trying to build for a 32-bit arc
On 12/6/20 18:15, Paul Backus wrote:
I think I have something that works:
ref int foo();
int bar();
enum isLvalue(string expr) = q{
__traits(compiles, (auto ref x) {
static assert(__traits(isRef, x));
}(} ~ expr ~ q{))
};
pragma(msg, mixin(isLvalue!"foo()")); // true
pragma
On Friday, 12 June 2020 at 16:16:18 UTC, mw wrote:
On Friday, 12 June 2020 at 15:21:12 UTC, Guillaume Piolat wrote:
- With LDC + 32-bit it still fail with:
libcmt.lib(chkstk.obj) : fatal error LNK1112: module machine
type 'X86' conflicts with target machine type 'x64'
Error: C:\Program Fi
On Friday, 12 June 2020 at 14:56:41 UTC, Arafel wrote:
Hi all,
I'm hitting a problem that it's making crazy... is there any
way to find out if the return of an `auto ref` function is
actually ref or not?
So, according to the documentation [1] it depends on the return
expressions... however
On Friday, 12 June 2020 at 15:21:12 UTC, Guillaume Piolat wrote:
- With LDC + 32-bit it still fail with:
libcmt.lib(chkstk.obj) : fatal error LNK1112: module machine
type 'X86' conflicts with target machine type 'x64'
Error: C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\BIN\link.
Originally I installed VisualD and LDC and DMD with the VisualD
installer on top of VS2019 and life was good.
Then because VS2019 is very slow, I uninstalled VS2019 and
installed VS2015 instead.
This broke both DMD+64-bit and LDC despite having LDC_VSDIR set
at "invalid-path". Isn't it suppose
Hi all,
I'm hitting a problem that it's making crazy... is there any way to find
out if the return of an `auto ref` function is actually ref or not?
So, according to the documentation [1] it depends on the return
expressions... however in my case I'm implementing `opDispatch` in a
wrapper ty
I was just looking through the DIPs in the system, and noticed that
DIP1000 is "superseded".
I thought that was odd, since it's in the compiler as a switch and is a
major driver of discussion and hope for memory safety.
In the DIP it says [1]:
"This DIP did not complete the review process. I
On Friday, 12 June 2020 at 12:02:19 UTC, duck_tape wrote:
For speedups with getting my hands dirty:
- Does writef and company flush on every line? I still haven't
found the source of this.
- It looks like I could use {f}printf if I really wanted to:
https://forum.dlang.org/post/hzcjbanvkxgohkbv
On Friday, 12 June 2020 at 07:25:09 UTC, Jon Degenhardt wrote:
tsv-utils has the advantage of only needing to support utf-8
files with Unix newlines, so the code is simpler. (Windows
newlines are detected, this occurs separately from
bufferedByLine.) But as you describe, support for a wider
va
On Friday, 12 June 2020 at 06:20:59 UTC, H. S. Teoh wrote:
I glanced over the implementation of byLine. It appears to be
the unhappy compromise of trying to be 100% correct, cover all
possible UTF encodings, and all possible types of input streams
(on-disk file vs. interactive console). It do
24 matches
Mail list logo
