A hack is to create the gc code you in a function want to call,
say does the "gc" opEquals. Then cast that function to a nogc
version by first casting to a void*. This way you can call gc
code from nogc code, by bypassing the compiler's ability to
check. It will obviously break your code if you
winmain.d(40): Error: found 'while' when expecting ';' following
statement
winmain.d(40): Error: unexpected ( in declarator
winmain.d(40): Error: basic type expected, not &
winmain.d(40): Error: found '&' when expecting ')'
winmain.d(40): Error: found 'msg' when expecting ')'
winmain.d(40): Error
It's nice to be able to pass delegates and functions as callbacks.
A nice feature is something like
R foo(R,Args...)(R function(Args) callback, Args args) { return
callback(args); }
There are two problems with this.
One is that type deduction doesn't work. I have to explicitly
specify the t
On Wednesday, 3 August 2016 at 08:12:00 UTC, Ali Çehreli wrote:
On 08/02/2016 07:55 PM, Mark J Twain wrote:
[...]
I didn't know one could use 'auto ref' in this case but the
following simple test works:
auto foo(Func, Args...)(Func callback, auto ref Args args) {
return callback(args);
How can I construct a va_list for vsprintf when all I have is the
a list of pointers to the data, without their type info?
A va_list seems to be a packed struct of values and/or pointers
to the data. While I could construct such a list, theoretically,
I don't always know when I should store an
On Thursday, 4 August 2016 at 21:03:52 UTC, Mark "J" Twain wrote:
How can I construct a va_list for vsprintf when all I have is
the a list of pointers to the data, without their type info?
A va_list seems to be a packed struct of values and/or pointers
to the data. While I could construct such
On Friday, 5 August 2016 at 08:32:42 UTC, kink wrote:
On Thursday, 4 August 2016 at 21:03:52 UTC, Mark "J" Twain [...]
This has absolutely nothing to do with D as these are C
functions, so you'd be better off asking this in another forum.
Um, then I wonder why I am using D? Why does D even ha
I use malloc to allocate some memory, then free it later. For
monitoring purposes, I would like to know how much is free'ed by
free by just knowing the object. Or, rather, given a ptr
allocated by malloc, bet the block size it allocated from the ptr
alone.
Some C compilers have special intrin
On Friday, 5 August 2016 at 20:43:12 UTC, H.Loom wrote:
On Friday, 5 August 2016 at 19:55:22 UTC, Mark "J" Twain wrote:
[...]
You can wrap the C memory allocations functions with a version
identifier, e.g
version(stat)
{
__gshared size_t[size_t] sizes;
}
version(stat)
{
auto mallo
Any solution out there that can get call stack, file and line
info? Similar to exceptions but I simply want to track memory
allocations and need the complete call stack rather than just the
previous call(using __FUNCTION__/__FILE__/etc), which is usually
useless.
Of course, exceptions have Tr
On Saturday, 6 August 2016 at 01:44:04 UTC, Adam D. Ruppe wrote:
On Saturday, 6 August 2016 at 01:29:37 UTC, Mark "J" Twain
wrote:
Of course, exceptions have TraceInfo... could that be used
anywhere or hacked to get what I need?
The function is defaultTraceHandler in druntime for what the
exc
11 matches
Mail list logo
