I am needing pairs of specific nested classes with already-coded
collection management; eg: classComputers having nested
classComputer as following (as seen by client code that is):
- classComputer ← objComputers.add("ID1", "workstation # 1")
- classComputer ← objComputers.add("ID2", "workstati
Hello there,
I got a weird compilation error which was hard to debug (even for
just a little program) and I thought, this is quite related to
this thread. This is my error message:
```
***search.d(42,1): Error: class ***.XXX has forward references
***box.d(21,32): Error: template instance ***
On Thursday, 10 June 2021 at 21:25:35 UTC, JN wrote:
I have to disagree. I don't see a good reason for this behavior
and it's just one more thing to trip people. I think it'd be
better if such thing was done explicit, something like:
```d
Bar b = new Bar();
Foo* f2 = cast(Foo*)b.ptr;
```
Isn
On Saturday, 29 May 2021 at 22:26:48 UTC, ag0aep6g wrote:
You're writing @system code, so dangerous casts are allowed.
It's no surprise that the code compiles. If you want to be
safeguarded against such things, use @safe.
The result is a class object being reinterpreted as a struct
object. Us
Normally computers are deterministic and same input produces same
output. There is however theory on neural network stability and
it can be tuned.
On Thursday, 10 June 2021 at 19:51:51 UTC, Dennis wrote:
On Thursday, 10 June 2021 at 19:37:36 UTC, seany wrote:
However, i sometimes see, that the results are _radically_
different.
Are you using uninitialized memory or multi-threading?
I am using things like :
`double [][] myArr = new dou
On Thursday, 10 June 2021 at 19:37:36 UTC, seany wrote:
However, i sometimes see, that the results are _radically_
different.
Are you using uninitialized memory or multi-threading?
I have (as mentioned before) an AI project in D.
It is doing several million Floating Point operations.
However, i sometimes see, that the results are _radically_
different.
The same input, fed to the same system .
I do not have and random values. There are some *foreach* loops.
By radically
On Thursday, 10 June 2021 at 19:06:42 UTC, Tejas wrote:
But how scalable will this be? We have to get real D code to
enrich our ambiguously-defined-small ecosystem.
It says bindings generator, but it has to convert the code
keeping the semantic as close as possible.
It does direct translat
On Thursday, 10 June 2021 at 16:49:59 UTC, Dukc wrote:
On Thursday, 10 June 2021 at 15:09:02 UTC, Tejas wrote:
Sorry, I'm rather ignorant when it comes to this, but why
can't we use
[pegged](https://github.com/PhilippeSigaud/Pegged) to
transpile C++ code to D? Then we won't need a nogc compati
On Thursday, 10 June 2021 at 16:50:41 UTC, evilrat wrote:
On Thursday, 10 June 2021 at 15:09:02 UTC, Tejas wrote:
Sorry, I'm rather ignorant when it comes to this, but why
can't we use
[pegged](https://github.com/PhilippeSigaud/Pegged) to
transpile C++ code to D? Then we won't need a nogc comp
On Thursday, 10 June 2021 at 15:09:02 UTC, Tejas wrote:
Sorry, I'm rather ignorant when it comes to this, but why can't
we use [pegged](https://github.com/PhilippeSigaud/Pegged) to
transpile C++ code to D?
See
https://stackoverflow.com/questions/14589346/is-c-context-free-or-context-sensitive
On Wednesday, 9 June 2021 at 19:13:10 UTC, JG wrote:
produces:
123
I would expect 0.
What is the rationale for this behaviour or is it a bug?
Processor just takes lower 6 bits for the shift amount and those
hold zero in your case, shifting by 65 will shift by 1.
On Thursday, 10 June 2021 at 15:09:02 UTC, Tejas wrote:
Sorry, I'm rather ignorant when it comes to this, but why can't
we use [pegged](https://github.com/PhilippeSigaud/Pegged) to
transpile C++ code to D? Then we won't need a nogc compatible
std library and so many other things could get easie
On Thursday, 10 June 2021 at 15:57:44 UTC, Imperatorn wrote:
On Thursday, 10 June 2021 at 15:09:02 UTC, Tejas wrote:
Sorry, I'm rather ignorant when it comes to this, but why
can't we use
[pegged](https://github.com/PhilippeSigaud/Pegged) to
transpile C++ code to D? Then we won't need a nogc c
On Thursday, 10 June 2021 at 15:09:02 UTC, Tejas wrote:
Sorry, I'm rather ignorant when it comes to this, but why can't
we use [pegged](https://github.com/PhilippeSigaud/Pegged) to
transpile C++ code to D? Then we won't need a nogc compatible
std library and so many other things could get easie
On Thursday, 10 June 2021 at 15:09:02 UTC, Tejas wrote:
Sorry, I'm rather ignorant when it comes to this, but why can't
we use [pegged](https://github.com/PhilippeSigaud/Pegged) to
transpile C++ code to D? Then we won't need a nogc compatible
std library and so many other things could get easie
On Thursday, 10 June 2021 at 13:19:34 UTC, dokutoku wrote:
The reason seems to be that WCHAR should be mangled with
wcha_t, but it is mangled with chat16_t.
Confirmed: https://issues.dlang.org/show_bug.cgi?id=22014
Wrt. `tagRECT`, this should come in handy (for a druntime fix):
https://dlang.
Sorry, I'm rather ignorant when it comes to this, but why can't
we use [pegged](https://github.com/PhilippeSigaud/Pegged) to
transpile C++ code to D? Then we won't need a nogc compatible std
library and so many other things could get easier, like getting
legacy code to use Dlang. It might not b
On Thursday, 10 June 2021 at 13:19:34 UTC, dokutoku wrote:
I still haven't solved this problem.
Not sure if this is the issue, but you don't need `extern` on
these. You already have the `extern(C++)` thing at the top of the
file.
```d
extern void str_test(LPCSTR str1);
not
It's been a while since then, but the problem with the structure
has been solved.
The reason seems to be that the structure name defined in
core.sys.windows.windef was not tagRECT.
I was able to get it to compile by adding a custom definition as
follows
```d
extern (C)
struct tagRECT
{
21 matches
Mail list logo
