Re: Win32 + OpenGL bindings
On Saturday, 20 April 2013 at 03:26:29 UTC, Diggory wrote: I've been trying to write a win32 app using opengl in D, but none of the bindings I've found have been sufficient: - core.sys.windows.windows: Missing large parts of wingdi.h, including PFD_* constants, ChoosePixelFormat(), SwapBuffers(), wgl*() functions. - win32.windows: Apparantly out of date and gives linker errors, although it does declare all the functions needed. - derelict.util.wintypes: Declares a small number of useful windows functions, many of which conflict with those declared in core.sys.windows.windows (such as PIXELFORMATDESCRIPTOR). However, SetPixelFormat is not declared. - derelict.opengl.gl: Has all of opengl plus wgl* functions needed for windows, but has more dependencies than an ideal opengl binding would have. Why isn't there a simple relationship between C/C++ header files and D modules, instead of this weird mix where some things are duplicated and others not declared at all? All of the windows specific functions including wgl* are supposed to be in windows.h, and opengl functions in gl/gl.h It's a shame because I really like the ideas behind D - in fact the reason I found it is that I'd come up with a whole bunch of ideas I wanted in an ideal language and it turned out D already implemented them all... Deimos has some OpenGL bindings for up to 3.1 core here https://github.com/D-Programming-Deimos/OpenGL/tree/master/deimos/gl I also have my own that are up to 4.2 core here https://bitbucket.org/Kapps/shardgraphics/src (gl.d, glfuncs.d, gltypes.d, and possibly glfw.d if you need that), which include loading the function pointers, but there may be some licensing issues because they're parsed from the OpenGL man pages. Also there may be some incorrect functions in mine because of parsing errors.
Re: x64 Link Issues - Can someone please help?
On Saturday, 20 April 2013 at 04:46:45 UTC, dnewbie wrote: phobos64.lib(dmain2_4ac_1a5.obj) : error LNK2019: unresolved external symbol _Dmain referenced in function main Please add -L/DLL to the command line. Ahhh ok, thanks! I assumed DMD would have detected the output file being a DLL and sent this itself, but clearly not. In any case, the DLL now builds fine, however one of my other projects in the solution is also refusing to build but for a different reason. Here is it's build output: -- Building: HookLoader (Debug|x64) Performing main compilation... C:\Development\Tools\ResourceCompiler\rc.exe /fo obj\Debug\Resources.Win32Manifest.res C:\Development\Projects\EyefinityMaximizer\HookLoader\Resources\Win32Manifest.rc Current dictionary: C:\Development\Projects\EyefinityMaximizer\HookLoader dmd.exe -debug -gc obj\Debug\Resources.Win32Manifest.res C:\Development\Projects\EyefinityMaximizer\EyefinityMaximizer\eyemax\WinAPI.d main.d HookLoader.def -IC:\Development\Compilers\D\dmd2\src\phobos -IC:\Development\Compilers\D\dmd2\src\druntime\src -odobj\Debug -ofC:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLoader.x64.exe -m64 HookLoader.def(1) : warning LNK4017: EXETYPE statement not supported for the target platform; ignored HookLoader.def(1) : warning LNK4017: SUBSYSTEM statement not supported for the target platform; ignored Creating library C:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLoader.x64.lib and object C:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLoader.x64.exp LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt --- errorlevel 1123 Exit code 1123 Build complete -- 1 error, 0 warnings -- Any ideas as to what would cause a 'failure during conversion to COFF'??
Duck typing with std.variant.Algebraic/Variant
Hi,
I wonder why I can't use Algebraic like this:
struct Foo(bool flag)
{
size_t bar() { return flag ? 42 : 0; }
}
Foo!false f;
Foo!true t;
Algebraic!(typeof(t), typeof(f)) v;
v = t;
Variant i = v.bar(); // or an Algebraic of the return types.
This doesn't compile anyway
assert(i.type == typeof(size_t));
assert(i.get!size_t() == 42);
Essentially what I miss is opDispatch implemented on Variant.
There seemed to be a discussion with a proposal for an Any type
in std.typecons some time ago
(http://forum.dlang.org/thread/20100708100757.GA4412@dsource),
but for some reason none of it has made it into Phobos.
Can anyone explain about why it isn't implemented? Seems like I
missed something...
Re: Win32 + OpenGL bindings
On Saturday, 20 April 2013 at 03:26:29 UTC, Diggory wrote: - win32.windows: Apparantly out of date and gives linker errors, although it does declare all the functions needed. Is this the ChoosePixelFormat error from your other thread? If so - you probably need to link your program with gdi32.lib. You can do this by adding this line to your program (won't work with GDC): pragma(lib, gdi32); Or, just add gdi32.lib to the compiler's command line. If it's some other error - are you using the .lib / .def files from the same project? There are some additional import libraries files in the repository's lib directory.
Re: Win32 + OpenGL bindings
On 2013-04-20 05:26, Diggory wrote: - derelict.opengl.gl: Has all of opengl plus wgl* functions needed for windows, but has more dependencies than an ideal opengl binding would have. Dependencies, like what? -- /Jacob Carlborg
Re: x64 Link Issues - Can someone please help?
It seems my resources were breaking the link! Essentially, I was suffering from this problem: http://stackoverflow.com/questions/10888391/link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-invalid-or-c/14144713 In any case, problem solved. Thanks! :)
Re: Win32 + OpenGL bindings
On Saturday, 20 April 2013 at 10:09:37 UTC, Jacob Carlborg wrote:
On 2013-04-20 05:26, Diggory wrote:
- derelict.opengl.gl:
Has all of opengl plus wgl* functions needed for windows, but
has more
dependencies than an ideal opengl binding would have.
Dependencies, like what?
Well the opengl module depends on the util module. The util
module declares a load of stuff duplicated by the windows module
so importing them both without aliasing is impossible. All I want
is to import the raw opengl and win32 functions.
I've got my program partially working using the old win32.windows
module with an opengl module I got from elsewhere which included
opengl32.lib, but doesn't define glViewport...
I would like to use the opengl module from deimos if possible -
it doesn't need to be particularly up to date - but I don't know
how to get/generate the .lib file for it.
Are the .lib files used with D just C/C++ .lib files? If so what
are the requirements of them - .lib files from the windows SDK
don't seem to be compatible? Do I need to generate them instead
from the .d files?
Also the program I'm compiling is bringing up a console window
when it runs, even though I'm setting the subsystem to Windows
and using WinMain exactly as the documentation describes.
Finally I seem to have discovered a bug with final switch:
This correctly does nothing when passed 36 (neither WM_SIZE and
WM_DESTROY equal 36):
switch (message) {
case WM_SIZE:
glViewport(0, 0, LOWORD(lParam), HIWORD(lParam));
break;
case WM_DESTROY:
PostQuitMessage(0);
break;
default:
break;
}
While this runs the WM_DESTROY case statement when passed 36.
final switch (message) {
case WM_SIZE:
glViewport(0, 0, LOWORD(lParam), HIWORD(lParam));
break;
case WM_DESTROY:
PostQuitMessage(0);
break;
}
Re: Quadratic time to sort in a simple case?
On Friday, 19 April 2013 at 22:56:00 UTC, bearophile wrote: So, why isn't TimSort the default? Probably because someone thinks that on average the other sort is faster. In theory the other should be faster, because if you relax the constraints of the sort being stable I think in theory you should be able to write a little faster sorting algorithm (I don't know if this is true). I'm just throwing my 2c in, but I think TimSort ought to be the default. It's simply the safer option. Since worst-case performance can be designed (and it can be designed unless the pivots are, at least, pseudo-randomly chosen), there is a very real risk of the default sort being used in a way that can be compromised by an attacker. From this perspective, seems to be like TimSort being default would support the design goal #5 of D, Make doing things the right way easier than the wrong way. Plus, TimSort seems to be faster in most cases in my attempts. The only cases I could find that it wasn't faster is when I could guarantee that the data I was passing in had no order to it. In cases where you suspect (but can't guarantee) data is sorted when passed in (think fetching from a web API and it gives you sorted data, but the docs don't say it should), calling TimSort is nearly as fast as calling an isSorted ... So, my recommendation is to just call TimSort and don't worry about the extra branching code ([checking sortedness, if not sorted, call sort] vs [call sort]). This makes it so the fast code is also very convenient to write. TBH, though, I think the reason that TimSort is not the default is because it was added only semi-recently. The old stable sort was not nearly as fast as the unstable sort (and, in fact, IIRC, it didn't work properly when I tried it). I doubt that someone intentionally said that quicksort was faster than TimSort on average ... it's just that no one thought to change the default when TimSort was added. Maybe an enhancement request could be made on this?
Bug: Accessing return value of type static array with length 1 or 2 by index.
import std.stdio : writeln;
template Template (uint n, T)
{
T[n] statArr()
{
T[n] arr;
return arr;
}
T[] dynArr()
{
T[] dynArr = new T[n];
return dynArr;
}
}
void main()
{
alias statArr9 = Template!(9, int).statArr;
alias statArr3 = Template!(3, int).statArr;
alias statArr2 = Template!(2, int).statArr;
alias statArr1 = Template!(1, int).statArr;
alias statArr0 = Template!(0, int).statArr;
// Fine
statArr9().writeln(); // Writes [0, 0, 0, 0, 0, 0, 0,
0, 0]
statArr3().writeln(); // Writes [0, 0, 0]
statArr2().writeln(); // Writes [0, 0]
statArr1().writeln(); // Writes [0]
statArr0().writeln(); // Writes []
// 2 bugs
statArr9()[0].writeln();// OK : Writes 0
statArr3()[0].writeln();// OK : Writes 0
//statArr2()[0].writeln(); // BUG: Internal error:
..\ztc\cgcs.c 344
//statArr1()[0].writeln(); // BUG: Internal error:
..\ztc\cgcs.c 344
//statArr0()[0].writeln(); // OK : Error: array index 0 is
out of bounds
// getArr0()[0 .. 0]
alias dynArr9 = Template!(9, int).dynArr;
alias dynArr3 = Template!(3, int).dynArr;
alias dynArr2 = Template!(2, int).dynArr;
alias dynArr1 = Template!(1, int).dynArr;
alias dynArr0 = Template!(0, int).dynArr;
dynArr9()[0].writeln(); // OK: Writes 0
dynArr3()[0].writeln(); // OK: Writes 0
dynArr2()[0].writeln(); // OK: Writes 0
dynArr1()[0].writeln(); // OK: Writes 0
//dynArr0()[0].writeln(); // OK: core.exception.RangeError:
// Range violation
// Other types
//Template!(2, bool).statArr()[0].writeln();// BUG
//Template!(2, byte).statArr()[0].writeln();// BUG
//Template!(2, ubyte).statArr()[0].writeln(); // BUG
//Template!(2, short).statArr()[0].writeln(); // BUG
//Template!(2, ushort).statArr()[0].writeln(); // BUG
//Template!(2, int).statArr()[0].writeln(); // BUG
//Template!(2, uint).statArr()[0].writeln();// BUG
//Template!(2, long).statArr()[0].writeln();// BUG
//Template!(2, ulong).statArr()[0].writeln(); // BUG
//Template!(2, float).statArr()[0].writeln(); // BUG
//Template!(2, double).statArr()[0].writeln(); // BUG
Template!(2, real).statArr()[0].writeln(); // OK :
Writes nan
//Template!(2, ifloat).statArr()[0].writeln(); // BUG
//Template!(2, idouble).statArr()[0].writeln(); // BUG
Template!(2, ireal).statArr()[0].writeln(); // OK :
Writes inan
//Template!(2, cfloat).statArr()[0].writeln(); // BUG
Template!(2, cdouble).statArr()[0].writeln(); // OK :
Writes nan+nani
Template!(2, creal).statArr()[0].writeln(); // OK :
Writes nan+nani
//Template!(2, char).statArr()[0].writeln();// BUG
//Template!(2, wchar).statArr()[0].writeln(); // BUG
//Template!(2, dchar).statArr()[0].writeln(); // BUG
struct Sint { int a; }
struct Sreal{ real a; }
Template!(2, Sint).statArr()[0].writeln(); // OK :
Writes Sint(0)
Template!(2, Sreal).statArr()[0].writeln(); // OK :
Writes Sreal(nan)
}
Found in both dmd 2.061 and 2.062 for 32- and 64-bit. Other types
only tested with dmd 2.062.
Re: Calculation differences between Debug and Release mode
On Sat, 13 Apr 2013 18:36:21 +0200, Jeremy DeHaan dehaan.jerem...@gmail.com wrote: I'm on Windows, and I my compilation was nothing more than dmd -O -release main.d to get the issue I described. Turns out, the problem starts here: static const(float) pi = 3.141592654f; If we compare that to std.math.PI, we see that they're different: writeln( 3.141592654f - std.math.PI ); 4.10207e-10 If, however, we assign these values to some temporary floats, we see that they're equal: float a = 3.141592654f; float b = std.math.PI; writeln( a - b ); 0 Replace float with double or real in the above, and the difference reappears. So, we have established that 3.141592654f is a valid approximation to pi for a float. The problem thus has to be one of precision. I'm not sure if it's a valid optimization for the compiler to use doubles instead of floats (it certainly seem innocuous enough). I'd say file a bug on it. Worst case, it gets closed as invalid. -- Simen
Re: Bug: Accessing return value of type static array with length 1 or 2 by index.
Made available on dpaste: http://dpaste.dzfl.pl/7b5c36f8 On dpaste, the struct with an int didn't compile. (Same error message) It turns out that Template!(2, Sint).statArr()[0].writeln(); compiles with $ dmd test.d -m64 but not with $ dmd test.d
Re: Bug: Accessing return value of type static array with length 1 or 2 by index.
On Saturday, 20 April 2013 at 13:37:55 UTC, John Colvin wrote:
On Saturday, 20 April 2013 at 12:23:20 UTC, deed wrote:
import std.stdio : writeln;
template Template (uint n, T)
{
T[n] statArr()
{
T[n] arr;
return arr;
}
T[] dynArr()
{
T[] dynArr = new T[n];
return dynArr;
}
}
void main()
{
alias statArr9 = Template!(9, int).statArr;
alias statArr3 = Template!(3, int).statArr;
alias statArr2 = Template!(2, int).statArr;
alias statArr1 = Template!(1, int).statArr;
alias statArr0 = Template!(0, int).statArr;
// Fine
statArr9().writeln(); // Writes [0, 0, 0, 0, 0, 0, 0,
0, 0]
statArr3().writeln(); // Writes [0, 0, 0]
statArr2().writeln(); // Writes [0, 0]
statArr1().writeln(); // Writes [0]
statArr0().writeln(); // Writes []
// 2 bugs
statArr9()[0].writeln();// OK : Writes 0
statArr3()[0].writeln();// OK : Writes 0
//statArr2()[0].writeln(); // BUG: Internal error:
..\ztc\cgcs.c 344
//statArr1()[0].writeln(); // BUG: Internal error:
..\ztc\cgcs.c 344
//statArr0()[0].writeln(); // OK : Error: array index 0 is
out of bounds
// getArr0()[0 .. 0]
alias dynArr9 = Template!(9, int).dynArr;
alias dynArr3 = Template!(3, int).dynArr;
alias dynArr2 = Template!(2, int).dynArr;
alias dynArr1 = Template!(1, int).dynArr;
alias dynArr0 = Template!(0, int).dynArr;
dynArr9()[0].writeln(); // OK: Writes 0
dynArr3()[0].writeln(); // OK: Writes 0
dynArr2()[0].writeln(); // OK: Writes 0
dynArr1()[0].writeln(); // OK: Writes 0
//dynArr0()[0].writeln(); // OK:
core.exception.RangeError:
// Range violation
// Other types
//Template!(2, bool).statArr()[0].writeln();// BUG
//Template!(2, byte).statArr()[0].writeln();// BUG
//Template!(2, ubyte).statArr()[0].writeln(); // BUG
//Template!(2, short).statArr()[0].writeln(); // BUG
//Template!(2, ushort).statArr()[0].writeln(); // BUG
//Template!(2, int).statArr()[0].writeln(); // BUG
//Template!(2, uint).statArr()[0].writeln();// BUG
//Template!(2, long).statArr()[0].writeln();// BUG
//Template!(2, ulong).statArr()[0].writeln(); // BUG
//Template!(2, float).statArr()[0].writeln(); // BUG
//Template!(2, double).statArr()[0].writeln(); // BUG
Template!(2, real).statArr()[0].writeln(); // OK :
Writes nan
//Template!(2, ifloat).statArr()[0].writeln(); // BUG
//Template!(2, idouble).statArr()[0].writeln(); // BUG
Template!(2, ireal).statArr()[0].writeln(); // OK :
Writes inan
//Template!(2, cfloat).statArr()[0].writeln(); // BUG
Template!(2, cdouble).statArr()[0].writeln(); // OK :
Writes nan+nani
Template!(2, creal).statArr()[0].writeln(); // OK :
Writes nan+nani
//Template!(2, char).statArr()[0].writeln();// BUG
//Template!(2, wchar).statArr()[0].writeln(); // BUG
//Template!(2, dchar).statArr()[0].writeln(); // BUG
struct Sint { int a; }
struct Sreal{ real a; }
Template!(2, Sint).statArr()[0].writeln(); // OK :
Writes Sint(0)
Template!(2, Sreal).statArr()[0].writeln(); // OK :
Writes Sreal(nan)
}
Found in both dmd 2.061 and 2.062 for 32- and 64-bit. Other
types only tested with dmd 2.062.
I can only replicate one of these bugs in dmd git master x64,
the cfloat one. It segfaults during the initialisation of the
array.
dmd calls _memset64 to do the initialisation. It seems to
(partially) forget that we're in x64 and tries to pass the
value to set to (float.nan) on the stack.
The result: A complete mess. Not enough arguments, in the wrong
places.
_memset64 gets the right destination pointer but gets the
length of the array (2) as the value to write and then tries to
initialise RDX number of values. But RDX was never set.
Segfault.
Sorry should specify this was on linux x64
Re: Bug: Accessing return value of type static array with length 1 or 2 by index.
On Saturday, 20 April 2013 at 12:23:20 UTC, deed wrote:
import std.stdio : writeln;
template Template (uint n, T)
{
T[n] statArr()
{
T[n] arr;
return arr;
}
T[] dynArr()
{
T[] dynArr = new T[n];
return dynArr;
}
}
void main()
{
alias statArr9 = Template!(9, int).statArr;
alias statArr3 = Template!(3, int).statArr;
alias statArr2 = Template!(2, int).statArr;
alias statArr1 = Template!(1, int).statArr;
alias statArr0 = Template!(0, int).statArr;
// Fine
statArr9().writeln(); // Writes [0, 0, 0, 0, 0, 0, 0,
0, 0]
statArr3().writeln(); // Writes [0, 0, 0]
statArr2().writeln(); // Writes [0, 0]
statArr1().writeln(); // Writes [0]
statArr0().writeln(); // Writes []
// 2 bugs
statArr9()[0].writeln();// OK : Writes 0
statArr3()[0].writeln();// OK : Writes 0
//statArr2()[0].writeln(); // BUG: Internal error:
..\ztc\cgcs.c 344
//statArr1()[0].writeln(); // BUG: Internal error:
..\ztc\cgcs.c 344
//statArr0()[0].writeln(); // OK : Error: array index 0 is
out of bounds
// getArr0()[0 .. 0]
alias dynArr9 = Template!(9, int).dynArr;
alias dynArr3 = Template!(3, int).dynArr;
alias dynArr2 = Template!(2, int).dynArr;
alias dynArr1 = Template!(1, int).dynArr;
alias dynArr0 = Template!(0, int).dynArr;
dynArr9()[0].writeln(); // OK: Writes 0
dynArr3()[0].writeln(); // OK: Writes 0
dynArr2()[0].writeln(); // OK: Writes 0
dynArr1()[0].writeln(); // OK: Writes 0
//dynArr0()[0].writeln(); // OK:
core.exception.RangeError:
// Range violation
// Other types
//Template!(2, bool).statArr()[0].writeln();// BUG
//Template!(2, byte).statArr()[0].writeln();// BUG
//Template!(2, ubyte).statArr()[0].writeln(); // BUG
//Template!(2, short).statArr()[0].writeln(); // BUG
//Template!(2, ushort).statArr()[0].writeln(); // BUG
//Template!(2, int).statArr()[0].writeln(); // BUG
//Template!(2, uint).statArr()[0].writeln();// BUG
//Template!(2, long).statArr()[0].writeln();// BUG
//Template!(2, ulong).statArr()[0].writeln(); // BUG
//Template!(2, float).statArr()[0].writeln(); // BUG
//Template!(2, double).statArr()[0].writeln(); // BUG
Template!(2, real).statArr()[0].writeln(); // OK :
Writes nan
//Template!(2, ifloat).statArr()[0].writeln(); // BUG
//Template!(2, idouble).statArr()[0].writeln(); // BUG
Template!(2, ireal).statArr()[0].writeln(); // OK :
Writes inan
//Template!(2, cfloat).statArr()[0].writeln(); // BUG
Template!(2, cdouble).statArr()[0].writeln(); // OK :
Writes nan+nani
Template!(2, creal).statArr()[0].writeln(); // OK :
Writes nan+nani
//Template!(2, char).statArr()[0].writeln();// BUG
//Template!(2, wchar).statArr()[0].writeln(); // BUG
//Template!(2, dchar).statArr()[0].writeln(); // BUG
struct Sint { int a; }
struct Sreal{ real a; }
Template!(2, Sint).statArr()[0].writeln(); // OK :
Writes Sint(0)
Template!(2, Sreal).statArr()[0].writeln(); // OK :
Writes Sreal(nan)
}
Found in both dmd 2.061 and 2.062 for 32- and 64-bit. Other
types only tested with dmd 2.062.
I can only replicate one of these bugs in dmd git master x64, the
cfloat one. It segfaults during the initialisation of the array.
dmd calls _memset64 to do the initialisation. It seems to
(partially) forget that we're in x64 and tries to pass the value
to set to (float.nan) on the stack.
The result: A complete mess. Not enough arguments, in the wrong
places.
_memset64 gets the right destination pointer but gets the length
of the array (2) as the value to write and then tries to
initialise RDX number of values. But RDX was never set. Segfault.
subclass to base class but not subclass pointer to base class pointer?
Why can D implicitly cast from the subclass to the base class, but not implicitly from the subclasse pointer to the base class pointer? This works: http://dpaste.1azy.net/30dd34a0 This not: http://dpaste.1azy.net/ffacfd83 Makes not much sense for me.
Re: Bug: Accessing return value of type static array with length 1 or 2 by index.
On Saturday, 20 April 2013 at 12:23:20 UTC, deed wrote:
import std.stdio : writeln;
template Template (uint n, T)
{
T[n] statArr()
{
T[n] arr;
return arr;
}
T[] dynArr()
{
T[] dynArr = new T[n];
return dynArr;
}
}
void main()
{
alias statArr9 = Template!(9, int).statArr;
alias statArr3 = Template!(3, int).statArr;
alias statArr2 = Template!(2, int).statArr;
alias statArr1 = Template!(1, int).statArr;
alias statArr0 = Template!(0, int).statArr;
// Fine
statArr9().writeln(); // Writes [0, 0, 0, 0, 0, 0, 0,
0, 0]
statArr3().writeln(); // Writes [0, 0, 0]
statArr2().writeln(); // Writes [0, 0]
statArr1().writeln(); // Writes [0]
statArr0().writeln(); // Writes []
// 2 bugs
statArr9()[0].writeln();// OK : Writes 0
statArr3()[0].writeln();// OK : Writes 0
//statArr2()[0].writeln(); // BUG: Internal error:
..\ztc\cgcs.c 344
//statArr1()[0].writeln(); // BUG: Internal error:
..\ztc\cgcs.c 344
//statArr0()[0].writeln(); // OK : Error: array index 0 is
out of bounds
// getArr0()[0 .. 0]
alias dynArr9 = Template!(9, int).dynArr;
alias dynArr3 = Template!(3, int).dynArr;
alias dynArr2 = Template!(2, int).dynArr;
alias dynArr1 = Template!(1, int).dynArr;
alias dynArr0 = Template!(0, int).dynArr;
dynArr9()[0].writeln(); // OK: Writes 0
dynArr3()[0].writeln(); // OK: Writes 0
dynArr2()[0].writeln(); // OK: Writes 0
dynArr1()[0].writeln(); // OK: Writes 0
//dynArr0()[0].writeln(); // OK:
core.exception.RangeError:
// Range violation
// Other types
//Template!(2, bool).statArr()[0].writeln();// BUG
//Template!(2, byte).statArr()[0].writeln();// BUG
//Template!(2, ubyte).statArr()[0].writeln(); // BUG
//Template!(2, short).statArr()[0].writeln(); // BUG
//Template!(2, ushort).statArr()[0].writeln(); // BUG
//Template!(2, int).statArr()[0].writeln(); // BUG
//Template!(2, uint).statArr()[0].writeln();// BUG
//Template!(2, long).statArr()[0].writeln();// BUG
//Template!(2, ulong).statArr()[0].writeln(); // BUG
//Template!(2, float).statArr()[0].writeln(); // BUG
//Template!(2, double).statArr()[0].writeln(); // BUG
Template!(2, real).statArr()[0].writeln(); // OK :
Writes nan
//Template!(2, ifloat).statArr()[0].writeln(); // BUG
//Template!(2, idouble).statArr()[0].writeln(); // BUG
Template!(2, ireal).statArr()[0].writeln(); // OK :
Writes inan
//Template!(2, cfloat).statArr()[0].writeln(); // BUG
Template!(2, cdouble).statArr()[0].writeln(); // OK :
Writes nan+nani
Template!(2, creal).statArr()[0].writeln(); // OK :
Writes nan+nani
//Template!(2, char).statArr()[0].writeln();// BUG
//Template!(2, wchar).statArr()[0].writeln(); // BUG
//Template!(2, dchar).statArr()[0].writeln(); // BUG
struct Sint { int a; }
struct Sreal{ real a; }
Template!(2, Sint).statArr()[0].writeln(); // OK :
Writes Sint(0)
Template!(2, Sreal).statArr()[0].writeln(); // OK :
Writes Sreal(nan)
}
Found in both dmd 2.061 and 2.062 for 32- and 64-bit. Other
types only tested with dmd 2.062.
btw: all the imaginary/complex builtin types will likely be
deprecated at some point in the future. std.complex is the
intended replacement
Re: Bug: Accessing return value of type static array with length 1 or 2 by index.
On Saturday, 20 April 2013 at 13:37:55 UTC, John Colvin wrote:
On Saturday, 20 April 2013 at 12:23:20 UTC, deed wrote:
import std.stdio : writeln;
template Template (uint n, T)
{
T[n] statArr()
{
T[n] arr;
return arr;
}
T[] dynArr()
{
T[] dynArr = new T[n];
return dynArr;
}
}
void main()
{
alias statArr9 = Template!(9, int).statArr;
alias statArr3 = Template!(3, int).statArr;
alias statArr2 = Template!(2, int).statArr;
alias statArr1 = Template!(1, int).statArr;
alias statArr0 = Template!(0, int).statArr;
// Fine
statArr9().writeln(); // Writes [0, 0, 0, 0, 0, 0, 0,
0, 0]
statArr3().writeln(); // Writes [0, 0, 0]
statArr2().writeln(); // Writes [0, 0]
statArr1().writeln(); // Writes [0]
statArr0().writeln(); // Writes []
// 2 bugs
statArr9()[0].writeln();// OK : Writes 0
statArr3()[0].writeln();// OK : Writes 0
//statArr2()[0].writeln(); // BUG: Internal error:
..\ztc\cgcs.c 344
//statArr1()[0].writeln(); // BUG: Internal error:
..\ztc\cgcs.c 344
//statArr0()[0].writeln(); // OK : Error: array index 0 is
out of bounds
// getArr0()[0 .. 0]
alias dynArr9 = Template!(9, int).dynArr;
alias dynArr3 = Template!(3, int).dynArr;
alias dynArr2 = Template!(2, int).dynArr;
alias dynArr1 = Template!(1, int).dynArr;
alias dynArr0 = Template!(0, int).dynArr;
dynArr9()[0].writeln(); // OK: Writes 0
dynArr3()[0].writeln(); // OK: Writes 0
dynArr2()[0].writeln(); // OK: Writes 0
dynArr1()[0].writeln(); // OK: Writes 0
//dynArr0()[0].writeln(); // OK:
core.exception.RangeError:
// Range violation
// Other types
//Template!(2, bool).statArr()[0].writeln();// BUG
//Template!(2, byte).statArr()[0].writeln();// BUG
//Template!(2, ubyte).statArr()[0].writeln(); // BUG
//Template!(2, short).statArr()[0].writeln(); // BUG
//Template!(2, ushort).statArr()[0].writeln(); // BUG
//Template!(2, int).statArr()[0].writeln(); // BUG
//Template!(2, uint).statArr()[0].writeln();// BUG
//Template!(2, long).statArr()[0].writeln();// BUG
//Template!(2, ulong).statArr()[0].writeln(); // BUG
//Template!(2, float).statArr()[0].writeln(); // BUG
//Template!(2, double).statArr()[0].writeln(); // BUG
Template!(2, real).statArr()[0].writeln(); // OK :
Writes nan
//Template!(2, ifloat).statArr()[0].writeln(); // BUG
//Template!(2, idouble).statArr()[0].writeln(); // BUG
Template!(2, ireal).statArr()[0].writeln(); // OK :
Writes inan
//Template!(2, cfloat).statArr()[0].writeln(); // BUG
Template!(2, cdouble).statArr()[0].writeln(); // OK :
Writes nan+nani
Template!(2, creal).statArr()[0].writeln(); // OK :
Writes nan+nani
//Template!(2, char).statArr()[0].writeln();// BUG
//Template!(2, wchar).statArr()[0].writeln(); // BUG
//Template!(2, dchar).statArr()[0].writeln(); // BUG
struct Sint { int a; }
struct Sreal{ real a; }
Template!(2, Sint).statArr()[0].writeln(); // OK :
Writes Sint(0)
Template!(2, Sreal).statArr()[0].writeln(); // OK :
Writes Sreal(nan)
}
Found in both dmd 2.061 and 2.062 for 32- and 64-bit. Other
types only tested with dmd 2.062.
I can only replicate one of these bugs in dmd git master x64,
the cfloat one. It segfaults during the initialisation of the
array.
dmd calls _memset64 to do the initialisation. It seems to
(partially) forget that we're in x64 and tries to pass the
value to set to (float.nan) on the stack.
The result: A complete mess. Not enough arguments, in the wrong
places.
_memset64 gets the right destination pointer but gets the
length of the array (2) as the value to write and then tries to
initialise RDX number of values. But RDX was never set.
Segfault.
bug submitted:
http://d.puremagic.com/issues/show_bug.cgi?id=9969
Re: subclass to base class but not subclass pointer to base class pointer?
On 4/20/13, Namespace rswhi...@googlemail.com wrote: Why can D implicitly cast from the subclass to the base class, but not implicitly from the subclasse pointer to the base class pointer? This works: http://dpaste.1azy.net/30dd34a0 This not: http://dpaste.1azy.net/ffacfd83 Makes not much sense for me. I'd really recommend reading one of the D books before asking so many fundamental questions: http://wiki.dlang.org/Books And probably the spec too. Bottom line: D is not C++.
Re: subclass to base class but not subclass pointer to base class pointer?
On Saturday, 20 April 2013 at 15:32:20 UTC, Andrej Mitrovic wrote: On 4/20/13, Namespace rswhi...@googlemail.com wrote: Why can D implicitly cast from the subclass to the base class, but not implicitly from the subclasse pointer to the base class pointer? This works: http://dpaste.1azy.net/30dd34a0 This not: http://dpaste.1azy.net/ffacfd83 Makes not much sense for me. I'd really recommend reading one of the D books before asking so many fundamental questions: http://wiki.dlang.org/Books And probably the spec too. Bottom line: D is not C++. It's not allowed in c++ either. See my original reply.
Re: subclass to base class but not subclass pointer to base class pointer?
On Saturday, 20 April 2013 at 14:56:25 UTC, Namespace wrote:
Why can D implicitly cast from the subclass to the base class,
but not implicitly from the subclasse pointer to the base class
pointer?
This works: http://dpaste.1azy.net/30dd34a0
This not: http://dpaste.1azy.net/ffacfd83
Makes not much sense for me.
a pointer to class in D is actually a pointer to a pointer as
classes are reference types. Polymorphism for pointers to
pointers to objects is not allowed.
Consider this (ported from here
https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.c++/kNZ-ksORPwU):
class Base
{
void doBaseThings();
}
class Dirv
{
doDirvThings();
}
void AssignNewBaseTo(Base* basePtr)
{
*basePtr = new Base;
}
void Oops()
{
Dirv dirv;
AssignNewBaseTo(dirv);
dirv.doDirvThings(); // runtime crash -- a Base
object
// being asked to do Dirv
things.
}
Direlect3 with Mono-D
I have all the needed files to use Direlect3, and I have Mono-D installed on Xamarin, I was wondering how I could put it all together in a project.
Re: Calculation differences between Debug and Release mode
Thanks for the analysis. On 04/20/2013 05:30 AM, Simen Kjaeraas wrote: static const(float) pi = 3.141592654f; If we compare that to std.math.PI, we see that they're different: writeln( 3.141592654f - std.math.PI ); 4.10207e-10 std.math.PI is a 'real'. According to the language definition, the calculation above must be done as 'real'. It is described under Usual Arithmetic Conversions here: http://dlang.org/type.html Quoting: If either operand is real, the other operand is converted to real. Unfortunately, the variable 'pi' above cannot be as good a representation of pi as std.math.PI. If, however, we assign these values to some temporary floats, we see that they're equal: float a = 3.141592654f; float b = std.math.PI; It is arguable whether that lossy conversion from real to float should be allowed. Such rules have been inherited all the way from C. They will not change at this point for D. :/ writeln( a - b ); 0 Replace float with double or real in the above, and the difference reappears. So, we have established that 3.141592654f is a valid approximation to pi for a float. The problem thus has to be one of precision. I'm not sure if it's a valid optimization for the compiler to use doubles instead of floats (it certainly seem innocuous enough). I'd say file a bug on it. Worst case, it gets closed as invalid. Unfortunately, it is not a bug in D or dmd. Ali
Re: Quadratic time to sort in a simple case?
20-Apr-2013 16:22, Chris Cain пишет: On Friday, 19 April 2013 at 22:56:00 UTC, bearophile wrote: So, why isn't TimSort the default? Probably because someone thinks that on average the other sort is faster. In theory the other should be faster, because if you relax the constraints of the sort being stable I think in theory you should be able to write a little faster sorting algorithm (I don't know if this is true). I'm just throwing my 2c in, but I think TimSort ought to be the default. It's simply the safer option. Since worst-case performance can be designed (and it can be designed unless the pivots are, at least, pseudo-randomly chosen), there is a very real risk of the default sort being used in a way that can be compromised by an attacker. From this perspective, seems to be like TimSort being default would support the design goal #5 of D, Make doing things the right way easier than the wrong way. And this all is good but TimSort allocates O(N) memory. The constant in front of N is smallish less then 1.0 but it could cause some grief. -- Dmitry Olshansky
Re: subclass to base class but not subclass pointer to base class pointer?
On Saturday, 20 April 2013 at 15:34:50 UTC, John Colvin wrote: On Saturday, 20 April 2013 at 15:32:20 UTC, Andrej Mitrovic wrote: On 4/20/13, Namespace rswhi...@googlemail.com wrote: Why can D implicitly cast from the subclass to the base class, but not implicitly from the subclasse pointer to the base class pointer? This works: http://dpaste.1azy.net/30dd34a0 This not: http://dpaste.1azy.net/ffacfd83 Makes not much sense for me. I'd really recommend reading one of the D books before asking so many fundamental questions: http://wiki.dlang.org/Books And probably the spec too. Bottom line: D is not C++. It's not allowed in c++ either. See my original reply. It works fine in C++ (of course with -std=c++0x) http://codepad.org/qLIjGGd4 But thanks for your answer. I know that D classes a reference types but I was thinking that the compiler could detect what I want and could implicit cast. I'd really recommend reading one of the D books before asking so many fundamental questions: http://wiki.dlang.org/Books And probably the spec too. Not very helpful. But why many? I cannot remember one fundamental question.
Re: subclass to base class but not subclass pointer to base class pointer?
On Saturday, 20 April 2013 at 16:36:09 UTC, Namespace wrote: It works fine in C++ (of course with -std=c++0x) http://codepad.org/qLIjGGd4 It's been a while since I did any c++ but: 1) I don't see any pointer to pointer polymorphism in there. 2) That c++ code is equivalent to the version of your D code that works, not the version that doesn't.
Re: subclass to base class but not subclass pointer to base class pointer?
On Saturday, 20 April 2013 at 17:24:33 UTC, John Colvin wrote: On Saturday, 20 April 2013 at 16:36:09 UTC, Namespace wrote: It works fine in C++ (of course with -std=c++0x) http://codepad.org/qLIjGGd4 It's been a while since I did any c++ but: 1) I don't see any pointer to pointer polymorphism in there. 2) That c++ code is equivalent to the version of your D code that works, not the version that doesn't. I return a pointer from an instance of B and the compiler cast it implicit to A*. Look what is inside of 'bstore' (instances of B) and what the type of 'get' is (A*). And no, the equivalent version would use 'A' as return type of 'get', not 'A*'.
Re: Calculation differences between Debug and Release mode
The D book has a diagram that shows implicit conversions. All implicit conversions from integral types to floating point go to real, not double or float.
Re: subclass to base class but not subclass pointer to base class pointer?
I return a pointer from an instance of B and the compiler cast it implicit to A*. Look what is inside of 'bstore' (instances of B) and what the type of 'get' is (A*). And no, the equivalent version would use 'A' as return type of 'get', not 'A*'. Ah, I think I understand know what you meant. Sure there is no pointer to pointer polymorphism in there. But I thought, even if D classes are reference types and not really compareable to C++ classes, that the compiler could do the same implicit cast for pointer of D classes. ;)
Re: Direlect3 with Mono-D
No responses? Should I post this somewhere else?
Re: Direlect3 with Mono-D
Dne 20.4.2013 20:45, Dementor561 napsal(a): No responses? Should I post this somewhere else? Hi, this is the correct forum. However, you may have to wait a while. It is Saturday and the group of people who use Derelict with Mono-D is probably only a small subset of participants in this forum (I am not one of them). In a nutshell - be patient. Regards, Martin
Re: Calculation differences between Debug and Release mode
On 04/20/2013 11:04 AM, Casper Færgemand shortt...@gmail.com wrote: The D book has a diagram that shows implicit conversions. It is Figure 2.3 on page 44 of my copy of TDPL. All implicit conversions from integral types to floating point go to real, not double or float. Yes. The figure shows that implicit conversions are possible between float--double and double--real (in both directions). It indicates that float--real is possible as well. Ali
Re: subclass to base class but not subclass pointer to base class pointer?
On Saturday, 20 April 2013 at 17:42:02 UTC, Namespace wrote: And no, the equivalent version would use 'A' as return type of 'get', not 'A*'. Sorry, no. //C++ A* get(unsigned int id); //D A get(unsigned int id); Those are the equivalent declarations. A reference is, for these intents and purposes, a pointer and D classes are reference types. In D, get returns a reference to an object, i.e. a pointer to an object. C++ does not have polymorphic pointers to pointers to class objects, for good reason (see my original reply). AFAIK the same reasons apply to D, hence D has no polymorphic pointers to references to class objects.
Re: subclass to base class but not subclass pointer to base class pointer?
On Saturday, 20 April 2013 at 21:36:37 UTC, John Colvin wrote: On Saturday, 20 April 2013 at 17:42:02 UTC, Namespace wrote: And no, the equivalent version would use 'A' as return type of 'get', not 'A*'. Sorry, no. //C++ A* get(unsigned int id); //D A get(unsigned int id); Those are the equivalent declarations. A reference is, for these intents and purposes, a pointer and D classes are reference types. In D, get returns a reference to an object, i.e. a pointer to an object. C++ does not have polymorphic pointers to pointers to class objects, for good reason (see my original reply). AFAIK the same reasons apply to D, hence D has no polymorphic pointers to references to class objects. woops, that should be uint in the D declaration not unsinged int.
