On Wednesday, 18 September 2019 at 01:03:27 UTC, Nicholas Wilson
wrote:
I think a mixin that does
string LOG_SCOPE = q{
callDepth++;
scope(exit) callDepth--;
}
is probably the easiest. for bonus points
string LOG_SCOPE = q{
callDepth++;
debug_log(__FUNCTION__);// or __PRETTY_FUNTION__
scope(e
I think it's better to give a concrete example rather than
explaining this vaguely.
- For those who are familiar with LDC internals:
I want to create something like LOG_SCOPE. You can skip the
explanation.
- For those who are not:
Imagine that you want to track down how deep in the call stack
On Wednesday, 11 September 2019 at 02:09:42 UTC, Stefanos
Baziotis wrote:
I have branched to an old PR (4 months ago) and the problem
doesn't exist.
For clarification, the problem doesn't exist _in that_ branch. On
my current
new branch, I still haven't been able to solve it.
On Tuesday, 10 September 2019 at 15:01:11 UTC, Stefanos Baziotis
wrote:
On Tuesday, 10 September 2019 at 14:47:00 UTC, Nicholas Wilson
wrote:
Is this you have built your own DMD
Yes
I have branched to an old PR (4 months ago) and the problem
doesn't exist.
On Tuesday, 10 September 2019 at 14:47:00 UTC, Nicholas Wilson
wrote:
Is this you have built your own DMD
Yes
and using it to compile a test program and you get that error,
or you get that error trying to build DMD?
Both. I get that error trying to compile _any_ program.
I don't if this the right group to post this.
DMD built from source fails to link / find `main`. The error is:
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o: In function
`_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
Error: li
Thank you all for your responses. I understand that the compiler
can't ensure @safe and @trusted is needed.. I'm not familiar
though with all aspects of D and thought I might have missed
something.
On Friday, 12 July 2019 at 01:24:06 UTC, Jonathan M Davis wrote:
BTW, if you're implementing mem
On Thursday, 11 July 2019 at 19:37:38 UTC, Nathan S. wrote:
If you know that what you're doing cannot result in memory
corruption but the compiler cannot automatically infer @safe,
it is appropriate to use @trusted. (For this case make sure
you're not returning the byte slices, since if the a
On Thursday, 11 July 2019 at 18:46:57 UTC, Paul Backus wrote:
What's the actual problem you're trying to solve? There may be
a different way to do it that's @safe.
I hope I answered the "what". In case the "why" helps too, it is
because
I'm implementing memcmp().
On Thursday, 11 July 2019 at 18:46:57 UTC, Paul Backus wrote:
Casting from one type of pointer to another and slicing a
pointer are both @system, by design.
Yes, I'm aware, there are no pointers in the code. The pointer
was used
here because it was the only way to solve the problem (but not
I searched the forum but did not find something.
I want to do this:
int foo(T)(ref T s1, ref T s2)
{
const byte[] s1b = (cast(const(byte)*)&s1)[0 .. T.sizeof];
const byte[] s2b = (cast(const(byte)*)&s2)[0 .. T.sizeof];
}
Which is to create a byte array from the bytes of the value
given
On Tuesday, 18 June 2019 at 17:10:50 UTC, Adam D. Ruppe wrote:
On Tuesday, 18 June 2019 at 17:09:48 UTC, Adam D. Ruppe wrote:
pop EAX;
errr you can see my 32 bit bias here (forgive me, I'm old), but
you know what i mean :)
Thank you, quite clever.
There is also the "$" symbol that is relate
I can't do for example:
lea RAX, [RIP+something];
Generally, RIP does not seem to be available.
On Sunday, 28 April 2019 at 18:48:55 UTC, Adam D. Ruppe wrote:
Sounds like you have a stack corruption bug somewhere else...
memory being overwritten by something else.
Can you post any more of the context code?
I fixed it, there was a bug, but not related to stack. Not
related to memory a
Hello everyone,
I have a function:
void foo(T *t) { ... }
void bar(...) {
T *t = ...;
foo(t);
}
In the debugger, before calling 'foo', 't' had a value (an
address) let's say 10. Stepping
into 'foo', the 't' that 'foo' got, which is supposed to have the
same value that the 't' in 'bar'
On Wednesday, 17 April 2019 at 23:44:42 UTC, Adam D. Ruppe wrote:
In C++, if you define a struct/class, and constructors apply
for this.
struct Test {
Test(const char* foo) {}
};
void cool(Test t) {}
cool("string"); // works
That works in C++, unless you mark that constructor with
`ex
On Wednesday, 17 April 2019 at 16:33:17 UTC, Adam D. Ruppe wrote:
[...]
Thanks for the info!
I argue C++'s mistake was *out-out* implicit construction
What do you mean by out-out?
- Stefanos
On Wednesday, 17 April 2019 at 12:48:52 UTC, Adam D. Ruppe wrote:
This is the "implicit construction" I sometimes talk about
and D doesn't support it, by design (alas).
Sorry if this has been asked again, I didn't find anything.
Do we know the reason why it is not supported?
There's t
I have a custom Buf struct (working as a simple vector)
struct Buf(T) {
size_t cap, len;
T *data;
@nogc
this(T[] arr) {
reserve(arr.length);
foreach(item; arr) {
push(item);
}
}
...
};
And I have a function like this:
void test(Buf!(i
19 matches
Mail list logo