Re: Status of Win32 C++ interop
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.
Status of Win32 C++ interop
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
Re: Status of Win32 C++ interop
On Friday, 4 September 2015 at 08:58:41 UTC, Benjamin Thaut wrote: 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. What about 32bit phobos? Last time I checked (2.067) only x64 was distributed.
Re: Status of Win32 C++ interop
On Friday, 4 September 2015 at 14:18:40 UTC, Benjamin Thaut wrote: 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. Hmm that is very good to hear, as is promising. In the mean time I tired making tiny Win x64 C++/D app as described by A.Ruppe in his book (I did that also when it was released and stdio was crashing apps) but now using phobos64.lib from 2.068 distribution does not even link properly with VC2015. Oh well, not just yet I suppose. Thanks for your assistance!
Re: Status of Win32 C++ interop
On Friday, 4 September 2015 at 16:26:51 UTC, Kagamin wrote: On Friday, 4 September 2015 at 15:43:44 UTC, Szymon Gatner wrote: but now using phobos64.lib from 2.068 distribution does not even link properly with VC2015. That's https://issues.dlang.org/show_bug.cgi?id=14849 yup, that looks like it
Re: Interlocked (compare) exchange
On Friday, 17 April 2015 at 11:00:40 UTC, rumbu wrote: On Friday, 17 April 2015 at 10:36:33 UTC, Szymon Gatner wrote: Hi, are there equivalents of Interlocked.Exchange [1] and Interlocked.CompareExchange [2] in D? I can't find it in teh docs? [1] https://msdn.microsoft.com/en-us/library/f2090ex9(v=vs.110).aspx [2] https://msdn.microsoft.com/en-us/library/h7etff8w(v=vs.110).aspx All D equivalents of Interlocked class methods: https://github.com/rumbu13/sharp/blob/master/src/system/threading/package.d Ah, thanks to all you guys!
Interlocked (compare) exchange
Hi, are there equivalents of Interlocked.Exchange [1] and Interlocked.CompareExchange [2] in D? I can't find it in teh docs? [1] https://msdn.microsoft.com/en-us/library/f2090ex9(v=vs.110).aspx [2] https://msdn.microsoft.com/en-us/library/h7etff8w(v=vs.110).aspx
Re: UFCS and overloading
On Tuesday, 7 April 2015 at 14:46:52 UTC, cym13 wrote:
EDIT: mis-formatted previous snippet
import std.algorithm, std.stdio, std.range, std.conv;
void main()
{
stdin
.byLine
.filter!(s = !s.empty s.front != '#’) // Filter
with this lambda function
.map!(s = s.to!double) // Map the strings to doubles
.array // Sorting needs random access
.sort!((a, b) = a b) // Another lambda
.take(10) // Applyable to any range
.writeln;
}
Yup, I get that, still does not explain why UFCS can't extend
overload set. Especially if there would be no conflict wrt to
overload of method vs free function.
Re: UFCS and overloading
On Monday, 6 April 2015 at 17:53:13 UTC, Steven Schveighoffer
wrote:
On 4/6/15 12:23 PM, Szymon Gatner wrote:
Hi,
I am surprised that this doesn't work:
class Foo
{
void bar(string) {}
}
void bar(Foo foo, int i)
{
}
auto foo = new Foo();
foo.bar(123); // === error
causing compilation error:
main.d(24): Error: function main.Foo.bar (string _param_0) is
not
callable using argument types (int)
does UFCS now work with method overloading? I know it is not a
syntax
error because changing the name of int version of bar to bar2
and
calling foo.bar2(123) works fine.
You can't do this. UFCS cannot add overloads, it can only add
whole overload sets (if not already present).
-Steve
Why is that? The use case is to provide a set of convenience
extension methods to a basic interface. Say, given:
interface Subject
{
void add(SomeInterface obj);
}
// and then
void add(Subject a, Type1 v1)
{
a.add(convertToSomeInterface(v1));
}
void add(Subject a, Type2 v2)
{
a.add(convertToSomeInterface(v2));
}
this way client can just implement Subject interface and still
use it with types Type1 and Type2. C# allows that, why D does not?
UFCS and overloading
Hi,
I am surprised that this doesn't work:
class Foo
{
void bar(string) {}
}
void bar(Foo foo, int i)
{
}
auto foo = new Foo();
foo.bar(123); // === error
causing compilation error:
main.d(24): Error: function main.Foo.bar (string _param_0) is not
callable using argument types (int)
does UFCS now work with method overloading? I know it is not a
syntax error because changing the name of int version of bar to
bar2 and calling foo.bar2(123) works fine.
dlib help
Hi, I am hoping to use dlib for image manipulation utility program but I can't find any documentation for it. Am I missing something? Any examples at least? (also: dlib from dub does not compile with wcslen import conflict., I managed to find a fix on github but bup packages need updating)
Re: Implementing SmartPtr - compiler bug?
On Monday, 27 October 2014 at 18:42:11 UTC, Marc Schütz wrote: On Monday, 27 October 2014 at 16:58:56 UTC, Szymon Gatner wrote: On Monday, 27 October 2014 at 14:04:53 UTC, Marc Schütz wrote: On Monday, 27 October 2014 at 12:40:17 UTC, Shachar Shemesh wrote: On 27/10/14 11:31, Szymon Gatner wrote: Right, sorry. Tho I admit I made assumptions since that was not the full code. I've opened a bug. It has a fully contained sample (that does not, in fact, implement smartptr). https://issues.dlang.org/show_bug.cgi?id=13661 Strictly speaking, your opAssign is wrong, because it doesn't swap source and destination, as it should. This doesn't matter here, but it would for a smartptr. However, that opAssign isn't even called is certainly a bug. Why would opAssign() swap things? This is necessary to make assignment exception safe (in the general case). It's known as the copy-and-swap idiom in C++. Here it's described in the D spec: http://dlang.org/struct#assign-overload For your example code it's not necessary, because there can never be exceptions, but depending on what the smart pointer does, it might throw in one of its members' opAssign, which could lead to a partially copied object. Copy-and-swap in C++ as the name implies requires 1) copy first - a temporary copy-constructed object on created on the stack then 2) trivial/nothrow swap with that temporary. Your suggestion sounded like source and destination of opAssign() were suppose to be swapped. In C++ this is sometimes used when move-assigning.
Re: Implementing SmartPtr - compiler bug?
On Monday, 27 October 2014 at 07:31:34 UTC, Shachar Shemesh wrote: For reasons I won't go into (but should be fairly obvious), I am trying to write code that does not rely on the garbage collector. As such, I'm using reference counting structs allocated on a pool. To keep things sane, I'm trying to use RAII semantics, and to that end, a smart pointer that calls incref and decref when appropriate. The SmartPtr struct implements this(T*), this(SmartPtr), this(this), ~this(), opAssign(SmartPtr), opAssign(ref SmartPtr) and opAssign(T*). To the best of my understanding this should be enough to catch all relevant cases. All works fine except one case: Foo foo; SmartPtr!Foo[4] array; array[0] = foo; assert(foo.refcount == 1); array = array.init; assert(foo.refcount == 0, This assert fails); I am compiling this on dmd v2.065 Switching the init line to array[] = SmartPtr!Foo.init makes the second assert pass. To the best of my understanding, array = array.init should always be equivalent to array[] = typeof(array[0]).init for static arrays. Am I missing something? Is this a compiler bug? Thanks, Shachar You have created dynamic array of SmartPtrs. In that case they now live on GS's heap and destructor calls are no longer deterministic (and in fact are not guaranteed at all). That is the very first things that gets C++ programmers coming to D (happened to me too). RAII does not work in D. At least not how C++ would expect it to.
Re: Implementing SmartPtr - compiler bug?
On Monday, 27 October 2014 at 09:21:14 UTC, ketmar via Digitalmars-d-learn wrote: On Mon, 27 Oct 2014 09:11:33 + Szymon Gatner via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: You have created dynamic array of SmartPtrs. nope. it's stack-allocated array. Right, sorry. Tho I admit I made assumptions since that was not the full code.
Re: Implementing SmartPtr - compiler bug?
On Monday, 27 October 2014 at 14:04:53 UTC, Marc Schütz wrote: On Monday, 27 October 2014 at 12:40:17 UTC, Shachar Shemesh wrote: On 27/10/14 11:31, Szymon Gatner wrote: Right, sorry. Tho I admit I made assumptions since that was not the full code. I've opened a bug. It has a fully contained sample (that does not, in fact, implement smartptr). https://issues.dlang.org/show_bug.cgi?id=13661 Strictly speaking, your opAssign is wrong, because it doesn't swap source and destination, as it should. This doesn't matter here, but it would for a smartptr. However, that opAssign isn't even called is certainly a bug. Why would opAssign() swap things?
Re: Global const variables
On Tuesday, 21 October 2014 at 08:48:09 UTC, safety0ff wrote:
On Tuesday, 21 October 2014 at 08:25:07 UTC, bearophile wrote:
Minas Mina:
Aren't pure functions supposed to return the same result
every time? If yes, it is correct to not accept it.
But how can main() not be pure? Or, how can't the 'a' array be
immutable?
Bye,
bearophile
There can exist a mutable reference to a's underlying memory:
const int[] a;
int[] b;
static this()
{
b = [1];
a = b;
}
Ant this code works? What is the point of const then if you can
assign it to mutable slice?
Re: COFF on Win32 how to try?
On Saturday, 11 October 2014 at 13:35:55 UTC, Rainer Schuetze wrote: Yes, DMD git HEAD is required. Getting this when trying to build all with Digger: std\uri.d(872): Deprecation: alias object.clear is deprecated - Please use destroy instead. std\uri.d(1166): Deprecation: alias object.clear is deprecated - Please use destroy instead. std\concurrency.d(1352): Error: function expected before (), not currSystemTick() of type TickDuration std\concurrency.d(1354): Error: function expected before (), not currSystemTick() of type TickDuration std\concurrency.d(1348): Error: function std.concurrency.FiberScheduler.FiberCondition.wait no return exp; or assert(0); at end of function std\concurrency.d(1395): Error: function expected before (), not this.m_fibers[this.m_pos].state() of type State std\concurrency.d(1971): Error: function expected before (), not currSystemTick() of type TickDuration std\concurrency.d(2019): Error: function expected before (), not currSystemTick() of type TickDuration std\concurrency.d(1822): Error: function std.concurrency.MessageBox.get!(Duration, bool delegate(Tid origin, CurlMessage!(immutable(ubyte)[]) _data) @system, bool delegate(Tid origin, CurlMessage!bool f) @system).get no return exp; or assert(0); at end of function std\concurrency.d(811): Error: template instance std.concurrency.MessageBox.get!(Duration, bool delegate(Tid origin, CurlMessage!(immutable(ubyte)[]) _data) @system, bool delegate(Tid origin, CurlMessage!bool f) @system) error instantiating std\net\curl.d(1185):instantiated from here: receiveTimeout!(bool delegate(Tid origin, CurlMessage!(immutable(ubyte)[]) _data) @system, bool delegate(Tid origin, CurlMessage!bool f) @system) std\internal\math\biguintx86.d(120): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d-mixin-141(141): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(147): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d-mixin-158(158): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(163): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(120): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d-mixin-141(141): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(147): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d-mixin-158(158): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(163): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(225): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(235): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(236): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(225): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(235): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(236): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(120): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d-mixin-141(141): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(147): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d-mixin-158(158): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(163): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(120): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d-mixin-141(141): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(147): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d-mixin-158(158): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(163): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does
Re: COFF on Win32 how to try?
On Saturday, 11 October 2014 at 13:35:55 UTC, Rainer Schuetze wrote: Yes, DMD git HEAD is required. Getting this when trying to build all with Digger: std\uri.d(872): Deprecation: alias object.clear is deprecated - Please use destroy instead. std\uri.d(1166): Deprecation: alias object.clear is deprecated - Please use destroy instead. std\concurrency.d(1352): Error: function expected before (), not currSystemTick() of type TickDuration std\concurrency.d(1354): Error: function expected before (), not currSystemTick() of type TickDuration std\concurrency.d(1348): Error: function std.concurrency.FiberScheduler.FiberCondition.wait no return exp; or assert(0); at end of function std\concurrency.d(1395): Error: function expected before (), not this.m_fibers[this.m_pos].state() of type State std\concurrency.d(1971): Error: function expected before (), not currSystemTick() of type TickDuration std\concurrency.d(2019): Error: function expected before (), not currSystemTick() of type TickDuration std\concurrency.d(1822): Error: function std.concurrency.MessageBox.get!(Duration, bool delegate(Tid origin, CurlMessage!(immutable(ubyte)[]) _data) @system, bool delegate(Tid origin, CurlMessage!bool f) @system).get no return exp; or assert(0); at end of function std\concurrency.d(811): Error: template instance std.concurrency.MessageBox.get!(Duration, bool delegate(Tid origin, CurlMessage!(immutable(ubyte)[]) _data) @system, bool delegate(Tid origin, CurlMessage!bool f) @system) error instantiating std\net\curl.d(1185):instantiated from here: receiveTimeout!(bool delegate(Tid origin, CurlMessage!(immutable(ubyte)[]) _data) @system, bool delegate(Tid origin, CurlMessage!bool f) @system) std\internal\math\biguintx86.d(120): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d-mixin-141(141): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(147): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d-mixin-158(158): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(163): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(120): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d-mixin-141(141): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(147): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d-mixin-158(158): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(163): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(225): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(235): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(236): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(225): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(235): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(236): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(120): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d-mixin-141(141): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(147): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d-mixin-158(158): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(163): Deprecation: asm statement is assumed to be impure - mark it with 'pure' if it is not std\internal\math\biguintx86.d(120): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d-mixin-141(141): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(147): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d-mixin-158(158): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does not std\internal\math\biguintx86.d(163): Deprecation: asm statement is assumed to throw - mark it with 'nothrow' if it does
Re: COFF on Win32 how to try?
On Saturday, 11 October 2014 at 09:21:18 UTC, Rainer Schuetze
wrote:
On 10.10.2014 20:44, Szymon Gatner wrote:
Hi, thanks for all the information.
I got Digger (pretty nice tool btw) and it pulled all
neccessary repos
from GitHub. As my understanding is that I should not be doing
Build
with Diggger I just opened Windows console, entered druntime
dir and typed:
You have to build dmd, so it should be good starting point to
succeed in building the full chain for win64: dmd, druntime and
win64.
You mean for Win32? Beacause that is what I am after.
d:\digger-1.0\repo\druntimemake -f win64.mak MODEL=32mscoff
CC=\%VCINSTALLDIR
%\bin\cl.exe\
and got:
dmd -c -o- -Isrc -Iimport -Hfimport\core\sync\barrier.di
src\core\sync\barrier.d
src\core\stdc\stdio.d(859): Error: found 'nothrow' when
expecting '{'
Ahh, I thought it would use a compiled dmd by default. You will
have to specify the path to dmd too:
make -f win64.mak MODEL=32mscoff
CC=\%VCINSTALLDIR%\bin\cl.exe\ DMD=../result/bin/dmd
The given dmd path is specific to building with digger (the
normal path is ../dmd/src/dmd). You'll have to update sc.ini
there, too.
So to build HEAD druntime and Phobos I also need HEAD DMD,
correct? Installation of 2.066 I have now is not sufficent?
COFF on Win32 how to try?
I would like to try recently merged COFF support on Win32 for a hybrid D/C++ application. Until now I tried that (hybridizing) only with DMD from the official installer and in x64 mode. My question is: how to try the same in 32 bits?
Re: COFF on Win32 how to try?
On Friday, 10 October 2014 at 16:14:56 UTC, Rainer Schuetze wrote:
On 10.10.2014 10:37, Szymon Gatner wrote:
I would like to try recently merged COFF support on Win32 for
a hybrid
D/C++ application.
Until now I tried that (hybridizing) only with DMD from the
official
installer and in x64 mode.
My question is: how to try the same in 32 bits?
You need a recent version of dmd, druntime and phobos from
github: https://github.com/D-Programming-Language
If you have never built these yourself, Digger might be of
great help: https://github.com/CyberShadow/Digger/releases. It
will also fetch these from github and download tools needed for
building. Digger doesn't know about COFF32 yet, though.
Then build druntime inside its directory:
make -f win64.mak MODEL=32mscoff
CC=\%VCINSTALLDIR%\bin\cl.exe\ target unittest
and phobos:
make -f win64.mak MODEL=32mscoff
CC=\%VCINSTALLDIR%\bin\cl.exe\
AR=\%VCINSTALLDIR%\bin\lib.exe\
Add a configuration section [Environment32mscoff] to your
sc.ini and add options matching these:
https://github.com/D-Programming-Language/dmd/blob/master/ini/windows/bin/sc.ini#L84
Building is done with option -m32mscoff instead of -m32/-m64.
Hi, thanks for all the information.
I got Digger (pretty nice tool btw) and it pulled all neccessary
repos from GitHub. As my understanding is that I should not be
doing Build with Diggger I just opened Windows console, entered
druntime dir and typed:
d:\digger-1.0\repo\druntimemake -f win64.mak MODEL=32mscoff
CC=\%VCINSTALLDIR
%\bin\cl.exe\
and got:
dmd -c -o- -Isrc -Iimport -Hfimport\core\sync\barrier.di
src\core\sync\barrier.d
src\core\stdc\stdio.d(859): Error: found 'nothrow' when expecting
'{'
src\core\stdc\stdio.d(861): Error: mismatched number of curly
brackets
src\core\stdc\stdio.d(862): Error: mismatched number of curly
brackets
src\core\stdc\stdio.d(863): Error: mismatched number of curly
brackets
src\core\stdc\stdio.d(864): Error: mismatched number of curly
brackets
src\core\stdc\stdio.d(865): Error: mismatched number of curly
brackets
src\core\stdc\stdio.d(866): Error: mismatched number of curly
brackets
src\core\stdc\stdio.d(867): Error: mismatched number of curly
brackets
src\core\stdc\stdio.d(871): Error: asm statements must end in ';'
src\core\stdc\stdio.d(874): Error: found 'private' instead of
statement
src\core\stdc\stdio.d(884): Error: no identifier for declarator
add
src\core\stdc\stdio.d(887): Error: no identifier for declarator
usDone
src\core\stdc\stdio.d(887): Error: Declaration expected, not ':'
src\core\stdc\stdio.d(894): Error: Declaration expected, not '('
src\core\stdc\stdio.d(896): Error: Declaration expected, not
'foreach'
src\core\stdc\stdio.d(896): Error: Declaration expected, not '0'
src\core\stdc\stdio.d(901): Error: no identifier for declarator
__fhnd_info[fd]
src\core\stdc\stdio.d(901): Error: Declaration expected, not '='
src\core\stdc\stdio.d(902): Error: Declaration expected, not
'return'
src\core\stdc\stdio.d(904): Error: unrecognized declaration
--- errorlevel 1
Re: Interop with C++ library - what toolchain do you use?
On Wednesday, 17 September 2014 at 22:28:44 UTC, Cliff wrote: So I am trying to use a C++ library with D. My toolchain is currently Visual Studio 2013 with Visual D, using the DMD compiler. When trying to link, I obviously ran into the OMF vs. COFF issue, which makes using the C++ library a bit of a trial to say the least (I played around with some lib format converters but perhaps unsurprisingly this led to somewhat unpredictable behavior.) I'd like to fix up my toolchain to avoid having this issue. For those of you who are on Windows and who do D and C++ interop, what toolchain have you had success with? Additionally, I have heard tell that D now allows calling C++ non-virtual class methods but I have not found documentation on how to make this work (how do I define the C++ class layout in D - I know how to do it for vtable entries but not non-virtual methods.) Pointers to docs or samples would be much appreciated. Thanks! I am using Visual Studio 2012 (in x64 bit mode that is). Binary D distribution also comes with phobos64.lib that C++ executable has to link. With VisualD plugin you can just add D static library project to the solution and the link C++ exe to it. It is very easy to make back-and-forth function calls between C++/D. I recommend Adam Ruppe's excellent D Cookbook Integration chapter on the details on how to expose this for cross-lang usage. It does not all work correctly tho. I reported my issues on learn subforum but didn't get much help. In short: it seems not everything in D run-time (Phobos) gets properly initialized even after successful rt_init() call. In my case simple call to writeln() causes a crash because stdout is not properly initialized on D'd side. Happy hybridizing!
Re: writeln() assertion failed in hybrid x64
On Thursday, 4 September 2014 at 20:57:41 UTC, Kagamin wrote: https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dmain2.d#L270 well, this sucks. Is there a way I can call module c-tors explicitly? I was under impression that D(dmd) was suppose to work with VisualC++ in x64bit mode.
Re: writeln() assertion failed in hybrid x64
On Thursday, 4 September 2014 at 15:25:59 UTC, ketmar via Digitalmars-d-learn wrote: On Thu, 04 Sep 2014 15:10:21 + Jorge A. S. via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: In one of the specializations of the write function in the std.stdio (the call site that you showed in your post) no check for closed stdout (when stdout._p is null) is done. I can't say if this is a bug in the write function or the desired behaviour (I'm a novice here). it's definitely a bug. writeln() should throw, not segfaulting. Shouldn't writeln() work tho instead of throwing or segfaulting?
Re: writeln() assertion failed in hybrid x64
On Thursday, 4 September 2014 at 18:22:55 UTC, Marc Schütz wrote: On Thursday, 4 September 2014 at 17:57:47 UTC, Szymon Gatner wrote: On Thursday, 4 September 2014 at 15:25:59 UTC, ketmar via Digitalmars-d-learn wrote: On Thu, 04 Sep 2014 15:10:21 + Jorge A. S. via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: In one of the specializations of the write function in the std.stdio (the call site that you showed in your post) no check for closed stdout (when stdout._p is null) is done. I can't say if this is a bug in the write function or the desired behaviour (I'm a novice here). it's definitely a bug. writeln() should throw, not segfaulting. Shouldn't writeln() work tho instead of throwing or segfaulting? No, if stdout is closed, how should it work? Throwing is the correct behaviour. Ah sorry, I totaly missed close() part. Any idea why it is null in my case tho?
Re: writeln() assertion failed in hybrid x64
On Thursday, 4 September 2014 at 20:38:38 UTC, Kagamin wrote: Maybe some module constructor wasn't run due to linking mess. So it remains uninitialized. Is there a way I can check if module c-tor run? rt_init() returned no error.
Linking phobos64.lib errors
Hi,
I am trying to make simple x64 C++ application that uses D static
library (trying to do Interfacing with C++ from D Cookbook
chapter). I am Using Visual Studio 2012 to create main() like
this:
#include iostream
extern C int rt_init();
extern C void rt_term();
// RAII struct for D runtime initialization and termination
struct DRuntime {
DRuntime() {
if(!rt_init()) {
// you could also use an exception
fprintf(stderr, D Initialization failed);
exit(1);
}
}
~DRuntime() {
rt_term();
}
};
int main()
{
DRuntime druntime;
}
and then I am just setting linker to link to phobos64.lib but I
am getting those:
1phobos64.lib(dmain2_4ec_2f9.obj) : error LNK2019: unresolved
external symbol _deh_beg referenced in function rt_init
1phobos64.lib(sections_win64_575_4e2.obj) : error LNK2001:
unresolved external symbol _deh_beg
1phobos64.lib(sections_win64_57b_5a5.obj) : error LNK2019:
unresolved external symbol _minfo_end referenced in function
_D2rt14sections_win6414getModuleInfosFZAyPS6object10ModuleInfo
1phobos64.lib(sections_win64_57b_5a5.obj) : error LNK2019:
unresolved external symbol _minfo_beg referenced in function
_D2rt14sections_win6414getModuleInfosFZAyPS6object10ModuleInfo
1phobos64.lib(sections_win64_575_4e2.obj) : error LNK2019:
unresolved external symbol _deh_end referenced in function
_D2rt14sections_win6412SectionGroup8ehTablesMxFNdZAyS2rt15deh_win64_posix9FuncTable
What am I doing wrong? Book says that on x64 Windows VC++ can be
used to create hybrid application.
Re: Linking phobos64.lib errors
On Wednesday, 3 September 2014 at 08:47:35 UTC, Rikki Cattermole
wrote:
On 3/09/2014 7:22 p.m., Szymon Gatner wrote:
Hi,
I am trying to make simple x64 C++ application that uses D
static
library (trying to do Interfacing with C++ from D Cookbook
chapter).
I am Using Visual Studio 2012 to create main() like this:
#include iostream
extern C int rt_init();
extern C void rt_term();
// RAII struct for D runtime initialization and termination
struct DRuntime {
DRuntime() {
if(!rt_init()) {
// you could also use an exception
fprintf(stderr, D Initialization failed);
exit(1);
}
}
~DRuntime() {
rt_term();
}
};
int main()
{
DRuntime druntime;
}
and then I am just setting linker to link to phobos64.lib but
I am
getting those:
1phobos64.lib(dmain2_4ec_2f9.obj) : error LNK2019: unresolved
external
symbol _deh_beg referenced in function rt_init
1phobos64.lib(sections_win64_575_4e2.obj) : error LNK2001:
unresolved
external symbol _deh_beg
1phobos64.lib(sections_win64_57b_5a5.obj) : error LNK2019:
unresolved
external symbol _minfo_end referenced in function
_D2rt14sections_win6414getModuleInfosFZAyPS6object10ModuleInfo
1phobos64.lib(sections_win64_57b_5a5.obj) : error LNK2019:
unresolved
external symbol _minfo_beg referenced in function
_D2rt14sections_win6414getModuleInfosFZAyPS6object10ModuleInfo
1phobos64.lib(sections_win64_575_4e2.obj) : error LNK2019:
unresolved
external symbol _deh_end referenced in function
_D2rt14sections_win6412SectionGroup8ehTablesMxFNdZAyS2rt15deh_win64_posix9FuncTable
What am I doing wrong? Book says that on x64 Windows VC++ can
be used to
create hybrid application.
My gut feeling looking at that, is that its not linking against
the c runtime.
For reference I'm pretty sure _deh_beg is related to exception
handling.
Hey, for some reason I missed this:
http://forum.dlang.org/thread/ji93fh$15ph$1...@digitalmars.com
The fix is to add main() function to D library. Don't know why it
is needed for static lib but it sure helps to resolve link issues.
writeln() assertion failed in hybrid x64
Hey,
I am trying to build hybrid (C++, D) application (more here:
http://forum.dlang.org/thread/ugkpqprobonorbdun...@forum.dlang.org)
but I am now getting assertion failure from within writeln().
writeln() is called from a D function that has C++ linkage:
D definition:
extern (C++) void printSomething()
{
writeln(hello from D);
}
usage from C++:
extern C++ void printSomething();
int main()
{
DRuntime druntime; // rt_init(), rt_term()
printSomething();
}
this causes run-time assertion in fprintf() called from within
writeln():
int __cdecl fprintf (
FILE *str,
const char *format,
...
)
/*
* 'F'ile (stream) 'PRINT', 'F'ormatted
*/
{
va_list(arglist);
FILE *stream;
int buffing;
int retval=0;
_VALIDATE_RETURN( (str != NULL), EINVAL, -1); === assetion
here
[...]
}
meaning that str arg passed is null. writelns()'s call site:
enforce(fprintf(.stdout._p.handle, %.*s\n,
cast(int) args[0].length, args[0].ptr) =
0);
so for some reason .stdout._p.handle is null.
Re: writeln() assertion failed in hybrid x64
On Wednesday, 3 September 2014 at 09:55:55 UTC, Szymon Gatner
wrote:
Hey,
I am trying to build hybrid (C++, D) application (more here:
http://forum.dlang.org/thread/ugkpqprobonorbdun...@forum.dlang.org)
but I am now getting assertion failure from within writeln().
writeln() is called from a D function that has C++ linkage:
D definition:
extern (C++) void printSomething()
{
writeln(hello from D);
}
usage from C++:
extern C++ void printSomething();
int main()
{
DRuntime druntime; // rt_init(), rt_term()
printSomething();
}
this causes run-time assertion in fprintf() called from within
writeln():
int __cdecl fprintf (
FILE *str,
const char *format,
...
)
/*
* 'F'ile (stream) 'PRINT', 'F'ormatted
*/
{
va_list(arglist);
FILE *stream;
int buffing;
int retval=0;
_VALIDATE_RETURN( (str != NULL), EINVAL, -1); === assetion
here
[...]
}
meaning that str arg passed is null. writelns()'s call site:
enforce(fprintf(.stdout._p.handle, %.*s\n,
cast(int) args[0].length, args[0].ptr)
= 0);
so for some reason .stdout._p.handle is null.
Any ideas why this happens?
Re: Programming a Game in D? :D
On Tuesday, 27 May 2014 at 10:03:36 UTC, David wrote: On Saturday, 24 May 2014 at 08:54:53 UTC, ponce wrote: Hi David, Learning programming, learning D and learning 3D are 3 significant endeavours. You might want to begin with http://www.basic4gl.net/ which will get you going with 3D, quite a topic in itself. Then learn D regardless :) So, I'v used Blender for a half year or sth. and I think I can make a little area :) As far as I know, I do now need a graphic and physics engines, 1 of the graphic APIs and for sure my programming stuff and here I'm stuck :D And I still can't install Mono-D :( if I try I just get a whole bunch of errors that any packages couldn't be found, don't know if I'm doing sth. wrong (I probably do :P) I would STRONGLY advise to go with a ready engine like Unity. You still have to learn a lot before you will have just building blocks to create a game like loading and rendering 3D models, a gameplay framework etc etc. Start with Unity, lean how to make a game there. Learn how to programm gameplay there and after that, when you see what is needed before even being able to make a game, only then try to make things from scratch. Use C# in Unity too as it is similar to D so you will have easier transition when necessary.
