mixin template Common() {
private int m_member;
this( int m ) { m_member = m; }
}
struct Foo {
mixin Common;
}
struct Bar {
mixin Common;
this( int m, float n ) { m_member = m * n; }
}
auto foo = Foo(1); // ok
auto b_1 = Bar( 1, 2 ); // ok
auto b_2 = Bar( 3 ); // Error: co
On Monday, February 26, 2018 12:30:24 ParticlePeter via Digitalmars-d-learn
wrote:
> mixin template Common() {
>private int m_member;
>this( int m ) { m_member = m; }
> }
>
> struct Foo {
>mixin Common;
> }
>
> struct Bar {
>mixin Common;
>this( int m, float n ) { m_member = m
On Monday, 26 February 2018 at 12:47:48 UTC, Jonathan M Davis
wrote:
On Monday, February 26, 2018 12:30:24 ParticlePeter via
Digitalmars-d-learn wrote:
mixin template Common() {
private int m_member;
this( int m ) { m_member = m; }
}
struct Foo {
mixin Common;
}
struct Bar {
mixin
On Monday, 26 February 2018 at 13:09:40 UTC, ParticlePeter wrote:
Thanks for clarification, unfortunately your suggestion doesn't
work.
Since when is alias this = something; supposed to work?
alias Common.this this; doesn't work as well and following also
not:
struct Baz {
Foo foo;
alias
On Monday, 26 February 2018 at 12:30:24 UTC, ParticlePeter wrote:
Is this expected behavior?
yes sort of, but there are bugs associated with it too...
I wrote about this in the "Tip of the Week" section here before
http://arsdnet.net/this-week-in-d/2016-feb-07.html
there's a workaround ther
On Monday, 26 February 2018 at 14:02:56 UTC, Adam D. Ruppe wrote:
On Monday, 26 February 2018 at 12:30:24 UTC, ParticlePeter
wrote:
Is this expected behavior?
yes sort of, but there are bugs associated with it too...
I wrote about this in the "Tip of the Week" section here before
http://arsd
On Monday, 26 February 2018 at 14:38:22 UTC, ParticlePeter wrote:
This cool, I didn't know that we can name mixins when
instantiating but also never taught that there could be any
purpose for naming. Works, thanks.
oh yes, there's a lot of cool things with mixin. You might want
to skim my tip
On Monday, 26 February 2018 at 14:42:58 UTC, Adam D. Ruppe wrote:
On Monday, 26 February 2018 at 14:38:22 UTC, ParticlePeter
wrote:
This cool, I didn't know that we can name mixins when
instantiating but also never taught that there could be any
purpose for naming. Works, thanks.
oh yes, ther
On Monday, 26 February 2018 at 05:15:48 UTC, jmh530 wrote:
On Sunday, 25 February 2018 at 14:25:04 UTC, Arredondo wrote:
On Friday, 23 February 2018 at 16:56:13 UTC, jmh530 wrote:
I had given up and used WSL at this point rather than compile
it myself with CMAKE. Less of a headache.
I don’t u
On Monday, 26 February 2018 at 17:12:51 UTC, Arredondo wrote:
Okay, so I just finished configuring WSL. The way I want to use
my app is having it read from stdin, do some calculations, and
write to stdout, in an infinite cycle. I wanted to feed this to
some higher level algorithms in Wolfram
I've tried both gdb and windbg debugger both it either get a
"received signal ?" from gdb or crash the GUI application
(windbg).
The error is:
core.exception.OutOfMemoryError@src\core\exception.d(696):
Memory allocation failed
How do I find out the source of the error?
On Wed, Feb 21, 2018 at 11:16:44PM -0500, Nick Sabalausky (Abscissa) via
Digitalmars-d-learn wrote:
> Are there any tutorials or articles out there for "getting started
> with converting a C++ codebase to D one module at a time?" Or at the
> very least: tips, tricks, lessions learned, from those w
On Monday, 26 February 2018 at 17:40:05 UTC, jmh530 wrote:
On Monday, 26 February 2018 at 17:12:51 UTC, Arredondo wrote:
Okay, so I just finished configuring WSL. The way I want to
use my app is having it read from stdin, do some calculations,
and write to stdout, in an infinite cycle. I want
On Monday, 26 February 2018 at 19:02:36 UTC, Arredondo wrote:
This worked. Thank you jmh530!
I feel like at this moment, lubeck should be clearly marked
"not Windows ready", as not everybody will have the
inclination/patience to deal with incompatible object file
formats or the Windows subsy
On Monday, 26 February 2018 at 18:01:07 UTC, Marc wrote:
I've tried both gdb and windbg debugger both it either get a
"received signal ?" from gdb or crash the GUI application
(windbg).
The error is:
core.exception.OutOfMemoryError@src\core\exception.d(696):
Memory allocation failed
How do
On Monday, 16 January 2017 at 19:44:34 UTC, Russel Winder wrote:
On Mon, 2017-01-16 at 17:47 +, King_DuckZ via
Digitalmars-d-learn wrote:
[…]
> Meson can build D stuff out of the box.
>
Hadn't heard of this before, I'll have a look. Btw I don't see
any mention of D on their home page.
I've been experimenting with D's Better C mode, and I have a
question regarding something that I started thinking about after
watching one of Jonathon Blow's talks on data-oriented
programming - more specifically the aspect of fake "inheritance"
I have the following code. My question is if it'
On Monday, 26 February 2018 at 20:50:35 UTC, Kayomn wrote:
I've been experimenting with D's Better C mode, and I have a
question regarding something that I started thinking about
after watching one of Jonathon Blow's talks on data-oriented
programming - more specifically the aspect of fake "inh
On Monday, 26 February 2018 at 21:04:51 UTC, TheFlyingFiddle
wrote:
On Monday, 26 February 2018 at 20:50:35 UTC, Kayomn wrote:
[...]
Don't think you can alias member variables directly.
You could do this though:
struct Player {
Entity entity;
ref auto pos() inout { return entity.pos
Kayomn wrote:
On Monday, 26 February 2018 at 21:04:51 UTC, TheFlyingFiddle wrote:
On Monday, 26 February 2018 at 20:50:35 UTC, Kayomn wrote:
[...]
Don't think you can alias member variables directly.
You could do this though:
struct Player {
Entity entity;
ref auto pos() inout { r
On Sunday, 25 February 2018 at 21:35:33 UTC, ketmar wrote:
add postblit debug prints, and you will see.
I get that it will call the postblit since it creates a temporary.
What I expected though was that.
auto s = S(0).foo(1);
Would become something like:
S s; s.__ctor(0).foo(1);
But maybe
On Sunday, 25 February 2018 at 14:52:19 UTC, Steven Schveighoffer
wrote:
1 == 1.0, no?
no. at least, not when a language forces you to think in terms of
types.
1 is an int.
1.0 is a floating point.
I admit, I've never printed output without using format
specifiers, but still, if I say wri
On Mon, Feb 26, 2018 at 11:34:06PM +, psychoticRabbit via
Digitalmars-d-learn wrote:
[...]
> and what's going on here btw?
>
> assert( 1 == 1.01 ); // assertion error in DMD but not in
> LDC
> assert( 1 == 1.001 ); // no assertion error??
>
> (compiled in 64
On Monday, February 26, 2018 16:04:59 H. S. Teoh via Digitalmars-d-learn
wrote:
> On Mon, Feb 26, 2018 at 11:34:06PM +, psychoticRabbit via
> Digitalmars-d-learn wrote: [...]
>
> > and what's going on here btw?
> >
> > assert( 1 == 1.01 ); // assertion error in DMD but not
> >
On Tuesday, 27 February 2018 at 00:04:59 UTC, H. S. Teoh wrote:
A 64-bit double can only hold about 14-15 decimal digits of
precision. Anything past that, and there's a chance your
"different" numbers are represented by exactly the same bits
and the computer can't tell the difference.
T
I
On Tue, Feb 27, 2018 at 12:26:56AM +, psychoticRabbit via
Digitalmars-d-learn wrote:
> On Tuesday, 27 February 2018 at 00:04:59 UTC, H. S. Teoh wrote:
> >
> > A 64-bit double can only hold about 14-15 decimal digits of
> > precision. Anything past that, and there's a chance your
> > "differe
On Monday, February 26, 2018 17:49:21 H. S. Teoh via Digitalmars-d-learn
wrote:
> On Tue, Feb 27, 2018 at 12:26:56AM +, psychoticRabbit via Digitalmars-
d-learn wrote:
> > On Tuesday, 27 February 2018 at 00:04:59 UTC, H. S. Teoh wrote:
> > > A 64-bit double can only hold about 14-15 decimal di
On Mon, Feb 26, 2018 at 05:18:00PM -0700, Jonathan M Davis via
Digitalmars-d-learn wrote:
> On Monday, February 26, 2018 16:04:59 H. S. Teoh via Digitalmars-d-learn
> wrote:
[...]
> > (There *are* exact representations for certain subsets of
> > irrationals that allow fast computation that does n
On Monday, February 26, 2018 18:33:13 H. S. Teoh via Digitalmars-d-learn
wrote:
> Well, the way I deal with floating point is, design my code with the
> assumption that things will be inaccurate, and compensate accordingly.
The way that I usually deal with it is to simply not use floating point
n
On Mon, Feb 26, 2018 at 07:50:10PM -0700, Jonathan M Davis via
Digitalmars-d-learn wrote:
[...]
> One case that I found interesting was that in writing
> core.time.convClockFreq so that it didn't require floating point
> values, it not only avoided the inaccuracies caused by using FP, but
> it eve
30 matches
Mail list logo