| Thread overview | |||||
|---|---|---|---|---|---|
|
October 17, 2014 core.thread.memcpy conflicts with core.stdc.string.memcpy | ||||
|---|---|---|---|---|
| ||||
When I read that error I wondered why anyone would define a function for threads with the same name as a well established C function. On a closer look it revealed to be just another name for the same extern(C) memcpy to avoid the import of core.stdc.string in core.thread:
private
{
import core.sync.mutex;
import core.atomic;
//
// from core.memory
//
extern (C) void gc_enable();
extern (C) void gc_disable();
extern (C) void* gc_malloc(size_t sz, uint ba = 0);
//
// from core.stdc.string
//
extern (C) void* memcpy(void*, const void*, size_t);
//
// exposed by compiler runtime
//
extern (C) void rt_moduleTlsCtor();
extern (C) void rt_moduleTlsDtor();
alias void delegate() gc_atom;
extern (C) void function(scope gc_atom) gc_atomic;
}
Well, it is mildly annoying. `private` doesn't really help in the way the author expected it to work here.
--
Marco
| ||||
October 17, 2014 Re: core.thread.memcpy conflicts with core.stdc.string.memcpy | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Marco Leise | Its a holdover from when we were trying to eliminate imports in druntime because of the associated overhead. I'd submit a bugzilla about it. | |||
October 18, 2014 Re: core.thread.memcpy conflicts with core.stdc.string.memcpy | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | Am Fri, 17 Oct 2014 15:54:27 +0000 schrieb "Sean Kelly" <sean@invisibleduck.org>: > Its a holdover from when we were trying to eliminate imports in druntime because of the associated overhead. I'd submit a bugzilla about it. Alright, I guessed so. https://issues.dlang.org/show_bug.cgi?id=13627 -- Marco | |||
Copyright © 1999-2021 by the D Language Foundation
Permalink
Reply