Re: Debugging on Windows
On Thursday, 8 February 2018 at 21:09:33 UTC, JN wrote: Hi, is there any way to debug binaries on Windows? I'd at least like to know which line of code made it crash. If it's D code, I get a call trace usually, but if it's a call to a C library, I get a crash and that's it. I am using VSCode and I'd prefer to debug in it if possible, but using other IDEs is a possibility for me if that will help. The best option most likely is to get the Visual Studio Community Edition and then Install the VisualD extension for Visual Studio. This will give you a very good debugging experience with a bulitin D expression evaulator and the usual features the very good Visual Studio debugger comes with. Kind Regards Benjamin Thaut
Re: invalid or corrupt file: duplicate COMDAT / Previous Definition Different
Am 10.01.2018 um 20:32 schrieb Anonymouse: I don't have a reduced testcase yet. I figured I'd ask if it's something known before making the effort. Are you by any chance mixing debug and release builds? Or are the -version specifiers different when compiling the various parts of your program? Check your compiler flags and ansure that they are the same over your entire build process. Especiall -debug -relase -inline -O -version -- Kind Regards Benjamin Thaut
Re: How do I set a class member value by its name in a string?
On Wednesday, 27 December 2017 at 20:04:29 UTC, Marc wrote:
I'd like to set the members of a class by its name at runtime,
I would do something like this:
__traits(getMember, myClass, name) = value;
but since name is only know at runtime, I can't use __traits().
What's a workaround for this?
You will have to use a combination of compile time and runtime
methologies.
Essentially what you want is this:
void setMemberValue(string name, int value)
{
switch(name)
{
case "member1":
member1 = value;
break;
case "member2":
member2 = value;
break:
...
}
}
As you don't want to write this for all members by hand you
should write a function which generates the source code for this
switch using static foreach and __traits(allMembers) and then
mixin the generated string into the setMemberValue method. If
your members can have different types you will also need runtime
type that can hold multiple types. For simplicity I just used
"int" in the above example. You could use "std.variant" for this.
Re: float.max + 1.0 does not overflow
On Wednesday, 27 December 2017 at 13:40:28 UTC, rumbu wrote:
Is that normal?
use std.math;
float f = float.max;
f += 1.0;
assert(IeeeFlags.overflow) //failure
assert(f == float.inf) //failure, f is in fact float.max
On the contrary, float.max + float.max will overflow. The
behavior is the same for double and real.
This is actually correct floating point behavior. Consider the
following program:
float nextReprensentableToMax = float.max;
// find next smaller representable floating point number
(*cast(int*))--;
writefln("%f", float.max - nextReprensentableToMax);
It computes the difference between float.max and the next smaller
reprensentable number in floating point. The difference printed
by the program is:
20282409603651670423947251286016.0
As you might notice this is siginificantly bigger then 1.0.
Floating point operations work like this: They perform the
operation and then round to the nearest representable number in
floating point. So adding 1.0 to float.max and then rounding to
the nearest representable number will just give you back
float.max. If you however add float.max and float.max the next
nearest reprensentable number is float.inf.
When trying to understand how floating point works I would highly
recommend that you read these articles (oldest first):
https://randomascii.wordpress.com/category/floating-point/
Kind Regards
Benjamin Thaut
Re: DMD Windows 64bit target - how to setup the environment?
On Monday, 25 December 2017 at 16:35:26 UTC, realhet wrote: Now I have my first DMD 64bit windows console app running. (And I'm already afraid of the upcoming windowed application haha) My recommendation for getting setup on Windows with D is as follows: 1) Install the latest visual studio community version: https://www.visualstudio.com/thank-you-downloading-visual-studio/?sku=Community=15 2) Install dmd through the windows installer: https://dlang.org/download.html , exe option under windows. This will correctly configure dmd to use the visual studio install from above. From here on dmd will be able to compiler with -m64 and -m32mscoff from the command line. 3) Install VisualD from http://rainers.github.io/visuald/visuald/StartPage.html 4) Create a D project in visual studio and start programming. Compile and debug as usual in Visual Studio. For you command line compilation. Why are you passing -c to the compiler? The idea behind D is that you pass all modules at the same time to the compiler. This allows the compiler to reuse template instances across modules and in general compilation with D is fast enough to be able to recompile everything each time you make changes. No need for a build system. A single batch file with one command in it is usually enough. There is no need to call the linker manually. Dmd will do this for you. Just call dmd like this: dmd -m64 source1.d source2.d source3.d -ofoutput.exe and thats it. You can add additional options like -O -inline -noboundscheck -g -debug -relase. Those are the most commoly used options. Kind Regards Benjamin Thaut
Re: DMD Test Suite Windows
On Wednesday, 20 December 2017 at 10:15:45 UTC, Benjamin Thaut wrote: I found that both the make that comes with msys and the make that comes with mingw work for me. I‘m currently on vacation but once I‘m back and in case you are interrested I can post the batch file I use to run the dmd tests. Here are my scripts: http://stuff.benjamin-thaut.de/D/DmdScripts.zip You need to edit import/config.cmd and put in your paths to visual studio, msys and tdm gcc. A regular mingw also works, but if you use a regular mingw you have to remove the -j4 flag from the run-tests scripts as multi job make is broken in regular mingw (Thats why I use tdm-gcc). The 5 scripts included are: run-tests-win32mscoff.cmd - Runs the dmd test suite with the -m32mscoff flag run-tests-win64.cmd - Runs the dmd test suite with the -m64 flag setup-path-32mscoff.cmd - Sets up the environment so that building of druntime / phobos using the -m32mscoff flag becomes possible. setup-path-64.cmd - Sets up the environment so that building of druntime / phobos using the -m64 flag becomes possible. make-dlls.cmd - A bit of a unlucky name, but makes sense for my local workflow. Builds both druntime and phobos in 64 and 32mscoff. Hope this helps. Kind Regards Benjamin Thaut
Re: DMD Test Suite Windows
On Monday, 18 December 2017 at 16:06:33 UTC, Jonathan Marler wrote: Trying to run the dmd test suite on windows, looks like Digital Mars "make" doesn't work with the Makefile, I tried Gnu Make 3.81 but no luck with that either. Anyone know which version of make it is supposed to work with on windows? Is it supposed to work on windows at all? I found that both the make that comes with msys and the make that comes with mingw work for me. I‘m currently on vacation but once I‘m back and in case you are interrested I can post the batch file I use to run the dmd tests.
Re: Test if a class is extern(c++)
On Monday, 10 April 2017 at 18:56:42 UTC, BBasile wrote: Hello, I have a trait for this: https://github.com/BBasile/iz/blob/master/import/iz/types.d#L650 Hi BBasile, I think your trait is a good starting point for my needs. Thanks.
Test if a class is extern(c++)
In particular I want to know if the vtable of the class has the class info member. Is there any way to do this at compile time? At runtime? Kind Regards Benjamin Thaut
Bug in std.allocator?
Please consider the following program:
import std.experimental.allocator.mallocator;
import std.experimental.allocator.building_blocks.allocator_list
: AllocatorList;
import std.experimental.allocator.building_blocks.free_list;
import std.experimental.allocator;
import std.stdio;
enum uint size = 1104;
alias ScalableFreeList = AllocatorList!((n) =>
ContiguousFreeList!(Mallocator, 0, unbounded)(size * 128,
size)
);
void main(string[] args)
{
void[][20] allocs;
ScalableFreeList allocator;
for(int i=0; i < 100; i++)
{
writefln("pass %d", i);
foreach(ref alloc; allocs)
{
alloc = allocator.allocate(size);
writefln("%x", alloc.ptr);
}
foreach(alloc; allocs)
{
allocator.deallocate(alloc);
}
}
}
I would assume that this program should run forever and never run
out of memory. But instead it triggers an assert inside
alocator_list in pass 11. So I assume this is some bug in
std.allocator?
Also whats interresting. The first allocation in each new pass is
_not_ the last allocation to be freed. Instead it seems to "leak"
one allocation each pass.
From the output of the program:
229a290fd60 <- same
229a2932570 <- leaked?
pass 11
229a290fd60 <- same
Or can anyone see a bug in my program?
Kind Regards
Benjamin Thaut
std.paralellism.Task value type problems
I would like to use std.paralellism.TaskPool to schedule various tasks I create. The problem however is that these tasks don't have a lifetime which is bound to any function scope I have. So I need to create a new task object on the heap and push it into a array for bookkeeping. The problem however is that std.paralellism.Task is a struct and the only way to instanciate it is to use std.paralelism.task which returns it as a value. I have no idea at the moment how to allocate a instance of std.paralellism.Task on the heap. Any suggestions? Kind Regards Benjamin Thaut
std.experimental.allocator and GC.addRange
Lets assume I have a allocator which cains together multiple building blocks from std.experimental.allocator and at the end there is a mallocator providing the underlying memory. Now I alloacte a type which contains a pointer into GC memory. Obviously the memory of the mallocator is not scanned by the GC so the pointer might become dangling if the GC chooses to collect. I'm wondering if std.experimental.allocator has any building blocks or mechanism to automatically call GC.addRange. Kind Regards Benjamin Thaut
Re: Strange stack variable corruption error after calling extern(C) function
On Wednesday, 4 May 2016 at 17:53:32 UTC, cc wrote: The OS is Win64 though the program is being compiled as 32-bit and I'm using the 32-bit distributed DLL. fmod.dll: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows Tried int and long as the return type, same issue both ways. Tried void too just in case, same thing though. Could you please post the definition of FMOD_RESULT. Its possible that the create sound function returns it on stack and not inside a register. This is usually the case if FMOD_RESULT is defined as a struct in C/C++. But its hard to say. In your case I would actually look at the disassembly and step through it to see where its going wrong and messing up the stack.
Re: Strange stack variable corruption error after calling extern(C) function
On Tuesday, 3 May 2016 at 19:06:30 UTC, cc wrote: it fails to link with "Error 42: Symbol Undefined _FMOD_System_CreateSound@20". With extern(C) it compiles and runs but the problem from above persists. Is this on Windows x64? Try replacing FMOD_RESULT by int. When declaring the fmod create sound function and see if that helps.
Re: Stacktraces in static constructors
On Wednesday, 4 May 2016 at 06:37:28 UTC, Nordlöw wrote:
On Tuesday, 3 May 2016 at 12:31:10 UTC, Benjamin Thaut wrote:
I assume this is on windows? Yes its a known issue (I know
No, the problem occurs on my Linux aswell.
From core.runtime:
static this()
{
// NOTE: Some module ctors will run before this handler is
set, so it's
// still possible the app could exit without a stack
trace. If
// this becomes an issue, the handler could be set in C
main
// before the module ctors are run.
Runtime.traceHandler =
}
So a possible workaround would be to either import core.runtime
in each of your modules or manually run the line
Runtime.traceHandler =
Also I find it strange that the trace handler is initialized in a
regular module constructor. In my eyes it should be a shared
module ctor because the storage behind Runtime.traceHandler is
__gshared anyway.
Kind Regards
Benjamin Thaut
Re: Strange stack variable corruption error after calling extern(C) function
On Tuesday, 3 May 2016 at 11:32:31 UTC, cc wrote: Hello, I've been encountering a strange problem that seems to occur after calling some external C functions. I've been working on a program that incorporates the FMOD C API for playing sound, with a simple D binding based off the C headers, and actually everything works more or less fine, I've had working sound in my program for a few months now. However I recently started noticing some strange behavior, currently using DMD v2.070.2 (haven't tried v2.071 yet, will soon). I can't post the entire program but I'll include the relevant code, I might try to make a small working compilable sample if this isn't enough information. [...] It seems that one of the fmod functions you declared is not correct. Either the fmod api is not using the c calling convention or you made a mistake when declaring the paramters of the fmod functions. You should double check that the functions match the fmod headers. Kind Regards Benjamin Thaut
Re: Stacktraces in static constructors
On Tuesday, 3 May 2016 at 10:52:20 UTC, Nordlöw wrote: On Tuesday, 3 May 2016 at 10:48:51 UTC, Nordlöw wrote: AFAICT, stacktraces are not emitted with debug information when Should be static shared module constructors. errors occur in static module constructors. Is this a know bug? My stacktraces contain no information of the call stack so it's very very tedious work to find the reason for a failing unittest. I assume this is on windows? Yes its a known issue (I know about it). I Don't know if its filed though. As a workaround you can import "core.sys.windows.stacktrace" into each of your modules. That will force the module system to initialize the stacktracing code before the module ctors. The underlying issue is that the module system does not know about the implicit dependeny of every module on the stacktracing module. Kind Regards Benjamin Thaut
Re: Debugging D DLL from C# app with C linkage for native Unity 5 plugin
On Tuesday, 29 March 2016 at 23:41:28 UTC, Thalamus wrote: dmd dllmain.d dll.def -w -wi -g -map -ofLogic.dll -m64 -debug -shared Anyone know what I should try next? Am I missing something simple? :) thanks! Thalamus You should be using "-gc" instead of "-g" when building 64-bit D programs that should be debugged with visual studio. Otherwise the visual studio debugger might get confused over some of the symbol names. (Because they contain '.')
Re: Shared static constructors from C# EXE
On Thursday, 25 February 2016 at 17:46:18 UTC, Thalamus wrote: On Thursday, 25 February 2016 at 16:05:37 UTC, Benjamin Thaut wrote: [...] Thanks Benjamin. When I went to whittle this down to its barest essentials, though, the repro is pretty simple. It involves LIBs, but not Dlls, and it doesn't require anything but a single D EXE. [...] The problem is that when you build with -lib the resulting library is optimized for linker stripping. E.g. everything that is not directly used will not be pulled into the final executable. If you want everything in the final exectuable you shouldn't be using a .lib file. Instead compile with -c resutling in a .obj file and link the resulting .obj file into your executable. Then everything will end up in the final executable even if its not directly used. Kind Regards Benjamin Thaut
Re: Shared static constructors from C# EXE
On Thursday, 25 February 2016 at 14:42:14 UTC, Thalamus wrote: your entry point. Hi Guillaume, Thanks for responding so quickly! I had found that wiki page before and I'd been following the "DLLs with a C Interface" section closely. I had forgotten to add -shared when building the DLL, but the behavior didn't change when I added it. So, I added a call to Runtime.initialize() as the first line of the endpoint I'm exposing. (I also made sure that this was the only endpoint invoked and that it was only invoked once just to be cautious.) I can see Runtime.initialize() being called, but the Class A shared static constructor still is not called when run from the C# EXE. Do you have any other ideas? In the meantime, I'm working on putting together a minimal repro source, but the scenario is a bit complicated so there's a lot of details to whittle away. thanks! Gene You shouldn't be calling Runtime.initialize() manually. Just do the following in one of your source files: import core.sys.windows.dll; mixin SimpleDllMain; This will generate a DllMain that will correctly initialize and deinitialize druntime. Kind Regards Benjamin Thaut
Re: How is the TypeInfo assigned?
On Saturday, 13 February 2016 at 12:44:40 UTC, Tofu Ninja wrote: Is the TypeInfo given by typeid() guaranteed to be the same for a type regardless of where I call it? I guess my question is, is the TypeInfo a valid way to dynamically check types? I am implementing a message passing system for an entity-component system, I was planning to use structs as messages and use the TypeInfo to determine where they are supposed to go. Will this cause any problems? Also will typeid() allocate? Or is the TypeInfo statically allocated at compile time? Also how does shared libs affect this? Will a TypeInfo passed across different libs still match up? Thanks Yes, type infos are garantueed to have identity. You can use their adress to identify a type. The linux shared library mechanism ensures that they have the same adress across multiple shared libraries (if all of these libraries are loaded into the same process) With windows dlls there can be cases where a typeinfo is duplicated. But as dlls don't really work yet, I wouldn't worry about it.
Re: Octree implementation?
On Monday, 1 February 2016 at 02:56:06 UTC, Tofu Ninja wrote: Just out of curiosity, does anyone have an octree implementation for D laying around? Just looking to save some time. https://github.com/Ingrater/thBase/blob/master/src/thBase/container/octree.d Its a loose octree implementation. That means the cells overlap a bit to accomondate for the problem of objects that are on the border between to cells. I don't know though if you can rip out the implementation without some modifications. Kind Regards Benjamin Thaut
Re: Assert failure on 2.070.0 without stack trace
On Thursday, 28 January 2016 at 18:33:19 UTC, Nordlöw wrote: Thanks, I'm aware of these tools. But it's easier to use the stacktrace...if I only get one. The function where the assert() is called is, in turn, called in hundreds of places. Which platform are you on? Are all your binaries compiled with debug symbols? If one or multiple functions on the stack are within phobos or druntime you might not have debug symbols for phobos or druntime. Using inline asm might also destroy your stack frames.
Re: D Dll's usefulness
On Monday, 25 January 2016 at 19:45:21 UTC, Igor wrote: Am I off target here? Dlls are currently not properly supported in D, I would strongly advice against using them. Just link everything statically and be happy for now. Kind Regards Benjamin Thaut
Re: Shared library question
On Saturday, 23 January 2016 at 00:38:45 UTC, Dibyendu Majumdar wrote: On Friday, 22 January 2016 at 22:06:35 UTC, Dibyendu Majumdar wrote: Hi I am trying to create a simple shared library that exports a D function, but when I try to link to it I get errors such as: error LNK2001: unresolved external symbol _D7xxx12__ModuleInfoZ I have uploaded my small test here so if anyone can tell me what I am doing wrong it will hugely appreciated. Thanks! https://github.com/dibyendumajumdar/d-lab/tree/master/sharedlib Dll support on windows is basically non existant at the moment and I strongly advice against trying to use it. Trust me I've been there. I'm currently working on propper Dll support but that is most likely going to take a few more months. Your best option currently is to simply link everything statically. Kind Regards Benjamin
Re: cast fails for classes from windows dll
On Tuesday, 12 January 2016 at 19:00:26 UTC, Andre wrote:
Hi,
I am not sure, whether this is a current limitation of the
windows dll functionality of D
or I am doing s.th. which will not work.
I have developed in D a windows DLL which creates class
instances by passing the name (using object.factory method).
In another D application I am using this DLL. My issue is, that
the cast fails, although
typeid(bar).name shows the correct name .
module main;
// these classes are in a seperate module
// used for the dll & for this application
export class Foo {}
export class Bar : Foo {}
class Baz : Bar {}
void main()
{
// this method calls the dll and returns Foo
Foo c = dllCreateClass("main.Baz");
// no failure
assert( typeid(c).name == "main.Baz");
// > fails
if (auto myBar = cast(Bar) c){}
}
Kind regards
André
Thats a limitation of the current dll functionality. The type
info of the class gets duplciated into both your executable and
the dll and thus the cast fails. Until D properly supports Dlls
on windows this is going to stay this way. Currently only a C
like interface across dll boundaries is possible.
Re: cairo(D) / x64 / unresolved externals / don't know why
Am 11.01.2016 um 18:27 schrieb Robert M. Münch: Import symbols are symbols used for dll linking and start with "__imp_" Is this a DMD convention or a general one? Never heard about this. This seems to be a general convetion on windows. All c++ compilers I've seen on windows so far emit so called import symbols using the "__imp_" prefix. Basically its just another level of indirection during a function call to be able to resolve function addresses at runtime, e.g. implement dynamic linking. Its kind of a implementation detail, so in theory you don't have to know about it. But it helps when reading linker errors. In case my talk gets accepted for dconf 2016 I'm going to cover this there in more detail. -- Kind Regards Benjamin Thaut
Re: cairo(D) / x64 / unresolved externals / don't know why
On Sunday, 10 January 2016 at 22:22:03 UTC, Robert M. Münch wrote: I made to compile a bunch of libs on Win64 and got my D project compiled as well. Only problem left are some strange unresolved externals. Linking... dmd -of.dub\build\application-debug-windows-x86_64-dmd_2069-F0A1450B9B033D5CD11F3F60481557B0\webchat.exe .dub\build\application-debug-windows-x86_64-dmd_2069-F0A1450B9B033D5CD11F3F60481557B0\webchat.obj ..\vibe-d-0.7.26\lib\win-amd64\libeay32.lib ..\vibe-d-0.7.26\lib\win-amd64\ssleay32.lib ..\cairoD\cairoD.lib C:\Users\robby\AppData\Roaming\dub\packages\derelict-ft-1.0.2\lib\DerelictFT.lib C:\Users\robby\AppData\Roaming\dub\packages\derelict-util-2.0.4\lib\DerelictUtil.lib C:\Users\robby\AppData\Roaming\dub\packages\x11-1.0.9\x11.lib ..\vibe-d-0.7.26\vibe-d.lib wsock32.lib ws2_32.lib advapi32.lib user32.lib -LD:\develop\cairo\cairo\src\release\cairo-static.lib -LD:\develop\cairo\libpng\libpng.lib -Lgdi32.lib -m64 -m64 -m64 -m64 -m64 -m64 -g cairo-static.lib(cairo-image-source.obj) : error LNK2001: unresolved external "__imp__hypot" and some more missing in other .obj files: "__imp__ctime64" "__imp_ldiv" "__imp_strncpy" "__imp_rand" IMO this all looks like msvcrt standard lib stuff so wondering why it's not found. Do I explicitly have to link to the msvcrt lib? You should not need to link manually against msvcrt, dmd does this for you. You can view the linker commands that are stored inside a object file via microsoft dumpbin tool "dumpbin /DIRECTIVES your.obj". You should check the declarations of the functions that cause a unresolved external error. If they have a "export" in front of them, remove the export. I can not think of any other reason why dmd would otherwise reference a import symbol. Import symbols are symbols used for dll linking and start with "__imp_" Out of curiosity, why do you pass "-m64" 6 times to dmd? Once would be enough. For debug builds targeting windows 64 I would also highly recommend using "-gc -op" instead of "-g". This will give a much better debugging experience in Visual Studio.
Re: Linking a DLL to a DLL with packages
Am 09.01.2016 um 16:45 schrieb Thalamus: Hi Benjamin, I wouldn't say I need DLLs to work fully _really_ badly. The only non-negligible issue with single very large binaries that's crossed my mind is patching, but we're years away from having to worry about that too much. That being said, I'm definitely willing to do some testing, especially for something that helps us down the road. I'll follow up with you offline. Thanks! Great, some help with bugfixing and testing would be greatly apreciated. I didn't get any e-mail from you yet, I assume you didn't send one? Kind Regards Benjamin Thaut
Re: Linking a DLL to a DLL with packages
On Thursday, 7 January 2016 at 19:29:43 UTC, Thalamus wrote: Hi everyone, First off, I've been working with D for a couple of weeks now and I think it's the bee's knees! :) Except for DLLs. thanks! :) Dlls don't currently work on Windows. The only thing that works is giving your dlls a C-like interface. If you need any kind of D interface (classes, modules, etc) it won't work. I'm currently working on this, if you need it really badly and are willing to help bug testing send me a mail to code at benjamin-thaut.de Kind Regards Benjamin Thaut
Re: Why my app require MSVCR120.dll?
On Friday, 6 November 2015 at 16:21:35 UTC, Suliman wrote: On Friday, 6 November 2015 at 13:50:56 UTC, Kagamin wrote: MSVCR is a C runtime. On Linux it will depend on a C runtime too. But which part of my App depend on C runtime? All of it. Phobos and druntime use the C runtime, that means the language itself depends on the C runtime.
Re: __simd_sto confusion
On Saturday, 3 October 2015 at 14:47:02 UTC, Nachtraaf wrote:
I'm trying to create some linear algebra functions using simd
intrinsics. I watched the dconf 2013 presentation by Manu Evans
but i'm still confused about some aspects and the following
piece of code doesn't work. I'm trying to copy the result of a
dot product from the register to memory but dmd fails with an
overload resolution error, which i guess is due some implicit
conversion?
dmd error:
simd1.d(34): Error: core.simd.__simd_sto called with argument
types (XMM, float, __vector(float[4])) matches both:
/usr/include/dlang/dmd/core/simd.d(434):
core.simd.__simd_sto(XMM opcode, double op1, __vector(void[16])
op2)
and:
/usr/include/dlang/dmd/core/simd.d(435):
core.simd.__simd_sto(XMM opcode, float op1, __vector(void[16])
op2)
from the following piece of code:
float dot_simd1(float4 a, float4 b)
{
float4 result = __simd(XMM.DPPS, a, b, 0xFF);
float value;
__simd_sto(XMM.STOSS, value, result);
return value;
}
What am I doing wrong here?
core.simd is horribly broken. I recommend that you avoid it for
any serious work. If you want to do simd programming with D get
LDC or GDC and use their simd intrinsics instead of core.simd.
If you have to do simd with dmd write inline assembly.
Re: Status of Win32 C++ interop
On Tuesday, 8 September 2015 at 12:56:00 UTC, Laeeth Isharc wrote: This is really very clear and helpful, and I appreciate your taking the time. I will place it on the wiki if that's okay. Thats ok. Library support is surely one of the largest impediments to the adoption of D, and we ought to place some emphasis on updating the documentation here: http://dlang.org/cpp_interface.html How does it work when external APIs expect objects from the C++ standard library? strings, and so on? How about funny pointer types? shared_ptr etc? std::vector, std::list? For templated types like std::vector, std::list and shared_ptr you have two options: - Redo the complete implementation on the D side ensuring that the data layout is the same - Or, expose helper functions which call placement new / desturctor of your needed std::vector and do the hidden data trick I described above. The regular functions of std::vector just have to be declared and the linker will find them if and only if the c++ side instanciated the template. Here is one C++ library used by many in finance (at least as a backup). I think there might be a decent amount of value in making this usable from D. (Trying to put my own interests aside!) Paging Andy Smith ? http://quantlib.org/reference/_bermudan_swaption_8cpp-example.html I think you have to make this usable from D yourself ;-) Are there any well-known C++ libraries that you have interfaced to ? Could you give some examples of how long it takes ? I'm interfacing to a 3D engine I'm working on in my spare time with some collegues. So no well known C++ library. Would you be able to drop me an email about something else? No contact info on your blog, but my domain is kaleidicassociates.com and my user id is laeeth@ Will do. Kind Regards Benjamin Thaut
Re: Status of Win32 C++ interop
On Monday, 7 September 2015 at 19:30:44 UTC, drug wrote: 07.09.2015 21:37, Benjamin Thaut пишет: snip So far I haven't found a situation where I couldn't make it work the way I wanted. Its just some work to write the D headers for the C++ classes and vise versa, because you have to duplicate everything once more. An automated tool for this would be nice, but unfotunately there is currently none. Kind Regards Benjamin Thaut It's great. But isn't it based on your custom modifications of compiler and the others? No, the compiler modifications are only for the Windows DLL support. All modifications I did to the c++ binding are already in 2.068
Re: Status of Win32 C++ interop
On Friday, 4 September 2015 at 16:19:49 UTC, Laeeth Isharc wrote:
Hi Benjamin
Would you be able to give a little more colour on what the
limits are of interoperability for C++ with DMD master or
release ? As I understand it destructors and constructors
don't work, and obviously it will get tricky passing structures
and classes from C++ libraries not ported to D.
So, things that work really well are classes. Given that you
construct them in the their "native environment". E.g. create D
objects in D land and C++ objects in C++ land. I usually use
factory methods for this. Manually destroying objects also works
if you add some kind of "Destory" method (can be virtual, but
doesn't have to be) to your class which simply does a "delete
this" or similar. The only problems with interfacing C++ classes
to D is if they have a virtual destructor. But there is a easy
workaround like so:
C++:
class SomeBaseClass
{
public:
virtual ~SomeBaseClass();
virtual void SomeVirtualFunc();
}
D:
extern(C++) class SomeBaseClass
{
protected:
abstract void __cppDtor(); // don't call
public:
void SomeVirtualFunc(); // default virtual in D
}
Free functions, static functions, non virtual functions all work
flawlessly.
I recommend that you create your own pointer type on the C++
side, e.g. DPtr which calls the GC.addRoot / GC.removeRoot
methods of the D's gc interface in the apropriate places in case
you want to pass D objects into C++ space. If you have a
reference counting concept on the c++ side its also possible to
build a small proxy object which does reference counting in c++
and calls GC.removeRoot when the last reference count drops.
If you want to bind more complex types, e.g. c++ templates you
can either declare them extern(C++) in D and the compiler will do
the correct mangling, or what I did to make them fully functional
on both sides: I did a full implementation both in D and C++. The
implementation ensures that the data layout is exactly the same
for D and C++ but other than that the implementation is
duplicated on both sides and even different in some cases. It
still possible to pass this complex type from C++ to D because
the data layout is the same. I did this for a custom hash map
implementation and passing it around works flawlessly (by
reference)
I had another complicated case where I wanted a complex value
type that is implemented in C++ on the D side. It had a lot of
members which types don't have a equivalent in D, so I did the
following.
extern(C++)
{
void constructComplexStruct(ComplexStruct* self);
void destructComplexStruct(ComplexStruct* self);
}
struct DefaultCtor {}; // helper type
alias defaultCtor = DefaultCtor();
struct ComplexStruct
{
@disable this();
@disable this(this);
this(DefaultCtor)
{
constructComplexStruct();
}
~this()
{
destructComplexStruct(~this);
}
extern(C++) void SomeMethodOfComplexStruct();
private:
// must be sizeof(ComplexStruct) from c++, use unittest to
ensure!
void[288] m_data;
}
constructComplexStruct and destructComplexStruct just do a
placement new / call the C++ dtor.
Usage then works like this:
void someDFunc()
{
ComplexStruct myStruct(defaultCtor); // constructed using C++
default ctor
myStruct.SomeMethodOfComplexStruct(); // call C++ implemented
method
// destructed using C++ dtor
}
So far I haven't found a situation where I couldn't make it work
the way I wanted. Its just some work to write the D headers for
the C++ classes and vise versa, because you have to duplicate
everything once more. An automated tool for this would be nice,
but unfotunately there is currently none.
Kind Regards
Benjamin Thaut
Re: Status of Win32 C++ interop
On Friday, 4 September 2015 at 08:53:27 UTC, Szymon Gatner wrote: Hi, what is the current status of: - Win x86/32bit/coff32 interop with C++? - improvements for general C++ interop that were suppose to come with 2.068 If you use either the -m64 or -mscoff32 interop should be pretty good. I'm currently using it heavily and its working quite nicely.
Re: Status of Win32 C++ interop
On Friday, 4 September 2015 at 09:07:39 UTC, Szymon Gatner wrote: What about 32bit phobos? Last time I checked (2.067) only x64 was distributed. You have to compile it yourself. Use the win64 makefile and replace the arch=64 with arch=32mscoff. For more details see here: http://www.digitalmars.com/d/archives/digitalmars/D/learn/How_to_get_32mscoff_libraries_for_phobos_73980.html
Re: Status of Win32 C++ interop
On Friday, 4 September 2015 at 10:04:48 UTC, Szymon Gatner wrote: On Friday, 4 September 2015 at 09:27:14 UTC, Benjamin Thaut wrote: On Friday, 4 September 2015 at 09:07:39 UTC, Szymon Gatner wrote: What about 32bit phobos? Last time I checked (2.067) only x64 was distributed. You have to compile it yourself. Use the win64 makefile and replace the arch=64 with arch=32mscoff. For more details see here: http://www.digitalmars.com/d/archives/digitalmars/D/learn/How_to_get_32mscoff_libraries_for_phobos_73980.html Ah so that didn't change. Did you try it? Do you run hybrid C++/D apps on Win (whether 32 or 64)?. Asking because last time I tried it (Win x64 tho) writeln() call from D side crashed app because stdio wasn't properly initialized even tho rt_init() was successful. I am running hybrid D/C++ apps. I found it to work best when you give D the control over the main method, e.g. the program entry point should be in D land. Then simply call a C++ function from there to initialize your c++ stuff. I'm currently even running hybrid C++/D apps with dlls. E.g. multiple D dlls + multiple C++ dlls loaded by a c++ main program. But to do that I have heavy compiler + runtime modifications which are not ready yet to do a PR for them.
Re: AMD Windows 7
On Friday, 12 June 2015 at 14:39:55 UTC, Chris wrote: I wish it were an error in the Python code so I could fix it, but it works on all other machines (at least those with Intel). It's only on the HP625 with AMD that this error occurs. Another DLL (which isn't mine) also failed to load, although with a different error message. It might be just this particular model, or AMD, I dunno. I couldn't find anything about it on the internet. Atm I'm using dmd 2.067.1, maybe compiling with GDC or LDC will fix it. That sounds more like its the software installed on the machine and not the processor. Are you sure that all microsoft runtime libraries are installed? If you did use the vs 2012 linker to create the D-dll you need to install this redistributable package: http://www.microsoft.com/en-US/download/details.aspx?id=30679 Did you run Depends on the dll? Usually depends will tell you why the dll does not load: http://www.dependencywalker.com/ Kind Regards Benjamin Thaut
Re: Accessing x86 Performance Counters
On Wednesday, 13 May 2015 at 08:53:10 UTC, Kagamin wrote: There was no word about windows, but process explorer shows page faults and cycles per process from unprivileged account, so I guess, this information is available through some API. Not sure is such system-wide statistics is available too. He is talking about the performance counters build into intel x86 processors (at least thats what I understood) thats something completely different from page faults and cycles per process. And as it is processor specific there is _no_ general api for it.
Re: Accessing x86 Performance Counters
On Wednesday, 13 May 2015 at 03:38:33 UTC, Maxime Chevalier-Boisvert wrote: I was wondering if anyone has written D code to access the x86 performance counters, to get information such as the number of cache misses and cycle count. I considered doing that at one point. So I looked for resources on the topic and it turns out that you need a kernel mode executable to be able to read the performance counters. Luckly there is a open source driver for windows which gives you some API to access the counters from user mode executables. Unfortunately you need to either switch your windows into a unsafe mode to allow for loading unsigned drivers or you need to somehow get a certificate to sign the driver (these are quite expensive). At that point I stopped looking into this, because both of these options weren't viable for my use case. Once I find some time I could dig up the resources I found if you are interested.
Re: C++ interface problem
On Wednesday, 29 April 2015 at 19:04:11 UTC, extrawurst wrote: On Wednesday, 29 April 2015 at 13:55:46 UTC, Benjamin Thaut wrote: On Monday, 27 April 2015 at 21:19:02 UTC, extrawurst wrote: here is the shortened version of the returned class CSteamID: https://gist.github.com/Extrawurst/936f56ceaa87cf287257 this is the shortened interface (no destructors in the rest of the code either): https://gist.github.com/Extrawurst/b20dc5ab84132ecab30d the method `GetFriendByIndex` is the one crashing on win32. I assume that's because CSteamID is returned by value. Are you defining CSteamID in D as a struct? If not you have to because only structs can be returned by value. The next problem is that CSteamID is 64bits wide, this might be a problem as it can not be returned in a single register. You could try changeing the definition of GetFriendByIndex on the D side to ulong GetFriendByIndex(...) and reinterpret the ulong on the D side. If that does not work however you are most likely out of luck because the way your c++ library returns a value type 32-bit is not compatible with what dmd expects. Do you have debug symbols for the third party c++ library? Can you step into the virtual function call to actually see if it ends up in the correct function on the c++ side? Kind Regards Benjamin Thaut Seems i am out of luck. I tried all that. The Steamworks SDK is closed source without debugging symbols. so it wont work.. too bad, this library would have been a good example case of seamless c++-interfacing from D... Did you try windows 64-bit? Calling conventions on 64-bit windows are better standardized.
Re: C++ interface problem
On Monday, 27 April 2015 at 21:19:02 UTC, extrawurst wrote: here is the shortened version of the returned class CSteamID: https://gist.github.com/Extrawurst/936f56ceaa87cf287257 this is the shortened interface (no destructors in the rest of the code either): https://gist.github.com/Extrawurst/b20dc5ab84132ecab30d the method `GetFriendByIndex` is the one crashing on win32. I assume that's because CSteamID is returned by value. Are you defining CSteamID in D as a struct? If not you have to because only structs can be returned by value. The next problem is that CSteamID is 64bits wide, this might be a problem as it can not be returned in a single register. You could try changeing the definition of GetFriendByIndex on the D side to ulong GetFriendByIndex(...) and reinterpret the ulong on the D side. If that does not work however you are most likely out of luck because the way your c++ library returns a value type 32-bit is not compatible with what dmd expects. Do you have debug symbols for the third party c++ library? Can you step into the virtual function call to actually see if it ends up in the correct function on the c++ side? Kind Regards Benjamin Thaut
Re: C++ interface problem
On Monday, 27 April 2015 at 13:08:33 UTC, extrawurst wrote:
Don't ask me about the compiler, like stated above I have no
control over the binaries, it is proprietary.
Thats bad to start with.
the C++ class basically is:
```
class S
{
union SteamID_t
{
struct SteamIDComponent_t
{
uint32 m_unAccountID : 32;
unsigned intm_unAccountInstance : 20;
unsigned intm_EAccountType : 4;
EUniverse m_EUniverse : 8;
} m_comp;
uint64 m_unAll64Bits;
} m_steamid;
}
```
Where is the fuction declaratiosn for bar? If bar is not virtual
you can not use a extern(C++) Interface. If bar is non-virtual
you have to use a extern(C++) class.
Re: C++ interface problem
On Monday, 27 April 2015 at 11:00:23 UTC, extrawurst wrote: Thought about that too and tried uint aswell. does not work either.. Please post the c++ declarations as well. Which c++ compiler do you use for win32? (dmc or msvc) Kind Regards Benjamin
Re: C++ interface problem
Am 27.04.2015 um 17:16 schrieb extrawurst:
On Monday, 27 April 2015 at 13:14:21 UTC, Benjamin Thaut wrote:
On Monday, 27 April 2015 at 13:08:33 UTC, extrawurst wrote:
Don't ask me about the compiler, like stated above I have no control
over the binaries, it is proprietary.
Thats bad to start with.
the C++ class basically is:
```
class S
{
union SteamID_t
{
struct SteamIDComponent_t
{
uint32m_unAccountID : 32;
unsigned intm_unAccountInstance : 20;
unsigned intm_EAccountType : 4;
EUniversem_EUniverse : 8;
} m_comp;
uint64 m_unAll64Bits;
} m_steamid;
}
```
Where is the fuction declaratiosn for bar? If bar is not virtual you
can not use a extern(C++) Interface. If bar is non-virtual you have to
use a extern(C++) class.
of course it is all virtual. it is a c++-interface. and everything works
fine under osx, that would not be the case otherwise, right ?
It depends on the compiler, I don't know the vtbl layout on OSX. Does
the class have a virtual destructor? If you would post a bit more of S
declaration I wouldn't have to guess into the blue. Not knowing the
compiler your third party library was compiled with doesn't really help
either.
Kind Regards
Benjamin
Re: Should this work: export extern(C) auto ...
On Thursday, 19 March 2015 at 12:58:42 UTC, Robert M. Münch wrote: On 2015-03-18 21:50:39 +, Adam D. Ruppe said: It will not work because a function with an auto return value is actually a template, and unused templates won't be put into a dll. Ok, that makes it clear. Thanks. Generally don't expect to many things to work with DLLs at the moment. Generally speaking only exporting global functions works. Don't try to export classes / structs or anything fancy.
Re: Seems core.thread.Fiber is broken dmd windows 64-bit build
On Monday, 9 March 2015 at 14:39:34 UTC, Carl Sturtivant wrote: Please confirm or deny that this is a real bug, as its getting in the way of a genuine project. How should I proceed? I'm working on a 64-bit Windows port of the following. http://www.cs.arizona.edu/icon/ Here's the 32-bit Windows port. http://www.cs.arizona.edu/icon/v95w.htm Among other things I'm using D to implement Icon's coexpressions portably using core.thread.Fiber which works fine at 32 bits. They are implemented using pthreads on other platforms, though historically there used to be a platform dependent assembly code context switch, close to the way that core.thread.Fiber is implemented. The Fiber implementation is 20 times faster at 32 bits. I can reproduce this issue with dmd 2.066.1, please go forward and open a issue on https://issues.dlang.org/ Kind Regards Benjamin Thaut
Re: Initializing defaults based on type.
On Friday, 6 March 2015 at 15:36:47 UTC, anon wrote:
Hi,
I can't figure this out.
struct Pair(T)
{
T x;
T y;
alias x c;
alias y r;
}
What would like is that the x and y to be initialized to
different values depending on type eg:
struct Container
{
Pair!double sample1; // This will initialize sample1 with 0
for both x and y
Pair!intsample2; // This will initialize sample2 with 1
for both x and y
}
currently I'm using two different struct one with doubles and
the other with ints and initialized with default value but was
wondering if its possible to do the above.
anon
struct Pair(T)
{
static if(is(T == int))
enum int initValue = 1;
else
enum T initValue = 0;
T x = initValue;
T y = initValue;
alias x c;
alias y r;
}
Re: Int to float?
Am 05.03.2015 um 21:00 schrieb Taylor Hillegeist: How to I cast a Int to float without changing its binary representation? int someValue = 5; float sameBinary = *(cast(float*)cast(void*)someValue);
Re: C++ calling convention only
Am 21.02.2015 um 11:30 schrieb Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net:
For C++, you can just use the newly added namespace support:
extern(C++, nobody.uses.this.name) myFunc() {}
Thats actually a good idea. Thanks.
Re: C++ calling convention only
On Thursday, 19 February 2015 at 21:34:57 UTC, John Colvin wrote: I would duplicate the declaration, once without extern(C++), once with, the use the .mangleof from the 1st to set the mangle of the 2nd with pragma(mangle Yes that would work. But using pragma(mangle) feels so hacky...
Re: C++ calling convention only
On Friday, 20 February 2015 at 13:00:39 UTC, John Colvin wrote: I agree. Wrap it in a mixin / mixin template? Why do you need this? Presumably it'll be hidden in the depths of some library / bindings where beauty is somewhat optional? Using the .mangleof from an extern(D) function should mean it's robust. Well the use case is creating a function which sole purpose it is to create a function pointer from it and pass it to C++. If it recieves C++ mangling however I have to pay attention that it does not conflict with any other C++ symbols. The same goes for extern(C). Sometimes you want to create functions with a C calling convetion so you can create a function pointer from it. With extern(C) its even a bigger problem because the C mangling conflicts a lot easier.
C++ calling convention only
Is it possible to declare a function in D which gets the C++ calling convetion but not the C++ mangling? Kind Regards Benjamin Thaut
Re: @nogc with assoc array
Am 16.02.2015 um 18:55 schrieb Jonathan Marler:
Why is the 'in' operator nogc but the index operator is not?
void main() @nogc
{
int[int] a;
auto v = 0 in a; // OK
auto w = a[0]; // Error: indexing an associative
// array in @nogc function main may
// cause GC allocation
}
Because the index operator throws a OutOfRange exception and throwing
exceptions allocates, maybe?
Re: What is the Correct way to Malloc in @nogc section?
Hi, you can also take a look at my implementation: https://github.com/Ingrater/druntime/blob/master/src/core/allocator.d Look at AllocatorNew and AllocatorDelete Especially important is, that you correctly handle the constructor throwing an exception. You have to catch that exception in your new function, release the memory and rethrow. Kind Regards Benjamin Thaut
Binding C++ value types
When binding C++ value types you might want to use them by placing them on the D-Stack. This however seems to be not supported as the mangling for the constructor is completely wrong. Is this supposed to work? Kind Regards Benjamin Thaut
Re: windows wininet library
Am 01.02.2015 um 17:15 schrieb ketmar: On Sun, 01 Feb 2015 16:07:58 +, John Chapman wrote: On Sunday, 1 February 2015 at 08:37:23 UTC, ketmar wrote: seems that my idea of using D to write a simple windows utility was very wrong. ok, another attempt to use D for our windows developement has failed. i'm in no way can sell manual .def creation to our team -- they will make fun of me, showing how their Visual C can compile this code without any troubles and external utilities... It's easier to run coffimplib on the lib files from the Windows SDK. sorry if i'm rude, i really appreciate your advice. i messed myself thinking that this is another thread in general NG. The Windows SDK can be downloaded seperately from visual studio: https://msdn.microsoft.com/en-us/windows/desktop/ff851942.aspx They are also backwards compatible, so the latest one should work on XP. But you can also just use the oldest one available to make sure it still works on your machine.
Re: What is @return?
On Thursday, 29 January 2015 at 11:50:29 UTC, FG wrote:
@property auto info() @safe @nothrow @pure @return const {
return this; }
It is mesmerizing... (@ _ @)
And soon its gong to look like this:
export @property auto info() @safe @nothrow @pure @return const {
return this; }
Read from stdin without blocking
I want to read all input from stdin without blocking. That means I simply want to read the remaining input from stdin. All ways I tried so far always end up in me waiting for the user to enter additional input, which is not what I want. I tried around a lot with D's files / streams but couldn't find any way to do that. Any help is appreciated. Kind Regards Benjamin Thaut
vibe.d mongodb connections
I'm currently trying around with vibe.d and I'm confused about the
MongoDB example:
import vibe.d;
MongoClient client;
void test()
{
auto coll = client.getCollection(test.collection);
foreach (doc; coll.find([name: Peter]))
logInfo(Found entry: %s, doc.toJson());
}
shared static this()
{
client = connectMongoDB(127.0.0.1);
}
client is TLS but is initialized within a shared module consturctor,
meaning that only the main thread will have a initialized db-connection.
http://vibed.org/api/vibe.db.mongo.mongo/connectMongoDB says: Thus, the
MongoClient instance can - and should - be shared among all fibers in a
thread by storing in in a thread local variable.
So wouldn't it make more sense that the MongoDB example initializes the
client variable in a static this() instead of a shared static this() ?
Kind Regards
Benjamin Thaut
Re: Example usage of the core.sync classes
Am 02.01.2015 um 19:45 schrieb Vlad Levenfeld: My personal favorite method is to use the primitives in core.atomic with a double or triple buffer. To double buffer, keep two buffers in an array (data[][] or something) and an integer index that points to the active buffer, then use atomicStore to update active buffer index when you want to swap. Triple buffering can improve runtime performance at the cost of more memory, and in this case you will need two indices and two swap methods, one for the producer and another for the consumer. I use cas with a timed sleep to update the indices in this case. Take it with a grain of salt, I'm far from a pro, but this has worked well for me in the past. I can post some example code if you need it. I have to agree with Vlad here. The usual way is to do double buffering. So you have two buffers which hold all the data that the physics simulation passes to the game logic. While the physics simulation is computing the next frame, the game logic can use the results from the last frame. The only point where sinchronisation is neccessary is when swapping the buffers. You have to ensure that both the game logic and the physics thread are done with their current buffer and then sawp them. The only downside of this approach is, that you will get a small delay (usually the time taken for 1 frame) into the data you pass this way. Sometimes this approach is called the exractor pattern. I use it to pass data from the game simulation to the renderer, so the renderer can render in paralell with the game simulation computing the next frame. You can find a example of my double buffered solution here: https://github.com/Ingrater/Spacecraft/blob/master/game/sources/renderer/extractor.d I had tripple buffering up and running at some point, but I went back to double buffering, because tripple buffering can cause micro lags and you don't want that. Kind Regards Benjamin Thaut
vibe.d + dub dynamic library
Is it possible to get dub to build vibe.d into a dynamic library? Or is it at least possible to make dub link against the shared version of phobos? I found this blog post about dynamic linktimes, unfortunately it does not describe how to actually make dub use the dynamic version of phobos. https://code.dawg.eu/reducing-vibed-turnaround-time-part-1-faster-linking.html (I'm on linux) Kind Regards Benjamin Thaut
Re: How do I write __simd(void16*, void16) ?
Am 08.10.2014 21:12, schrieb Etienne: On 2014-10-08 3:04 PM, Benjamin Thaut wrote: I strongly advise to not use core.simd at this point. It is in a horribly broken state and generates code that is far from efficient. If I think I'll have to re-write the xmmintrin.h functions I need as string mixins to inline the assembly. Is that supposed to be compatible with LDC/GDC anyways? I know that GDC stopped supporting D style inline asm a while ago. If you need inline asm with GDC you have to use the gcc style inline assembly. I don't know about ldc though. But generally you want to use the official intrinsics with gdc and ldc because they won't perform any optimizations on inline assembly. Kind Regards Benjamin Thaut
Re: How do I write __simd(void16*, void16) ?
Am 09.10.2014 21:04, schrieb Etienne: On 2014-10-09 2:32 PM, Benjamin Thaut wrote: I know that GDC stopped supporting D style inline asm a while ago. If you need inline asm with GDC you have to use the gcc style inline assembly. I don't know about ldc though. But generally you want to use the official intrinsics with gdc and ldc because they won't perform any optimizations on inline assembly. Kind Regards Benjamin Thaut Any idea where I can find the headers in D for it? I think a good starting point would be Manu's std.simd module. I don't know if he is still working on it, but a old version can be found here: https://github.com/TurkeyMan/simd/blob/master/std/simd.d If you have further questions you might be well advised to ask him: turkey...@gmail.com You can also find the druntime versions of ldc and gdc on github. For example: https://github.com/ldc-developers/druntime/blob/ldc/src/ldc/simd.di https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/gcc/builtins.d Unforunately the gcc.buildints module seems to be generated during compilation of gdc, so you might want to get a binary version or compile it yourself to see the module. Kind Regards Benjamin Thaut
Re: How do I write __simd(void16*, void16) ?
Am 08.10.2014 20:56, schrieb Etienne: I can't seem to find this function anywhere: __simd(void16*, void16) The mangling seems to go through to dmd's glue.lib This is for SSE2 operations: MOVDQU = void _mm_storeu_si128 ( __m128i *p, __m128i a) MOVDQU = __m128i _mm_loadu_si128 ( __m128i *p) Would I have to write this with ASM? I strongly advise to not use core.simd at this point. It is in a horribly broken state and generates code that is far from efficient. If you use core.simd your code will be slower then if you use normal floating point math. Also afaik core.simd is currently only supported by dmd meaning that yuo have to rewrite the code in case you want to go to ldc or gdc. If you need simd with dmd, write inline assembly. If you need simd with the other two compilers, use the gcc intrinsics, they work on both compilers. Kind Regards Benjamin Thaut
Re: Programming a Game in D? :D
Am 22.05.2014 17:39, schrieb David: Hey, I'm really new to D, and pretty new to programming overall too, But I want to make a 3d Game, (just sth. small). I really like D and want to do it in D, but in the Internet there is no shit about programming a game in D ^^ Is there any engine written in D? For example the CryEngine is for C++, so I would have to write a wrapper? So, how do I write a wrapper? I would need a wrapper for DirectX too right? Are there any wrappers ore Engines for D i can use? btw. I know I dont write that in 1 day ^^ Are there any tutorials or sth. on Programming a Game in D? S I just wanna come as far to have a little Cube where i can run around on with a few phisics :) so just the startup to load a world and so on Thanks in advance :) And sry my english sucks :D I wrote a game in D, and its doable. See http://3d.benjamin-thaut.de/?p=20 Its even on github: https://github.com/Ingrater/Spacecraft Kind Regards Benjamin Thaut
