On Sunday, 12 June 2016 at 04:19:33 UTC, Joerg Joergonson wrote:
1. I had an older distro(I think) of ldc. The ldc2.exe is 18MB
while the "new" one is 36MB. I copied the old ldc bin dir to
the new one and didn't change anything and everything compiled
EXCEPT
That's just asking for problems. You may get lucky and find that
it works, but in general you don't want to go around swapping
compiler executables like that.
2. I got an error that I don't get with dmd:
Error: incompatible types for ((ScreenPainter) !is (null)):
cannot use '!is' with types
and I have defined ScreenPainter in my code. It is also in
arsd's simpledisplay. I do not import simpledisplay directly:
The code is
import arsd.gamehelpers;
auto window = create2dWindow(cast(int)width, cast(int)height,
cast(int)ViewportWidth, cast(int)ViewportHeight, title);
// Let the gui handle painting the screen
window.redrawOpenGlScene = {
if (ScreenPainter !is null || !ScreenPainter()) <--- error
...
};
I have defined ScreenPainter elsewhere in the module.
So ScreenPainter is a *type* and not an instance of a type? That
*should* be an error, no matter which compiler you use. You can't
compare a type against null. What does that even mean? And if
SimpleDisplay already defines the type, why have you redefined it?
Assuming ScreenPainter is a class, then:
if(ScreenPainter !is null) <-- Invalid
auto sp = new ScreenPainter;
if(sp !is null) <-- valid
I can fix this by avoiding the import... but the point is that
it's different than dmd.
If ScreenPainter is defined as a type, it shouldn't ever compile.
How have you defined it?
So ldc parses things differently than dmd... I imagine this is
a bug!
LDC and DMD share the same front end, meaning they parse code the
same. I really would like to see your code, particularly your
definition of ScreenPainter.
Although, If I set the subsystem to windows I then get the error
error LNK2019: unresolved external symbol WinMain referenced
in function "int __cdecl __scrt_common_main_seh(void)"
(?__scrt_common_main_seh@@YAHXZ)>
Which looks like it's not linking to runtime and/or phobos?
No, this has nothing to do with DRuntime, Phobos, or even D. It's
a Windows thing. By default, when you compile a D program, you
are creating a console system executable so your primary entry
point is an extern(C) main function that is generated by the
compiler. This initializes DRuntime, which in turn calls your D
main function.
When using OPTLINK with DMD, the linker will ensure that the
generated extern(C) main remains the entry point when you set the
subsystem to Windows. When using the MS linker, this is not the
case. The linker will expect WinMain to be the entry point when
the subsystem is set to Windows. If you do not have a WinMain,
you will see the error above. In order to keep the extern(C) main
as your entry point, you have to pass the /ENTRY option to the
linker (see[1]). LDC should provide a means for passing linker
options. You can probably set in VisualD's project settings, but
if there's no field for it then ldc2 --help may tell you what you
need.
Alternatively, you can create a WinMain, but then you need to
initialize DRuntime yourself. See [2], but ignore the .def file
requirement since you are already setting the subsystem.
I seriously don't know how anyone gets anything done with all
these problems ;/ The D community can't expect to get people
interested in things don't work. If it wasn't because the D
language was so awesome I wouldn't stick around! It's as if no
one does any real testing on this stuff before it's released ;/
Then I would ask you to stop and think. There are a number of
people using D without problems every day, including several
companies. Obviously, they aren't having the same difficulties
you are, else they wouldn't be successfully using D. You seem to
be very quick to blame the tools rather than considering you
might not fully understand how to use them. I don't mean that in
a disparaging way. I've been there myself, trying to get
something I wanted to use working and failing, then getting
frustrated and blaming the tools. These days, I always blame
yourself first. Sure, the tools sometimes have bugs and other
issues, but more often than not it's because I'm using them the
wrong way.
Right now, documentation on getting up to speed with LDC is
sorely lacking. That's a valid criticism to make. For people who
aren't familiar with it, or who aren't well versed in working
with ahead of time compilers, whichever the case may be, it may
not be the best choice for getting started with D. Since you seem
to be having difficulties using LDC and since you've already told
me that DMD is working for you, I strongly recommend that you use
DMD instead for now. Once you are comfortable with D and the
ecosystem, then look into using LDC.
1. LDC has a bug in it. Simple as that. Replacing ldc2's bin
dir with older ldc2 version essentially solved the problem(that
being it not parsing paths correctly).
2. LDC has a discontinuity with dmd. Maybe fixed in the latest
version... but I can't tell.
LDC may have bugs, but I don't believe the problem you talked
about above is one of them. I would really like to see all of the
code you are trying to compile. The error you saw was what I
would expect to see when trying to compare a type to null.
3. LDC x64 cannot find "winmain" or whatever while DMD does.
This is if the subsystem is set to windows. If set to console
it works but then windows app has console that pops up, which
is not acceptable. This too may have been fixed in the latest
ldc.
As I explained above, this is not a problem with LDC. The
compile-link process in D is the same as it is in C and C++ and
the generated Windows executables have the same requirements. As
it is not D specific, there are a number of pages on the internet
dealing with compiling and linking on Windows. Those will help
you when using D compilers as well. You just have to adapt any
compiler-specific command line arguments to the compiler you are
using. I strongly recommend you familiarize yourself with the MS
linker options, since it is prominent in the D toolchain on
Windows now.
[1] https://msdn.microsoft.com/en-us/library/f9t8842e.aspx
[2] https://wiki.dlang.org/D_for_Win32
