Is it possible to make a function return dependent upon the constancy of
the this reference?
i.e. this:
struct foo {
int n;
inout( ref int ) getn( ) inout {
return n;
}
}
--
Simen
Stanislav Blinov wrote:
Bob Cowdery wrote:
On 29/08/2010 20:17, Stanislav Blinov wrote:
Stanislav Blinov wrote:
I'm not sure about Variant part yet (never tried it myself)
Hmm, after some inspection I can say this is an implementation issue.
You'll find that there are cases when what's tol
Bob Cowdery wrote:
On 29/08/2010 20:17, Stanislav Blinov wrote:
Stanislav Blinov wrote:
I'm not sure about Variant part yet (never tried it myself)
Hmm, after some inspection I can say this is an implementation issue.
You'll find that there are cases when what's told in TDPL doesn't work
(s
Bob Cowdery wrote:
On 29/08/2010 19:17, Stanislav Blinov wrote:
Bob Cowdery wrote:
Hi
I'm trying out some very simple concurrency tests to make sure I
understand how it operates. However I'm having a few problems. I'm sure
this is just lack of knowledge. I dont know enough to debug these thi
I have a program which does a bit of scanning through files, and right now
I'm running into issues where std.File.isfile() is reporting sockets as
files, which is problematic, because sockets cause segfaults when I try to
read them.
This is the output of ls -lha on the directory with the socket:
On 29/08/2010 20:17, Stanislav Blinov wrote:
> Stanislav Blinov wrote:
>
>>
>> I'm not sure about Variant part yet (never tried it myself)
>
> Hmm, after some inspection I can say this is an implementation issue.
>
> You'll find that there are cases when what's told in TDPL doesn't work
> (see rec
On 29/08/2010 19:17, Stanislav Blinov wrote:
> Bob Cowdery wrote:
>> Hi
>>
>> I'm trying out some very simple concurrency tests to make sure I
>> understand how it operates. However I'm having a few problems. I'm sure
>> this is just lack of knowledge. I dont know enough to debug these things
>>
Stanislav Blinov wrote:
I'm not sure about Variant part yet (never tried it myself)
Hmm, after some inspection I can say this is an implementation issue.
You'll find that there are cases when what's told in TDPL doesn't work
(see recent msg[0] or msg.field[0]? in this group, for example). I
Bob Cowdery wrote:
Hi
I'm trying out some very simple concurrency tests to make sure I
understand how it operates. However I'm having a few problems. I'm sure
this is just lack of knowledge. I dont know enough to debug these things
on my own yet.
Bob
The test below builds but does not output
SK:
> What is the explanation?
The syntax shown in TDPL can't be supported yet, because the DMD compiler
doesn't yet allow it. It will be added. In the meantime you have to use the
.field[] syntax, or the "secret" ._0 ._1 ecc syntax. But keep in mind that this
second syntax will be removed once
Hi
I'm trying out some very simple concurrency tests to make sure I
understand how it operates. However I'm having a few problems. I'm sure
this is just lack of knowledge. I dont know enough to debug these things
on my own yet.
Bob
The test below builds but does not output anything so I assume
>From the concurrency chapter, TDPL states that tuple fields are accessed
with the [] operator, as in:
***void* writer() {
*for* (;;) {
*auto* msg = receiveOnly!(Tid, *int*)();
writeln("Secondary thread: ", msg[1]);
msg[0].send(thisTid);
}
}
However, for me this code ret
12 matches
Mail list logo
