Re: Beta problems
On 13.10.2013 01:49, Namespace wrote: I can't reproduce the error but with the current beta I get in a specific project this output: Compiling Audio\Core\core.d... D:\D\dmd2\windows\bin\..\..\src\phobos\std\array.d(15): Error: importing package 'memory' requires a 'package.d' file which cannot be found in 'core\memory\package.d' import path[0] = D:\D\dmd2\src\ext import path[1] = D:\D\dmd2\windows\bin\..\..\src\phobos import path[2] = D:\D\dmd2\windows\bin\..\..\src\druntime\import binaryD:\D\dmd2\windows\bin\dmd.exe version v2.064 configD:\D\dmd2\windows\bin\sc.ini parse core importall core import object (D:\D\dmd2\windows\bin\..\..\src\druntime\import\object.di) import derelict.openal.al(D:\D\dmd2\src\ext\derelict\openal\al.d) import derelict.openal.types(D:\D\dmd2\src\ext\derelict\openal\types.d) import derelict.openal.functions (D:\D\dmd2\src\ext\derelict\openal\functions.d) import derelict.util.loader(D:\D\dmd2\src\ext\derelict\util\loader.d) import std.array(D:\D\dmd2\windows\bin\..\..\src\phobos\std\array.d) importcore.memory(core\memory\package.d) Building Debug\Audio-Core-core.obj failed! If I try to reproduce it with a reduced test case, I get the right output: importstd.array (D:\D\dmd2\windows\bin\..\..\src\phobos\std\array.d) importcore.memory (D:\D\dmd2\windows\bin\..\..\src\druntime\import\core\me mory.d) What could cause the error? Any ideas? I have no idea... My best guess is that you have a directory names core\memory in your source directory. I'm not sure if it qualifies as a dmd regression, maybe it should continue searching for core.memory in the other import folders.
Re: Begining with D
On Saturday, 12 October 2013 at 21:27:18 UTC, 1100110 wrote:
On 10/10/2013 02:36 PM, Adam D. Ruppe wrote:
On Thursday, 10 October 2013 at 19:19:53 UTC, Ali Çehreli
wrote:
import std.c.linux.termios;
worth noting that this is Linux only. doing it on Windows is a
little
different.
Working with console/terminal input and output can get
surprisingly
complex, and doing it cross-platform is easiest with a library.
Robik's consoleD is one:
https://github.com/robik/ConsoleD/blob/master/consoled.d
it focuses on enabling color and drawing mainly, and also has
functions
to turn off the line buffering and getch().
If you use his library, you can do this:
import consoled;
void main() {
int a = getch(); // gets just one character
writecln(a); // prints back out what you got
}
and other nice things.
I had issues with getch() on ConsoleD...
If you too have issue, you can try
github.com/D-Programming-Deimos/ncurses which has similar
functions, but is also way more complex...
I guess its was on linux right? Probably because some last
quickfixes i added wasn't propely (read never) tested on linux :P
Soon I'll try to finally start working on merging terminald and
consoled somehow.
Re: Beta problems
Nice try. I get another error which is maybe related. core/memory.d with nothing else than import std.array causes D:\D\dmd2\windows\bin\..\..\src\phobos\std\array.d(15): Error: module memory fro m file core\memory.d must be imported as module 'memory' And with core/all.d: module core.all; import std.array; and core/memory/test.d I get it: C:\Users\Besitzer\Desktopdmd core/all.d core/memory/test.d -v binaryD:\D\dmd2\windows\bin\dmd.exe version v2.064 configD:\D\dmd2\windows\bin\sc.ini parse all parse test importall all importobject (D:\D\dmd2\windows\bin\..\..\src\druntime\import\object. di) importstd.array (D:\D\dmd2\windows\bin\..\..\src\phobos\std\array.d) importcore.memory (core\memory\package.d) D:\D\dmd2\windows\bin\..\..\src\phobos\std\array.d(15): Error: importing package 'memory' requires a 'package.d' file which cannot be found in 'core\memory\pack age.d' import path[0] = D:\D\dmd2\windows\bin\..\..\src\phobos import path[1] = D:\D\dmd2\windows\bin\..\..\src\druntime\import Even if I compile only core/all.d: C:\Users\Besitzer\Desktopdmd core/all.d D:\D\dmd2\windows\bin\..\..\src\phobos\std\array.d(15): Error: importing package 'memory' requires a 'package.d' file which cannot be found in 'core\memory\pack age.d' import path[0] = D:\D\dmd2\windows\bin\..\..\src\phobos import path[1] = D:\D\dmd2\windows\bin\..\..\src\druntime\import
Re: Begining with D
On Thursday, 10 October 2013 at 18:56:58 UTC, Alejandro wrote:
Hi
I'm new in D, have some experience in JavaScript and PHP, and
learned, for long time ago, C and a bit little C++
I remember that when I learned C with console output, it was
two easy ways to catch input : one witch a required Enter
keydown, and an other witch catched a single character, a
single keydown. I liked very much this last function (I think
it was get()), very useful when making small programs for
learning purposes.
I'm looking for something like that in D, widthout finding it.
I'm sorry coming here width my bad English asking a question
like that, I see everyone here has a hight level in coding D,
but since there is no much documentation around Internet, I
don't find another solution.
I think what you want is as simple as following.
import std.process;
void main()
{
//try and learn here
system(pause);
}
Re: Begining with D
On Sunday, 13 October 2013 at 11:45:39 UTC, Elvis Zhou wrote:
On Thursday, 10 October 2013 at 18:56:58 UTC, Alejandro wrote:
Hi
I'm new in D, have some experience in JavaScript and PHP, and
learned, for long time ago, C and a bit little C++
I remember that when I learned C with console output, it was
two easy ways to catch input : one witch a required Enter
keydown, and an other witch catched a single character, a
single keydown. I liked very much this last function (I think
it was get()), very useful when making small programs for
learning purposes.
I'm looking for something like that in D, widthout finding it.
I'm sorry coming here width my bad English asking a question
like that, I see everyone here has a hight level in coding D,
but since there is no much documentation around Internet, I
don't find another solution.
I think what you want is as simple as following.
import std.process;
void main()
{
//try and learn here
system(pause);
}
windows only
Memory leaks
Windows task manager shows constantly increasing memory usage of my D application, yet there is ZERO allocation done by it at the time. I have made a hook inside the rt/lifetime.d for _d_allocmemory, and I do get notified when an array or a class object in constructed. What could be the source of rapidly climbing (hundred kilobytes per second) memory usage?
Re: Linker error: Symbol Undefined
On Friday, 11 October 2013 at 22:33:31 UTC, Namespace wrote:
On Friday, 11 October 2013 at 21:16:38 UTC, Brad Roberts wrote:
It's due to having the destructor versioned out when building
foo and visible when building bar. When brought together,
you've created an incompatible whole. There's no destructor
actually included in foo's .o file that you told it it could
expect to find.
There's no bug in the compiler or linker, just your usage of
mis-matched code.
On 10/11/13 11:39 AM, Namespace wrote:
Hey, I'm curious about this linker error:
OPTLINK (R) for Win32 Release 8.00.13
Copyright (C) Digital Mars 1989-2010 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
bar.obj(bar)
Error 42: Symbol Undefined _D3foo1A6__dtorMFZv
--- errorlevel 1
foo.d:
debug import std.stdio;
struct A {
public:
int id;
this(int id) {
debug writeln(CTor A with , id);
this.id = id;
}
debug ~this() {
writeln(DTor A with , id);
}
}
bar.d
import foo;
void test(A a) {
a.id++;
}
void main() {
test(A(42));
A a = A(23);
test(a);
}
Usage:
C:\Users\Besitzer\Desktopdmd -lib foo.d
C:\Users\Besitzer\Desktopdmd bar.d foo.lib -debug
OPTLINK (R) for Win32 Release 8.00.13
Copyright (C) Digital Mars 1989-2010 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
bar.obj(bar)
Error 42: Symbol Undefined _D3foo1A6__dtorMFZv
--- errorlevel 1
Without -debug or with 'debug' _in_ the DTor (before writeln)
instead before the DTor works fine.
Another question: Is there a way that the DTor is only
generated if I compile foo with -debug? So that if I compile
and link bar.d and foo.lib, even with -debug, but compiled
foo.d without, the DTor is automatically generated? Hope that
is not to weird. :D
No, you can't. However, you can use other version condition
instead to avoid debug code.
foo.d:
version(TrackDTor){
import std.stdio;
}
struct A {
public:
int id;
this(int id) {
debug writeln(CTor A with , id);
this.id = id;
}
version(TrackDTor){
~this() {
writeln(DTor A with , id);
}
}
}
then compile foo.d with -version=TrackDTor
Re: Memory leaks
Am 13.10.2013 14:08, schrieb develop32: Windows task manager shows constantly increasing memory usage of my D application, yet there is ZERO allocation done by it at the time. I have made a hook inside the rt/lifetime.d for _d_allocmemory, and I do get notified when an array or a class object in constructed. What could be the source of rapidly climbing (hundred kilobytes per second) memory usage? If your programm is a 32-bit application the GC most likely leaks memory because it thinks its still referenced. Try compilling your application for 64-bit. If the problem goes away it's not your fault. A possible workaround for this situation is to allocate large blocks of memory which you know will not contain any pointers with GC.malloc manually and specifying the don't scan flag. If the problem still exists in a 64-bit application you most likely continue to allocate memory that remains referenced. Make sure you don't have any infinitly growing arrays or other containers that still reference the memory you allocated. -- Kind Regards Benjamin Thaut
Re: Array copy warning
Am 13.10.2013 15:10, schrieb Benjamin Thaut: I'm just in the progress of upgrading to dmd 2.063 and I now get the following warnings in my code: Warning: explicit element-wise assignment mem[cast(uint)0..this.length()] = (this.opSlice())[] is better than mem[cast(uint)0..this.length()] = this.opSlice() I don't quite understand this warning. It doesn't make much sense to overload the slice operator if I can't use it the same way as the regular slice operator on a normal array. Whats the idea behind this warning? Additionally this warning appears in generic code. Which means I don't even now if a regular array is passed in as a argument or just a type which overloads the slice operator. -- Kind Regards Benjamin Thaut
Re: Memory leaks
On Sunday, 13 October 2013 at 13:18:47 UTC, Benjamin Thaut wrote: Am 13.10.2013 14:08, schrieb develop32: Windows task manager shows constantly increasing memory usage of my D application, yet there is ZERO allocation done by it at the time. I have made a hook inside the rt/lifetime.d for _d_allocmemory, and I do get notified when an array or a class object in constructed. What could be the source of rapidly climbing (hundred kilobytes per second) memory usage? If your programm is a 32-bit application the GC most likely leaks memory because it thinks its still referenced. Try compilling your application for 64-bit. If the problem goes away it's not your fault. A possible workaround for this situation is to allocate large blocks of memory which you know will not contain any pointers with GC.malloc manually and specifying the don't scan flag. If the problem still exists in a 64-bit application you most likely continue to allocate memory that remains referenced. Make sure you don't have any infinitly growing arrays or other containers that still reference the memory you allocated. Thanks, will try 64-bit when possible. No, there are no allocations in my code, I have set breakpoints wherever I can throughout it and there are no allocations being made every frame (its a video game). I don't use built-in dynamic array directly, have my own wrapper for it. My question is, are there any more places in druntime that I can change so that I will get a notification when allocation occurs, besides _d_allocmemory?
Re: Memory leaks
On Sunday, 13 October 2013 at 13:18:47 UTC, Benjamin Thaut wrote: Am 13.10.2013 14:08, schrieb develop32: Windows task manager shows constantly increasing memory usage of my D application, yet there is ZERO allocation done by it at the time. I have made a hook inside the rt/lifetime.d for _d_allocmemory, and I do get notified when an array or a class object in constructed. What could be the source of rapidly climbing (hundred kilobytes per second) memory usage? If your programm is a 32-bit application the GC most likely leaks memory because it thinks its still referenced. Try compilling your application for 64-bit. If the problem goes away it's not your fault. A possible workaround for this situation is to allocate large blocks of memory which you know will not contain any pointers with GC.malloc manually and specifying the don't scan flag. If the problem still exists in a 64-bit application you most likely continue to allocate memory that remains referenced. Make sure you don't have any infinitly growing arrays or other containers that still reference the memory you allocated. I've added GC.collect and GC.minimize() at the end of each frame, looks like the growth has stopped, so its not a 32-bit problem yet.
Re: Memory leaks
On Sunday, 13 October 2013 at 13:46:13 UTC, develop32 wrote: My question is, are there any more places in druntime that I can change so that I will get a notification when allocation occurs, besides _d_allocmemory? I set breakpoints on gc_malloc and gc_qalloc too. I'm pretty sure they catch more than d_allocmemory. qalloc in particular catches accidental usage of array literals. Yes, they always allocate at runtime unless specifically marked static... i'd love for that to change!
Re: Memory leaks
Am 13.10.2013 15:52, schrieb develop32: On Sunday, 13 October 2013 at 13:18:47 UTC, Benjamin Thaut wrote: Am 13.10.2013 14:08, schrieb develop32: Windows task manager shows constantly increasing memory usage of my D application, yet there is ZERO allocation done by it at the time. I have made a hook inside the rt/lifetime.d for _d_allocmemory, and I do get notified when an array or a class object in constructed. What could be the source of rapidly climbing (hundred kilobytes per second) memory usage? If your programm is a 32-bit application the GC most likely leaks memory because it thinks its still referenced. Try compilling your application for 64-bit. If the problem goes away it's not your fault. A possible workaround for this situation is to allocate large blocks of memory which you know will not contain any pointers with GC.malloc manually and specifying the don't scan flag. If the problem still exists in a 64-bit application you most likely continue to allocate memory that remains referenced. Make sure you don't have any infinitly growing arrays or other containers that still reference the memory you allocated. I've added GC.collect and GC.minimize() at the end of each frame, looks like the growth has stopped, so its not a 32-bit problem yet. Well the GC doesn't kick in always. It only collects memory when its neccessary (a certain limit is reached). For a game it is usually a good idea to run the GC every frame to avoid the ocasional long pause times that otherwise occur. Or you could work around the GC entierly. Kind Regards Benjamin Thaut -- Kind Regards Benjamin Thaut
Re: Memory leaks
On Sunday, 13 October 2013 at 14:01:09 UTC, Adam D. Ruppe wrote: On Sunday, 13 October 2013 at 13:46:13 UTC, develop32 wrote: My question is, are there any more places in druntime that I can change so that I will get a notification when allocation occurs, besides _d_allocmemory? I set breakpoints on gc_malloc and gc_qalloc too. I'm pretty sure they catch more than d_allocmemory. qalloc in particular catches accidental usage of array literals. Yes, they always allocate at runtime unless specifically marked static... i'd love for that to change! Thank you, that helped to find it. Its as shame that usage of static arrays doesn't prevent heap allocation.
Re: Memory leaks
Am 13.10.2013 16:23, schrieb develop32: On Sunday, 13 October 2013 at 14:13:39 UTC, Benjamin Thaut wrote: Am 13.10.2013 15:52, schrieb develop32: On Sunday, 13 October 2013 at 13:18:47 UTC, Benjamin Thaut wrote: Am 13.10.2013 14:08, schrieb develop32: Windows task manager shows constantly increasing memory usage of my D application, yet there is ZERO allocation done by it at the time. I have made a hook inside the rt/lifetime.d for _d_allocmemory, and I do get notified when an array or a class object in constructed. What could be the source of rapidly climbing (hundred kilobytes per second) memory usage? If your programm is a 32-bit application the GC most likely leaks memory because it thinks its still referenced. Try compilling your application for 64-bit. If the problem goes away it's not your fault. A possible workaround for this situation is to allocate large blocks of memory which you know will not contain any pointers with GC.malloc manually and specifying the don't scan flag. If the problem still exists in a 64-bit application you most likely continue to allocate memory that remains referenced. Make sure you don't have any infinitly growing arrays or other containers that still reference the memory you allocated. I've added GC.collect and GC.minimize() at the end of each frame, looks like the growth has stopped, so its not a 32-bit problem yet. Well the GC doesn't kick in always. It only collects memory when its neccessary (a certain limit is reached). For a game it is usually a good idea to run the GC every frame to avoid the ocasional long pause times that otherwise occur. Or you could work around the GC entierly. Kind Regards Benjamin Thaut Indeed, I tried to work around it and use manual memory management a year ago, but everything felt so ugly that I decided to throw that and go the idiomatic way. I'm bit surprised that even with GC running every frame I haven't noticed a drop in performance, even when using more than 1 gb RAM. Did you profile how much time the GC takes every frame? For me that was 8-9 ms every frame. That was not acceptable for my case. -- Kind Regards Benjamin Thaut
Re: Memory leaks
On Sunday, 13 October 2013 at 14:31:13 UTC, Benjamin Thaut wrote: Am 13.10.2013 16:23, schrieb develop32: On Sunday, 13 October 2013 at 14:13:39 UTC, Benjamin Thaut wrote: Am 13.10.2013 15:52, schrieb develop32: On Sunday, 13 October 2013 at 13:18:47 UTC, Benjamin Thaut wrote: Am 13.10.2013 14:08, schrieb develop32: Windows task manager shows constantly increasing memory usage of my D application, yet there is ZERO allocation done by it at the time. I have made a hook inside the rt/lifetime.d for _d_allocmemory, and I do get notified when an array or a class object in constructed. What could be the source of rapidly climbing (hundred kilobytes per second) memory usage? If your programm is a 32-bit application the GC most likely leaks memory because it thinks its still referenced. Try compilling your application for 64-bit. If the problem goes away it's not your fault. A possible workaround for this situation is to allocate large blocks of memory which you know will not contain any pointers with GC.malloc manually and specifying the don't scan flag. If the problem still exists in a 64-bit application you most likely continue to allocate memory that remains referenced. Make sure you don't have any infinitly growing arrays or other containers that still reference the memory you allocated. I've added GC.collect and GC.minimize() at the end of each frame, looks like the growth has stopped, so its not a 32-bit problem yet. Well the GC doesn't kick in always. It only collects memory when its neccessary (a certain limit is reached). For a game it is usually a good idea to run the GC every frame to avoid the ocasional long pause times that otherwise occur. Or you could work around the GC entierly. Kind Regards Benjamin Thaut Indeed, I tried to work around it and use manual memory management a year ago, but everything felt so ugly that I decided to throw that and go the idiomatic way. I'm bit surprised that even with GC running every frame I haven't noticed a drop in performance, even when using more than 1 gb RAM. Did you profile how much time the GC takes every frame? For me that was 8-9 ms every frame. That was not acceptable for my case. Currently it is 3 ms, would love to drop that to one. Though I'm using a very slow laptop, can't play any AAA game released in last 5 years.
Re: Call a function with a function pointer
Am 10.10.2013 17:45, schrieb Namespace:
On Thursday, 10 October 2013 at 15:15:45 UTC, bearophile wrote:
Namespace:
You mean like this?
void foo(T)(extern(C) void function(T*) func) {
}
That prints: Error: basic type expected, not extern
In theory that's correct, in practice the compiler refuses that, it's
in Bugzilla, so try to define the type outside the signature (untested):
alias TF = extern(C) void function(T*);
void foo(T)(TF func) {}
Bye,
bearophile
/d917/f732.d(8): Error: basic type expected, not extern
/d917/f732.d(8): Error: semicolon expected to close alias declaration
/d917/f732.d(8): Error: no identifier for declarator void function(T*)
I found a possible workaround. Its ugly as hell, but at least it works
until the bugs are fixed. The trick is to make a helper struct. Define
the function you want within that, and then use typeof to get the type.
import std.stdio;
extern(C) void testFunc(int* ptr)
{
*ptr = 5;
}
struct TypeHelper(T)
{
extern(C) static void func(T*);
alias typeof(func) func_t;
}
void Foo(T)(TypeHelper!T.func_t func, T* val)
{
func(val);
}
void main(string[] args)
{
pragma(msg, TypeHelper!int.func_t.stringof);
int test = 0;
Foo!int(testFunc, test);
writefln(%d, test);
}
--
Kind Regards
Benjamin Thaut
Re: Traits
On 10/13/13 02:25, luminousone wrote:
On Saturday, 12 October 2013 at 23:48:56 UTC, Artur Skawina wrote:
template isBaseOf(BASE, C) {
enum isBaseOf = {
static if (is(C S == super))
foreach (A; S)
static if (isBaseOf!(BASE, A))
return true;
return is(C==BASE);
}();
}
Sorry, didn't test this properly; going to blame the dlang is-expression
docs.
It's not like D has multiple inheritance, so using base classes (plural)
is very misleading...
yea is can be a lil confusing, especially that is( C S == super)
expression.
I take it that is( C S == super) is only the bases directly listed for
inheritance by the class and not the bases bases as well? which is the reason
for the change you made their?
Yes, D supports only single inheritance, so there can never be more than
one super class (plus interfaces). I'm not using classes in D often and
when I looked up that is-expr syntax, the wrong doc confused me. It should
say base class (or super class), not base classes.
artur
Re: Call a function with a function pointer
On 10/13/13 16:43, Benjamin Thaut wrote:
Am 10.10.2013 17:45, schrieb Namespace:
On Thursday, 10 October 2013 at 15:15:45 UTC, bearophile wrote:
Namespace:
You mean like this?
void foo(T)(extern(C) void function(T*) func) {
}
That prints: Error: basic type expected, not extern
In theory that's correct, in practice the compiler refuses that, it's
in Bugzilla, so try to define the type outside the signature (untested):
alias TF = extern(C) void function(T*);
void foo(T)(TF func) {}
Bye,
bearophile
/d917/f732.d(8): Error: basic type expected, not extern
/d917/f732.d(8): Error: semicolon expected to close alias declaration
/d917/f732.d(8): Error: no identifier for declarator void function(T*)
I found a possible workaround. Its ugly as hell, but at least it works until
the bugs are fixed.
There's no need for such ugly workarounds -- this is just a problem with
the *new* alias syntax. The old one accepts it (unless this changed recently):
alias extern(C) static void function(int*) Func_t;
artur
Re: Array copy warning
On 10/13/2013 03:15 PM, Benjamin Thaut wrote: Am 13.10.2013 15:10, schrieb Benjamin Thaut: I'm just in the progress of upgrading to dmd 2.063 and I now get the following warnings in my code: Warning: explicit element-wise assignment mem[cast(uint)0..this.length()] = (this.opSlice())[] is better than mem[cast(uint)0..this.length()] = this.opSlice() I don't quite understand this warning. It doesn't make much sense to overload the slice operator if I can't use it the same way as the regular slice operator on a normal array. Whats the idea behind this warning? Additionally this warning appears in generic code. Which means I don't even now if a regular array is passed in as a argument or just a type which overloads the slice operator. With 2.063 and up when assigning to a slice you'll also need to use the slice operator on the right of the assignment. This is also true for regular arrays. -- Mike Wey
Re: Array copy warning
Am 13.10.2013 17:22, schrieb Mike Wey: With 2.063 and up when assigning to a slice you'll also need to use the slice operator on the right of the assignment. This is also true for regular arrays. The code that generates the warning looks like this: mem[0..this.length] = this[]; So I assume this already correct, unless I misunderstand it and the new form should be: mem[0..this.length] = this[][];
Re: Call a function with a function pointer
Am 13.10.2013 17:17, schrieb Artur Skawina:
On 10/13/13 16:43, Benjamin Thaut wrote:
Am 10.10.2013 17:45, schrieb Namespace:
On Thursday, 10 October 2013 at 15:15:45 UTC, bearophile wrote:
Namespace:
You mean like this?
void foo(T)(extern(C) void function(T*) func) {
}
That prints: Error: basic type expected, not extern
In theory that's correct, in practice the compiler refuses that, it's
in Bugzilla, so try to define the type outside the signature (untested):
alias TF = extern(C) void function(T*);
void foo(T)(TF func) {}
Bye,
bearophile
/d917/f732.d(8): Error: basic type expected, not extern
/d917/f732.d(8): Error: semicolon expected to close alias declaration
/d917/f732.d(8): Error: no identifier for declarator void function(T*)
I found a possible workaround. Its ugly as hell, but at least it works until
the bugs are fixed.
There's no need for such ugly workarounds -- this is just a problem with
the *new* alias syntax. The old one accepts it (unless this changed recently):
alias extern(C) static void function(int*) Func_t;
artur
Oh so this bug was fixed? Thats good to know.
Re: fast floor
On Friday, 11 October 2013 at 20:31:50 UTC, Spacen Jasset wrote: I will have to learn about what to does exactly. It wasn't around when I looked at D x years ago. http://dlang.org/phobos/std_conv.html#.to Its principal benefit is that it can do overflow checks, so it's worth using unless there is a very extreme speed requirement. That's why I suggest trying it first (in combination with floor()) and then perhaps replacing to!int with a cast only if it turns out to be unacceptably slow.
Re: fast floor
On Thursday, 10 October 2013 at 22:27:14 UTC, Spacen Jasset wrote: Hello, I am after a fast floor function; In fact a fast truncation and conversion to integer. I see that std.math takes a real, and that std.c.math takes a double. Is there a quicker function, and what might cast(int)1.5f do? Regards, Spacen. If you don't need to handle negatives, I suggest you simply use a cast(int) since truncation has both a x87 instruction (FISTTP) and a SSE instruction (CVTTSS2SI).
Understanding opAssign and 'alias this'
Hello,
Can anybody explain my what is happening here?
enum xxx = true;
struct A {
static if (xxx) ref A opAssign(ref const A a) { return this; }
ref A opAssign(int v) { return this; }
}
struct B {
A a;
alias a this;
}
void main() {
A a;
B b;
a = b; // [1]
b = a; // [2]
}
When xxx is false:
[1] Gives an error
[2] Compiles fine
When xxx is true:
[1] Compiles fine
[2] Gives an error
What exactly is happening here? When xxx is false, what does 'b =
a' do that is wrong when xxx is true?
I can't find any clear documentation about opAssign and its
'default' implementation.
Thanks!
-Maurice-
Re: Understanding opAssign and 'alias this'
On Sunday, 13 October 2013 at 21:37:31 UTC, Maurice wrote:
Hello,
Can anybody explain my what is happening here?
enum xxx = true;
struct A {
static if (xxx) ref A opAssign(ref const A a) { return this; }
ref A opAssign(int v) { return this; }
}
struct B {
A a;
alias a this;
}
void main() {
A a;
B b;
a = b; // [1]
b = a; // [2]
}
When xxx is false:
[1] Gives an error
[2] Compiles fine
When xxx is true:
[1] Compiles fine
[2] Gives an error
What exactly is happening here? When xxx is false, what does 'b
= a' do that is wrong when xxx is true?
I can't find any clear documentation about opAssign and its
'default' implementation.
Thanks!
-Maurice-
It is a bug from my POV
