Re: Using .lib and .dll in D applications

[docandrew via Digitalmars-d-learn]

On Sunday, 19 June 2016 at 18:33:36 UTC, moe wrote:

On Sunday, 19 June 2016 at 18:00:07 UTC, Mike Parker wrote:

On Sunday, 19 June 2016 at 17:33:43 UTC, moe wrote:







Unfortunatelly I still don't get it. I would like to have an 
independant project "dbar". The created lib is then used in 
another project "dfoo". Assuming that "dfoo" has no access to 
"dbar" other than the .lib file.


You can't do it with only the lib file. You *need* the source 
file too for the import statement. As I explained, the lib 
file is used by the linker, not the compiler. The compiler 
needs the source file.




My folder structure is like this:

-dtest
--dbar
source\barlib.d
dub.json
This project creates a dbar.lib file which seams to work.


-dtest
--dfoo
lib\dbar.d  // copied from the dbar project
source\app.d
dub.json


You don't need to copy dbar to the lib directory in this case.

This project would use the dbar.lib but should otherwise not 
have access to the dbar project. Basically simulating, that 
someone else made a dbar project to which I would not have 
access other than using the dbar.lib. How do I have to 
configure the dub.json file for this to work?


One of two things would happen:

1) They would register the project with he dub registry, then 
you add a dependency to a specific version the library. Dub 
would then download the necessary files for you and ensure 
that everything you need is passed to the compiler when 
building your project.


2) They would provide some other means for you to get the 
source and the library. Then you would need to manually 
configure your dub.json to pass the import path to the 
compiler and link with the library.




I have tried a variety of configurations for the dub.json. At 
this point it feels like a bad guessing game. That is no way 
to deveop anything. I need to figure out how to properly 
setup the dub.json but I don't seam to find the answer 
online. "http://code.dlang.org/package-format?lang=json; 
isn't very helpful.


All the information you need is there on that page.



I have meanwhile adjusted my dtest/dfoo/dub.json to this:



"dependencies": {
"dbar": "~master"
}


This gives me the error: "Root package dfoo references 
unknown package dear"


As I explained above, you need a path attribute for the 
dependency in this case since it is on your local file system 
and not in the registry. The documentation link I gave you 
explains how to to this. Try this:


"dependencies": {
"dbar":  {"path": "../dbar"}
}


I see where I went wrong. I thought that it's possible to only 
use the .lib file without the source code of dbar. Having 
access to the source makes what I am trying somewhat pointless. 
Is it otherwise possible to provide some functionality without 
having to give away your source? I would like to put together a 
library that I can reuse, without having to rely on the source 
each time. Maybe a dll instead?


Note: I don't have a problem with giving away my code. I just 
want to know if it can be done. Or maybe later build a plugin 
system where the creator of the plugin does not need the source 
of the entire application. And in turn the app does not need to 
be recompiled in order to use the plugin.


Thanks for your help!


Sure, you can just have a file with "extern" functions that tells 
the compiler that the source for those functions isn't available 
at compile time, but that later on when you link the library, the 
linker will find those function definitions in the .lib file (I'm 
not a Windows expert, but from my understanding .DLLs are a 
different ball game, and have to be loaded and called with 
special functions in your app.)


In your example, in your "dfoo.d", you can declare the functions 
from the dbar.lib inside as "extern myfunction();" and the 
compiler will say, "OK, myfunction() isn't defined here, so we'll 
let the linker sort it out." If you try and compile without 
telling it about dbar.lib, you'll get errors like "undefined 
reference to myfunction()...".


When you see that somebody wrote a "binding" in D for a library 
like OpenGL, etc., this is what they are providing, a .d file 
filled with "extern" definitions and maybe some glue code to 
convert D types into C types if the .lib file is a C library.


APIs generally work the same way. Library writers will provide a 
.h header file that doesn't expose any of their closed source, 
but gives users of the library the definitions of the functions 
they need to use it's functions.


I hope this helps!

-Jon

Re: What exactly does the compiler switch -betterC do?

[docandrew via Digitalmars-d-learn]

On Sunday, 19 June 2016 at 19:53:46 UTC, Gary Willoughby wrote:
When compiling, what exactly does the -betterC flag do? The 
command help says "omit generating some runtime information and 
helper functions" but what does this really mean? Is there any 
specifics somewhere?


My understanding was that -betterC was not fully implemented yet, 
due mostly to tight compiler integration with the runtime. (old 
info?)


I'm not super smart on the DMD source, but it looks like betterC 
prevents genhelpers() and genModuleInfo() from being called, with 
"helpers" appearing to be array checking, asserts and unit tests.


A comparison of object files compiled with and without the flags 
shows just a small reduction in the size of the code, but 
grepping for bounds checking, unit tests and ModuleInfo in the 
-betterC generated object file shows they are missing.


Hope this helps,

-Jon

Re: Linker error

[docandrew via Digitalmars-d-learn]

On Sunday, 5 June 2016 at 21:26:56 UTC, Anonymous wrote:

On Sunday, 5 June 2016 at 21:16:36 UTC, Andrej Mitrovic wrote:
On 6/5/16, Anonymous via Digitalmars-d-learn 
 wrote:
Should I report this as a dmd bug then? Not sure where / how 
to do that.


You can report it here: https://issues.dlang.org

I think I'll just let it go; I was able to work passed it 
anyway using "static Note[] empty;", and `null` works too. Is 
either one better?


null is simpler from a reader's perspective. :)

By the way, this is from an example I found in "D Web 
Development" by Kai Nacke.


Interesting that they would use such code in the book. Which 
chapter is it?


Thanks. I agree it's simpler and switched to `null`.

The example is in chapter 3.


That it works on OSX but not on Windows makes me think it should 
definitely be reported as a bug.


-Jon

Re: Embed files into binary.

[docandrew via Digitalmars-d-learn]

On Monday, 6 June 2016 at 02:05:09 UTC, Pie? wrote:
I saw somewhere someone explaining how to embed resources into 
a binary using the import keyword.


I believe the essentially converted the file into a ubyte or 
something and then wrote that out to a temp file and read in 
the temp file... this seems a bit of a kludge to me.


Is it possible to do the same, but create a sort of "in memory" 
file layout?


While I can modify my own routines to read the "file" from 
memory, I can't do that easily with outside code(I could modify 
the binaries).


Basically reading a file has to read it to memory, and if the 
file data already exists in memory, there is no point to read, 
just get it direct.


Any thoughts on this?

Because D allows such an embedding feature, maybe the file 
system should allow working with this concept? That way, it 
becomes VERY easy to embed files into the binary and work with 
them like they wernt. Also, going between the two different 
versions(embedded vs not) could be done with version (Release).


I'm not sure about import, but one option is to put the external 
files directly in your binary as part of the linker step. Check 
out:


http://www.linuxjournal.com/content/embedding-file-executable-aka-hello-world-version-5967

On Windows I think there's a way to embed files in .DLLs and then 
link those into your executable, but I'm ignorant of the 
steps/tools required.


-Jon

Re: Linker error

[docandrew via Digitalmars-d-learn]

On Sunday, 5 June 2016 at 18:36:13 UTC, Anonymous wrote:

On Sunday, 5 June 2016 at 18:30:25 UTC, Anonymous wrote:

[...]


Should have included:

OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
ns.obj(ns)  Offset 0BA0AH Record Type 009D
 Error 16: Index Range
--- errorlevel 1


Hmm, on OSX w/ dmd v2.071.0 I'm unable to duplicate. Can you try 
upgrading to v2.071 and see if that works?


-Jon

Re: Quite sure a simple basic problem...

[docandrew via Digitalmars-d-learn]

On Thursday, 2 June 2016 at 00:37:58 UTC, WhatMeWorry wrote:
I've got a fairly complex D project (25+ modules) that has 
grown haphazardly over time. So it is not well designed. But I 
want to get the thing fully ported before refining the code. 
(that's called refactoring, I believe?)


Anyway, there is a new module called audio.d which which has 
all the sound functionality.


And in the (main.d) module is a code snippet like so

void main(string[] argv)
{
// . . .
auto blop = new AlurePlaySound("../bleep.wav");
blop.play();
// . . .
}

So all is well and good except I need to place the sound in 
another module (game.d) where

collisions are detected.

I tried:

module game;
import main;   // is this as ugly as I think it is?

if (collision[0])  // If collision make sound
blop.play();


but this returns:  game.d(501): Error: undefined identifier 
'blop'



So can someone tell me what various solutions to this problem 
or type of problems?  I presume there are quick and dirty 
solutions (like here) and more elegant solutions?


Would this type of problem fall under the domain of "scope".  
Like in global scope. But I don't think D has such a concept.


Thanks.


Since blop is being declared inside your main() function, it 
isn't visible to other modules or functions. You're right that 
the issue is a problem of "scope".


Importing your main module will work, but you must declare your 
as a global variable outside the main() function.


i.e.

--

module main;

AlurePlaySound blop;

void main()
{
   //etc...

   blop = new AlurePlaySound("../beep.wav");

   //etc...
}

--

module game;

import main;

void collision()
{
blop.play(); //or whatever
}

If your game loop is running in a separate thread, then I think 
you'll want to use:


__gshared AlurePlaySound blop;

for the declaration, since variables are thread-local by default.

Using global variables is generally frowned upon for production 
code because you can never be sure which functions are modifying 
it. But for a quick hack, it works! A better option might be to 
make a third module with a class containing all your audio 
objects, initialize it in main(), and then pass it to your main 
game loop.


-Jon