On Mon, 13 Dec 2010 11:24:48 +0300, spir <denis.s...@gmail.com> wrote:
I have a strange bug with an input range interface. Initially, I had a
(rather big) struct called Text with loads of working unittests. When
adding a range interface, noting worked anymore, any test ran into an
infinite loop (the terminal writes pages of '[') ending with segfault.
@property Text front () {
return Text(this.stacks[this.rangeIndex]);
}
Um. There is recursion. front() of Text returns Text. formatValue iterates
through Range, trying to format every element of it... but goes nowhere
because Range.front never yields anything but itself typewise.
After shrinking the bug's scope,I finally found it happens on simple
writeln(text).
Not so simple, with all underlying mess of templates :-D I suppose it's a
bug that instantiation of formatValue for Range types there always tries
to iterate manually, ignoring existing toString.
void formatValue(Writer, T, Char)(Writer w, T val,
ref FormatSpec!Char f)
if ( ( is(T == struct) || is(T == union) ) && !isInputRange!T)
As you can see it even explicitly mention that default formatting for
struct (which can use toString) not to be used for Ranges. I think it's
wrong.
https://bitbucket.org/denispir/denispir-d/changeset/39200b499fb9#chg-textbug.d.
Note that the range interface itself works fine.
btw, I wonder, how do you build it? I ended up with very long command line
for dmd, as there was no makefile and jake/rdmd failed to produce anything
ether.
So, it seems that, in my case for any reason, introducing an input range
lets D shortcut toString (and try to use what instead?). Look like a bug?
Yup! Still, stack overflow is due to unconventional Range interface.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
