On 15/04/12 09:23, ReneSac wrote:
What really amazes me is the difference between g++, DMD and GDC in size of
the executable binary. 100 orders of magnitude!
I have remarked it in another topic before, with a simple "hello world". I need
to update there, now that I got DMD working. BTW, it is 2 orders of magnitude.
Ack. Yes, 2 orders of magnitude, 100 _times_ larger. That'll teach me to send
comments to a mailing list at an hour of the morning so late that it can be
called early. ;-)
Sounds stupid as the C stuff should be fastest, but I've been surprised
sometimes at how using idiomatic D formulations can improve things.
Well, it may indeed be faster, especially the IO that is dependent on things
like buffering and so on. But for this I just wanted something as close as the
C++ code as possible.
Fair dos. Seems worth trying the idiomatic alternatives before assuming the
speed difference is always going to be so great, though.
Yeah, I don't know. I just did just throw those qualifiers against the compiler,
and saw what sticks. And I was testing the decode speed specially to see easily
if the output was corrupted. But maybe it haven't corrupted because the compiler
don't optimize based on "pure" yet... there was no speed difference too.. so...
I think it's because although there's mutability outside the function, those
variables are still internal to the struct. e.g. if you try and compile this code:
int k = 23;
pure int twotimes(int a)
{
auto b = 2*a;
auto c = 2*k;
return b+c;
}
... it'll fail, but if you try and compile,
struct TwoTimes
{
int k = 23;
pure int twotimes(int a)
{
auto b = 2*a;
auto c = 2*k;
return b+c;
}
}
... the compiler accepts it. Whether that's because it's acceptably pure, or
because the compiler just doesn't detect this case of impurity, is another
matter. The int k is certainly mutable from outside the scope of the function,
so AFAICS it _should_ be disallowed.
