On 15.04.2012 12:29, Joseph Rushton Wakeling wrote:
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;
}
}
Simple - it's called weakly pure. (it can modify this for instance)
It's allowed so that you can do:
pure int f(){
Twotimes t;
return t.towtime(1,1);
}
which is obviously normal/strongly pure. Of course, the compiler knows
what kind of purity each function has.
... 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.
--
Dmitry Olshansky
