Re: Some strange parameter deduction problems in opOpAssign and opBinary
On Sunday, 2 September 2012 at 04:10:39 UTC, Ivan Agafonov wrote:
There are 3 separated versions of opOpAssign
first version must be the same as the second for Vec!(sometype,
4)
why it doesn't work?
Simplified code:
struct Vec(T, uint size)
{
this(T rhs) { array[] = rhs; }
// It doesn't work but compiles
ref Vec!(T, size) opOpAssign(string op) (Vec!(T, size) rhs)
{
mixin("array[] "~op~"= rhs.array[];");
return this;
}
// but it work's
ref Vec!(T, 4) opOpAssign(string op) (Vec!(T, 4) rhs)
{
mixin("array[] "~op~"= rhs.array[];");
return this;
}
// and this work;s
ref Vec!(T, size) opAddAssign(Vec!(T, size) rhs)
{
array[] += rhs.array[];
return this;
}
T[size] array = 0;
}
int main()
{
auto z = Vec!(float, 4)(5.0f);
z += z;
writeln(z);
return 0;
}
Problem solved:
alias Vec!(T, size) V;
// This works fine
ref V opOpAssign(string op)(V rhs)
{
mixin("array[] "~op~"= rhs.array[];");
return this;
}
But I think this is a bug.
Re: Some strange parameter deduction problems in opOpAssign and opBinary
Hmm, strange... z.opOpAssign!"+"(z); works with both first and second versions
Some strange parameter deduction problems in opOpAssign and opBinary
There are 3 separated versions of opOpAssign
first version must be the same as the second for Vec!(sometype, 4)
why it doesn't work?
Simplified code:
struct Vec(T, uint size)
{
this(T rhs) { array[] = rhs; }
// It doesn't work but compiles
ref Vec!(T, size) opOpAssign(string op) (Vec!(T, size) rhs)
{
mixin("array[] "~op~"= rhs.array[];");
return this;
}
// but it work's
ref Vec!(T, 4) opOpAssign(string op) (Vec!(T, 4) rhs)
{
mixin("array[] "~op~"= rhs.array[];");
return this;
}
// and this work;s
ref Vec!(T, size) opAddAssign(Vec!(T, size) rhs)
{
array[] += rhs.array[];
return this;
}
T[size] array = 0;
}
int main()
{
auto z = Vec!(float, 4)(5.0f);
z += z;
writeln(z);
return 0;
}
Re: Derelict3+SFML2
On Saturday, 1 September 2012 at 19:59:33 UTC, cal wrote: On Saturday, 1 September 2012 at 15:53:20 UTC, Zhenya wrote: Hello, I've got a little problem with DerelictSFML2. Despite the fact that I downloaded from the official website binaries CSFML2, this little application closes with the message: "Failed to load symbol sfWindow_setSize from shared library csfml-window-2.dll" I just had a look at the windows sfml2 binary folder, and the setSize symbol is not included in the csfml-window-2.dll exports (although getSize is). You might have to rebuild from source. (There are quite a few symbols missing from the prebuilt binaries, based on what should be there from the docs on the website). Thank you very much,I will try to build csfml from source.
Re: Derelict3+SFML2
On Saturday, 1 September 2012 at 15:53:20 UTC, Zhenya wrote: Hello, I've got a little problem with DerelictSFML2. Despite the fact that I downloaded from the official website binaries CSFML2, this little application closes with the message: "Failed to load symbol sfWindow_setSize from shared library csfml-window-2.dll" I just had a look at the windows sfml2 binary folder, and the setSize symbol is not included in the csfml-window-2.dll exports (although getSize is). You might have to rebuild from source. (There are quite a few symbols missing from the prebuilt binaries, based on what should be there from the docs on the website).
Re: Assigning global and static associative arrays
On Saturday, September 01, 2012 11:10:17 Jonathan M Davis wrote: > On Saturday, September 01, 2012 16:14:29 ixid wrote: > > Those still have different addresses when made immutable too, is > > this something that could be optimized for all immutable enums to > > behave like strings or are there reasons to keep them unique at > > each instance? > > The compiler has to got to extra work to make string literals use the same > memory like that. While it _could_ do the same with other array literals of > basic types, it's not worth it, because they're just not used enough, > whereas string literals get used all over the place. The other thing to remember is that for the whole sharing address thing to work, the elements in the array literal must be immutable, and string literals are the only ones which are that way by default. Other array literals are only going to have immutable elements if they're used to directly initialize an array with immutable elements. So, it's probably relatively rare for other array literals to even be used in a way, and unless they're used that way _and_ the same literal is used in multiple places, then you can't make them share the same memory. So, there's not much point in trying to make them share memory. String literals, on the other hand, are immutable and frequently duplicated, so there's some value in sharing them. But even with them, it wouldn't surprise me at all if they only share memory within a single module, since separate compilation could screw with their ability to share. I don't know though. - Jonathan M Davis
Re: Assigning global and static associative arrays
On Saturday, September 01, 2012 16:14:29 ixid wrote: > Those still have different addresses when made immutable too, is > this something that could be optimized for all immutable enums to > behave like strings or are there reasons to keep them unique at > each instance? The compiler has to got to extra work to make string literals use the same memory like that. While it _could_ do the same with other array literals of basic types, it's not worth it, because they're just not used enough, whereas string literals get used all over the place. - Jonathan M Davis
Derelict3+SFML2
Hello, I've got a little problem with DerelictSFML2. Despite the
fact that I downloaded from the official website binaries CSFML2,
this little application closes with the message: "Failed to load
symbol sfWindow_setSize from shared library csfml-window-2.dll"
module main;
import std.stdio;
import derelict.sfml2.system;
import derelict.sfml2.window;
int main (string [] argv)
{
DerelictSFML2System.load ();
DerelictSFML2Window.load ();
return 0;
}
Could you explain to me what is wrong?
Re: Call a function on an entire slice
Because the built-in arithmetic vector operators are supported by hardware. Should that matter from a user's point of view? It's a clean syntax that should be made more univeral. It'd be nice to be able to do things like: return a[] + b[]; and using that in lambdas as well without needing the unnecessary repetition of return a[] = a[] + b[];
Re: Assigning global and static associative arrays
Those still have different addresses when made immutable too, is this something that could be optimized for all immutable enums to behave like strings or are there reasons to keep them unique at each instance?
Re: Assigning global and static associative arrays
On Saturday, September 01, 2012 11:07:34 Philippe Sigaud wrote:
> > Using enum can be very useful, but I wouldn't use it for AAs at all, and
> > I'd be leery of using it for much in the way of arrays other than string
> > literals (since the string literals should avoid the memory allocations
> > that other array literals get). It's fine most other stuff, but for those
> > items, you need to be very wary of it or risk lots of unnecessary GC
> > allocations.
>
> I guess the rule to follow is not to use enum for anything with lots
> of allocation.
>
> Why do string literals have less memory allocations?
If I understand correctly, you end up with all uses of the same string literal
being the exact same chunk of memory, but I could be wrong. Let's see... Well,
this program seems to print the same thing 4 times
import std.stdio;
enum a = "hello";
enum b = "hello";
void main()
{
writeln(a.ptr);
writeln(a.ptr);
writeln(b.ptr);
writeln(b.ptr);
}
so it looks like not only do all instances of the same string enum use the
same memory, but another enum with the same string literal shares it as well.
So, only one is allocated. And on Linux at least, as I understand it, the
string literals go in ROM. But it may be that the above code functions
differently in Windows, since it _doesn't_ put string literals in ROM.
Regardless, you can contrast that with this
import std.stdio;
enum a = [1, 2, 3, 4, 5];
enum b = [1, 2, 3, 4, 5];
void main()
{
writeln(a.ptr);
writeln(a.ptr);
writeln(b.ptr);
writeln(b.ptr);
}
which prints 4 different addresses. So clearly, each use of an enum which is an
array literal allocates a new array.
- Jonathan M Davis
Re: Assigning global and static associative arrays
> Using enum can be very useful, but I wouldn't use it for AAs at all, and I'd > be leery of using it for much in the way of arrays other than string literals > (since the string literals should avoid the memory allocations that other > array literals get). It's fine most other stuff, but for those items, you need > to be very wary of it or risk lots of unnecessary GC allocations. I guess the rule to follow is not to use enum for anything with lots of allocation. Why do string literals have less memory allocations?
Re: Assigning global and static associative arrays
On Saturday, September 01, 2012 09:39:04 Philippe Sigaud wrote: > On Sat, Sep 1, 2012 at 12:21 AM, Jonathan M Davis wrote: > > Using an enum is particularly bad for an AA, since it's not exactly a > > simple data type, and there's definitely some cost to constructing them. > > Yeah, my (nasty) bad. I'm too used to put 'enum' everywhere. > > Gosh, I confirm using static this() instead of enum results in a 40% > decrease in runtime for me. > I'll scourge my code from enum AA... Using enum can be very useful, but I wouldn't use it for AAs at all, and I'd be leery of using it for much in the way of arrays other than string literals (since the string literals should avoid the memory allocations that other array literals get). It's fine most other stuff, but for those items, you need to be very wary of it or risk lots of unnecessary GC allocations. - Jonathan M Davis
Re: Assigning global and static associative arrays
On Sat, Sep 1, 2012 at 12:21 AM, Jonathan M Davis wrote: > Using an enum is particularly bad for an AA, since it's not exactly a simple > data type, and there's definitely some cost to constructing them. Yeah, my (nasty) bad. I'm too used to put 'enum' everywhere. Gosh, I confirm using static this() instead of enum results in a 40% decrease in runtime for me. I'll scourge my code from enum AA...
Re: segfault
On Sat, Sep 1, 2012 at 1:38 AM, Ellery Newcomer wrote: > On 08/31/2012 03:18 PM, Andrej Mitrovic wrote: >> >> On 8/31/12, Ellery Newcomer wrote: >>> >>> hey, is anyone else getting a segfault from dmd on this code? >> >> >> Yep on win32. >> > > thanks Same here on Linux 32.
