Undefined symbol ModuleInfoZ when including a SWIG generated module

2014-04-23 Thread Walter Gray via Digitalmars-d-learn

Hi there,
 I'm currently trying to set up a small demo project using the 
Leap Motion API in D.  I've run SWIG with -d -d2, and created the 
intermediate C++ DLL along with a pair of .d files, leap.d and 
leap_im.d.  I'm new to D, but very interested and I'd like to set 
this up in an idiomatic way  be able to share it, but I'm 
running into a problem: When I create a simple sample project 
with Visual D and import the Leap module, I get a number of 
linker errors:


Error 42: Symbol Undefined 
_D4Leap10Controller6__ctorMFZC4Leap10Controller (Leap.Controller 
Leap.Controller.__ctor())

Error 42: Symbol Undefined _D4Leap10Controller7__ClassZ
Error 42: Symbol Undefined _D4Leap12__ModuleInfoZ

I've discovered that if I run dmd manually and link in the object 
files for leap.d and leap_im.d, these problems go away, and if I 
create a separate project to build a .lib and then link to that 
it also solves the issue.  Both of these options seem hacky to me 
though, and I'm wondering if there's some 3rd option I'm missing 
- the files contain the entire definitions, so why would it be 
necessary to link to them AND specify them as imports?  What am I 
missing here?


Rust style memory management in D?

2014-01-12 Thread Walter Gray
I've been looking into alternatives to C++ and have been 
following D since back in the D1 Tango/Phobos days, and recently 
started digging in again.  I'm quite impressed with the progress, 
and I've started a simple toy game project to test out some of 
the language features.  One thing that really bothers me as 
someone who works on applications where responsiveness is 
critical and even 50ms delays can cause problems is the GC though 
- It seems to be that the only really good answer is to to just 
use malloc  free from the standard library, but that seems 
really awful for such an elegant language.  Every area but memory 
management is beautiful and can do what you like, but trying to 
avoid the GC is downright painful and forces you to ditch much of 
the safety D provides. Given that it is designed to be a systems 
programming language  in such applications memory management is 
so important, this seems like a tremendous oversight.


In my searching, I ran across Rust, which is relatively new and 
takes a rather different approach to a lot of things, including 
memory management - making unique shared pointers(~ is used to 
denote them) a language feature along side garbage collection so 
that the compiler can enforce ownership rules. One of the main 
language developers has noted that the unique pointer with 
ownership transfer rules is used so much more than the GC option 
that he's trying to get GC removed from the language and placed 
in the standard library.


Given D's target domain of high performance systems programming, 
this memory management model seems like a radically better fit 
than screw it, we'll GC everything. I've seen a few other 
people talk about this issue, and the difficulty of avoiding the 
GC seems to be THE argument against D that I wind up seeing. Has 
such a model been considered, and is there a reason (besides the 
fact that the entire standard library would probably have to be 
rewritten) that it isn't used?