Re: WeakRefs for a CPP-D wrapper
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 works, unfortunately storing the
address as ulong in an AA does not seem to be defeating the
garbage collector!
I guess I'll have to go for a WeakRef implementation, I'll try
Robert's implementation in signals, but I'd really like to know
how long it is likely to last as a working weak ref (in terms of
the D GC changing etc.) and if I'm taking the right approach.
Re: WeakRefs for a CPP-D wrapper
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(void*) x);
foo(x);
}
Thanks Tobias that indeed works, unfortunately storing the
address as ulong in an AA does not seem to be defeating the
garbage collector!
I guess I'll have to go for a WeakRef implementation, I'll try
Robert's implementation in signals, but I'd really like to know
how long it is likely to last as a working weak ref (in terms
of the D GC changing etc.) and if I'm taking the right approach.
Sorry to reply to my own message, looking at Robert's
InvisibleAddress class I think he's hiding the address from the
GC by e.g. rotating the bits in the ulong. He's also made it all
thread safe - I certainly don't understand the details but it's
given me some ideas.
Re: WeakRefs for a CPP-D wrapper
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*) x);
foo(x);
x = new X;
writeln(cast(void*) x);
foo(x);
}
Thanks Tobias that indeed works, unfortunately storing the
address as ulong in an AA does not seem to be defeating the
garbage collector!
I guess I'll have to go for a WeakRef implementation, I'll try
Robert's implementation in signals, but I'd really like to
know how long it is likely to last as a working weak ref (in
terms of the D GC changing etc.) and if I'm taking the right
approach.
The current GC is imprecise. Everything that looks like a
pointer at the bit level, is treated like one. I can't help you
create weak references.
No don't worry you've got me past that point of incomprehension,
thanks again
Re: WeakRefs for a CPP-D wrapper
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.
//
import core.runtime; // Load DLL for Win
import std.stdio;// writeln
version(linux) {
import core.sys.posix.dlfcn; // define dlopen() и dlsym()
// On Linux DMD v2.063.2, these functions are not defined
in core.runtime, so I had to write to.
extern (C) void* rt_loadLibrary(const char* name) { return
dlopen(name, RTLD_GLOBAL || RTLD_LAZY); }
void* GetProcAddress(void* hLib, string nameFun) { return
dlsym(hLib, nameFun.ptr);}
}
version(Windows) {
import std.c.windows.windows; // GetProcAddress for Windows
}
// Warning!!!
// When defining constructors and member functions attribute
extern (C) required!
alias extern (C) void function(void*, char*)
t_QByteArray_QByteArray; t_QByteArray_QByteArray
QByteArray_QByteArray;
alias extern (C) void* function(void*, char, int)
t_QByteArray_fill;t_QByteArray_fill
QByteArray_fill;
//T he structure of the QByteArray from the file qbytearray.h
in the include directory. Because C++ inline functions missing
in DLL
// there is no possibility to directly call a dozen functions.
// If you look in C++ there definition is as follows:
// inline char *QByteArray::data() { detach(); return d-data;
} where d is the Data*
struct Data {
void* rref;
int alloc;
int size;
char* data; // That's what we need, a pointer to
an array of bytes
char array[1];
}
// == Experimental class DQByteArray ==
class DQByteArray {
Data* QtObj; // this is object: QtObj - size 4 byte
(32 os)
// --
// constructor D called of a constructor C++
this(char* buf) {
QByteArray_QByteArray(QtObj, buf);
}
~this() {
// I can find a destructor, and here his record, but
too lazy to do it
}
// As inline function is not stored in a DLL have to model
it through the structure of the Data
char* data() {
return (*QtObj).data;
}
// D format: Data** == C++ format: QByteArray
// so it became clear that such a C++object, looking at it
from the D
void* fill(char ch, int resize=-1) {
return QByteArray_fill(QtObj, ch, resize);
}
}
int main(string[] args) {
// These files get QByteArray C++
version(linux) {auto nameQtCore = libQtCore.so; }
version(Windows) {auto nameQtCore = QtCore4.dll; }
auto h = Runtime.loadLibrary(nameQtCore); // Loading dll or
so
// Load function constructor QByteArray::QByteArray(char*);
QByteArray_QByteArray =
cast(t_QByteArray_QByteArray)GetProcAddress(h,
_ZN10QByteArrayC1EPKc);
// QByteArray::fill(char*, int);
QByteArray_fill = cast(t_QByteArray_fill)GetProcAddress(h,
_ZN10QByteArray4fillEci);
// QByteArray::~QByteArray()
// Create our experimental subject and consider its data
DQByteArray ba = new DQByteArray(cast(char*)ABC.ptr);
printf(\n ba.data() = %s, ba.data());
// Experience the action of the fill() and see the result
ba.fill('Z', 5);
printf(\n ba.data() = %s, ba.data());
return 0;
}
Hi yes I think noticed in another thread that you were wrapping
Qt with dynamic loading of the qt libs, interesting idea - does
your code allow subclassing of the Qt classes and overriding the
virtual methods? I'm taking a much more traditional approach, but
there is method in my madness :-)
WeakRefs for a CPP-D wrapper
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 background is lots of professional Java, Python etc., but not so much writing of C++ (plenty of reading but not writing). I need to maintain a mapping between C++ void* addresses and D wrapper Objects. The naive implementation would be Object[void*] wrappingRegistry; but of course that prevents the wrapped objects from being garbage collected - I need weak ref semantics. I had a go at making it e.g. ulong[ulong] and storing the cast(ulong) address of the D object, but it seems that I don't understand what taking the address of an obj (obj) actually is doing - it doesn't seem to point to the memory occupied by the object but instead to the address of the variable pointing to the object? I've had a good google around and because my understanding is poor in this area (GC innards, shared data, D pointers etc) I can't identify which of the implementations around is best for 2.064/2.065 and moving forwards. My best guess is the WeakRef found in this one: https://github.com/phobos-x/phobosx/blob/master/source/phobosx/signal.d by Robert in his signals2 implementation. Can anyone expain what is going on in WeakRef and InvisibleAddress? thanks for any help you can give me.
Re: WeakRefs for a CPP-D wrapper
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 instance, you can use cast(void*) for example.
Hi Tobias, can casting the address to void* make a difference to
its value?
Here's an example of what I don't understand:
import std.stdio;
import std.string: format;
class Foo {
int x;
}
void printAddress(Foo foo) {
writeln(Address of parameter foo is %x.format(foo));
writeln(Address of parameter foo cast to void* is
%x.format(cast(void*) foo));
}
void main() {
auto foo = new Foo();
writeln(Address of foo is %x.format(foo));
writeln(Address of foo cast to void* is %x.format(cast(void*)
foo));
printAddress(foo);
}
When run I get:
Address of foo is 7fff40ac4558
Address of foo cast to void* is 7fff40ac4558
Address of parameter foo is 7fff40ac4538
Address of parameter foo cast to void* is 7fff40ac4538
So why is the address of the parameter foo different to the
address of main foo, when they both refer to the same object?
thanks
Arrays of an interface
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 following (Method is the interface, MethodImpl is the implementation): smidgen/ast/klass.d(108): Error: function smidgen.ast.klass.Klass.addMethod (Method method) is not callable using argument types (MethodImpl) smidgen/ast/klass.d(113): Error: function smidgen.ast.klass.Klass.addMethod (Method method) is not callable using argument types (MethodImpl) smidgen/ast/klass.d(293): Error: cannot append type smidgen.ast.method.Method to type Method[] smidgen/ast/klass.d(322): Error: forward reference to getAllWrappedMethods smidgen/ast/klass.d(360): Error: forward reference to type Method[] smidgen/ast/klass.d(360): Error: cannot implicitly convert expression (baseMethods) of type Method[] to Method[] smidgen/ast/klass.d(363): Error: cannot implicitly convert expression (baseKlass.methods) of type Method[] to Method[] smidgen/ast/klass.d(542): Error: forward reference to getAllWrappedMethods smidgen/ast/klass.d(636): Error: forward reference to getAllWrappedMethods smidgen/ast/klass.d(672): Error: forward reference to getAllWrappedMethods smidgen/ast/klass.d(15): Error: size of type Method is not known smidgen/ast/klass.d(709): Error: function smidgen.ast.klass.Klass.isCovariantMethod (Method otherMethod) is not callable using argument types (Method) smidgen/ast/klass.d(746): Error: forward reference to type Method[] smidgen/ast/klass.d(746): Error: cannot implicitly convert expression (allWrappedMethods) of type Method[] to Method[] I have a feeling that D doesn't fully support arrays of interfaces, e.g. Method[], particularly as a return type. Is there a better way to pass around lists of instances of an interface? I'm using DMD 2.064 on Linux 64bit, thanks
Re: Arrays of an interface
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 example (later useful for Bugzilla)? Bye, bearophile Honestly I'd like to do that but I'm pretty swamped ATM and I don't think a simple example is going to be easy to knock up. It might simply be a quirk somewhere in the code that's causing a load of spurious error messages. I'm going to try backing out my last change set and slowly reapply and see where it goes haywire, but I'm losing confidence in arrays of interfaces and really would like an alternative so that I can get coding on the real problem.
Re: Arrays of an interface
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,
interface Method: ConverterManagerProvider {
bool virtual();
bool abstract_();
bool static_();
bool constructor();
bool destructor();
bool hasEllipsis();
bool const_();
bool transferBack();
etc...
Well, interfaces don't have sizes, do they? So does [] only
really work for classes?
Re: Arrays of an interface
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 you import the module with the interface above any use of it, and do a full import instead of a selective one and see what happens. Ah! Great, doing the full import fixed it. The interface precedes the implementation in the same file, so it seems to me it's possibly a subtle glitch in the compiler with selective imports (the change I was making was in another module where I was subclassing Klass, which was the class with the array on it). Thanks both for your speedy replies!
Re: Equality == comparisons with floating point numbers
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 cache?) and whether this can be reliably done without writing output to screen. It's an interesting question. If I was attacking this problem I think I'd look at the assembly generated by the compiler, write a little self contained assembly program, and see if I could replicate it. I don't think it's a compiler problem - but what do I know!.
Re: Equality == comparisons with floating point numbers
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
Re: Equality == comparisons with floating point numbers
... 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( ... )) I use writeln to print the value of isIdentical(...) to the screen, then it prints true, and the assertion passes. If I don't have the print statement, then the assert fails. I'm presuming that calling writefln to print the variable involves it being taken off the FPU? I'm just guessing now but it seems that you are in an area that changes depending on which compiler you are using (how does it compile the FP instructions, does it use SSE instructions, how is it checking equality) and which exact processor are you on, does it support IEEE754, does the compiler try to support IEEE754 exactly? I haven't seen much in the forums about FP behaviour in e.g. dmd. E.g. how does it deal with the issues raised in http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf? The people who know these things can found discussing them at http://forum.dlang.org/thread/khbodtjtobahhpzma...@forum.dlang.org?page=3#post-l4rj5o:24292k:241:40digitalmars.com :-). It's generally held that checking FP numbers for exact equality isn't practical and it's better to go for equality within a certain tolerance - any reason why you're not happy with that :-)?
Re: Equality == comparisons with floating point numbers
On Friday, 6 December 2013 at 14:58:31 UTC, Joseph Rushton Wakeling wrote: On 06/12/13 15:02, Ali Çehreli wrote: Are they identical when printed with %a? Yes. You can see some of the results here (for the 32-bit systems where I was getting failures): https://d.puremagic.com/test-results/pull.ghtml?projectid=1runid=811923logid=6 https://d.puremagic.com/test-results/pull.ghtml?projectid=1runid=811924logid=6 https://d.puremagic.com/test-results/pull.ghtml?projectid=1runid=811927logid=6 https://d.puremagic.com/test-results/pull.ghtml?projectid=1runid=811930logid=6 So, as I said, it's baffling why the equality operator is not returning true. Some time ago in a test I had written (C++) apparently identical floating point operations were returning different answers (in the 17th/18th sign fig), when re-running the same code with the same data. The paper described how the result could change if the numbers remained in the FPU (which had a few bits extra precision over the normal register size) during the course of the calculation as a opposed to being swapped in and out of the main registers. Depending on when numbers could get flushed out of the FPU (task swapping I suppose) you would get slightly different answers. Could this be a factor? Abdulhaq
