On Friday, August 12, 2016 05:25:45 Mike Parker via Digitalmars-d-learn wrote:
> immutable class Foo { ... } is the same as declaring every member
> of Foo as immutable, just as final class Foo { ... } makes every
> method final.
I'm not sure that that's quite the same thing, because there is such
On Thursday, August 11, 2016 21:49:46 Charles Hixson via Digitalmars-d-learn
wrote:
> It works, it's just not the syntax that I'd prefer. And it leaves me
> wondering exactly what
> immutable class Msg {...}
> was declaring.
All it does is make the members of the class immutable. It doesn't affe
On Friday, 12 August 2016 at 08:35:54 UTC, Jonathan M Davis wrote:
On Friday, August 12, 2016 05:25:45 Mike Parker via
Digitalmars-d-learn wrote:
immutable class Foo { ... } is the same as declaring every
member of Foo as immutable, just as final class Foo { ... }
makes every method final.
I'
I'm planning on 'importing' a thread into the D runtime using
thread_attachThis(), and was just wondering about the potential
pitfalls of this process. For example:
- Would having an entry function other than
core.thread.thread_entryPoint() pose problems? What about during
stack unwinding? Sh
Hi,
This has probably been asked many times before, but after search
for hours and hours I can't find an answer. I have seen in C an
extern function taking in a struct as one of its parameters, like
so:
extern unsigned long free_page_tables(struct task_struct * tsk);
I was wondering how th
On Friday, 12 August 2016 at 15:21:22 UTC, D.Rex wrote:
extern unsigned long free_page_tables(struct task_struct * tsk);
extern(C) ulong free_page_tables(task_struct* tsk);
void main() {
task_struct tsk = …… ;
free_page_tables(&tsk);
};
That should be what you're after?
On Friday, 12 August 2016 at 02:09:21 UTC, Engine Machine wrote:
On Thursday, 11 August 2016 at 21:25:20 UTC, sldkf wrote:
On Thursday, 11 August 2016 at 20:27:01 UTC, Engine Machine
issue solved using a "template this parameter":
°°
template Cow()
{
void sound
On 08/12/2016 05:23 PM, Cauterite wrote:
void main() {
[...]
};
No semicolon there, please.
On Friday, 12 August 2016 at 16:50:43 UTC, ag0aep6g wrote:
On 08/12/2016 05:23 PM, Cauterite wrote:
No semicolon there, please.
Why would I not terminate a declaration with a semi-colon?
Why should a declaration not end in a semi-colon just because the
last token is a brace?
Why should I not t
On Friday, 12 August 2016 at 17:33:34 UTC, Cauterite wrote:
On Friday, 12 August 2016 at 16:50:43 UTC, ag0aep6g wrote:
On 08/12/2016 05:23 PM, Cauterite wrote:
No semicolon there, please.
Why would I not terminate a declaration with a semi-colon?
Why should a declaration not end in a semi-colo
On 08/12/2016 07:33 PM, Cauterite wrote:
Why would I not terminate a declaration with a semi-colon?
Why should a declaration not end in a semi-colon just because the last
token is a brace?
Why should I not tell the lexer precisely where my declaration ends
instead of relying on whatever other tok
Thanks colon-nazis, I'll take that into consideration ¬_¬
On Friday, 12 August 2016 at 10:45:22 UTC, Cauterite wrote:
- Would having an entry function other than
core.thread.thread_entryPoint() pose problems?
No.
What about during stack unwinding?
It doesn't need runtime or attachment.
Should I try to replicate the exception handling code of
On Friday, 12 August 2016 at 18:59:35 UTC, Guillaume Piolat wrote:
- Callback case:
You may have problems if one of the registered thread is
destroyed outside of your program and then the GC tries to stop
it though. For this reason if you are in the callback case you
can try to detach it on ex
On Friday, 12 August 2016 at 18:59:35 UTC, Guillaume Piolat wrote:
On Friday, 12 August 2016 at 10:45:22 UTC, Cauterite wrote:
Thanks, this is very helpful. I already feel much more confident
about the idea.
My use is definitely the 'whole-lifetime' case, so I might be
able to get away wi
On Friday, 12 August 2016 at 15:35:50 UTC, sldkf wrote:
On Friday, 12 August 2016 at 02:09:21 UTC, Engine Machine wrote:
On Thursday, 11 August 2016 at 21:25:20 UTC, sldkf wrote:
On Thursday, 11 August 2016 at 20:27:01 UTC, Engine Machine
issue solved using a "template this parameter":
°
On Thursday, 11 August 2016 at 20:43:13 UTC, Meta wrote:
On Thursday, 11 August 2016 at 18:11:30 UTC, Engine Machine
wrote:
[...]
It can be done, but you have to be explicit and should think
very carefully if this is really a good design.
struct X(int defaultSize = 100)
{
int size;
On Friday, 12 August 2016 at 23:14:23 UTC, Engine Machine wrote:
On Friday, 12 August 2016 at 15:35:50 UTC, sldkf wrote:
On Friday, 12 August 2016 at 02:09:21 UTC, Engine Machine
wrote:
On Thursday, 11 August 2016 at 21:25:20 UTC, sldkf wrote:
On Thursday, 11 August 2016 at 20:27:01 UTC, Engin
On Friday, 12 August 2016 at 23:48:54 UTC, sldkf wrote:
On Friday, 12 August 2016 at 23:14:23 UTC, Engine Machine wrote:
On Friday, 12 August 2016 at 15:35:50 UTC, sldkf wrote:
On Friday, 12 August 2016 at 02:09:21 UTC, Engine Machine
wrote:
On Thursday, 11 August 2016 at 21:25:20 UTC, sldkf w
Thank you both.
On 08/12/2016 01:35 AM, Jonathan M Davis via Digitalmars-d-learn wrote:
On Friday, August 12, 2016 05:25:45 Mike Parker via Digitalmars-d-learn wrote:
immutable class Foo { ... } is the same as declaring every member
of Foo as immutable, just as final class Foo { ... } makes ev
I was trying to use std.regex, and it takes an output stream to
pump the result to, which is great, but I wanted to perform TWO
replacements, one with the output of the previous, with data that
might be a tricky size to cache redundantly.
So, ideally when you do something like regexp replacing
Here's how to do it using context switches. There ought to be a
way to manually pass specific state around to keep that from
happening, but probably not since there's no interface to pause
something writing to an OutputRange.
auto pipe(T, alias oh)()
{
import std.concurrency: Generator
On Friday, 12 August 2016 at 15:21:22 UTC, D.Rex wrote:
I was wondering how this is achieved in D, or if D has an
alternative implementation of this.
It isn't, because C interfaces that require you to pass in
structures are inherently bad design, and usually both unstable
and extremely C spec
23 matches
Mail list logo
