No, try this:
import std.stdio;
class X {}
void foo(X x) { writeln(cast(void*) x); }
void main() {
X x; // null reference by default.
writeln(cast(void*) x);
foo(x);
x = new X;
writeln(cast(void*) x);
foo(x);
}
Thanks Tobias that indeed
On Sunday, 12 January 2014 at 10:48:15 UTC, Abdulhaq wrote:
No, try this:
import std.stdio;
class X {}
void foo(X x) { writeln(cast(void*) x); }
void main() {
X x; // null reference by default.
writeln(cast(void*) x);
foo(x);
x = new X;
writeln(cast
On Sunday, 12 January 2014 at 12:12:53 UTC, Tobias Pankrath wrote:
On Sunday, 12 January 2014 at 10:48:15 UTC, Abdulhaq wrote:
No, try this:
import std.stdio;
class X {}
void foo(X x) { writeln(cast(void*) x); }
void main() {
X x; // null reference by default.
writeln(cast(void
On Sunday, 12 January 2014 at 16:17:23 UTC, MGW wrote:
Maybe this will be useful in the work:
Compile
Windows: dmd st1.d
Linux: dmd st1.d -L-ldl
// ---
// MGW 05.01.14
// Model in D a C++ object QByteArray of Qt.
I'm implementing a wrapper program for wrapping generic C++
libraries - it's going very well (subclassing, virtual methods,
nested classes, enums working) but I've hit an area that I don't
have enough D experience to answer, and am hoping someone can
point me in the right direction. My
On Saturday, 11 January 2014 at 20:17:14 UTC, Tobias Pankrath
wrote:
class X {};
X x;
x is an reference to an instance of X, with other words a
pointer without arithmetic but with syntax sugar. x will take
the address of this pointer/reference. If you want the address
of the actual
Hi all, hoping someone can help,
I'm used to coding to interfaces and I'm using them very lightly
in an application I'm writing (a CPP wrapper like SWIG, except in
D). Every now and then I touch a piece of code which seems almost
unrelated and then get a bunch of compile errors such as the
On Tuesday, 31 December 2013 at 14:26:33 UTC, bearophile wrote:
Abdulhaq:
I have a feeling that D doesn't fully support arrays of
interfaces, e.g. Method[], particularly as a return type.
If that's true, than it seems a D bug worth fixing. Are you
able and willing to create a minimized
Sorry to reply to me own post so quickly, a clue (it seems to me)
is this part of the error:
smidgen/ast/klass.d(15): Error: size of type Method is not known
Line 15 is where I import the interface:
import smidgen.ast.method: Method, MethodImpl, Visibility, SMID;
and in the relevant file,
On Tuesday, 31 December 2013 at 14:54:31 UTC, Adam D. Ruppe wrote:
On Tuesday, 31 December 2013 at 14:43:25 UTC, Abdulhaq wrote:
Well, interfaces don't have sizes, do they?
They have fixed size, interfaces are always implemented as
pointers.
Could be a forward reference problem, make sure
To give context, you're talking about a comparison of
(a ^^ 2.0) * 1.0 + 0.0 == a ^^ 2.0
(or, alternatively, the same but using isIdentical).
I'm curious to confirm why placing writefln statements before
the isIdentical check should change its behaviour (I assume
flushing the FPU
I was tidying up my emails at work and by coincidence I found the
original paper that I was referring to, it's very pertinent to
this discussion and interesting too,
The pitfalls of verifying floating-point computations
David Monniaux (LIENS, Verimag - Imag)
http://arxiv.org/abs/cs/0701192
... I thought I did, but now I'm up against an interesting
conundrum: while equality == comparison can fail here for
32-bit, isIdentical comparison can fail even for 64-bit,
although only for the release-mode build.
What's particularly odd is that if before calling
assert(isIdentical(
suppose) you would get slightly different
answers.
Could this be a factor?
Abdulhaq
14 matches
Mail list logo
