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). - Jonathan M Davis
