Bug 5237 – writefln doesn't respect Complex.toString

Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P2
Component
phobos
Product
D
Version
D2
Platform
Other
OS
Windows
Creation time
2010-11-18T14:19:00Z
Last change time
2011-09-10T11:46:40Z
Keywords
patch
Assigned to
andrei
Creator
clugdbug

Comments

Comment #0 by clugdbug — 2010-11-18T14:19:09Z
import std.complex; import std.stdio; void main() { cdouble z2 = 10 + 1.5e-6i; Complex!(double) z; z.re = 10; z.im = 1.5e-6; writefln("z= %.16f z2 = %.16f", z, z2); writefln("z = %f z2 = %f", z, z2); writefln("z = %e z2 = %e", z, z2); writefln("z = %a z2 = %a", z, z2); } z = 10+1.5e-06i z2 = 10.0000000000000000+0.0000015000000000i z = 10+1.5e-06i z2 = 10.000000+0.000001i z = 10+1.5e-06i z2 = 1.000000e+01+1.500000e-06i z = 10+1.5e-06i z2 = 0x1.4p+3+0x1.92a737110e454p-20i Clearly the format string is not being passed, or is being ignored.
Comment #1 by clugdbug — 2010-11-19T01:25:33Z
Partial fix in svn 2183. This fixes the last 3 cases, not the first one. It would be very straightforward to implement the first case, but we need to think if it would really be a sensible design, since we'd be doing atoi(itoa(atoi(original_string))).
Comment #2 by clugdbug — 2010-11-19T01:27:43Z
*** Issue 5231 has been marked as a duplicate of this issue. ***
Comment #3 by bugzilla — 2010-11-19T02:26:47Z
(In reply to comment #1) > Partial fix in svn 2183. This fixes the last 3 cases, not the first one. > It would be very straightforward to implement the first case, but we need to > think if it would really be a sensible design, since we'd be doing > atoi(itoa(atoi(original_string))). Couln't that be easily solved by storing the full format string in FormatSpec?
Comment #4 by clugdbug — 2010-11-19T04:19:11Z
(In reply to comment #3) > (In reply to comment #1) > > Partial fix in svn 2183. This fixes the last 3 cases, not the first one. > > It would be very straightforward to implement the first case, but we need to > > think if it would really be a sensible design, since we'd be doing > > atoi(itoa(atoi(original_string))). > > Couln't that be easily solved by storing the full format string in FormatSpec? Probably. My guess is that positional parameters will make it more complicated, but possibly it's really simple.
Comment #5 by bugzilla — 2010-11-19T04:32:21Z
(In reply to comment #4) > My guess is that positional parameters will make it more complicated, > but possibly it's really simple. Regarding positional parameters, allow me to restate a point I made in the DIP9 thread on the newsgroup: I think it's best to leave out the '%' from the format string that is sent to toString(). This will facilitate the use of positional parameters, in which the percent is followed by a position specifier which necessarily has to be handled at a higher level than toString(). Example: BigInt i = "456"; BigInt j = "123"; writefln("%2$s %1$s", i, j); // Prints "123 456" The only thing BigInt.writeTo() needs to see is the part after the '$' character.
Comment #6 by bugzilla — 2010-11-19T04:35:04Z
(In reply to comment #3) > (In reply to comment #1) > > Partial fix in svn 2183. This fixes the last 3 cases, not the first one. > > It would be very straightforward to implement the first case, but we need to > > think if it would really be a sensible design, since we'd be doing > > atoi(itoa(atoi(original_string))). > > Couln't that be easily solved by storing the full format string in FormatSpec? One problem is of course when the user passes a non-immutable format string, as in char[] fmt = "%s %s".dup; writefln(fmt, 1, 3.14); Then each format specifier has to be dup-ed before being stored in FormatSpec.
Comment #7 by k.hara.pg — 2011-09-02T12:09:52Z
Comment #8 by k.hara.pg — 2011-09-10T11:46:40Z