How to compile for Win64 with Visual D? Optlink error?
I'm trying to compile my project as a Win64 application but this is happening: Building C:\Users\me\test\test.exe... OPTLINK (R) for Win32 Release 8.00.17 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html OPTLINK : Warning 183: Extension not .RES : obj\debug\dummy\test\..\source\c.obj obj\debug\dummy\test\..\source\b.obj(1) : Error 52: .DEF Syntax Error d†šöñÀY$@ ^ Building C:\Users\me\test\test.exe failed! I'm on a Win64 machine and compiling Win32 works fine. I'm using Visual Studio 17 Community with Visual D. DMD is up to date as is Visual D. I added a x64 "solution platform" to the configuration manager which added a -m64 flag to my linker options. I'm not sure what else I'm meant to do to get it to compile as x64?
Re: extern(C) enum
On Friday, 15 September 2017 at 19:35:50 UTC, nkm1 wrote:
On Friday, 15 September 2017 at 19:21:02 UTC, Timothy Foster
wrote:
I believe C enum size is implementation defined. A C compiler
can pick the underlying type (1, 2, or 4 bytes, signed or
unsigned) that fits the values in the enum.
No, at least, not C99. See 6.4.4.3: "An identifier declared as
an enumeration constant has type int". You must be thinking
about C++.
You are correct, however 6.7.2.2 "Enumeration specifiers" states:
"Each enumerated type shall be compatible with char, a signed
integer type, or an unsigned integer type. The choice of type is
implementation-defined, but shall be capable of representing the
values of all the members of the enumeration."
I believe that means that if you have the following:
enum ABC { A, B, C }
Then A, B, and C are by themselves ints, but the enum type ABC
can be a char if the compiler decides that's what it wants it to
be.
Re: extern(C) enum
On Friday, 15 September 2017 at 15:35:48 UTC, bitwise wrote: On Friday, 15 September 2017 at 07:24:34 UTC, Jonathan M Davis wrote: On Friday, September 15, 2017 04:15:57 bitwise via Digitalmars-d-learn wrote: I translated the headers for FreeType2 to D, and in many cases, enums are used as struct members. If I declare an extern(C) enum in D, is it guaranteed to have the same underlying type and size as it would for a C compiler on the same platform? extern(C) should have no effect on enums. It's for function linkage, and enums don't even have an address, so they don't actually end up in the program as a symbol. And since C's int and D's int are the same on all platforms that D supports (we'd have c_int otherwise, like we have c_long), any enum with a base type of int (which is the default) will match what's in C. - Jonathan M Davis I'm confused...is it only C++ that has implementation defined enum size? I thought that was C as well. I believe C enum size is implementation defined. A C compiler can pick the underlying type (1, 2, or 4 bytes, signed or unsigned) that fits the values in the enum. A D int is always the same size as a C int because C ints are 4 bytes on 32bit and above architectures and D doesn't support architectures below 32bit so you never run into a case where a C int is 2 bytes. D can't guarantee that the size of an extern(C) enum will match an arbitrary C compiler's choice, so I'm pretty sure it'll just default to a D int. It's further likely that padding in a struct will differ between C compilers so if you need a D struct to be the same size as a C struct in every case... welp that's not exactly going to be fun.
Re: Access Violation when passing the result of a C function directly to a D function?
On Friday, 15 September 2017 at 16:55:27 UTC, Kagamin wrote:
On Friday, 15 September 2017 at 04:01:13 UTC, Timothy Foster
wrote:
am I required to save the result of a C function to variable
before passing it into another function or?
No. You probably have stack corruption. Does it crash if
FMOD_System_Create returns ok?
FMOD_System_Create is always returning FMOD_OK. I have zero
issues when I save the result of a fmod function to a variable
before passing it to my helper function.
Sometimes crashes:
ErrorFMOD(Some_FMOD_Function(...), "print text");
Never crashes:
auto result = Some_FMOD_Function(...);
ErrorFMOD(result, "print text");
The crashes happen even if ErrorFMOD is an empty function:
void ErrorFMOD(int r, string s = ""){
//nothing happening
}
Re: Access Violation when passing the result of a C function directly to a D function?
On Friday, 15 September 2017 at 10:33:55 UTC, Vadim Lopatin wrote: On Friday, 15 September 2017 at 04:01:13 UTC, Timothy Foster wrote: [...] Probably you have to use const char * msg when interfacing with C. string is a struct - size_t length and const char * value The string doesn't touch any C functions, it just gets printed in the writeln() call.
Access Violation when passing the result of a C function directly to a D function?
I'm compiling on Windows 7 x64, DMD32 D Compiler v2.075.1 and I'm
using Derelict Fmod to handle audio in my application. Every Fmod
function returns an int telling me if the function ran okay, or
if there was an error. I've written the following helper function
that will print something for me if it encounters an error:
static void ErrorFMOD(int result, string msg = ""){
if(result != FMOD_OK)
writeln("[ FMOD ] ", msg, FMOD_ErrorString(result));
}
This function has been causing Access Violation Errors when I
call it. It doesn't happen every time and it doesn't always
happen in the same place. The errors occur _even when I comment
out everything inside the function_. I've been calling it like so:
ErrorFMOD(FMOD_System_Create(), "Error Creating System: ");
Making the calls without my helper function doesn't cause an
Access Violation.
Calling it like this is the only thing that seems to fix it:
auto result = FMOD_System_Create();
ErrorFMOD(result, "Error Creating System: ");
Is this a known issue, or am I required to save the result of a C
function to variable before passing it into another function or?
Is compiling for Android/iOS possible?
I'm just wondering if I made an application for Windows/Mac/Linux if I could get it to also work on mobile devices, or would I have to rewrite the application in another language to get it to work? If it's possible, what should I be looking at to get something like a "Hello World" example to show on my phone using D?
Re: writeln() sometimes double prints from main() if I run a thread checking for input?
On Wednesday, 30 August 2017 at 11:28:49 UTC, Stefan Koch wrote:
On Wednesday, 30 August 2017 at 10:55:20 UTC, Timothy Foster
wrote:
On Wednesday, 30 August 2017 at 10:44:43 UTC, Ivan Kazmenko
wrote:
[...]
import std.stdio, core.thread;
void main(){
auto thread = new Thread().start;
writeln("Output");
writeln("Output2");
writeln("Output3");
while(true){}
}
void func(){
foreach(line; stdin.byLineCopy){}
}
The printout from the above typically gives me:
Output
Output2
Output2
Output3
I've narrowed down the issue. I just don't know what to do
about it.
I cannot reproduce this. what os / compiler are you using ?
Windows 7 Ultimate 64-bit
DMD32 D Compiler v2.075.1
The issue is inconsistent. Sometimes it'll print as it should,
sometimes it'll double the first line, sometimes the second,
sometimes both the first and second.
Re: writeln() sometimes double prints from main() if I run a thread checking for input?
On Wednesday, 30 August 2017 at 10:44:43 UTC, Ivan Kazmenko wrote:
On Wednesday, 30 August 2017 at 10:13:57 UTC, Timothy Foster
wrote:
I'm not sure if this is a known issue, or if I just don't
understand how to use threads, but I've got writeln statements
sometimes printing out twice in some areas of my code.
<...>
Does anyone know what is causing this or how I can fix it?
Difficult to say by what you posted.
You may want to provide a complete example so that others may
try to reproduce it. Additionally, as you gradually simplify
your code until it is small enough to post here, or on DPaste,
you may find the cause faster yourself.
Ivan Kazmenko.
import std.stdio, core.thread;
void main(){
auto thread = new Thread().start;
writeln("Output");
writeln("Output2");
writeln("Output3");
while(true){}
}
void func(){
foreach(line; stdin.byLineCopy){}
}
The printout from the above typically gives me:
Output
Output2
Output2
Output3
I've narrowed down the issue. I just don't know what to do about
it.
writeln() sometimes double prints from main() if I run a thread checking for input?
I'm not sure if this is a known issue, or if I just don't
understand how to use threads, but I've got writeln statements
sometimes printing out twice in some areas of my code. It seems
to only happen when I start a thread that checks for input with
stdin.byLineCopy (I'm not sure of the internal workings of it so
that may be the issue)
The setup is basically this:
void main(){
auto thread = Thread().start;
writeln("Output");
...
}
void func(){
foreach (line; stdin.byLineCopy) {
...
}
}
Some of the time it will print out "Output" and some of the time
it will print out
"Output
Output"
Does anyone know what is causing this or how I can fix it?
Terminating a thread (which is blocking)
I've started a thread at the beginning of my program that waits
for user input:
`thread = new Thread().start;`
`static void checkInput(){
foreach (line; stdin.byLineCopy) { ... }
}`
I need to stop checking for user input at some point in my
program but I'm not sure how to kill this thread.
`thread.yield();` called from my main thread doesn't kill it and
I'm not sure how to send a message to the input checking thread
to get it to terminate itself when `stdin.byLineCopy` just sits
there and blocks until user input is received.
