On 08/25/2011 03:07 AM, Jonathan M Davis wrote:
On Wednesday, August 24, 2011 17:52 Timon Gehr wrote:
On 08/25/2011 02:34 AM, Jonathan M Davis wrote:
On Wednesday, August 24, 2011 17:17 Timon Gehr wrote:
On 08/25/2011 01:15 AM, Timon Gehr wrote:
On 08/24/2011 11:55 PM, bearophile wrote:
Timon Gehr:
If anyone is interested:
http://pastebin.com/2rEdx0RD
I suggest you to usually compile your D code with -w, I see some
missing overrides. At line 40 it gives me a "Warning: statement is not
reachable".
There is only one missing override, but it is reported for every
instantiation of the template. Statement at line 40 is necessary to
make the /type inference/ work out, and such things are the reason I
don't usually turn warnings on. Another example where warnings are a
pita:
case "bla","blu","blo": // Warning: fallthrough
case "xxx","yyy","zzz":
What the code expresses is: There are two cases, one occurs if the
input is bla blu or blo, and the other one if it is xxx or yyy or zzz.
Those cases should be handled the same way. (At least for now).
goto case; is both unnecessary and ugly in that case.
So basically, for me there are too many false positives to make the -w
switch really practical, which is a pity, as they would have catched
the missing override in this case.
Are you able to use it to translate the Haskell version of this task?
http://rosettacode.org/wiki/Hamming_numbers#Haskell
Challenge accepted.
ASDF. I got it working quite fast, and then I started a fight with
std.bigint.BigInt.toString until I accidentally cp'd over my source
code. That will be reported soon, it makes BigInt UNUSABLE.
I am going to code it again...
Don refuses to implement it, because it always creates a new string. He
wants something like the DIP for writeFrom (or whatever the exact
function name was) which allows for writing to a pre-existing buffer. I
think that there's already a bug on the issue, but I'd have to search
for it.
- Jonathan M Davis
We must just add _*RVO for arrays*_ to the compiler and then users can
use the built-in array concatenation syntax for the efficient thing.
Everything else would just waste the precious grammar rules.
How it is now is just painful and it does not fit well into the rest of
Phobos. Not even std.conv.to can convert a BigInt to a string. This is a
trivial issue that renders std.bigint unusable for these kinds of little
scripts, where they actually would be of use. I don't care if I get a
newly allocated string, because I only convert it once to output it. The
current design just hurts me everywhere, and wasted a lot of my time.
Premature optimization is the root of all evil.
The DIP actually solves the problem quite well, but it hasn't gone anywhere
yet. I'd argue that BigInt should have a toString in the interim, but Don is
against it (and std.conv.to requires toString, alias this to a string, or a
cast to a string for a struct or class to work with it, and BigInt has none of
those).
It could have a special case for BigInt.
The DIP does not solve the whole issue imho. This _cries_ for a more
general solution. The DIP says, 'composing strings is inefficient and
puts too much pressure on the heap, that is why we have to replace a
simple API with a more complex one'. Wrong. That is why we have to make
the compiler generate good code for composing strings, if necessary
through an ABI change.
writeTo looks like a neat solution if you want to Eg. output the thing
without heap activity. But toString means: Convert this Object to
string, and allocate a new string. I do not get why anyone would think
that a hermaphrodite method with the name toString and the functionality
of writeTo has any reason to exist. How do you simply convert a BigInt
to a string using that tool? (I haven't found out, I always get "0") It
really hurts generic code too, because it deviates from how things work
for other types. Don should seriously reconsider.
