On Monday, October 07, 2013 07:26:02 Nicholas Smith wrote:
> Thanks Jonathon, these are the kinds of warnings I was looking
> for.
>
> > There are _no_ guarantees of atomicity with shared. Yes, on some
> > architectures, writing a word size might be atomic, but the
> > language
> > guarantees no s
On Sunday, 6 October 2013 at 16:45:59 UTC, Benjamin Thaut wrote:
Am 06.10.2013 07:25, schrieb evilrat:
oh, on the second thought after some tests, i encountered
major ABI(or
should i say MS 'optimization'?) mismatch which requires
almost any
function to be wrapped within C++ code to work, i dou
Thanks Jonathon, these are the kinds of warnings I was looking
for.
There are _no_ guarantees of atomicity with shared. Yes, on some
architectures, writing a word size might be atomic, but the
language
guarantees no such thing.
I was looking narrowly at x86, which I *think* such a statement
Typically you link to one of the distributed Windows DLLs via
an import library, e.g. you would pass "kernel32.lib" at the
command-line when calling DMD for any functions in the kernel32
DLL. kernel32.lib is the import lib, and it's distributed along
with DMD.
I have never had to specify any
On Thursday, October 03, 2013 08:34:00 Nicholas Smith wrote:
> * Reads and writes to shared variables with a size equal to or
> less than the word size of the machine are atomic and are visible
> to all other threads immediately.
There are _no_ guarantees of atomicity with shared. Yes, on some
ar
Hey, I've been trying for a while to compile 64 bit programs on a
Windows 7 platform. The setup is the following:
Version: 2.063.2
OS: Windows 7 64
Linked: VS 11 64 bit linker
sc.ini:
[Version]
version=7.51 Build 020
[Environment]
LIB="%@P%\..\lib";\dm\lib
DFLAGS="-I%@P%\..\..\src\phobos"
"-
So I suppose shared is confusing to everyone else, too. :)
I'll just wing it and fill my program with rare but devastating
bugs ;)
On Thu, 03 Oct 2013 11:59:05 +0200
"Rene Zwanenburg" wrote:
>
> struct A { int i = 5; }
> void main() { writeln(A.init.i); }
>
> prints 5.
>
Ahh, ok, I think that's what confused me.
I need to share an associative array between two threads, and to
that extent I'd like to make the whole thing synchronized. And
I'd like to use the built-in synchronized{} blocks, and I'd also
like to use the ReadWriteMutex from core.sync.rwmutex, since it
seems pretty much tailor-made for this
On Sunday, 6 October 2013 at 19:44:16 UTC, Matt wrote:
I have noticed that a number of the current Windows C functions
are not in core.sys.windows.windows.d
I tried adding them to the module (after setting up source
control so I can roll back any errors I might make), and found
that Optlink w
I have noticed that a number of the current Windows C functions
are not in core.sys.windows.windows.d
I tried adding them to the module (after setting up source
control so I can roll back any errors I might make), and found
that Optlink wasn't finding the functions to resolve the symbols
to.
Am 06.10.2013 07:25, schrieb evilrat:
oh, on the second thought after some tests, i encountered major ABI(or
should i say MS 'optimization'?) mismatch which requires almost any
function to be wrapped within C++ code to work, i doubt it would ever
costs such efforts for me.
so i'm tired off both
On 10/6/13, Namespace wrote:
> And I should write a blog post about your and my solution. :)
Let me try to hack on __PRETTY_FUNCTION__ first and I'll post a
working example here soon.
This is also nice.
My final construct now looks like this:
Friend:
module Core.Friend;
struct Friend {
public:
immutable string FriendClass;
immutable string FriendMethod;
this(string friendClass, string friendMethod = null) {
this.FriendClass = frie
14 matches
Mail list logo
