Is this a bugs ?
==
struct A {
ref auto opCall(string tmp) scope return {
return this;
}
}
struct B {
A _a;
@property ref auto a() scope return {
return _a;
}
}
extern(C) int main(){
A a;
a("a")
On Monday, 9 March 2020 at 09:44:40 UTC, Simen Kjærås wrote:
As written on
https://dlang.org/spec/function.html#property-functions:
WARNING: The definition and usefulness of property functions
is being reviewed, and the implementation is currently
incomplete. Using property functions is not r
On Monday, 9 March 2020 at 12:14:06 UTC, Adam D. Ruppe wrote:
Here's a wiki page referencing one of the 2013 discussions
https://wiki.dlang.org/Property_Discussion_Wrap-up
though i'll note the thing is older than that.
What especially drove me nuts is people would so often say
"property *synt
The current compiler "-i=module_name" option will include
imported modules as source code.
When the module define from di file extension, I think compiler
should avoid treat it as source file.
What do you think?
On Monday, 9 March 2020 at 13:55:08 UTC, Calvin P wrote:
The current compiler "-i=module_name" option will include
imported modules as source code.
When the module define from di file extension, I think compiler
should avoid treat it as source file.
What do you think?
The use case:
If I
On Monday, 9 March 2020 at 19:10:54 UTC, Timon Gehr wrote:
https://wiki.dlang.org/DIP24
Hi , Timon Gehr
Thanks for the reply, very good DIPS.
I think this is very basic work, why the core team not take care
it for such a long time.
I use this code to get member function address on runtime:
=
struct A {
this(){};
}
auto ctor = (&__traits(getMember, A.init,"__ctor")).funcptr;
=
my question is, how to get it in compile time like static
function address:
=
struct A {
void d(){};
sta
I use this code to get member function address on runtime:
=
struct A {
this(){};
}
auto ctor = (&__traits(getMember, A.init,"__ctor")).funcptr;
=
my question is, how to get it in compile time like static
function address:
=
struct A {
void d(){};
sta
On Thursday, 19 March 2020 at 06:34:40 UTC, Alex wrote:
A non-static member method can use the context of the struct
where it is defined in. E.g. it could alter a member variable.
This context has to be constructed at run time (and there could
be many instances of the context) and does not exist
On Monday, 16 March 2020 at 18:43:47 UTC, Steven Schveighoffer
wrote:
enum A0 = &A.d;
Note that you can't call it at all, but you can get the
function pointer, and put it into a delegate later by assigning
.funcptr.
void main()
{
A a;
void delegate() dg;
dg.ptr = &a;
dg.func
On Thursday, 19 March 2020 at 13:23:41 UTC, Adam D. Ruppe wrote:
Check the error message there... you already have a function
pointer, no need to use the .funcptr metod.
It is a bit weird though because it actually EXCLUDES the
hidden argument for `this`. I prefer doing wrapper functions
us
On Thursday, 19 March 2020 at 23:46:01 UTC, Boris Carvajal wrote:
https://issues.dlang.org/show_bug.cgi?id=20687
https://github.com/dlang/dmd/pull/10946
Thanks very much for such a quick fix.
I try find a memory issue with ldc -betterC -g -fsanitize=address
-disable-fp-elim, get invalid path to external symbolizer!
Is there a way to print the symbol and line ?
=
==113433==ERROR: AddressSanitizer: heap-buffer-overflow
I made a cross build with LDC -g -gdwarf-4 -O0 -D_DEBUG, the app
crash with a report include PC address 0x005e34a9.
Is there a way to find the source location for that PC address?
==4172==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x035dfcf0 at pc 0x005e34a9 bp 0x035dfa20 sp 0x0
On Saturday, 12 December 2020 at 15:51:46 UTC, Calvin P wrote:
I made a cross build with LDC -g -gdwarf-4 -O0 -D_DEBUG, the
app crash with a report include PC address 0x005e34a9.
[...]
Find the solution:
lldb-11 tests_curl
(lldb) target create "tests_curl"
Current executable set to 'tests_cu
15 matches
Mail list logo
