On 08/25/2011 04:05 AM, Jonathan M Davis wrote:
On Thursday, August 25, 2011 03:35:05 Timon Gehr wrote:
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.
The DIP works great if it's fully implemented. It complicates the
implementations for classes and structs somewhat, but the code which uses them
isn't generally affected much. It just uses to!string(a) instead of
a.toString(). The problem is that the DIP hasn't been fully implemented. And
in the meantime, the lack of a toString on BigInt is crippling.
Yes I do think it is a good concept. However, what the dip achieves for
construction of new full-blown strings on the heap memory should be
doable in the compiler through some form of RVO and provide even
superior efficiency. The clear advantage would be that it would not
complicate the implementations for structs and classes. writeTo and
toString should be complementary, and everyone should be able to
implement what fits their needs best, except Phobos data structures,
those should implement both. to!string should default to toString (and
then writeTo if not available), and writeln should default to writeTo
(and then toString).
