digitalmars.D.bugs - [Issue 5231] New: BigInt lacks a normal toString()
- d-bugmail puremagic.com (33/33) Nov 17 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5231
- d-bugmail puremagic.com (11/11) Nov 17 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5231
- d-bugmail puremagic.com (16/16) Nov 18 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5231
- d-bugmail puremagic.com (11/11) Nov 18 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5231
- d-bugmail puremagic.com (17/18) Nov 18 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5231
- d-bugmail puremagic.com (8/10) Nov 18 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5231
- d-bugmail puremagic.com (23/32) Nov 18 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5231
- d-bugmail puremagic.com (9/11) Nov 18 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5231
- d-bugmail puremagic.com (22/22) Nov 18 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5231
- d-bugmail puremagic.com (14/24) Nov 18 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5231
- d-bugmail puremagic.com (16/26) Nov 18 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5231
- d-bugmail puremagic.com (7/19) Nov 18 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5231
- d-bugmail puremagic.com (29/29) Nov 18 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5231
- d-bugmail puremagic.com (6/6) Nov 18 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5231
- d-bugmail puremagic.com (10/28) Nov 18 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5231
- d-bugmail puremagic.com (11/11) Nov 18 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5231
- d-bugmail puremagic.com (13/13) Nov 19 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5231
- d-bugmail puremagic.com (8/12) Nov 19 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5231
http://d.puremagic.com/issues/show_bug.cgi?id=5231 Summary: BigInt lacks a normal toString() Product: D Version: unspecified Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nobody puremagic.com ReportedBy: jmdavisProg gmx.com PST --- This program import std.bigint; import std.stdio; void main() { auto b = BigInt(42); writeln(b); } prints BigInt rather than 42. BigInt does not define a normal toString(). It looks like it declares a version of toString() which takes a delegate and format string in an attempt to have more control of what the string looks like. However, this is useless for cases where you need an actual toString() - particularly when functions which you have no control over call toString(). Normally, all types should define a toString() so that they can be printed, and BigInt doesn't do that. So, BigInt should declare a normal toString() - presumably one which prints out the BigInt in decimal form. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 17 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5231 bearophile_hugs eml.cc changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bearophile_hugs eml.cc This is a dupe of my 4122 The lack of a normally usable toString is not acceptable. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 17 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5231 Don <clugdbug yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clugdbug yahoo.com.au That's not really the correct solution. BigInt should act like an int. Specifically, BigInt b; writefln(" b = %d, %x", b, b); should just work. This issue cannot be resolved until the definition of toString() is changed. void toString() is a fundamentally broken design. It's wrong on many levels. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 18 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5231 PST --- void toString()? Normally, it's string toString(). The only problem that I'm aware of with regards to toString() design at the moment is the fact that it must be _exactly_ string toString() and can't be const or pure or whatnot. I don't see why BigInt can't just have a normal toString() which returns a string representation of BigInt. Having a fancier toString() like it does now may be useful, but I don't see how it precludes having a normal toString(). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 18 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5231 nfxjfg gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nfxjfg gmail.comvoid toString() is a fundamentally broken design. It's wrong on many levels.But it allows more control over formatting and potentially reduces memory allocation. string toString() seems more broken to me: no control, forces you to do memory allocation. (Another broken design issue is that _all_ objects in D have a toString() method, even if it doesn't make sense, but that is off-topic here.) What is worrying is that void toString is nowhere documented. Does std.format use it or what? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 18 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5231What is worrying is that void toString is nowhere documented. Does std.format use it or what?Should be: is it supposed to use it? Of course it doesn't right now. If it should, the bug report is about std.format/writefln, and not std.bigint. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 18 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5231 Steven Schveighoffer <schveiguy yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |schveiguy yahoo.com 05:10:23 PST ---That's not really the correct solution. BigInt should act like an int. Specifically, BigInt b; writefln(" b = %d, %x", b, b); should just work. This issue cannot be resolved until the definition of toString() is changed. void toString() is a fundamentally broken design. It's wrong on many levels.So BigInt's aren't printable via writeln in protest? I guess I don't understand why you can't do this: string toString() { string retval; void sink(const(char)[] data) { retval ~= data; } toString(&sink, null); return retval; } It doesn't hurt/limit the current toString, does it? And then it makes bigints printable via writeln. BTW, toString's delegate is not scope, so you are going to allocate a closure for that... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 18 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5231So BigInt's aren't printable via writeln in protest?Yes. I refuse to play any part in propagating the toString() abomination. BigInt will NEVER have a string toString() function. No frigging way. This needs to be fixed in writefln/format. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 18 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5231 06:30:23 PST --- Pardon me for saying so, but that's too short-sighted. first, it's not just a writeln/format change, it's a compiler change too. The compiler is the one who decides whether to store a function pointer to toString in the TypeInfo_Struct. Maybe you can help fix that... Second, it's they way things currently work. It's like saying you refuse to have const functions because they should be inout, but inout doesn't work. When toString is fixed, then you can remove the crufty function, and nobody cares whether it was ever there or not. It looks to the outside like phobos is immature when it can't even print its own types, regardless of how inefficient it is. Note that I 100% agree that the current system is crap, and needs to be completely redone similar to how you have implemented it, but it's not how it works now. Can't BigInt just play along and we can push for changes to the system without making the library look like a stubborn child? BTW, when the system is changed, I wouldn't want it to be called toString, since string may have nothing to do with it. I'd call it something like format or output. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 18 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5231Second, it's they way things currently work. It's like saying you refuse to have const functions because they should be inout, but inout doesn't work. When toString is fixed, then you can remove the crufty function, and nobody cares whether it was ever there or not. It looks to the outside like phobos is immature when it can't even print its own types, regardless of how inefficient it is.If it was just a question of inefficiency, I would have implemented it. The issue is that it doesn't get the formatting string. So BigInt b; writefln("%x %+d", b, b); doesn't work, and cannot be made to work.Note that I 100% agree that the current system is crap, and needs to be completely redone similar to how you have implemented it, but it's not how it works now. Can't BigInt just play along and we can push for changes to the system without making the library look like a stubborn child?No. The format string is absolutely fundamental to the implementation of outputting BigInt and BigFloat. It's not just "a crap implementation". -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 18 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5231 10:20:08 PST ---If it was just a question of inefficiency, I would have implemented it. The issue is that it doesn't get the formatting string. So BigInt b; writefln("%x %+d", b, b); doesn't work, and cannot be made to work.But what about writeln, or writefln("%s"...) ? Should those usages be excluded because you can't have custom formatting?No. The format string is absolutely fundamental to the implementation of outputting BigInt and BigFloat. It's not just "a crap implementation".I disagree here. The huge problem I have with toString is the requirement for allocating immutable data that immediately gets thrown away. Supporting custom formatting is a nice feature but not having it does not severely impact users nearly as much as not having any output. In other words, if I want to print a BigInt in hex, and I get "BigInt", that is useless to me. If I get it in decimal, well at least I got something that can be used. If the format string is so fundamental, then why does BigInt.toString support a null format argument? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 18 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5231Yes. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------If it was just a question of inefficiency, I would have implemented it. The issue is that it doesn't get the formatting string. So BigInt b; writefln("%x %+d", b, b); doesn't work, and cannot be made to work.But what about writeln, or writefln("%s"...) ? Should those usages be excluded because you can't have custom formatting?
Nov 18 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5231 PST --- So, you don't want writeln(bi); or to!string(bi) to work? I would think that ideally, BigInt would work exactly the same way that integers do. to!string(i) -> decimal writeln(i) -> decimal writefln("%s", i) -> decimal writefln("%d", i) -> decimal writefln("%f", i) -> hex So, ideally, BigInt would do the same: to!string(bi) -> decimal writeln(bi) -> decimal writefln("%s", bi) -> decimal writefln("%d", bi) -> decimal writefln("%f", bi) -> hex But you only want this?: writefln("%d", bi) -> decimal writefln("%f", bi) -> hex Okay. I can see an argument for a better handling of toString() in general (I'd never even heard anyone complain about string toString() or discuss the possibility of a void toString() before the discussion on this bug report) and that to!string(), writeln(), writefln(), etc. need to be fixed to support a void toString() instead of string toString(), but I don't understand why you would refuse to allow for BigInt to be convertible to a string or printed as one without a format string. I don't see why it shouldn't act the same way that all of the built-in integral values do in this regard. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 18 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5231 PST --- Whoops. I meant %x, not %f for hex. Sorry about that. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 18 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5231So, you don't want writeln(bi); or to!string(bi) to work?No, that's not what I meant.I would think that ideally, BigInt would work exactly the same way that integers do. to!string(i) -> decimal writeln(i) -> decimal writefln("%s", i) -> decimal writefln("%d", i) -> decimal writefln("%f", i) -> hex So, ideally, BigInt would do the same: to!string(bi) -> decimal writeln(bi) -> decimal writefln("%s", bi) -> decimal writefln("%d", bi) -> decimal writefln("%f", bi) -> hexYes. The thing I do *not* want is where it works for one case but not any of the others. I find that suggestion completely indefensible. BTW, the void toString() was just a typo by me. I meant string toString(). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 18 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5231 PST --- Well, then I think that we agree on the desired eventual functionality. But I do think that in the interim, it would be a good idea to add string toString() to BigInt with the idea that it would be removed as soon as the fancier toString() stuff is sorted out. That way, at least _some_ of the desired behavior would work rather than forcing you to call the current toString() with a delegate just to get a string representation for a BigInt. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 18 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5231 Don <clugdbug yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE This is a bug in format. Even the partial fix I made for bug 5237, makes BigInt print correctly, without any change to the BigInt code. *** This issue has been marked as a duplicate of issue 5237 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 19 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5231This is a bug in format. Even the partial fix I made for bug 5237, makes BigInt print correctly, without any change to the BigInt code. *** This issue has been marked as a duplicate of issue 5237 ***See also: http://d.puremagic.com/issues/show_bug.cgi?id=4122 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 19 2010