www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Semantics of toString

reply Justin Johansson <free beer.com> writes:
I assert that the semantics of "toString" or similarly named/purposed
methods/functions in many
PL's (including and not limited to D) is ill-defined.

To put this statement into perspective, I would be most appreciative of D NG
readers
responding with their own idea(s) of what the semantics of "toString" are (or
should be)
in a language agnostic ideology.

If there are more than, say, two or three different views on the said semantics
then my
"ill-definition" assertion is surely correct.

If there are no replies on this matter, then guess I'm left concludeless.

Just thinking in the language round-up that this is (just another) one of the
things
we should address as a community.

So what does "toString" mean to you?

**beers,
Justin

**caveat: free beer offer available in-store only
Nov 05 2009
next sibling parent Michal Minich <michal minich.sk> writes:
Hello Justin,

 I assert that the semantics of "toString" or similarly named/purposed
 methods/functions in many PL's (including and not limited to D) is
 ill-defined.
 
 To put this statement into perspective, I would be most appreciative
 of D NG readers responding with their own idea(s) of what the
 semantics of "toString" are (or should be) in a language agnostic
 ideology.
 
 If there are more than, say, two or three different views on the said
 semantics then my "ill-definition" assertion is surely correct.
 
 If there are no replies on this matter, then guess I'm left
 concludeless.
 
 Just thinking in the language round-up that this is (just another) one
 of the things we should address as a community.
 
 So what does "toString" mean to you?
 
 **beers,
 Justin
 **caveat: free beer offer available in-store only
 
My practice tells me to use toString only for debugging - to quickly get string representation of object in human readable format - nothing else ever. So it is good that toString is part of D object class. It quite unsuitable e.g. for serializing object to xml/html or other formats. You may find yourself later finding out that your object should not only be toString-ed to xml, but now to json... Better to use specific method for specific purpose. what matters me more of object methods, is opEquals being part of them. But that is different story.
Nov 05 2009
prev sibling next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Justin Johansson wrote:
 So what does "toString" mean to you?
A string useful for debugging purposes and, when possible, useful for programming tasks. For example in Java there's StringWriter and the toString method returns the String being written, I think that's fine. An XML node might return it's xml representation. But most of the time an object dosen't have a use as a string.
Nov 05 2009
prev sibling next sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Justin Johansson Wrote:

 I assert that the semantics of "toString" or similarly named/purposed
methods/functions in many
 PL's (including and not limited to D) is ill-defined.
 
 To put this statement into perspective, I would be most appreciative of D NG
readers
 responding with their own idea(s) of what the semantics of "toString" are (or
should be)
 in a language agnostic ideology.
 
 If there are more than, say, two or three different views on the said
semantics then my
 "ill-definition" assertion is surely correct.
 
 If there are no replies on this matter, then guess I'm left concludeless.
 
 Just thinking in the language round-up that this is (just another) one of the
things
 we should address as a community.
 
 So what does "toString" mean to you?
 
 **beers,
 Justin
 
 **caveat: free beer offer available in-store only
 
Well some Java author said that the toSting method was only intended for debugging, but list containers use it so... I don't have that reference :( You can also check out the question on StackOverflow http://stackoverflow.com/questions/563676/is-tostring-only-useful-for-debugging But personally, output to the end-user should not come from toString and program logic should not be based on the string returned from toString.
Nov 05 2009
prev sibling next sibling parent Justin Whear <justin economicmodeling.com> writes:
Justin Johansson Wrote:

 I assert that the semantics of "toString" or similarly named/purposed
methods/functions in many
 PL's (including and not limited to D) is ill-defined.
 
 To put this statement into perspective, I would be most appreciative of D NG
readers
 responding with their own idea(s) of what the semantics of "toString" are (or
should be)
 in a language agnostic ideology.
 
 If there are more than, say, two or three different views on the said
semantics then my
 "ill-definition" assertion is surely correct.
 
 If there are no replies on this matter, then guess I'm left concludeless.
 
 Just thinking in the language round-up that this is (just another) one of the
things
 we should address as a community.
 
 So what does "toString" mean to you?
 
 **beers,
 Justin
 
 **caveat: free beer offer available in-store only
 
Two things: 1) Primarily for debugging purposes. It's very convenient. 2) As a default behavior in a few cases. For instance, if a listbox widget hasn't been given a view that knows how to render objects of type Foo, it can default to rendering the results of toString.
Nov 05 2009
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Justin Johansson" <free beer.com> wrote in message 
news:hcuhet$15a2$1 digitalmars.com...
I assert that the semantics of "toString" or similarly named/purposed 
methods/functions in many
 PL's (including and not limited to D) is ill-defined.

 To put this statement into perspective, I would be most appreciative of D 
 NG readers
 responding with their own idea(s) of what the semantics of "toString" are 
 (or should be)
 in a language agnostic ideology.

 If there are more than, say, two or three different views on the said 
 semantics then my
 "ill-definition" assertion is surely correct.

 If there are no replies on this matter, then guess I'm left concludeless.

 Just thinking in the language round-up that this is (just another) one of 
 the things
 we should address as a community.

 So what does "toString" mean to you?

 **beers,
 Justin

 **caveat: free beer offer available in-store only
(Deliberately not reading the other replies before posting...) It means to me, obtain a string-representation of an object (or an instance of a non-class type) in whatever form is reasonably appropriate for the given type. This string representation might include all data, but this is not guaranteed. It might be unique to each object, but this is not guaranteed. It might be fully-suitable for serialization, but this is not guaranteed.
Nov 05 2009
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
Justin Johansson wrote:
 I assert that the semantics of "toString" or similarly named/purposed
methods/functions in many
 PL's (including and not limited to D) is ill-defined.
 
 To put this statement into perspective, I would be most appreciative of D NG
readers
 responding with their own idea(s) of what the semantics of "toString" are (or
should be)
 in a language agnostic ideology.
 
 If there are more than, say, two or three different views on the said
semantics then my
 "ill-definition" assertion is surely correct.
 
 If there are no replies on this matter, then guess I'm left concludeless.
 
 Just thinking in the language round-up that this is (just another) one of the
things
 we should address as a community.
 
 So what does "toString" mean to you?
It's a hack from the early days of D. Should be unavailable unless the -debug flag is set, to discourage people from using it. I hate it.
Nov 05 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Don" <nospam nospam.com> wrote in message 
news:hcvf9l$91i$1 digitalmars.com...
 Justin Johansson wrote:
 So what does "toString" mean to you?
It's a hack from the early days of D. Should be unavailable unless the -debug flag is set, to discourage people from using it. I hate it.
What don't you like about it?
Nov 05 2009
parent reply Don <nospam nospam.com> writes:
Nick Sabalausky wrote:
 "Don" <nospam nospam.com> wrote in message 
 news:hcvf9l$91i$1 digitalmars.com...
 Justin Johansson wrote:
 So what does "toString" mean to you?
It's a hack from the early days of D. Should be unavailable unless the -debug flag is set, to discourage people from using it. I hate it.
What don't you like about it?
It cannot even do the most basic stuff. (1) You can't even make a struct that behaves like an int. struct MyInt { int z; string toString() { .... } } void main() { int a = 400; MyInt b = 400; writefln("%05d %05d", a, b); writefln("%x %x", a, b); } (2) It doesn't behave like a stream. Suppose you have XmlDoc.toString() You can't emit the doc, piece by piece. You have to create the ENTIRE string in one go!
Nov 05 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
On 06/11/2009 07:34, Don wrote:
 Nick Sabalausky wrote:
 "Don" <nospam nospam.com> wrote in message
 news:hcvf9l$91i$1 digitalmars.com...
 Justin Johansson wrote:
 So what does "toString" mean to you?
It's a hack from the early days of D. Should be unavailable unless the -debug flag is set, to discourage people from using it. I hate it.
What don't you like about it?
It cannot even do the most basic stuff. (1) You can't even make a struct that behaves like an int. struct MyInt { int z; string toString() { .... } } void main() { int a = 400; MyInt b = 400; writefln("%05d %05d", a, b); writefln("%x %x", a, b); } (2) It doesn't behave like a stream. Suppose you have XmlDoc.toString() You can't emit the doc, piece by piece. You have to create the ENTIRE string in one go!
The first issue you raise is IMO a problem with writefln and not with toString since writefln doesn't handle user-defined types properly. I think that writefln (btw, horrible name) should only deal with strings and their formatting and all other types need to provide an (optionally formatted) string. a numeric type would provide formatting of properties like number of decimal places, thousands separator, etc while user defined specification type could provide a type of standard format. auto spec = new Specification(HTML); string ansi = spec.toString(Specification.ANSI); string iso = spec.toString(Specification.ISO); the c style format string that specifies types is a horrible horrible thing and should be removed. regarding the second issue: forech (node; XmlDoc.preOrder()) writfln("{0}", node.toString());
Nov 06 2009
parent reply =?ISO-8859-1?Q?Pelle_M=E5nsson?= <pelle.mansson gmail.com> writes:
Yigal Chripun wrote:
 On 06/11/2009 07:34, Don wrote:
 Nick Sabalausky wrote:
 "Don" <nospam nospam.com> wrote in message
 news:hcvf9l$91i$1 digitalmars.com...
 Justin Johansson wrote:
 So what does "toString" mean to you?
It's a hack from the early days of D. Should be unavailable unless the -debug flag is set, to discourage people from using it. I hate it.
What don't you like about it?
It cannot even do the most basic stuff. (1) You can't even make a struct that behaves like an int. struct MyInt { int z; string toString() { .... } } void main() { int a = 400; MyInt b = 400; writefln("%05d %05d", a, b); writefln("%x %x", a, b); } (2) It doesn't behave like a stream. Suppose you have XmlDoc.toString() You can't emit the doc, piece by piece. You have to create the ENTIRE string in one go!
The first issue you raise is IMO a problem with writefln and not with toString since writefln doesn't handle user-defined types properly. I think that writefln (btw, horrible name) should only deal with strings and their formatting and all other types need to provide an (optionally formatted) string. a numeric type would provide formatting of properties like number of decimal places, thousands separator, etc while user defined specification type could provide a type of standard format. auto spec = new Specification(HTML); string ansi = spec.toString(Specification.ANSI); string iso = spec.toString(Specification.ISO); the c style format string that specifies types is a horrible horrible thing and should be removed.
How do you do %.3f in {}-notation? Your formatting string should be written as writeln(ansi, " ", iso);
Nov 06 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
On 06/11/2009 12:34, Pelle Månsson wrote:
 Yigal Chripun wrote:
 On 06/11/2009 07:34, Don wrote:
 Nick Sabalausky wrote:
 "Don" <nospam nospam.com> wrote in message
 news:hcvf9l$91i$1 digitalmars.com...
 Justin Johansson wrote:
 So what does "toString" mean to you?
It's a hack from the early days of D. Should be unavailable unless the -debug flag is set, to discourage people from using it. I hate it.
What don't you like about it?
It cannot even do the most basic stuff. (1) You can't even make a struct that behaves like an int. struct MyInt { int z; string toString() { .... } } void main() { int a = 400; MyInt b = 400; writefln("%05d %05d", a, b); writefln("%x %x", a, b); } (2) It doesn't behave like a stream. Suppose you have XmlDoc.toString() You can't emit the doc, piece by piece. You have to create the ENTIRE string in one go!
The first issue you raise is IMO a problem with writefln and not with toString since writefln doesn't handle user-defined types properly. I think that writefln (btw, horrible name) should only deal with strings and their formatting and all other types need to provide an (optionally formatted) string. a numeric type would provide formatting of properties like number of decimal places, thousands separator, etc while user defined specification type could provide a type of standard format. auto spec = new Specification(HTML); string ansi = spec.toString(Specification.ANSI); string iso = spec.toString(Specification.ISO); the c style format string that specifies types is a horrible horrible thing and should be removed.
 How do you do %.3f in {}-notation?
writefln("{0:F3}", value);
 Your formatting string should be written as writeln(ansi, " ", iso);
That is incorrect since in my example I use the format string to switch the order of the strings. ( hence the numbers inside the {} ) Please go and read the tango documentation starting with http://www.dsource.org/projects/tango/wiki/TutCSharpFormatter it has also links to the MSDN docs which describe the modifiers: for instance: http://msdn.microsoft.com/en-us/library/dwhawy9k%28VS.100%29.aspx This is one area in phobos that needs to be rewritten from scratch or better yet, use tango. I'm still waiting for when hell will freeze over and tango and phobos will be merged together in one consistent API.
Nov 06 2009
next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Yigal Chripun, el  6 de noviembre a las 14:23 me escribiste:
the c style format string that specifies types is a horrible horrible
thing and should be removed.
How do you do %.3f in {}-notation?
writefln("{0:F3}", value);
Your formatting string should be written as writeln(ansi, " ", iso);
This is horrible, horrible for internationalization, you just can't assume how a language order words. Anyway, about the type in the format, I think it's nice, as you just proved, tango have it too "{0:F3}" is saying "treat the value as a float and format it that way". The deal is, the type should not be used to know the size of the parameter in the stack like in C's printf(), it should be just a hint to convert the value to another type. So, type specification is important. Variables reordering is important too, and you even have it in POSIX's printf(): printf("%1$d:%2$.*3$d:%4$.*3$d\n", hour, min, precision, sec); (see http://www.opengroup.org/onlinepubs/9699919799/functions/printf.html) I like printf()'s format (I don't know if it's just because I'm used to it though :). -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- "All mail clients suck. This one just sucks less." -me, circa 1995
Nov 06 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 Yigal Chripun, el  6 de noviembre a las 14:23 me escribiste:
 the c style format string that specifies types is a horrible horrible
 thing and should be removed.
How do you do %.3f in {}-notation?
writefln("{0:F3}", value);
 Your formatting string should be written as writeln(ansi, " ", iso);
This is horrible, horrible for internationalization, you just can't assume how a language order words. Anyway, about the type in the format, I think it's nice, as you just proved, tango have it too "{0:F3}" is saying "treat the value as a float and format it that way". The deal is, the type should not be used to know the size of the parameter in the stack like in C's printf(), it should be just a hint to convert the value to another type. So, type specification is important. Variables reordering is important too, and you even have it in POSIX's printf(): printf("%1$d:%2$.*3$d:%4$.*3$d\n", hour, min, precision, sec); (see http://www.opengroup.org/onlinepubs/9699919799/functions/printf.html) I like printf()'s format (I don't know if it's just because I'm used to it though :).
I think you found a bug in Phobos. I tried this: import std.stdio; void main() { int hour = 1, min = 2, precision = 2, sec = 3; writef("%1$d:%2$.*3$d:%4$.*3$d\n", hour, min, precision, sec); } and it prints 1:002:003 But it should really print: 1:02:03 right? Andrei
Nov 06 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el  6 de noviembre a las 08:50 me escribiste:
So, type specification is important. Variables reordering is important
too, and you even have it in POSIX's printf():

	printf("%1$d:%2$.*3$d:%4$.*3$d\n", hour, min, precision, sec);

(see http://www.opengroup.org/onlinepubs/9699919799/functions/printf.html)

I like printf()'s format (I don't know if it's just because I'm used to it
though :).
I think you found a bug in Phobos. I tried this: import std.stdio; void main() { int hour = 1, min = 2, precision = 2, sec = 3; writef("%1$d:%2$.*3$d:%4$.*3$d\n", hour, min, precision, sec); } and it prints 1:002:003 But it should really print: 1:02:03 right?
Yes. ------------------------ $ cat t.c #include <stdio.h> int main() { int hour = 1, min = 2, precision = 2, sec = 3; printf("%1$d:%2$.*3$d:%4$.*3$d\n", hour, min, precision, sec); return 0; } $ make t cc t.c -o t $ ./t 1:02:03 ----------------------- -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Vaporeso, al verse enfundado por la depresión, decide dar fin a su vida tomando Chinato Garda mezclado con kerosene al 50%. Ante el duro trance pierde la movilidad en sus miembros derechos: inferior y superior. En ese momento es considerado como el hombre líder del movimiento de izquierda de Occidente.
Nov 06 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 Andrei Alexandrescu, el  6 de noviembre a las 08:50 me escribiste:
 So, type specification is important. Variables reordering is important
 too, and you even have it in POSIX's printf():

 	printf("%1$d:%2$.*3$d:%4$.*3$d\n", hour, min, precision, sec);

 (see http://www.opengroup.org/onlinepubs/9699919799/functions/printf.html)

 I like printf()'s format (I don't know if it's just because I'm used to it
 though :).
I think you found a bug in Phobos. I tried this: import std.stdio; void main() { int hour = 1, min = 2, precision = 2, sec = 3; writef("%1$d:%2$.*3$d:%4$.*3$d\n", hour, min, precision, sec); } and it prints 1:002:003 But it should really print: 1:02:03 right?
Yes. ------------------------ $ cat t.c #include <stdio.h> int main() { int hour = 1, min = 2, precision = 2, sec = 3; printf("%1$d:%2$.*3$d:%4$.*3$d\n", hour, min, precision, sec); return 0; } $ make t cc t.c -o t $ ./t 1:02:03 -----------------------
Thanks! http://d.puremagic.com/issues/show_bug.cgi?id=3479 Andrei
Nov 06 2009
prev sibling parent Yigal Chripun <yigal100 gmail.com> writes:
On 06/11/2009 15:38, Leandro Lucarella wrote:
 Yigal Chripun, el  6 de noviembre a las 14:23 me escribiste:
 the c style format string that specifies types is a horrible horrible
 thing and should be removed.
 How do you do %.3f in {}-notation?
writefln("{0:F3}", value);
 Your formatting string should be written as writeln(ansi, " ", iso);
This is horrible, horrible for internationalization, you just can't assume how a language order words. Anyway, about the type in the format, I think it's nice, as you just proved, tango have it too "{0:F3}" is saying "treat the value as a float and format it that way". The deal is, the type should not be used to know the size of the parameter in the stack like in C's printf(), it should be just a hint to convert the value to another type. So, type specification is important. Variables reordering is important too, and you even have it in POSIX's printf(): printf("%1$d:%2$.*3$d:%4$.*3$d\n", hour, min, precision, sec); (see http://www.opengroup.org/onlinepubs/9699919799/functions/printf.html) I like printf()'s format (I don't know if it's just because I'm used to it though :).
F in the above is _not_ a type specifier. It is a format specifier that means "fixed". More over, each type defines it's own format specifiers, and there's also a way to custom format stuff. Here's some more examples: (from MSDN) string myName = "Fred"; Console.WriteLine(String.Format("Name = {0}, hours = {1:hh}, minutes = {1:mm}", myName, DateTime.Now)); // Depending on the current time, the example displays output like the following: // Name = Fred, hours = 11, minutes = 30 string FormatString1 = String.Format("{0:dddd MMMM}", DateTime.Now); string FormatString2 = DateTime.Now.ToString("dddd MMMM"); Console.WriteLine("{0:F}", DateTime.Now); // NOT float // F for DateTime means Full date/time pattern (long time). Another issue with the .NET design is that it's locale aware. e.g. // Display using pt-BR culture's short date format DateTime thisDate = new DateTime(2008, 3, 15); CultureInfo culture = new CultureInfo("pt-BR"); Console.WriteLine(thisDate.ToString("d", culture)); // Displays 15/3/2008 besides, the printf format is plain unreadable. It's like comparing ASCII to Unicode - D moved to native Unicode support and should move to this much better design as well.
Nov 06 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Yigal Chripun wrote:
 On 06/11/2009 12:34, Pelle Månsson wrote:
 Yigal Chripun wrote:
 On 06/11/2009 07:34, Don wrote:
 Nick Sabalausky wrote:
 "Don" <nospam nospam.com> wrote in message
 news:hcvf9l$91i$1 digitalmars.com...
 Justin Johansson wrote:
 So what does "toString" mean to you?
It's a hack from the early days of D. Should be unavailable unless the -debug flag is set, to discourage people from using it. I hate it.
What don't you like about it?
It cannot even do the most basic stuff. (1) You can't even make a struct that behaves like an int. struct MyInt { int z; string toString() { .... } } void main() { int a = 400; MyInt b = 400; writefln("%05d %05d", a, b); writefln("%x %x", a, b); } (2) It doesn't behave like a stream. Suppose you have XmlDoc.toString() You can't emit the doc, piece by piece. You have to create the ENTIRE string in one go!
The first issue you raise is IMO a problem with writefln and not with toString since writefln doesn't handle user-defined types properly. I think that writefln (btw, horrible name) should only deal with strings and their formatting and all other types need to provide an (optionally formatted) string. a numeric type would provide formatting of properties like number of decimal places, thousands separator, etc while user defined specification type could provide a type of standard format. auto spec = new Specification(HTML); string ansi = spec.toString(Specification.ANSI); string iso = spec.toString(Specification.ISO); the c style format string that specifies types is a horrible horrible thing and should be removed.
 How do you do %.3f in {}-notation?
writefln("{0:F3}", value);
 Your formatting string should be written as writeln(ansi, " ", iso);
That is incorrect since in my example I use the format string to switch the order of the strings. ( hence the numbers inside the {} ) Please go and read the tango documentation starting with http://www.dsource.org/projects/tango/wiki/TutCSharpFormatter it has also links to the MSDN docs which describe the modifiers: for instance: http://msdn.microsoft.com/en-us/library/dwhawy9k%28VS.100%29.aspx This is one area in phobos that needs to be rewritten from scratch or better yet, use tango. I'm still waiting for when hell will freeze over and tango and phobos will be merged together in one consistent API.
Not sure to what extent it helps, but Phobos supports positional parameters too. Andrei
Nov 06 2009
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Don (nospam nospam.com)'s article
 Justin Johansson wrote:
 I assert that the semantics of "toString" or similarly named/purposed
methods/functions in many
 PL's (including and not limited to D) is ill-defined.

 To put this statement into perspective, I would be most appreciative of D NG
readers
 responding with their own idea(s) of what the semantics of "toString" are (or
should be)
 in a language agnostic ideology.

 If there are more than, say, two or three different views on the said
semantics then my
 "ill-definition" assertion is surely correct.

 If there are no replies on this matter, then guess I'm left concludeless.

 Just thinking in the language round-up that this is (just another) one of the
things
 we should address as a community.

 So what does "toString" mean to you?
It's a hack from the early days of D. Should be unavailable unless the -debug flag is set, to discourage people from using it. I hate it.
Why? You've said this several times w/o giving your reason. IMHO toString() is a great way to get a default string representation of something. If you care about the formatting details, then you use a non-special method. How else would you recommend giving objects a sane default string representation?
Nov 05 2009
parent div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

dsimcha wrote:
 
 Why?  You've said this several times w/o giving your reason.  IMHO toString()
is a
 great way to get a default string representation of something.
And that's *exactly* what is wrong. There is *never* a good default for anything. Just look at all the discussion of nullable. (shit people even complain about float.init == NaN) - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFK82NwT9LetA9XoXwRAkh+AJ4552uLI2Fz938zj4SsmY0qIHga3QCfZ5pa Y5NmGJYF7tz8qk9K6GYB5J0= =jmrB -----END PGP SIGNATURE-----
Nov 05 2009
prev sibling parent Justin Johansson <no spam.com> writes:
Don Wrote:

 Justin Johansson wrote:
 I assert that the semantics of "toString" or similarly named/purposed
methods/functions in many
 PL's (including and not limited to D) is ill-defined.
 
 To put this statement into perspective, I would be most appreciative of D NG
readers
 responding with their own idea(s) of what the semantics of "toString" are (or
should be)
 in a language agnostic ideology.
 
 If there are more than, say, two or three different views on the said
semantics then my
 "ill-definition" assertion is surely correct.
 
 If there are no replies on this matter, then guess I'm left concludeless.
 
 Just thinking in the language round-up that this is (just another) one of the
things
 we should address as a community.
 
 So what does "toString" mean to you?
It's a hack from the early days of D. Should be unavailable unless the -debug flag is set, to discourage people from using it. I hate it.
There are some interesting replies coming along here. Thanks everybody for chipping in. I must admit though, when I read Don's reply just now the first thought that went through my mind was "Sweet!" Justin
Nov 05 2009
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Justin Johansson wrote:

...
 So what does "toString" mean to you?
Whatever you got, give it to me as a string for my printf debugging while my debugger is broken.
Nov 08 2009
prev sibling next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Justin Johansson wrote:

 I assert that the semantics of "toString" or similarly named/purposed
 methods/functions in many PL's (including and not limited to D) is
 ill-defined.
 
 To put this statement into perspective, I would be most appreciative of D
 NG readers responding with their own idea(s) of what the semantics of
 "toString" are (or should be) in a language agnostic ideology.
 
My other reply didn't take the language agnostic into account, sorry. Semantics of toString would depend on the object, I would think there are three general types of objects: 1. objects with only one sensible or one clear default string representations, like integers. Maybe even none of these exist (except strings themselves?) 2. objects that, given some formatting options or locale have a clear string representation. floating points, dates, curreny and the like. 3. objects that have no sensible default representation. toString() would not make sense for 3) type objects and only for 2) type objects as part of a formatting / localization package. toString() as a debugging aid sometimes doubles as a formatter for 1) and 2) class objects, but that may be more confusing than it's worth.
Nov 08 2009
parent reply Justin Johansson <no spam.com> writes:
Lutger Wrote:

 Justin Johansson wrote:
 
 I assert that the semantics of "toString" or similarly named/purposed
 methods/functions in many PL's (including and not limited to D) is
 ill-defined.
 
 To put this statement into perspective, I would be most appreciative of D
 NG readers responding with their own idea(s) of what the semantics of
 "toString" are (or should be) in a language agnostic ideology.
 
My other reply didn't take the language agnostic into account, sorry. Semantics of toString would depend on the object, I would think there are three general types of objects: 1. objects with only one sensible or one clear default string representations, like integers. Maybe even none of these exist (except strings themselves?) 2. objects that, given some formatting options or locale have a clear string representation. floating points, dates, curreny and the like. 3. objects that have no sensible default representation. toString() would not make sense for 3) type objects and only for 2) type objects as part of a formatting / localization package. toString() as a debugging aid sometimes doubles as a formatter for 1) and 2) class objects, but that may be more confusing than it's worth.
Thanks for that Lutger. Do you think it would make better sense if programming languages/their libraries separated functions/methods which are currently loosely purposed as "toString" into methods which are more specific to the types you suggest (leaving only the types/classifications and number thereof to argue about)? In my own D project, I've introduced a toDebugString method and left toString alone. There are times when I like D's default toString printing out the name of the object class. For debug purposes there are times also when I like to see a string printed out in quotes so you can tell the difference between "123" and 123. Then again, and since I'm working on a scripting language, sometimes I like to see debug output distinguish between different numeric types. Anyway going by the replies on this topic, looks like most people view toString as being good for debug purposes and that about it. Cheers Justin
Nov 08 2009
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Justin Johansson wrote:

 Lutger Wrote:
 
 Justin Johansson wrote:
 
 I assert that the semantics of "toString" or similarly named/purposed
 methods/functions in many PL's (including and not limited to D) is
 ill-defined.
 
 To put this statement into perspective, I would be most appreciative of
 D NG readers responding with their own idea(s) of what the semantics of
 "toString" are (or should be) in a language agnostic ideology.
 
My other reply didn't take the language agnostic into account, sorry. Semantics of toString would depend on the object, I would think there are three general types of objects: 1. objects with only one sensible or one clear default string representations, like integers. Maybe even none of these exist (except strings themselves?) 2. objects that, given some formatting options or locale have a clear string representation. floating points, dates, curreny and the like. 3. objects that have no sensible default representation. toString() would not make sense for 3) type objects and only for 2) type objects as part of a formatting / localization package. toString() as a debugging aid sometimes doubles as a formatter for 1) and 2) class objects, but that may be more confusing than it's worth.
Thanks for that Lutger. Do you think it would make better sense if programming languages/their libraries separated functions/methods which are currently loosely purposed as "toString" into methods which are more specific to the types you suggest (leaving only the types/classifications and number thereof to argue about)? In my own D project, I've introduced a toDebugString method and left toString alone. There are times when I like D's default toString printing out the name of the object class. For debug purposes there are times also when I like to see a string printed out in quotes so you can tell the difference between "123" and 123. Then again, and since I'm working on a scripting language, sometimes I like to see debug output distinguish between different numeric types. Anyway going by the replies on this topic, looks like most people view toString as being good for debug purposes and that about it. Cheers Justin
Your design makes better sense (to me at least) because it is based on why you want a string from some object. Take .NET for example: it does provide very elaborate and nice formatting options based and toString() with parameters. For some types however, the default toString() gives you the name of the type itself which is in no way related to formatting an object. You learn to work with it, but I find it a bit muddled. As a last note, I think people view toString as a debug thing mostly because it is very underpowered.
Nov 10 2009
parent reply Don <nospam nospam.com> writes:
Lutger wrote:
 Justin Johansson wrote:
 
 Lutger Wrote:

 Justin Johansson wrote:

 I assert that the semantics of "toString" or similarly named/purposed
 methods/functions in many PL's (including and not limited to D) is
 ill-defined.

 To put this statement into perspective, I would be most appreciative of
 D NG readers responding with their own idea(s) of what the semantics of
 "toString" are (or should be) in a language agnostic ideology.
My other reply didn't take the language agnostic into account, sorry. Semantics of toString would depend on the object, I would think there are three general types of objects: 1. objects with only one sensible or one clear default string representations, like integers. Maybe even none of these exist (except strings themselves?) 2. objects that, given some formatting options or locale have a clear string representation. floating points, dates, curreny and the like. 3. objects that have no sensible default representation. toString() would not make sense for 3) type objects and only for 2) type objects as part of a formatting / localization package. toString() as a debugging aid sometimes doubles as a formatter for 1) and 2) class objects, but that may be more confusing than it's worth.
Thanks for that Lutger. Do you think it would make better sense if programming languages/their libraries separated functions/methods which are currently loosely purposed as "toString" into methods which are more specific to the types you suggest (leaving only the types/classifications and number thereof to argue about)? In my own D project, I've introduced a toDebugString method and left toString alone. There are times when I like D's default toString printing out the name of the object class. For debug purposes there are times also when I like to see a string printed out in quotes so you can tell the difference between "123" and 123. Then again, and since I'm working on a scripting language, sometimes I like to see debug output distinguish between different numeric types. Anyway going by the replies on this topic, looks like most people view toString as being good for debug purposes and that about it. Cheers Justin
Your design makes better sense (to me at least) because it is based on why you want a string from some object. Take .NET for example: it does provide very elaborate and nice formatting options based and toString() with parameters. For some types however, the default toString() gives you the name of the type itself which is in no way related to formatting an object. You learn to work with it, but I find it a bit muddled. As a last note, I think people view toString as a debug thing mostly because it is very underpowered.
There is a definite use for such as thing. But the existing toString() is much, much worse than useless. People think you can do something with it, but you can't. eg, people have asked for BigInt to support toString(). That is an over-my-dead-body.
Nov 10 2009
next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Don wrote:
...
 
 There is a definite use for such as thing. But the existing toString()
 is much, much worse than useless. People think you can do something with
 it, but you can't.
 eg, people have asked for BigInt to support toString(). That is an
 over-my-dead-body.
Since you are in the know and probably the biggest toString() hater around: are there plans (or rejections thereof) to change toString() before D2 turns gold? Seems to me it could break quite some code.
Nov 10 2009
next sibling parent reply Justin Johansson <no spam.com> writes:
Lutger Wrote:

 Don wrote:
 ...
 
 There is a definite use for such as thing. But the existing toString()
 is much, much worse than useless. People think you can do something with
 it, but you can't.
 eg, people have asked for BigInt to support toString(). That is an
 over-my-dead-body.
Since you are in the know and probably the biggest toString() hater around: are there plans (or rejections thereof) to change toString() before D2 turns gold? Seems to me it could break quite some code.
I have a feeling (and I may well be wrong) that toString might be used in relation to associative arrays. I implemented an AA recently based upon a struct key (I think). Though I cannot remember the exact details I do remember DMD saying something about toString not implemented and so without thinking I gave the struct a toString and that kept DMD happy. Since the code was throw-away I didn't bother to investigate. Like I say, I cannot remember the details but others may recall some similar experience. For all I know it may be a case of RTFM? beers, Justin
Nov 10 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Tue, Nov 10, 2009 at 3:59 AM, Justin Johansson <no spam.com> wrote:
 Lutger Wrote:

 Don wrote:
 ...
 There is a definite use for such as thing. But the existing toString()
 is much, much worse than useless. People think you can do something wi=
th
 it, but you can't.
 eg, people have asked for BigInt to support toString(). That is an
 over-my-dead-body.
Since you are in the know and probably the biggest toString() hater arou=
nd:
 are there plans (or rejections thereof) to change toString() before D2 t=
urns
 gold? Seems to me it could break quite some code.
I have a feeling (and I may well be wrong) that toString might be used in relation to associative arrays. =A0I implemented an AA recently based upo=
n
 a struct key (I think). =A0Though I cannot remember the exact details I d=
o
 remember DMD saying something about toString not implemented and
 so without thinking I gave the struct a toString and that kept DMD happy.
 Since the code was throw-away I didn't bother to investigate.

 Like I say, I cannot remember the details but others may recall some simi=
lar
 experience. =A0For all I know it may be a case of RTFM?
Shouldn't be the case. From TFM: """ Classes can be used as the KeyType. For this to work, the class definition must override the following member functions of class Object: =95hash_t toHash() =95bool opEquals(Object) =95int opCmp(Object) """ --bb
Nov 10 2009
parent Justin Johansson <no spam.com> writes:
Bill Baxter Wrote:

 On Tue, Nov 10, 2009 at 3:59 AM, Justin Johansson <no spam.com> wrote:
 Lutger Wrote:

 Don wrote:
 ...
 There is a definite use for such as thing. But the existing toString()
 is much, much worse than useless. People think you can do something with
 it, but you can't.
 eg, people have asked for BigInt to support toString(). That is an
 over-my-dead-body.
Since you are in the know and probably the biggest toString() hater around: are there plans (or rejections thereof) to change toString() before D2 turns gold? Seems to me it could break quite some code.
I have a feeling (and I may well be wrong) that toString might be used in relation to associative arrays.  I implemented an AA recently based upon a struct key (I think).  Though I cannot remember the exact details I do remember DMD saying something about toString not implemented and so without thinking I gave the struct a toString and that kept DMD happy. Since the code was throw-away I didn't bother to investigate. Like I say, I cannot remember the details but others may recall some similar experience.  For all I know it may be a case of RTFM?
Shouldn't be the case. From TFM: """ Classes can be used as the KeyType. For this to work, the class definition must override the following member functions of class Object: •hash_t toHash() •bool opEquals(Object) •int opCmp(Object) """ --bb
I think you are right; if I can dig up what it was, and if relevant to this discussion, I'll post it. Ignore what I said for mom. Just wondering now though and in reference to Lutger's comment
 Since you are in the know and probably the biggest toString() hater around:
 are there plans (or rejections thereof) to change toString() before D2 turns
 gold? Seems to me it could break quite some code.
how much core code would be broken if toString was actually banished?
Nov 10 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Lutger wrote:
 Don wrote:
 ...
 There is a definite use for such as thing. But the existing toString()
 is much, much worse than useless. People think you can do something with
 it, but you can't.
 eg, people have asked for BigInt to support toString(). That is an
 over-my-dead-body.
Since you are in the know and probably the biggest toString() hater around: are there plans (or rejections thereof) to change toString() before D2 turns gold? Seems to me it could break quite some code.
I'm hoping someone will come up with a design. Straw man: void toString(void delegate(const(char)[]) sink, string fmt) { // fmt holds the format string from writefln/formatln. // call sink() to print partial results. }
Nov 10 2009
next sibling parent reply Justin Johansson <no spam.com> writes:
Don Wrote:

 Lutger wrote:
 Don wrote:
 ...
 There is a definite use for such as thing. But the existing toString()
 is much, much worse than useless. People think you can do something with
 it, but you can't.
 eg, people have asked for BigInt to support toString(). That is an
 over-my-dead-body.
Since you are in the know and probably the biggest toString() hater around: are there plans (or rejections thereof) to change toString() before D2 turns gold? Seems to me it could break quite some code.
I'm hoping someone will come up with a design. Straw man: void toString(void delegate(const(char)[]) sink, string fmt) { // fmt holds the format string from writefln/formatln. // call sink() to print partial results. }
That's starting to look like a "serialize" method!
Nov 10 2009
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 10 Nov 2009 07:49:11 -0500, Justin Johansson <no spam.com> wrote:

 Don Wrote:

 Lutger wrote:
 Don wrote:
 ...
 There is a definite use for such as thing. But the existing  
toString()
 is much, much worse than useless. People think you can do something  
with
 it, but you can't.
 eg, people have asked for BigInt to support toString(). That is an
 over-my-dead-body.
Since you are in the know and probably the biggest toString() hater
around:
 are there plans (or rejections thereof) to change toString() before  
D2 turns
 gold? Seems to me it could break quite some code.
I'm hoping someone will come up with a design. Straw man: void toString(void delegate(const(char)[]) sink, string fmt) { // fmt holds the format string from writefln/formatln. // call sink() to print partial results. }
That's starting to look like a "serialize" method!
As it should. I should be able to print a 10000 element container without having to load a string representation of 10000 elements in memory. I'd also like to see the name toString changed to something more appropriate, like output(). And although I think a direct translation is mostly possible, emulating writefln string formatting from tango would be a burden. I don't know if there's any way around it without coming up with some complicated "formatting provider" interface/object implementation, and I don't think it's worth it. Unfortunately, I doubt Walter accepts this, it's been proposed in the past without success. -Steve
Nov 10 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Tue, 10 Nov 2009 07:49:11 -0500, Justin Johansson <no spam.com> wrote:
 
 Don Wrote:

 Lutger wrote:
 Don wrote:
 ...
 There is a definite use for such as thing. But the existing 
toString()
 is much, much worse than useless. People think you can do 
something with
 it, but you can't.
 eg, people have asked for BigInt to support toString(). That is an
 over-my-dead-body.
Since you are in the know and probably the biggest toString() hater
around:
 are there plans (or rejections thereof) to change toString() before 
D2 turns
 gold? Seems to me it could break quite some code.
I'm hoping someone will come up with a design. Straw man: void toString(void delegate(const(char)[]) sink, string fmt) { // fmt holds the format string from writefln/formatln. // call sink() to print partial results. }
That's starting to look like a "serialize" method!
As it should. I should be able to print a 10000 element container without having to load a string representation of 10000 elements in memory. I'd also like to see the name toString changed to something more appropriate, like output(). And although I think a direct translation is mostly possible, emulating writefln string formatting from tango would be a burden. I don't know if there's any way around it without coming up with some complicated "formatting provider" interface/object implementation, and I don't think it's worth it. Unfortunately, I doubt Walter accepts this, it's been proposed in the past without success. -Steve
Walter does not feel strongly about Phobos. The save() method in "On Iteration" intently makes it possible to define ranges as interfaces, which in turn should pave the way towards defining a coherent text streaming mechanism. Andrei
Nov 10 2009
prev sibling next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Tue, Nov 10, 2009 at 4:40 AM, Don <nospam nospam.com> wrote:
 Lutger wrote:
 Don wrote:
 ...
 There is a definite use for such as thing. But the existing toString()
 is much, much worse than useless. People think you can do something with
 it, but you can't.
 eg, people have asked for BigInt to support toString(). That is an
 over-my-dead-body.
Since you are in the know and probably the biggest toString() hater around: are there plans (or rejections thereof) to change toString() before D2 turns gold? Seems to me it could break quite some code.
I'm hoping someone will come up with a design. Straw man: void toString(void delegate(const(char)[]) sink, string fmt) { // fmt holds the format string from writefln/formatln. // call sink() to print partial results. }
That looks pretty good, actually. I guess I would like to see plain no-arg toString() still supported. A default toString() could be implemented in terms of the fancy one as: string toString() { char buf[]; toString( (string s) { buf ~= s; }, "" ); return assumeUnique!(buf); } could be a mixin in a library I suppose. I think I would like to see the format strings not necessarily tied to writefln's particular format. --bb
Nov 10 2009
parent reply Don <nospam nospam.com> writes:
Bill Baxter wrote:
 On Tue, Nov 10, 2009 at 4:40 AM, Don <nospam nospam.com> wrote:
 Lutger wrote:
 Don wrote:
 ...
 There is a definite use for such as thing. But the existing toString()
 is much, much worse than useless. People think you can do something with
 it, but you can't.
 eg, people have asked for BigInt to support toString(). That is an
 over-my-dead-body.
Since you are in the know and probably the biggest toString() hater around: are there plans (or rejections thereof) to change toString() before D2 turns gold? Seems to me it could break quite some code.
I'm hoping someone will come up with a design. Straw man: void toString(void delegate(const(char)[]) sink, string fmt) { // fmt holds the format string from writefln/formatln. // call sink() to print partial results. }
That looks pretty good, actually. I guess I would like to see plain no-arg toString() still supported.
The thing is, the toString() function is essentially a virtual function present in every struct. Each one of those functions needs a very strong justification to exist.
 A default toString() could be implemented in terms of the fancy one as:
 
 string toString() {
      char buf[];
      toString( (string s) { buf ~= s; }, "" );
      return assumeUnique!(buf);
 }
 
 could be a mixin in a library I suppose.
More for the benefit of consumers, or producers? Because void toString(void delegate(const(char)[]) sink, string fmt) { sink("xxx"); } isn't much more complex than: string toString() { return "xxx"; } other than the signature.
 
 I think I would like to see the format strings not necessarily tied to
 writefln's particular format.
I think the format strings are actually pretty similar, Tango vs writefln? There might be enough common ground. I think the Tango format is a slight superset of the writefln one.
Nov 10 2009
parent Bill Baxter <wbaxter gmail.com> writes:
On Tue, Nov 10, 2009 at 7:29 AM, Don <nospam nospam.com> wrote:
 Bill Baxter wrote:
 On Tue, Nov 10, 2009 at 4:40 AM, Don <nospam nospam.com> wrote:
 Lutger wrote:
 Don wrote:
 ...
 There is a definite use for such as thing. But the existing toString(=
)
 is much, much worse than useless. People think you can do something
 with
 it, but you can't.
 eg, people have asked for BigInt to support toString(). That is an
 over-my-dead-body.
Since you are in the know and probably the biggest toString() hater around: are there plans (or rejections thereof) to change toString() before D2 turns gold? Seems to me it could break quite some code.
I'm hoping someone will come up with a design. Straw man: void toString(void delegate(const(char)[]) sink, string fmt) { // fmt holds the format string from writefln/formatln. // call sink() to print partial results. }
That looks pretty good, actually. I guess I would like to see plain no-arg toString() still supported.
The thing is, the toString() function is essentially a virtual function present in every struct. Each one of those functions needs a very strong justification to exist.
Structs can't have virtual functions... so what do you mean?
 A default toString() could be implemented in terms of the fancy one as:

 string toString() {
 =A0 =A0 char buf[];
 =A0 =A0 toString( (string s) { buf ~=3D s; }, "" );
 =A0 =A0 return assumeUnique!(buf);
 }

 could be a mixin in a library I suppose.
More for the benefit of consumers, or producers?
Consumers. I was just thinking it would be a little annoying to have to reproduce the above 3-line snippet of code every time I want to get the string version of an object. But I guess such needs can be adequately served by std.string.format or sformat. So scratch that, no old-style toString() needed.
 Because
 void toString(void delegate(const(char)[]) sink, string fmt) {
 =A0 sink("xxx");
 }
 isn't much more complex than:
 string toString()
 {
 =A0return "xxx";
 }
 other than the signature.
Yeh, for authors of toString methods it's fine. Well, a different way to write delegates would be nice, but that's a different discussion.
 I think I would like to see the format strings not necessarily tied to
 writefln's particular format.
I think the format strings are actually pretty similar, Tango vs writefln=
?
 There might be enough common ground. I think the Tango format is a slight
 superset of the writefln one.
Pretty similar, maybe, but I'd be surprised if they just happened to be identical without any attempt at compatibility having been made. --bb
Nov 10 2009
prev sibling next sibling parent reply grauzone <none example.net> writes:
Don wrote:
 Lutger wrote:
 Don wrote:
 ...
 There is a definite use for such as thing. But the existing toString()
 is much, much worse than useless. People think you can do something with
 it, but you can't.
 eg, people have asked for BigInt to support toString(). That is an
 over-my-dead-body.
How are you supposed to print a BigInt then?
 Since you are in the know and probably the biggest toString() hater 
 around: are there plans (or rejections thereof) to change toString() 
 before D2 turns gold? Seems to me it could break quite some code.
I'm hoping someone will come up with a design. Straw man: void toString(void delegate(const(char)[]) sink, string fmt) { // fmt holds the format string from writefln/formatln. // call sink() to print partial results. }
Just put it into an "interface DebugOutput", remove Object.toString(), and be done with it. That interface could be defined in the same module as writefln or format, and its use will be clear.
Nov 10 2009
parent reply Don <nospam nospam.com> writes:
grauzone wrote:
 Don wrote:
 Lutger wrote:
 Don wrote:
 ...
 There is a definite use for such as thing. But the existing toString()
 is much, much worse than useless. People think you can do something 
 with
 it, but you can't.
 eg, people have asked for BigInt to support toString(). That is an
 over-my-dead-body.
How are you supposed to print a BigInt then?
How are you supposed to print one with it? It doesn't help. (The problem even more obvious if you consider BigFloat).
 Just put it into an "interface DebugOutput", remove Object.toString(), 
 and be done with it. That interface could be defined in the same module 
 as writefln or format, and its use will be clear.
BigInt is a struct, so it doesn't have interfaces.
Nov 10 2009
parent reply grauzone <none example.net> writes:
Don wrote:
 grauzone wrote:
 Don wrote:
 Lutger wrote:
 Don wrote:
 ...
 There is a definite use for such as thing. But the existing toString()
 is much, much worse than useless. People think you can do something 
 with
 it, but you can't.
 eg, people have asked for BigInt to support toString(). That is an
 over-my-dead-body.
How are you supposed to print a BigInt then?
How are you supposed to print one with it? It doesn't help. (The problem even more obvious if you consider BigFloat).
 Just put it into an "interface DebugOutput", remove Object.toString(), 
 and be done with it. That interface could be defined in the same 
 module as writefln or format, and its use will be clear.
BigInt is a struct, so it doesn't have interfaces.
Structs are a different matter. Nothing dictates that a struct should have a toString method, or what arguments that method should have, right? (There's this compiler/runtime hack to make struct toString work with writefln, but now that wirtefln uses compile time varargs, it can go.)
Nov 10 2009
parent Don <nospam nospam.com> writes:
grauzone wrote:
 Don wrote:
 grauzone wrote:
 Don wrote:
 Lutger wrote:
 Don wrote:
 ...
 There is a definite use for such as thing. But the existing 
 toString()
 is much, much worse than useless. People think you can do 
 something with
 it, but you can't.
 eg, people have asked for BigInt to support toString(). That is an
 over-my-dead-body.
How are you supposed to print a BigInt then?
How are you supposed to print one with it? It doesn't help. (The problem even more obvious if you consider BigFloat).
 Just put it into an "interface DebugOutput", remove 
 Object.toString(), and be done with it. That interface could be 
 defined in the same module as writefln or format, and its use will be 
 clear.
BigInt is a struct, so it doesn't have interfaces.
Structs are a different matter. Nothing dictates that a struct should have a toString method, or what arguments that method should have, right? (There's this compiler/runtime hack to make struct toString work with writefln, but now that wirtefln uses compile time varargs, it can go.)
This discussion is about that hack. Yes, it might be unnecessary if compile time varargs work sufficiently well.
Nov 10 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Don wrote:
 Lutger wrote:
 Don wrote:
 ...
 There is a definite use for such as thing. But the existing toString()
 is much, much worse than useless. People think you can do something with
 it, but you can't.
 eg, people have asked for BigInt to support toString(). That is an
 over-my-dead-body.
Since you are in the know and probably the biggest toString() hater around: are there plans (or rejections thereof) to change toString() before D2 turns gold? Seems to me it could break quite some code.
I'm hoping someone will come up with a design. Straw man: void toString(void delegate(const(char)[]) sink, string fmt) { // fmt holds the format string from writefln/formatln. // call sink() to print partial results. }
I think the best option for toString is to take an output range and write to it. (The sink is a simplified range.) Andrei
Nov 10 2009
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 11 Nov 2009 02:49:54 +0300, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Don wrote:
 Lutger wrote:
 Don wrote:
 ...
 There is a definite use for such as thing. But the existing toString()
 is much, much worse than useless. People think you can do something  
 with
 it, but you can't.
 eg, people have asked for BigInt to support toString(). That is an
 over-my-dead-body.
Since you are in the know and probably the biggest toString() hater around: are there plans (or rejections thereof) to change toString() before D2 turns gold? Seems to me it could break quite some code.
I'm hoping someone will come up with a design. Straw man: void toString(void delegate(const(char)[]) sink, string fmt) { // fmt holds the format string from writefln/formatln. // call sink() to print partial results. }
I think the best option for toString is to take an output range and write to it. (The sink is a simplified range.) Andrei
It means toString() must be either a template, or accept an abstract InputRange interface?
Nov 10 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:
 On Wed, 11 Nov 2009 02:49:54 +0300, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Don wrote:
 Lutger wrote:
 Don wrote:
 ...
 There is a definite use for such as thing. But the existing toString()
 is much, much worse than useless. People think you can do something 
 with
 it, but you can't.
 eg, people have asked for BigInt to support toString(). That is an
 over-my-dead-body.
Since you are in the know and probably the biggest toString() hater around: are there plans (or rejections thereof) to change toString() before D2 turns gold? Seems to me it could break quite some code.
I'm hoping someone will come up with a design. Straw man: void toString(void delegate(const(char)[]) sink, string fmt) { // fmt holds the format string from writefln/formatln. // call sink() to print partial results. }
I think the best option for toString is to take an output range and write to it. (The sink is a simplified range.) Andrei
It means toString() must be either a template, or accept an abstract InputRange interface?
It should take an interface. Andrei
Nov 10 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
2009/11/10 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:
 Denis Koroskin wrote:
 On Wed, 11 Nov 2009 02:49:54 +0300, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Don wrote:
 Lutger wrote:
 Don wrote:
 ...
 There is a definite use for such as thing. But the existing toString=
()
 is much, much worse than useless. People think you can do something
 with
 it, but you can't.
 eg, people have asked for BigInt to support toString(). That is an
 over-my-dead-body.
Since you are in the know and probably the biggest toString() hater around: are there plans (or rejections thereof) to change toString() =
before
 D2 turns gold? Seems to me it could break quite some code.
=A0I'm hoping someone will come up with a design. =A0Straw man: =A0void toString(void delegate(const(char)[]) sink, string fmt) { =A0// fmt holds the format string from writefln/formatln. // call sink() to print partial results. =A0}
I think the best option for toString is to take an output range and wri=
te
 to it. (The sink is a simplified range.)

 Andrei
It means toString() must be either a template, or accept an abstract InputRange interface?
It should take an interface.
So yet another type in object.d? Or require users in import something specific in every module that's going to use toString? --bb
Nov 10 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 2009/11/10 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:
 Denis Koroskin wrote:
 On Wed, 11 Nov 2009 02:49:54 +0300, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Don wrote:
 Lutger wrote:
 Don wrote:
 ...
 There is a definite use for such as thing. But the existing toString()
 is much, much worse than useless. People think you can do something
 with
 it, but you can't.
 eg, people have asked for BigInt to support toString(). That is an
 over-my-dead-body.
Since you are in the know and probably the biggest toString() hater around: are there plans (or rejections thereof) to change toString() before D2 turns gold? Seems to me it could break quite some code.
I'm hoping someone will come up with a design. Straw man: void toString(void delegate(const(char)[]) sink, string fmt) { // fmt holds the format string from writefln/formatln. // call sink() to print partial results. }
I think the best option for toString is to take an output range and write to it. (The sink is a simplified range.) Andrei
It means toString() must be either a template, or accept an abstract InputRange interface?
It should take an interface.
So yet another type in object.d? Or require users in import something specific in every module that's going to use toString? --bb
I am not sure. Opinions as always are welcome. Andrei
Nov 10 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Tue, Nov 10, 2009 at 5:27 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 2009/11/10 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:
 Denis Koroskin wrote:
 On Wed, 11 Nov 2009 02:49:54 +0300, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Don wrote:
 Lutger wrote:
 Don wrote:
 ...
 There is a definite use for such as thing. But the existing
 toString()
 is much, much worse than useless. People think you can do somethin=
g
 with
 it, but you can't.
 eg, people have asked for BigInt to support toString(). That is an
 over-my-dead-body.
Since you are in the know and probably the biggest toString() hater around: are there plans (or rejections thereof) to change toString(=
)
 before
 D2 turns gold? Seems to me it could break quite some code.
=A0I'm hoping someone will come up with a design. =A0Straw man: =A0void toString(void delegate(const(char)[]) sink, string fmt) { =A0// fmt holds the format string from writefln/formatln. // call sink() to print partial results. =A0}
I think the best option for toString is to take an output range and write to it. (The sink is a simplified range.) Andrei
It means toString() must be either a template, or accept an abstract InputRange interface?
It should take an interface.
So yet another type in object.d? Or require users in import something specific in every module that's going to use toString? --bb
I am not sure. Opinions as always are welcome.
That's why my opinion is that the delegate idea is nice. :-) But I guess toString is already defined by Object, right? So it would make sense for an interface needed by an Object method to be defined in object.d. I suppose it could be an interface defined inside the Object class itself? (Does that work? can you define interfaces inside classes?) --bb
Nov 10 2009
parent Don <nospam nospam.com> writes:
Bill Baxter wrote:
 On Tue, Nov 10, 2009 at 5:27 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 2009/11/10 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:
 Denis Koroskin wrote:
 On Wed, 11 Nov 2009 02:49:54 +0300, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Don wrote:
 Lutger wrote:
 Don wrote:
 ...
 There is a definite use for such as thing. But the existing
 toString()
 is much, much worse than useless. People think you can do something
 with
 it, but you can't.
 eg, people have asked for BigInt to support toString(). That is an
 over-my-dead-body.
Since you are in the know and probably the biggest toString() hater around: are there plans (or rejections thereof) to change toString() before D2 turns gold? Seems to me it could break quite some code.
I'm hoping someone will come up with a design. Straw man: void toString(void delegate(const(char)[]) sink, string fmt) { // fmt holds the format string from writefln/formatln. // call sink() to print partial results. }
I think the best option for toString is to take an output range and write to it. (The sink is a simplified range.) Andrei
It means toString() must be either a template, or accept an abstract InputRange interface?
It should take an interface.
So yet another type in object.d? Or require users in import something specific in every module that's going to use toString? --bb
I am not sure. Opinions as always are welcome.
That's why my opinion is that the delegate idea is nice. :-) But I guess toString is already defined by Object, right? So it would make sense for an interface needed by an Object method to be defined in object.d. I suppose it could be an interface defined inside the Object class itself? (Does that work? can you define interfaces inside classes?)
It also needs to be used by structs, which aren't inherited from Object. So I don't see how a nested interface could work. I suggest a design acceptance criterion: the simplest case should be about as simple as: return "xxx"; or put("xxx");
Nov 11 2009
prev sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 11 Nov 2009 04:27:45 +0300, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:
 2009/11/10 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:
 Denis Koroskin wrote:
 On Wed, 11 Nov 2009 02:49:54 +0300, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Don wrote:
 Lutger wrote:
 Don wrote:
 ...
 There is a definite use for such as thing. But the existing  
 toString()
 is much, much worse than useless. People think you can do  
 something
 with
 it, but you can't.
 eg, people have asked for BigInt to support toString(). That is an
 over-my-dead-body.
Since you are in the know and probably the biggest toString() hater around: are there plans (or rejections thereof) to change toString() before D2 turns gold? Seems to me it could break quite some code.
I'm hoping someone will come up with a design. Straw man: void toString(void delegate(const(char)[]) sink, string fmt) { // fmt holds the format string from writefln/formatln. // call sink() to print partial results. }
I think the best option for toString is to take an output range and write to it. (The sink is a simplified range.) Andrei
It means toString() must be either a template, or accept an abstract InputRange interface?
It should take an interface.
So yet another type in object.d? Or require users in import something specific in every module that's going to use toString? --bb
I am not sure. Opinions as always are welcome. Andrei
Some ranges may be polymorphic, so having base interface hierarchy in Phobos would be useful anyway. BTW, save() is already implemented and used throughout the Phobos under a different name - opSlice (i.e. auto copy = range[]). It's a bikeshed discussion, but why save() and not opSlice(), or even clone()?
Nov 11 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:
 On Wed, 11 Nov 2009 04:27:45 +0300, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Bill Baxter wrote:
 2009/11/10 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:
 Denis Koroskin wrote:
 On Wed, 11 Nov 2009 02:49:54 +0300, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Don wrote:
 Lutger wrote:
 Don wrote:
 ...
 There is a definite use for such as thing. But the existing 
 toString()
 is much, much worse than useless. People think you can do 
 something
 with
 it, but you can't.
 eg, people have asked for BigInt to support toString(). That is an
 over-my-dead-body.
Since you are in the know and probably the biggest toString() hater around: are there plans (or rejections thereof) to change toString() before D2 turns gold? Seems to me it could break quite some code.
I'm hoping someone will come up with a design. Straw man: void toString(void delegate(const(char)[]) sink, string fmt) { // fmt holds the format string from writefln/formatln. // call sink() to print partial results. }
I think the best option for toString is to take an output range and write to it. (The sink is a simplified range.) Andrei
It means toString() must be either a template, or accept an abstract InputRange interface?
It should take an interface.
So yet another type in object.d? Or require users in import something specific in every module that's going to use toString? --bb
I am not sure. Opinions as always are welcome. Andrei
Some ranges may be polymorphic, so having base interface hierarchy in Phobos would be useful anyway. BTW, save() is already implemented and used throughout the Phobos under a different name - opSlice (i.e. auto copy = range[]). It's a bikeshed discussion, but why save() and not opSlice(), or even clone()?
It can't be clone() because it doesn't clone. For example say you have a T[] - one would expect clone() actually copies the content. But using opSlice is a good idea. Andrei
Nov 11 2009
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 11 Nov 2009 18:50:47 +0300, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Denis Koroskin wrote:
 On Wed, 11 Nov 2009 04:27:45 +0300, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:
 2009/11/10 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:
 Denis Koroskin wrote:
 On Wed, 11 Nov 2009 02:49:54 +0300, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Don wrote:
 Lutger wrote:
 Don wrote:
 ...
 There is a definite use for such as thing. But the existing  
 toString()
 is much, much worse than useless. People think you can do  
 something
 with
 it, but you can't.
 eg, people have asked for BigInt to support toString(). That is  
 an
 over-my-dead-body.
Since you are in the know and probably the biggest toString() hater around: are there plans (or rejections thereof) to change toString() before D2 turns gold? Seems to me it could break quite some code.
I'm hoping someone will come up with a design. Straw man: void toString(void delegate(const(char)[]) sink, string fmt) { // fmt holds the format string from writefln/formatln. // call sink() to print partial results. }
I think the best option for toString is to take an output range and write to it. (The sink is a simplified range.) Andrei
It means toString() must be either a template, or accept an abstract InputRange interface?
It should take an interface.
So yet another type in object.d? Or require users in import something specific in every module that's going to use toString? --bb
I am not sure. Opinions as always are welcome. Andrei
Some ranges may be polymorphic, so having base interface hierarchy in Phobos would be useful anyway. BTW, save() is already implemented and used throughout the Phobos under a different name - opSlice (i.e. auto copy = range[]). It's a bikeshed discussion, but why save() and not opSlice(), or even clone()?
It can't be clone() because it doesn't clone. For example say you have a T[] - one would expect clone() actually copies the content. But using opSlice is a good idea. Andrei
Well, range doesn't own any of the contents it covers, so deep copy is impossible. Yet, there is also .dup array property which is pretends to be a standard way of creating instance copies.
Nov 11 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:
 Well, range doesn't own any of the contents it covers, so deep copy is 
 impossible.
 Yet, there is also .dup array property which is pretends to be a 
 standard way of creating instance copies.
Well so the second sentence contradicts the first. Let me put it another way: you have the entire vocabulary at your disposal to define save(). Wouldn't you think clone() may be a bit more confusing than others? Andrei
Nov 11 2009
parent Bill Baxter <wbaxter gmail.com> writes:
2009/11/11 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:
 Denis Koroskin wrote:
 Well, range doesn't own any of the contents it covers, so deep copy is
 impossible.
 Yet, there is also .dup array property which is pretends to be a standard
 way of creating instance copies.
Well so the second sentence contradicts the first. Let me put it another way: you have the entire vocabulary at your disposal to define save(). Wouldn't you think clone() may be a bit more confusing than others?
makeBreadCrumb() ? :-) --bb
Nov 11 2009
prev sibling parent reply Philippe Sigaud <philippe.sigaud gmail.com> writes:
Denis:
BTW, save() is already implemented and used throughout the Phobos under a
different name - opSlice (i.e. auto copy = range[]). It's a bikeshed discussion, but why save() and not opSlice(), or even clone()? 2009/11/11 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>
 It can't be clone() because it doesn't clone. For example say you have a
 T[] - one would expect clone() actually copies the content. But using
 opSlice is a good idea.
I don't get it. Shouldn't save() copy the content? Do you mean we could use opSlice() (the parameterless version) as a save function and write "auto r2 = r1[];"? But, again maybe I don't get something: for dyn. arrays (aka the range archetype) opSlice is not a save, it's just an alias. So using opSlice doesn't work for remembering positions with arrays. Philippe
Nov 11 2009
parent "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 11 Nov 2009 20:08:52 +0300, Philippe Sigaud  
<philippe.sigaud gmail.com> wrote:

 Denis:
 BTW, save() is already implemented and used throughout the Phobos under  
 a
different name - opSlice (i.e. auto copy = range[]). It's a bikeshed discussion, but why save() and not opSlice(), or even clone()? 2009/11/11 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>
 It can't be clone() because it doesn't clone. For example say you have a
 T[] - one would expect clone() actually copies the content. But using
 opSlice is a good idea.
I don't get it. Shouldn't save() copy the content? Do you mean we could use opSlice() (the parameterless version) as a save function and write "auto r2 = r1[];"? But, again maybe I don't get something: for dyn. arrays (aka the range archetype) opSlice is not a save, it's just an alias. So using opSlice doesn't work for remembering positions with arrays. Philippe
It remembers array bounds, not contents.
Nov 11 2009
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 10 Nov 2009 18:49:54 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 I think the best option for toString is to take an output range and  
 write to it. (The sink is a simplified range.)
Bad idea... A range only makes sense as a struct, not an interface/object. I'll tell you why: performance. Ranges are special in two respects: 1. They are foreachable. I think everyone agrees that calling 2 interface functions per loop iteration is much lower performing than using opApply, which calls one delegate function per loop. My recommendation -- use opApply when dealing with polymorphism. I don't think there's a way around this. 2. They are useful for passing to std.algorithm. But std.algorithm is template-interfaced. No need for using interfaces because the correct instatiation will be chosen. If you are intending to add a streaming module that uses ranges, would it not be templated for the range type as std.algorithm is? If not, the next logical choice is a delegate, which requires no vtable lookup. Using an interface is just asking for a performance penalty for not much gain. Here's what I mean by not much gain: I would expect a stream range that does output to have a method in it for outputting a buffer (I'd laugh at you if you wanted to define a stream range that outputs a character at a time). So the difference between: x.toString(outputRange, format) and x.toString(&outputRange.sink, format) is pretty darn minimal, and if outputRange is an interface or object, this saves a virtual call per buffer write. Plus the second form is more universal, you can pass any delegate, and not have to use a range type to wrap a delegate. Don't fall into the "OOP newbie" trap -- where just because you've found a new concept that is amazing, you want to use it for everything. I say this because I've seen in the past where someone discovers the power of OOP and then wants to use it for everything, when in some cases, it's overkill. Just look at some Java "classes"... From another thread:
 Walter does not feel strongly about Phobos.
Huh? I feel like this sentence doesn't make sense, so maybe there's a typo. -Steve
Nov 12 2009
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 12 Nov 2009 08:22:26 -0500, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 On Tue, 10 Nov 2009 18:49:54 -0500, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 I think the best option for toString is to take an output range and  
 write to it. (The sink is a simplified range.)
Bad idea... A range only makes sense as a struct, not an interface/object. I'll tell you why: performance. Ranges are special in two respects: 1. They are foreachable. I think everyone agrees that calling 2 interface functions per loop iteration is much lower performing than using opApply, which calls one delegate function per loop. My recommendation -- use opApply when dealing with polymorphism. I don't think there's a way around this.
Oops, I meant 3 virtual functions -- front, popNext, and empty. -Steve
Nov 12 2009
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 12 Nov 2009 16:23:22 +0300, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 On Thu, 12 Nov 2009 08:22:26 -0500, Steven Schveighoffer  
 <schveiguy yahoo.com> wrote:

 On Tue, 10 Nov 2009 18:49:54 -0500, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 I think the best option for toString is to take an output range and  
 write to it. (The sink is a simplified range.)
Bad idea... A range only makes sense as a struct, not an interface/object. I'll tell you why: performance. Ranges are special in two respects: 1. They are foreachable. I think everyone agrees that calling 2 interface functions per loop iteration is much lower performing than using opApply, which calls one delegate function per loop. My recommendation -- use opApply when dealing with polymorphism. I don't think there's a way around this.
Oops, I meant 3 virtual functions -- front, popNext, and empty. -Steve
Output range has only one method: put. I'm not sure, but I don't think there is a performance difference between calling a virtual function through an interface and invoking a delegate. But I agree passing a delegate is more generic. You can substitute an output range with a delegate (obj.toString(&range.put, fmt)) without any performance hit, but not vice versa (obj.toString(new DelegateWrapRange(&myput), fmt) implies an additional allocation and additional indirection per range.put call).
Nov 12 2009
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 12 Nov 2009 08:56:06 -0500, Denis Koroskin <2korden gmail.com>  
wrote:

 On Thu, 12 Nov 2009 16:23:22 +0300, Steven Schveighoffer  
 <schveiguy yahoo.com> wrote:

 On Thu, 12 Nov 2009 08:22:26 -0500, Steven Schveighoffer  
 <schveiguy yahoo.com> wrote:

 On Tue, 10 Nov 2009 18:49:54 -0500, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 I think the best option for toString is to take an output range and  
 write to it. (The sink is a simplified range.)
Bad idea... A range only makes sense as a struct, not an interface/object. I'll tell you why: performance. Ranges are special in two respects: 1. They are foreachable. I think everyone agrees that calling 2 interface functions per loop iteration is much lower performing than using opApply, which calls one delegate function per loop. My recommendation -- use opApply when dealing with polymorphism. I don't think there's a way around this.
Oops, I meant 3 virtual functions -- front, popNext, and empty. -Steve
Output range has only one method: put.
I was referring to range's ability to interact with foreach. An output range wouldn't qualify as a foreachable entity anyways (and rightfully so). Just covering all the bases.
 I'm not sure, but I don't think there is a performance difference  
 between calling a virtual function through an interface and invoking a  
 delegate.
Yes, there is: A delegate is equivalent to a struct member function call. (load data pointer (i.e. this), push args, call function) A virtual function uses a vtable to look up the function address, and then is equivalent to a struct member call. An interface function call is equivalent to a virtual call with the added penalty that you might have to adjust the 'this' pointer before calling.
 But I agree passing a delegate is more generic. You can substitute an  
 output range with a delegate (obj.toString(&range.put, fmt)) without any  
 performance hit, but not vice versa (obj.toString(new  
 DelegateWrapRange(&myput), fmt) implies an additional allocation and  
 additional indirection per range.put call).
You can use scope classes to avoid the allocation, but you can't get around the virtual/interface call penalty. But even if a range is a struct, it's simply a different form of delegate, one in which you undoubtedly call only one member function. Might as well use a delegate to allow the most usefulness. -Steve
Nov 12 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 A delegate is equivalent to a struct member function call.  (load data 
 pointer (i.e. this), push args, call function)
I think this particular point is incorrect. Andrei
Nov 12 2009
parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Steven Schveighoffer wrote:
 A delegate is equivalent to a struct member function call.  (load data
 pointer (i.e. this), push args, call function)
I think this particular point is incorrect. Andrei
Most of the overhead from indirect function calls come from the fact that they (usually) can't be inlined, not because they are indirect. The struct member function call is faster mostly because it can be inlined, not because it's direct. Here's roughly what the ASM would look like for a call to a member function of a struct on the stack, if I is a metasyntactic variable for any immediate value: mov EAX, EBP; // Copy frame pointer to EAX add EAX, I; // Add the offset of the struct to EAX. push EAX; // EAX is now the this ptr. Push it. call I; // Call the function. And for a delegate that lives on the stack: mov EAX, [EBP + I]; // Move delegate's this ptr into EAX. push EAX; // Push delegate's this ptr onto stack. call [EBP + I]; // Call whatever address is at offset I from EBP. I've actually benchmarked how much indirect function calls cost compared to direct calls that aren't inlined. The short answer is it's not measurable, at least when calling the same function indirectly in a loop over and over. It could in theory cause pipeline stalls because it's a branch, but according to some Intel optimization manual Don posted here a while back, modern CPUs predict the address of indirect function calls in their branch predictor. This means that if the same path is taken again and again, the overhead will be negligible.
Nov 12 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:
 On Thu, 12 Nov 2009 16:23:22 +0300, Steven Schveighoffer 
 <schveiguy yahoo.com> wrote:
 
 On Thu, 12 Nov 2009 08:22:26 -0500, Steven Schveighoffer 
 <schveiguy yahoo.com> wrote:

 On Tue, 10 Nov 2009 18:49:54 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 I think the best option for toString is to take an output range and 
 write to it. (The sink is a simplified range.)
Bad idea... A range only makes sense as a struct, not an interface/object. I'll tell you why: performance. Ranges are special in two respects: 1. They are foreachable. I think everyone agrees that calling 2 interface functions per loop iteration is much lower performing than using opApply, which calls one delegate function per loop. My recommendation -- use opApply when dealing with polymorphism. I don't think there's a way around this.
Oops, I meant 3 virtual functions -- front, popNext, and empty. -Steve
Output range has only one method: put. I'm not sure, but I don't think there is a performance difference between calling a virtual function through an interface and invoking a delegate. But I agree passing a delegate is more generic. You can substitute an output range with a delegate (obj.toString(&range.put, fmt)) without any performance hit, but not vice versa (obj.toString(new DelegateWrapRange(&myput), fmt) implies an additional allocation and additional indirection per range.put call).
I think that, on the contrary, working with a delegate is less generic. A delegate is cost-wise much like a class with only one (non-final) method. Since we're taking that hit already, we may as well define actual interfaces and classes that have multiple methods. That makes things more flexible and more efficient. Andrei
Nov 12 2009
next sibling parent reply Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:
 Denis Koroskin wrote:
 On Thu, 12 Nov 2009 16:23:22 +0300, Steven Schveighoffer 
 <schveiguy yahoo.com> wrote:

 On Thu, 12 Nov 2009 08:22:26 -0500, Steven Schveighoffer 
 <schveiguy yahoo.com> wrote:

 On Tue, 10 Nov 2009 18:49:54 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 I think the best option for toString is to take an output range and 
 write to it. (The sink is a simplified range.)
Bad idea... A range only makes sense as a struct, not an interface/object. I'll tell you why: performance. Ranges are special in two respects: 1. They are foreachable. I think everyone agrees that calling 2 interface functions per loop iteration is much lower performing than using opApply, which calls one delegate function per loop. My recommendation -- use opApply when dealing with polymorphism. I don't think there's a way around this.
Oops, I meant 3 virtual functions -- front, popNext, and empty. -Steve
Output range has only one method: put. I'm not sure, but I don't think there is a performance difference between calling a virtual function through an interface and invoking a delegate. But I agree passing a delegate is more generic. You can substitute an output range with a delegate (obj.toString(&range.put, fmt)) without any performance hit, but not vice versa (obj.toString(new DelegateWrapRange(&myput), fmt) implies an additional allocation and additional indirection per range.put call).
I think that, on the contrary, working with a delegate is less generic. A delegate is cost-wise much like a class with only one (non-final) method. Since we're taking that hit already, we may as well define actual interfaces and classes that have multiple methods. That makes things more flexible and more efficient.
How? It seems to introduce more requirements on the implementation, but I'm not seeing any benefit in exchange. FWIW, with regard to performance, I can easily imagine the compiler being able to perform the equivalent of a "named return value" optimisation on a delegate return, giving some chance of inlining. That's a lot less obvious with an interface.
Nov 12 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Don wrote:
 Andrei Alexandrescu wrote:
 Denis Koroskin wrote:
 On Thu, 12 Nov 2009 16:23:22 +0300, Steven Schveighoffer 
 <schveiguy yahoo.com> wrote:

 On Thu, 12 Nov 2009 08:22:26 -0500, Steven Schveighoffer 
 <schveiguy yahoo.com> wrote:

 On Tue, 10 Nov 2009 18:49:54 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 I think the best option for toString is to take an output range 
 and write to it. (The sink is a simplified range.)
Bad idea... A range only makes sense as a struct, not an interface/object. I'll tell you why: performance. Ranges are special in two respects: 1. They are foreachable. I think everyone agrees that calling 2 interface functions per loop iteration is much lower performing than using opApply, which calls one delegate function per loop. My recommendation -- use opApply when dealing with polymorphism. I don't think there's a way around this.
Oops, I meant 3 virtual functions -- front, popNext, and empty. -Steve
Output range has only one method: put. I'm not sure, but I don't think there is a performance difference between calling a virtual function through an interface and invoking a delegate. But I agree passing a delegate is more generic. You can substitute an output range with a delegate (obj.toString(&range.put, fmt)) without any performance hit, but not vice versa (obj.toString(new DelegateWrapRange(&myput), fmt) implies an additional allocation and additional indirection per range.put call).
I think that, on the contrary, working with a delegate is less generic. A delegate is cost-wise much like a class with only one (non-final) method. Since we're taking that hit already, we may as well define actual interfaces and classes that have multiple methods. That makes things more flexible and more efficient.
How? It seems to introduce more requirements on the implementation, but I'm not seeing any benefit in exchange.
The benefit is that it allows writing all character widths.
 FWIW, with regard to performance, I can easily imagine the compiler 
 being able to perform the equivalent of a "named return value" 
 optimisation on a delegate return, giving some chance of inlining.
 That's a lot less obvious with an interface.
That seems plausible. Andrei
Nov 12 2009
prev sibling parent reply Justin Johansson <no spam.com> writes:
Andrei Alexandrescu Wrote:

 Denis Koroskin wrote:
 On Thu, 12 Nov 2009 16:23:22 +0300, Steven Schveighoffer 
 <schveiguy yahoo.com> wrote:
 
 On Thu, 12 Nov 2009 08:22:26 -0500, Steven Schveighoffer 
 <schveiguy yahoo.com> wrote:

 On Tue, 10 Nov 2009 18:49:54 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 I think the best option for toString is to take an output range and 
 write to it. (The sink is a simplified range.)
Bad idea... A range only makes sense as a struct, not an interface/object. I'll tell you why: performance. Ranges are special in two respects: 1. They are foreachable. I think everyone agrees that calling 2 interface functions per loop iteration is much lower performing than using opApply, which calls one delegate function per loop. My recommendation -- use opApply when dealing with polymorphism. I don't think there's a way around this.
Oops, I meant 3 virtual functions -- front, popNext, and empty. -Steve
Output range has only one method: put. I'm not sure, but I don't think there is a performance difference between calling a virtual function through an interface and invoking a delegate. But I agree passing a delegate is more generic. You can substitute an output range with a delegate (obj.toString(&range.put, fmt)) without any performance hit, but not vice versa (obj.toString(new DelegateWrapRange(&myput), fmt) implies an additional allocation and additional indirection per range.put call).
I think that, on the contrary, working with a delegate is less generic. A delegate is cost-wise much like a class with only one (non-final) method. Since we're taking that hit already, we may as well define actual interfaces and classes that have multiple methods. That makes things more flexible and more efficient. Andrei
"Since we're taking that hit already, we may as well define
 actual interfaces and classes that have multiple methods."
Which you mean -- interfaces, classes or both? Don't interfaces have a higher cost than classes? Justin
Nov 12 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Justin Johansson wrote:
 Andrei Alexandrescu Wrote:
 
 Denis Koroskin wrote:
 On Thu, 12 Nov 2009 16:23:22 +0300, Steven Schveighoffer 
 <schveiguy yahoo.com> wrote:

 On Thu, 12 Nov 2009 08:22:26 -0500, Steven Schveighoffer 
 <schveiguy yahoo.com> wrote:

 On Tue, 10 Nov 2009 18:49:54 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 I think the best option for toString is to take an output range and 
 write to it. (The sink is a simplified range.)
Bad idea... A range only makes sense as a struct, not an interface/object. I'll tell you why: performance. Ranges are special in two respects: 1. They are foreachable. I think everyone agrees that calling 2 interface functions per loop iteration is much lower performing than using opApply, which calls one delegate function per loop. My recommendation -- use opApply when dealing with polymorphism. I don't think there's a way around this.
Oops, I meant 3 virtual functions -- front, popNext, and empty. -Steve
Output range has only one method: put. I'm not sure, but I don't think there is a performance difference between calling a virtual function through an interface and invoking a delegate. But I agree passing a delegate is more generic. You can substitute an output range with a delegate (obj.toString(&range.put, fmt)) without any performance hit, but not vice versa (obj.toString(new DelegateWrapRange(&myput), fmt) implies an additional allocation and additional indirection per range.put call).
I think that, on the contrary, working with a delegate is less generic. A delegate is cost-wise much like a class with only one (non-final) method. Since we're taking that hit already, we may as well define actual interfaces and classes that have multiple methods. That makes things more flexible and more efficient. Andrei
"Since we're taking that hit already, we may as well define
 actual interfaces and classes that have multiple methods."
Which you mean -- interfaces, classes or both? Don't interfaces have a higher cost than classes?
My understanding is that the costs are comparable. Andrei
Nov 12 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Tue, 10 Nov 2009 18:49:54 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 I think the best option for toString is to take an output range and 
 write to it. (The sink is a simplified range.)
Bad idea... A range only makes sense as a struct, not an interface/object. I'll tell you why: performance.
You are right. If range interfaces accommodate block transfers, this problem may be addressed. I agree that one virtual call per character output would be overkill. (I seem to recall it's one of the reasons why C++'s iostreams are so inefficient.)
 Ranges are special in two respects:
 
 1. They are foreachable.  I think everyone agrees that calling 2 
 interface functions per loop iteration is much lower performing than 
 using opApply, which calls one delegate function per loop.  My 
 recommendation -- use opApply when dealing with polymorphism.  I don't 
 think there's a way around this.

 2. They are useful for passing to std.algorithm.  But std.algorithm is 
 template-interfaced.  No need for using interfaces because the correct 
 instatiation will be chosen.
 
 If you are intending to add a streaming module that uses ranges, would 
 it not be templated for the range type as std.algorithm is?  If not, the 
 next logical choice is a delegate, which requires no vtable lookup.  
 Using an interface is just asking for a performance penalty for not much 
 gain.
I think the cost of calling through the delegate is roughly the same as a virtual call.
 Here's what I mean by not much gain: I would expect a stream range that 
 does output to have a method in it for outputting a buffer (I'd laugh at 
 you if you wanted to define a stream range that outputs a character at a 
 time).  So the difference between:
Well I'd laugh at you if you thought I'm that brain dead :o).
 x.toString(outputRange, format)
 
 and
 
 x.toString(&outputRange.sink, format)
 
 is pretty darn minimal, and if outputRange is an interface or object, 
 this saves a virtual call per buffer write.  Plus the second form is 
 more universal, you can pass any delegate, and not have to use a range 
 type to wrap a delegate.
 
 Don't fall into the "OOP newbie" trap -- where just because you've found 
 a new concept that is amazing, you want to use it for everything.  I say 
 this because I've seen in the past where someone discovers the power of 
 OOP and then wants to use it for everything, when in some cases, it's 
 overkill.  Just look at some Java "classes"...
There is no need to worry that I'll fall into at least that particular OOP newbie trap. What I think we should do is define a text output interface that allows writing individual characters of all widths and also arrays of all widths. That would be a universal means for text output. interface TextOutputStream { void put(dchar); // also accommodates char and wchar void put(in char[]); void put(in wchar[]); void put(in dchar[]); } The toString method (re-baptized as toStream) would take such an interface. Better ideas are always welcome. Perhaps I'm falling another OOP newbie trap! (Seriously!) One possible course of action would be to extend the text output stream to print (and possibly format) some or all primitive types, a la today's phobos streams. That would make TextOutputStream fatter and more diluted, something that I don't like. But then we might define a FormattingTextOutputStream that extends TextOutputStream with all that stuff.
  From another thread:
 Walter does not feel strongly about Phobos.
Huh? I feel like this sentence doesn't make sense, so maybe there's a typo.
I meant to say, Walter does not want to do library design. Andrei
Nov 12 2009
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 12 Nov 2009 10:29:17 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Tue, 10 Nov 2009 18:49:54 -0500, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 I think the best option for toString is to take an output range and  
 write to it. (The sink is a simplified range.)
Bad idea... A range only makes sense as a struct, not an interface/object. I'll tell you why: performance.
You are right. If range interfaces accommodate block transfers, this problem may be addressed. I agree that one virtual call per character output would be overkill. (I seem to recall it's one of the reasons why C++'s iostreams are so inefficient.)
IIRC, I don't think C++ iostreams use polymorphism, and I don't think they use the "one char at a time" method.
 Ranges are special in two respects:
  1. They are foreachable.  I think everyone agrees that calling 2  
 interface functions per loop iteration is much lower performing than  
 using opApply, which calls one delegate function per loop.  My  
 recommendation -- use opApply when dealing with polymorphism.  I don't  
 think there's a way around this.
>
 2. They are useful for passing to std.algorithm.  But std.algorithm is  
 template-interfaced.  No need for using interfaces because the correct  
 instatiation will be chosen.
  If you are intending to add a streaming module that uses ranges, would  
 it not be templated for the range type as std.algorithm is?  If not,  
 the next logical choice is a delegate, which requires no vtable  
 lookup.  Using an interface is just asking for a performance penalty  
 for not much gain.
I think the cost of calling through the delegate is roughly the same as a virtual call.
Not exactly. I think you are right that struct member calls are faster than delegates, but only slightly. The difference being that a struct member call does not need to load the function address from the stack, it can hard-code the address directly. However, virtual calls have to be lower performing because you are doing two indirections, one to the class vtable, then one to the function address itself. Plus those two locations are most likely located on the heap, not the stack, and so may not be in the cache.
 x.toString(outputRange, format)
  and
  x.toString(&outputRange.sink, format)
  is pretty darn minimal, and if outputRange is an interface or object,  
 this saves a virtual call per buffer write.  Plus the second form is  
 more universal, you can pass any delegate, and not have to use a range  
 type to wrap a delegate.
  Don't fall into the "OOP newbie" trap -- where just because you've  
 found a new concept that is amazing, you want to use it for  
 everything.  I say this because I've seen in the past where someone  
 discovers the power of OOP and then wants to use it for everything,  
 when in some cases, it's overkill.  Just look at some Java "classes"...
There is no need to worry that I'll fall into at least that particular OOP newbie trap. What I think we should do is define a text output interface that allows writing individual characters of all widths and also arrays of all widths. That would be a universal means for text output. interface TextOutputStream { void put(dchar); // also accommodates char and wchar void put(in char[]); void put(in wchar[]); void put(in dchar[]); } The toString method (re-baptized as toStream) would take such an interface. Better ideas are always welcome. Perhaps I'm falling another OOP newbie trap! (Seriously!)
This still fits within a single function, which takes one of the 3 widths (pick one, they can all be translated to eachother): void put(in char[] str) { foreach(dchar dc; str) { put((&dc)[0..1]); } } Note that you probably want to build a buffer of dchars instead of putting one at a time, but you get the idea. Also, putting a single character is probably pretty uncommon, but can be handled in a similar fashion. That being said, one other point that makes all this moot is -- toString is for debugging, not for general purpose. We don't need to support everything that is possible. You should be able to say "hey, toString only accepts char[], deal." Of course, you could substitute wchar[] or dchar[], but I think by far char[] is the most common (and is the default type for string literals). That's not to say there is no reason to have a TextOutputStream object. Such a thing is perfectly usable for a toString which takes a char[] delegate sink, just pass &put. In fact, there could be a default toString function in Object that does just that: class Object { ... void toString(delegate void(in char[] buf) put, string fmt) const {} void toString(TextOutputStream tos, string fmt) const { toString(&tos.put, fmt); } } Of course, then TextOutputStream has to be druntime-accessible, so maybe it's not a great idea... But there are ways around that: abstract class BaseTextOutputStream : TextOutputStream { void format(const Object o, string fmt) { o.toString(&this.put, fmt); } }
  From another thread:
 Walter does not feel strongly about Phobos.
Huh? I feel like this sentence doesn't make sense, so maybe there's a typo.
I meant to say, Walter does not want to do library design.
I'm trying to remember but I thought he did care about this particular issue, but it may be muddled in my memory. Also note that toString has special status from the compiler in regards to structs (that hack with the xtoString function in the struct's typeinfo), so it doesn't just affect library code. -Steve
Nov 12 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Thu, 12 Nov 2009 10:29:17 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Steven Schveighoffer wrote:
 On Tue, 10 Nov 2009 18:49:54 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 I think the best option for toString is to take an output range and 
 write to it. (The sink is a simplified range.)
Bad idea... A range only makes sense as a struct, not an interface/object. I'll tell you why: performance.
You are right. If range interfaces accommodate block transfers, this problem may be addressed. I agree that one virtual call per character output would be overkill. (I seem to recall it's one of the reasons why C++'s iostreams are so inefficient.)
IIRC, I don't think C++ iostreams use polymorphism
Oh yes they do. (Did you even google?) Virtual multiple inheritance, the works. http://www.deitel.com/articles/cplusplus_tutorials/20060225/virtualBaseClass/
, and I don't think 
 they use the "one char at a time" method.
Well they do offer one char at a time and also a block transfer. http://msdn.microsoft.com/en-us/library/760t8w1z%28VS.80%29.aspx I'm not sure how the heck but they still manage to call one virtual method per char, otherwise they'd be plenty fast, which they aren't. I seem to recall write() has a default implementation that calls put() in a loop or something. It's not a topic that I want to study closely. iostreams suck, why spend time on learning the quirks of a broken design.
 Ranges are special in two respects:
  1. They are foreachable.  I think everyone agrees that calling 2 
 interface functions per loop iteration is much lower performing than 
 using opApply, which calls one delegate function per loop.  My 
 recommendation -- use opApply when dealing with polymorphism.  I 
 don't think there's a way around this.
>
 2. They are useful for passing to std.algorithm.  But std.algorithm 
 is template-interfaced.  No need for using interfaces because the 
 correct instatiation will be chosen.
  If you are intending to add a streaming module that uses ranges, 
 would it not be templated for the range type as std.algorithm is?  If 
 not, the next logical choice is a delegate, which requires no vtable 
 lookup.  Using an interface is just asking for a performance penalty 
 for not much gain.
I think the cost of calling through the delegate is roughly the same as a virtual call.
Not exactly. I think you are right that struct member calls are faster than delegates, but only slightly. The difference being that a struct member call does not need to load the function address from the stack, it can hard-code the address directly. However, virtual calls have to be lower performing because you are doing two indirections, one to the class vtable, then one to the function address itself. Plus those two locations are most likely located on the heap, not the stack, and so may not be in the cache.
I think the only way to figure is to measure. For one thing I disagree with the comment about the cache - a vtable is quite likely to be warm after a couple of calls. I know one thing - Walter's old format function used delegates and it was unusably slow.
 x.toString(outputRange, format)
  and
  x.toString(&outputRange.sink, format)
  is pretty darn minimal, and if outputRange is an interface or 
 object, this saves a virtual call per buffer write.  Plus the second 
 form is more universal, you can pass any delegate, and not have to 
 use a range type to wrap a delegate.
  Don't fall into the "OOP newbie" trap -- where just because you've 
 found a new concept that is amazing, you want to use it for 
 everything.  I say this because I've seen in the past where someone 
 discovers the power of OOP and then wants to use it for everything, 
 when in some cases, it's overkill.  Just look at some Java "classes"...
There is no need to worry that I'll fall into at least that particular OOP newbie trap. What I think we should do is define a text output interface that allows writing individual characters of all widths and also arrays of all widths. That would be a universal means for text output. interface TextOutputStream { void put(dchar); // also accommodates char and wchar void put(in char[]); void put(in wchar[]); void put(in dchar[]); } The toString method (re-baptized as toStream) would take such an interface. Better ideas are always welcome. Perhaps I'm falling another OOP newbie trap! (Seriously!)
This still fits within a single function, which takes one of the 3 widths (pick one, they can all be translated to eachother): void put(in char[] str) { foreach(dchar dc; str) { put((&dc)[0..1]); } } Note that you probably want to build a buffer of dchars instead of putting one at a time, but you get the idea.
I don't get the idea. I'm seeing one virtual call per character.
 Also, putting a single character is probably pretty uncommon, but can be 
 handled in a similar fashion.
I'm not sure about the uncommonality of outputting one character, but it may be good to discourage it just to not foster slow code.
 That being said, one other point that makes all this moot is -- toString 
 is for debugging, not for general purpose.  We don't need to support 
 everything that is possible.  You should be able to say "hey, toString 
 only accepts char[], deal."  Of course, you could substitute wchar[] or 
 dchar[], but I think by far char[] is the most common (and is the 
 default type for string literals).
I was hoping we could elevate the usefulness of toString a bit.
 That's not to say there is no reason to have a TextOutputStream object.  
 Such a thing is perfectly usable for a toString which takes a char[] 
 delegate sink, just pass &put.  In fact, there could be a default 
 toString function in Object that does just that:
 
 class Object
 {
    ...
    void toString(delegate void(in char[] buf) put, string fmt) const
    {}
    void toString(TextOutputStream tos, string fmt) const
    { toString(&tos.put, fmt); }
 }
I'd agree with the delegate idea if we established that UTF-8 is favored compared to all other formats. Andrei
Nov 12 2009
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 12 Nov 2009 11:46:48 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Thu, 12 Nov 2009 10:29:17 -0500, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Tue, 10 Nov 2009 18:49:54 -0500, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 I think the best option for toString is to take an output range and  
 write to it. (The sink is a simplified range.)
Bad idea... A range only makes sense as a struct, not an interface/object. I'll tell you why: performance.
You are right. If range interfaces accommodate block transfers, this problem may be addressed. I agree that one virtual call per character output would be overkill. (I seem to recall it's one of the reasons why C++'s iostreams are so inefficient.)
IIRC, I don't think C++ iostreams use polymorphism
Oh yes they do. (Did you even google?) Virtual multiple inheritance, the works. http://www.deitel.com/articles/cplusplus_tutorials/20060225/virtualBaseClass/
From my C++ book, it appears to only use virtual inheritance. I don't know enough about virtual inheritance to know how that changes function calls. As far as virtual functions, only the destructor is virtual, so there is no issue there.
  void put(in char[] str)
 {
   foreach(dchar dc; str)
   {
      put((&dc)[0..1]);
   }
 }
  Note that you probably want to build a buffer of dchars instead of  
 putting one at a time, but you get the idea.
I don't get the idea. I'm seeing one virtual call per character.
You missed the note. I didn't implement it, but you could easily implement a stack-allocated buffer to cache the conversions, passing multiple converted code-points at once. But I don't think it's even worth discussing per my other points.
 That being said, one other point that makes all this moot is --  
 toString is for debugging, not for general purpose.  We don't need to  
 support everything that is possible.  You should be able to say "hey,  
 toString only accepts char[], deal."  Of course, you could substitute  
 wchar[] or dchar[], but I think by far char[] is the most common (and  
 is the default type for string literals).
I was hoping we could elevate the usefulness of toString a bit.
Whatever kind of data the output stream gets, it's going to convert it to the format it wants anyways (as for stdout, I think that would be utf8), the only benefit is if you have data stored in a different width that you wanted to output. Calling a conversion function in that case I think is reasonable enough, and saves the output stream from having to convert/deal with it. In other words, I don't think it's going to be that common a case where you need anything other than utf8 output, and therefore the cost of creating an interface, making virtual calls, disallowing simple delegate passing etc is worth the convenience *just in case* you have data stored as wchar[] you want to output.
 That's not to say there is no reason to have a TextOutputStream  
 object.  Such a thing is perfectly usable for a toString which takes a  
 char[] delegate sink, just pass &put.  In fact, there could be a  
 default toString function in Object that does just that:
  class Object
 {
    ...
    void toString(delegate void(in char[] buf) put, string fmt) const
    {}
    void toString(TextOutputStream tos, string fmt) const
    { toString(&tos.put, fmt); }
 }
I'd agree with the delegate idea if we established that UTF-8 is favored compared to all other formats.
D seems to favor UTF8 -- it is the default type for string literals. I don't think I've ever used dchar, and I usually only use wchar to talk to Win32 functions when required. The question I'd ask is -- how common is it where the versions other than char[] would be more convenient? -Steve
Nov 12 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Thu, 12 Nov 2009 11:46:48 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Steven Schveighoffer wrote:
 On Thu, 12 Nov 2009 10:29:17 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Tue, 10 Nov 2009 18:49:54 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 I think the best option for toString is to take an output range 
 and write to it. (The sink is a simplified range.)
Bad idea... A range only makes sense as a struct, not an interface/object. I'll tell you why: performance.
You are right. If range interfaces accommodate block transfers, this problem may be addressed. I agree that one virtual call per character output would be overkill. (I seem to recall it's one of the reasons why C++'s iostreams are so inefficient.)
IIRC, I don't think C++ iostreams use polymorphism
Oh yes they do. (Did you even google?) Virtual multiple inheritance, the works. http://www.deitel.com/articles/cplusplus_tutorials/20060225/virtualBaseClass/
From my C++ book, it appears to only use virtual inheritance. I don't know enough about virtual inheritance to know how that changes function calls. As far as virtual functions, only the destructor is virtual, so there is no issue there.
You're right, but there is an issue because as far as I can recall these functions' implementation do end up calling a virtual function per char; that might be streambuf.overflow. I'm not keen on investigating this any further, but I'd be grateful if you shared any related knowledge. At the end of the day, there seem to be violent agreement that we don't want one virtual call per character or one delegate call per character.
  void put(in char[] str)
 {
   foreach(dchar dc; str)
   {
      put((&dc)[0..1]);
   }
 }
  Note that you probably want to build a buffer of dchars instead of 
 putting one at a time, but you get the idea.
I don't get the idea. I'm seeing one virtual call per character.
You missed the note. I didn't implement it, but you could easily implement a stack-allocated buffer to cache the conversions, passing multiple converted code-points at once. But I don't think it's even worth discussing per my other points.
 That being said, one other point that makes all this moot is -- 
 toString is for debugging, not for general purpose.  We don't need to 
 support everything that is possible.  You should be able to say "hey, 
 toString only accepts char[], deal."  Of course, you could substitute 
 wchar[] or dchar[], but I think by far char[] is the most common (and 
 is the default type for string literals).
I was hoping we could elevate the usefulness of toString a bit.
Whatever kind of data the output stream gets, it's going to convert it to the format it wants anyways (as for stdout, I think that would be utf8), the only benefit is if you have data stored in a different width that you wanted to output. Calling a conversion function in that case I think is reasonable enough, and saves the output stream from having to convert/deal with it. In other words, I don't think it's going to be that common a case where you need anything other than utf8 output, and therefore the cost of creating an interface, making virtual calls, disallowing simple delegate passing etc is worth the convenience *just in case* you have data stored as wchar[] you want to output.
I'm not sure. http://www.gnu.org/s/libc/manual/html_node/Streams-and-I18N.html#Streams-and-I18N gnu defines means to set and detect a utf-16 console, which dmd observes (grep std/ for fwide). But then I'm not sure how many are using that kind of stuff.
 That's not to say there is no reason to have a TextOutputStream 
 object.  Such a thing is perfectly usable for a toString which takes 
 a char[] delegate sink, just pass &put.  In fact, there could be a 
 default toString function in Object that does just that:
  class Object
 {
    ...
    void toString(delegate void(in char[] buf) put, string fmt) const
    {}
    void toString(TextOutputStream tos, string fmt) const
    { toString(&tos.put, fmt); }
 }
I'd agree with the delegate idea if we established that UTF-8 is favored compared to all other formats.
D seems to favor UTF8 -- it is the default type for string literals. I don't think I've ever used dchar, and I usually only use wchar to talk to Win32 functions when required. The question I'd ask is -- how common is it where the versions other than char[] would be more convenient?
I don't know. I think Asian-language users might give a salient answer. Andrei
Nov 12 2009
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Thu, Nov 12, 2009 at 10:46 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 I'd agree with the delegate idea if we established that UTF-8 is favore=
d
 compared to all other formats.
D seems to favor UTF8 -- it is the default type for string literals. =A0=
I
 don't think I've ever used dchar, and I usually only use wchar to talk t=
o
 Win32 functions when required.

 The question I'd ask is -- how common is it where the versions other tha=
n
 char[] would be more convenient?
I don't know. I think Asian-language users might give a salient answer.
This isn't authoritative, but I don't think utf-16 is commonly used in Japan (except for calling Windows APIs). If you look at Mozilla the default Japanese encoding listed is Shift-JIS. A lot of Japanese email still gets sent as ISO-2022-JP. Otherwise utf-8 I think. A quick look at www.asahi.com shows they're using EUC-JP. nicovideo.jp is using utf-8. I seem to recall that my Japanese Visual Studio even saved files in Utf-8, or at least could be set to use utf-8. In short, I think utf-8 is closer to being a widely accepted standard for documents over there than utf-16 is. --bb
Nov 12 2009
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 12 Nov 2009 13:46:08 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

   From my C++ book, it appears to only use virtual inheritance.  I  
 don't know enough about virtual inheritance to know how that changes  
 function calls.
  As far as virtual functions, only the destructor is virtual, so there  
 is no issue there.
You're right, but there is an issue because as far as I can recall these functions' implementation do end up calling a virtual function per char; that might be streambuf.overflow. I'm not keen on investigating this any further, but I'd be grateful if you shared any related knowledge.
Yep, you are right. It appears the reason they do this is so the conversion to the appropriate width can be done per character (and is a no-op for char).
 At the end of the day, there seem to be violent agreement that we don't  
 want one virtual call per character or one delegate call per character.
After running my tests, it appears the virtual call vs. delegate is so negligible, and the virtual call vs. direct call is only slightly less negligible, I think the virtualness may not matter. However, I think avoiding one *call* per character is a worthy goal. This doesn't mean I change my mind :) I still think there is little benefit to having to conjure up an entire object just to convert something to a string vs. writing a simple inner function. One way to find out is to support only char[], and see who complains :) It'd be much easier to go from supporting char[] to supporting all the widths than going from supporting all to just one. -Steve
Nov 12 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Thu, 12 Nov 2009 13:46:08 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
   From my C++ book, it appears to only use virtual inheritance.  I 
 don't know enough about virtual inheritance to know how that changes 
 function calls.
  As far as virtual functions, only the destructor is virtual, so 
 there is no issue there.
You're right, but there is an issue because as far as I can recall these functions' implementation do end up calling a virtual function per char; that might be streambuf.overflow. I'm not keen on investigating this any further, but I'd be grateful if you shared any related knowledge.
Yep, you are right. It appears the reason they do this is so the conversion to the appropriate width can be done per character (and is a no-op for char).
 At the end of the day, there seem to be violent agreement that we 
 don't want one virtual call per character or one delegate call per 
 character.
After running my tests, it appears the virtual call vs. delegate is so negligible, and the virtual call vs. direct call is only slightly less negligible, I think the virtualness may not matter. However, I think avoiding one *call* per character is a worthy goal. This doesn't mean I change my mind :) I still think there is little benefit to having to conjure up an entire object just to convert something to a string vs. writing a simple inner function. One way to find out is to support only char[], and see who complains :) It'd be much easier to go from supporting char[] to supporting all the widths than going from supporting all to just one.
One problem I just realized is that, if we e.g. offer only put(in char[]) or a delegate to that effect, we make it impossible to output one character efficiently. The (&c)[0 .. 1] trick will not work in safe mode. You'd have to allocate a one-element array dynamically. Also, many OSs adopted UTF-16 as their standard format. It may be wise to design for compatibility. Andrei
Nov 12 2009
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 12 Nov 2009 14:40:12 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Thu, 12 Nov 2009 13:46:08 -0500, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

   From my C++ book, it appears to only use virtual inheritance.  I  
 don't know enough about virtual inheritance to know how that changes  
 function calls.
  As far as virtual functions, only the destructor is virtual, so  
 there is no issue there.
You're right, but there is an issue because as far as I can recall these functions' implementation do end up calling a virtual function per char; that might be streambuf.overflow. I'm not keen on investigating this any further, but I'd be grateful if you shared any related knowledge.
Yep, you are right. It appears the reason they do this is so the conversion to the appropriate width can be done per character (and is a no-op for char).
 At the end of the day, there seem to be violent agreement that we  
 don't want one virtual call per character or one delegate call per  
 character.
After running my tests, it appears the virtual call vs. delegate is so negligible, and the virtual call vs. direct call is only slightly less negligible, I think the virtualness may not matter. However, I think avoiding one *call* per character is a worthy goal. This doesn't mean I change my mind :) I still think there is little benefit to having to conjure up an entire object just to convert something to a string vs. writing a simple inner function. One way to find out is to support only char[], and see who complains :) It'd be much easier to go from supporting char[] to supporting all the widths than going from supporting all to just one.
One problem I just realized is that, if we e.g. offer only put(in char[]) or a delegate to that effect, we make it impossible to output one character efficiently. The (&c)[0 .. 1] trick will not work in safe mode. You'd have to allocate a one-element array dynamically.
char[1] buf; buf[0] = c; put(buf); Although it would be a useful feature to be able to convert a value type to an array of one element reference, especially since that should be as safe as taking a slice of a static array. Another solution, although I'm unaware of the added costs: void toString(void delegate(in char[]...) put, string fmt);
 Also, many OSs adopted UTF-16 as their standard format. It may be wise  
 to design for compatibility.
So you want toString's to look like this? version(utf16isdefault) { textobj.put("Array: "w); ... } else { textobj.put("Array: "); ... } -Steve
Nov 12 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Thu, 12 Nov 2009 14:40:12 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Steven Schveighoffer wrote:
 On Thu, 12 Nov 2009 13:46:08 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

   From my C++ book, it appears to only use virtual inheritance.  I 
 don't know enough about virtual inheritance to know how that 
 changes function calls.
  As far as virtual functions, only the destructor is virtual, so 
 there is no issue there.
You're right, but there is an issue because as far as I can recall these functions' implementation do end up calling a virtual function per char; that might be streambuf.overflow. I'm not keen on investigating this any further, but I'd be grateful if you shared any related knowledge.
Yep, you are right. It appears the reason they do this is so the conversion to the appropriate width can be done per character (and is a no-op for char).
 At the end of the day, there seem to be violent agreement that we 
 don't want one virtual call per character or one delegate call per 
 character.
After running my tests, it appears the virtual call vs. delegate is so negligible, and the virtual call vs. direct call is only slightly less negligible, I think the virtualness may not matter. However, I think avoiding one *call* per character is a worthy goal. This doesn't mean I change my mind :) I still think there is little benefit to having to conjure up an entire object just to convert something to a string vs. writing a simple inner function. One way to find out is to support only char[], and see who complains :) It'd be much easier to go from supporting char[] to supporting all the widths than going from supporting all to just one.
One problem I just realized is that, if we e.g. offer only put(in char[]) or a delegate to that effect, we make it impossible to output one character efficiently. The (&c)[0 .. 1] trick will not work in safe mode. You'd have to allocate a one-element array dynamically.
char[1] buf; buf[0] = c; put(buf);
This would not compile in SafeD.
 Although it would be a useful feature to be able to convert a value type 
 to an array of one element reference, especially since that should be as 
 safe as taking a slice of a static array.
 
 Another solution, although I'm unaware of the added costs:
 
 void toString(void delegate(in char[]...) put, string fmt);
 
 Also, many OSs adopted UTF-16 as their standard format. It may be wise 
 to design for compatibility.
So you want toString's to look like this? version(utf16isdefault) { textobj.put("Array: "w); ... } else { textobj.put("Array: "); ... } -Steve
I was just thinking of offering an interface that offers utf8 and utf16 and utf32. Andrei
Nov 12 2009
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 12 Nov 2009 16:19:39 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Thu, 12 Nov 2009 14:40:12 -0500, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Thu, 12 Nov 2009 13:46:08 -0500, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

   From my C++ book, it appears to only use virtual inheritance.  I  
 don't know enough about virtual inheritance to know how that  
 changes function calls.
  As far as virtual functions, only the destructor is virtual, so  
 there is no issue there.
You're right, but there is an issue because as far as I can recall these functions' implementation do end up calling a virtual function per char; that might be streambuf.overflow. I'm not keen on investigating this any further, but I'd be grateful if you shared any related knowledge.
Yep, you are right. It appears the reason they do this is so the conversion to the appropriate width can be done per character (and is a no-op for char).
 At the end of the day, there seem to be violent agreement that we  
 don't want one virtual call per character or one delegate call per  
 character.
After running my tests, it appears the virtual call vs. delegate is so negligible, and the virtual call vs. direct call is only slightly less negligible, I think the virtualness may not matter. However, I think avoiding one *call* per character is a worthy goal. This doesn't mean I change my mind :) I still think there is little benefit to having to conjure up an entire object just to convert something to a string vs. writing a simple inner function. One way to find out is to support only char[], and see who complains :) It'd be much easier to go from supporting char[] to supporting all the widths than going from supporting all to just one.
One problem I just realized is that, if we e.g. offer only put(in char[]) or a delegate to that effect, we make it impossible to output one character efficiently. The (&c)[0 .. 1] trick will not work in safe mode. You'd have to allocate a one-element array dynamically.
char[1] buf; buf[0] = c; put(buf);
This would not compile in SafeD.
:O Why not? I would expect that using a local buffer would be the main way for converting non-string things to strings, or to avoid calling the delegate/vfunction lots of times. i.e. if I want to output an integer i: if(i == 0) put("0"); else { char[20] buf; int idx = buf.length - 1; while(i != 0) { buf[idx] = i % 10; --idx; i /= 10; } put(buf[idx..$]); // no compily in SafeD??? } Do I have to allocate a heap buffer in SafeD?
 Also, many OSs adopted UTF-16 as their standard format. It may be wise  
 to design for compatibility.
So you want toString's to look like this? version(utf16isdefault) { textobj.put("Array: "w); ... } else { textobj.put("Array: "); ... } -Steve
I was just thinking of offering an interface that offers utf8 and utf16 and utf32.
Yes, and your explaination for this is because many OSes adopt UTF-16 as their standard format. My expectation is that the outputter will convert to the required OS format anyways, regardless of what you pass it, so why should we write code to cater to what the OS wants? I'd like to write string-handling code once and be done with it, not try to optimize my toString functions so that they use the "right" methods for the current OS. I asserted that the only reason you want to use the functions other than the char[] version is in the case where your data is *stored* as wchar[] or dchar[]. Otherwise, it makes no sense to do the conversion because the outputter already does it for you. So the question becomes, how often do you need to output data that's already in dchar[] or wchar[] format, and is it worth passing around a list of functions just in case you need that, or should you just call a conversion routine the few times you need it? Let's not forget that this is mainly for debugging... -Steve
Nov 12 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Thu, 12 Nov 2009 16:19:39 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Steven Schveighoffer wrote:
 On Thu, 12 Nov 2009 14:40:12 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Thu, 12 Nov 2009 13:46:08 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

   From my C++ book, it appears to only use virtual inheritance.  
 I don't know enough about virtual inheritance to know how that 
 changes function calls.
  As far as virtual functions, only the destructor is virtual, so 
 there is no issue there.
You're right, but there is an issue because as far as I can recall these functions' implementation do end up calling a virtual function per char; that might be streambuf.overflow. I'm not keen on investigating this any further, but I'd be grateful if you shared any related knowledge.
Yep, you are right. It appears the reason they do this is so the conversion to the appropriate width can be done per character (and is a no-op for char).
 At the end of the day, there seem to be violent agreement that we 
 don't want one virtual call per character or one delegate call per 
 character.
After running my tests, it appears the virtual call vs. delegate is so negligible, and the virtual call vs. direct call is only slightly less negligible, I think the virtualness may not matter. However, I think avoiding one *call* per character is a worthy goal. This doesn't mean I change my mind :) I still think there is little benefit to having to conjure up an entire object just to convert something to a string vs. writing a simple inner function. One way to find out is to support only char[], and see who complains :) It'd be much easier to go from supporting char[] to supporting all the widths than going from supporting all to just one.
One problem I just realized is that, if we e.g. offer only put(in char[]) or a delegate to that effect, we make it impossible to output one character efficiently. The (&c)[0 .. 1] trick will not work in safe mode. You'd have to allocate a one-element array dynamically.
char[1] buf; buf[0] = c; put(buf);
This would not compile in SafeD.
:O Why not? I would expect that using a local buffer would be the main way for converting non-string things to strings, or to avoid calling the delegate/vfunction lots of times.
Well a stack-allocated buffer is stack-allocated, and passing a slice out of it to a function may cause the function to escape the slice.
 i.e. if I want to output an integer i:
 
 
 if(i == 0) put("0");
 else
 {
   char[20] buf;
   int idx = buf.length - 1;
   while(i != 0)
   {
     buf[idx] = i % 10;
     --idx;
     i /= 10;
   }
   put(buf[idx..$]); // no compily in SafeD???
 }
 
 Do I have to allocate a heap buffer in SafeD?
I'm afraid so. Unless of course you have a put(dchar) routine handy :o).
 Also, many OSs adopted UTF-16 as their standard format. It may be 
 wise to design for compatibility.
So you want toString's to look like this? version(utf16isdefault) { textobj.put("Array: "w); ... } else { textobj.put("Array: "); ... } -Steve
I was just thinking of offering an interface that offers utf8 and utf16 and utf32.
Yes, and your explaination for this is because many OSes adopt UTF-16 as their standard format. My expectation is that the outputter will convert to the required OS format anyways, regardless of what you pass it, so why should we write code to cater to what the OS wants? I'd like to write string-handling code once and be done with it, not try to optimize my toString functions so that they use the "right" methods for the current OS. I asserted that the only reason you want to use the functions other than the char[] version is in the case where your data is *stored* as wchar[] or dchar[]. Otherwise, it makes no sense to do the conversion because the outputter already does it for you. So the question becomes, how often do you need to output data that's already in dchar[] or wchar[] format, and is it worth passing around a list of functions just in case you need that, or should you just call a conversion routine the few times you need it? Let's not forget that this is mainly for debugging...
If it's mainly for debugging maybe it's not worth spending time on. Andrei
Nov 12 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Thu, Nov 12, 2009 at 1:54 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Let's not forget that this is mainly for debugging...
If it's mainly for debugging maybe it's not worth spending time on.
Nonsense! Developers spend a lot of time debugging. Helping people debug their programs is certainly worth spending time on. --bb
Nov 12 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Thu, Nov 12, 2009 at 1:54 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Let's not forget that this is mainly for debugging...
If it's mainly for debugging maybe it's not worth spending time on.
Nonsense! Developers spend a lot of time debugging. Helping people debug their programs is certainly worth spending time on. --bb
Sorry sorry. I just meant to say it's not worth coming with an airtight design. We might afford some extra conversions and extra virtual calls I guess. But that being said, I'd so much want to start thinking of an actual text serialization infrastructure. Why develop one later with the mention "well use that stuff for debugging only, this is the real stuff." Andrei
Nov 12 2009
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 12 Nov 2009 17:13:06 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:
 On Thu, Nov 12, 2009 at 1:54 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Let's not forget that this is mainly for debugging...
If it's mainly for debugging maybe it's not worth spending time on.
Nonsense! Developers spend a lot of time debugging. Helping people debug their programs is certainly worth spending time on. --bb
Sorry sorry. I just meant to say it's not worth coming with an airtight design. We might afford some extra conversions and extra virtual calls I guess. But that being said, I'd so much want to start thinking of an actual text serialization infrastructure. Why develop one later with the mention "well use that stuff for debugging only, this is the real stuff."
The main purpose to serialize is to be able to deserialize. The main reason to print debug information is so a person can read it. I don't know if those two goals overlap enough. I think we need both. Maybe one uses the other, I'm not sure, but a way to say "here's how you interact with writefln and friends" would be very nice. -Steve
Nov 12 2009
parent Yigal Chripun <yigal100 gmail.com> writes:
Steven Schveighoffer wrote:
 On Thu, 12 Nov 2009 17:13:06 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Bill Baxter wrote:
 On Thu, Nov 12, 2009 at 1:54 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Let's not forget that this is mainly for debugging...
If it's mainly for debugging maybe it's not worth spending time on.
Nonsense! Developers spend a lot of time debugging. Helping people debug their programs is certainly worth spending time on. --bb
Sorry sorry. I just meant to say it's not worth coming with an airtight design. We might afford some extra conversions and extra virtual calls I guess. But that being said, I'd so much want to start thinking of an actual text serialization infrastructure. Why develop one later with the mention "well use that stuff for debugging only, this is the real stuff."
The main purpose to serialize is to be able to deserialize. The main reason to print debug information is so a person can read it. I don't know if those two goals overlap enough. I think we need both. Maybe one uses the other, I'm not sure, but a way to say "here's how you interact with writefln and friends" would be very nice. -Steve
I'd add to that the a format facility should be locale aware as in .Net. i.e: (pseudo-code) auto str = format("{0}", 2.4, CurrentCulture); // or specify a specific locale str will be either "2.4" or "2,4" based on locale. this serves an entirely different purpose from serialization even though both have common parts. you can't and shouldn't try to de-serialize the above text representation.
Nov 12 2009
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 12 Nov 2009 16:54:13 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


  Let's not forget that this is mainly for debugging...
If it's mainly for debugging maybe it's not worth spending time on.
Debugging is not always done by the developer on his system where a debugger is available. The main use I see for toString is logging (for the purpose of debugging post-mortem failures on customer's systems). -Steve
Nov 12 2009
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 12 Nov 2009 11:14:56 -0500, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 On Thu, 12 Nov 2009 10:29:17 -0500, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 I think the cost of calling through the delegate is roughly the same as  
 a virtual call.
Not exactly. I think you are right that struct member calls are faster than delegates, but only slightly. The difference being that a struct member call does not need to load the function address from the stack, it can hard-code the address directly. However, virtual calls have to be lower performing because you are doing two indirections, one to the class vtable, then one to the function address itself. Plus those two locations are most likely located on the heap, not the stack, and so may not be in the cache.
Some rudamentary attempts at benchmarking: testme.d: struct S { void foo(int x){} } interface I { void foo(int x); } class C : I { void foo(int x){} } const loopcount = 10_000_000_000L; void doVirtual() { C c = new C; for(auto x = loopcount; x > 0; x--) c.foo(x); } void doInterface() { I i = new C; for(auto x = loopcount; x > 0; x--) i.foo(x); } void doDelegate() { auto d = new C; auto dg = &d.foo; for(auto x = loopcount; x > 0; x--) dg(x); } void doStruct() { S s; for(auto x = loopcount; x > 0; x--) s.foo(x); } void main(char[][] args) { switch(args[1]) { case "virtual": doVirtual(); break; case "interface": doInterface(); break; case "struct": doStruct(); break; case "delegate": doDelegate(); break; } } [steves steveslaptop testd]$ time ./testme interface real 1m18.152s user 1m16.638s sys 0m0.015s [steves steveslaptop testd]$ time ./testme virtual real 1m11.146s user 1m10.497s sys 0m0.014s [steves steveslaptop testd]$ time ./testme struct real 1m5.828s user 1m5.249s sys 0m0.011s [steves steveslaptop testd]$ time ./testme delegate real 1m10.464s user 1m9.856s sys 0m0.010s According to this, delegates are slightly faster than virtual calls, but not by much. By far a direct call is faster, but I was surprised at how little overhead virtual calls add in relation to the loop counter. I had to use 10 billion loops or else the difference was undetectable. I used dmd 1.046 -release -O (the -release is needed to get rid of the class method checking the invariant every call). The relative assembly for calling a virtual method is: mov ECX,[EBX] mov EAX,EBX push dword ptr -8[EBP] call dword ptr 014h[ECX] and the assembly for calling a delegate is: push dword ptr -8[EBP] mov EAX,-010h[EBP] call EBX -Steve
Nov 12 2009
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article
 By far a direct call is faster, but I was surprised at how
 little overhead virtual calls add in relation to the loop counter.  I had
 to use 10 billion loops or else the difference was undetectable.
 I used dmd 1.046 -release -O (the -release is needed to get rid of the
 class method checking the invariant every call).
 The relative assembly for calling a virtual method is:
 mov	ECX,[EBX]
 mov	EAX,EBX
 push	dword ptr -8[EBP]
 call	dword ptr 014h[ECX]
 and the assembly for calling a delegate is:
 push	dword ptr -8[EBP]
 mov	EAX,-010h[EBP]
 call	EBX
 -Steve
Your benchmarks don't show that the direct call is much faster. You had inlining disabled. Was this intentional? If so, it proves my point that most of the overhead from virtual calls comes from the fact that they can't usually be inlined, not because they're virtual.
Nov 12 2009
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 12 Nov 2009 12:38:00 -0500, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article
  By far a direct call is faster, but I was surprised at how
 little overhead virtual calls add in relation to the loop counter.  I  
 had
 to use 10 billion loops or else the difference was undetectable.
 I used dmd 1.046 -release -O (the -release is needed to get rid of the
 class method checking the invariant every call).
 The relative assembly for calling a virtual method is:
 mov	ECX,[EBX]
 mov	EAX,EBX
 push	dword ptr -8[EBP]
 call	dword ptr 014h[ECX]
 and the assembly for calling a delegate is:
 push	dword ptr -8[EBP]
 mov	EAX,-010h[EBP]
 call	EBX
 -Steve
Your benchmarks don't show that the direct call is much faster. You had inlining disabled. Was this intentional? If so, it proves my point that most of the overhead from virtual calls comes from the fact that they can't usually be inlined, not because they're virtual.
The direct call was 5 seconds faster. Divide by 10 billion and you get a small but present amount. Inlining makes the struct member function call disappear (b/c foo does nothing!), so it's not really a relevant benchmark. I did the "struct" version as a baseline. Consider that the struct version is the cost of doing the loop increments, pushing the 'this' pointer and argument, and calling the function. Any difference from that is the overhead of virtual/delegate/interface calls. Inlining is not possible with delegates (yet), so it's not really important for this argument. -Steve
Nov 12 2009
parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article
 On Thu, 12 Nov 2009 12:38:00 -0500, dsimcha <dsimcha yahoo.com> wrote:
 == Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article
  By far a direct call is faster, but I was surprised at how
 little overhead virtual calls add in relation to the loop counter.  I
 had
 to use 10 billion loops or else the difference was undetectable.
 I used dmd 1.046 -release -O (the -release is needed to get rid of the
 class method checking the invariant every call).
 The relative assembly for calling a virtual method is:
 mov	ECX,[EBX]
 mov	EAX,EBX
 push	dword ptr -8[EBP]
 call	dword ptr 014h[ECX]
 and the assembly for calling a delegate is:
 push	dword ptr -8[EBP]
 mov	EAX,-010h[EBP]
 call	EBX
 -Steve
Your benchmarks don't show that the direct call is much faster. You had inlining disabled. Was this intentional? If so, it proves my point that most of the overhead from virtual calls comes from the fact that they can't usually be inlined, not because they're virtual.
The direct call was 5 seconds faster. Divide by 10 billion and you get a small but present amount.
Yes, about 0.5 nanoseconds. In other words, if your CPU is roughly 2 GHz, about one **clock cycle**. This is definitely negligible IMHO.
 Inlining makes the struct member function call disappear (b/c foo does
 nothing!), so it's not really a relevant benchmark.
Right, my point is that the overhead of indirect function calls compared to direct function calls is too small to ever be worth considering assuming the direct function call is not inlined. However, when the direct function call may be inlined, this is where indirect calls really hurt because they usually can't be inlined.
 I did the "struct" version as a baseline.  Consider that the struct
 version is the cost of doing the loop increments, pushing the 'this'
 pointer and argument, and calling the function.  Any difference from that
 is the overhead of virtual/delegate/interface calls.
 Inlining is not possible with delegates (yet), so it's not really
 important for this argument.
 -Steve
Nov 12 2009
prev sibling next sibling parent Justin Johansson <no spam.com> writes:
Don Wrote:

 Lutger wrote:
 Justin Johansson wrote:
 
 Lutger Wrote:

 Justin Johansson wrote:

 I assert that the semantics of "toString" or similarly named/purposed
 methods/functions in many PL's (including and not limited to D) is
 ill-defined.

 To put this statement into perspective, I would be most appreciative of
 D NG readers responding with their own idea(s) of what the semantics of
 "toString" are (or should be) in a language agnostic ideology.
My other reply didn't take the language agnostic into account, sorry. Semantics of toString would depend on the object, I would think there are three general types of objects: 1. objects with only one sensible or one clear default string representations, like integers. Maybe even none of these exist (except strings themselves?) 2. objects that, given some formatting options or locale have a clear string representation. floating points, dates, curreny and the like. 3. objects that have no sensible default representation. toString() would not make sense for 3) type objects and only for 2) type objects as part of a formatting / localization package. toString() as a debugging aid sometimes doubles as a formatter for 1) and 2) class objects, but that may be more confusing than it's worth.
Thanks for that Lutger. Do you think it would make better sense if programming languages/their libraries separated functions/methods which are currently loosely purposed as "toString" into methods which are more specific to the types you suggest (leaving only the types/classifications and number thereof to argue about)? In my own D project, I've introduced a toDebugString method and left toString alone. There are times when I like D's default toString printing out the name of the object class. For debug purposes there are times also when I like to see a string printed out in quotes so you can tell the difference between "123" and 123. Then again, and since I'm working on a scripting language, sometimes I like to see debug output distinguish between different numeric types. Anyway going by the replies on this topic, looks like most people view toString as being good for debug purposes and that about it. Cheers Justin
Your design makes better sense (to me at least) because it is based on why you want a string from some object. Take .NET for example: it does provide very elaborate and nice formatting options based and toString() with parameters. For some types however, the default toString() gives you the name of the type itself which is in no way related to formatting an object. You learn to work with it, but I find it a bit muddled. As a last note, I think people view toString as a debug thing mostly because it is very underpowered.
There is a definite use for such as thing. But the existing toString() is much, much worse than useless. People think you can do something with it, but you can't. eg, people have asked for BigInt to support toString(). That is an over-my-dead-body.
s/over-my-dead-body/over-your-dead-body/ :-) At least those are the words that Brendan Eich uses when people seek to make JavaScript multi-threaded. http://weblogs.mozillazine.org/roadmap/archives/2007/02/threads_suck.html http://www.teknico.net/misc/fortune/concurrency.en.txt Google: http://www.google.com.au/#hl=en&q=Brendan+Eich+"your+dead+body" Best regards and thanks to all respondents on "toString" topic, Justin
Nov 10 2009
prev sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Tue, Nov 10, 2009 at 2:51 AM, Don <nospam nospam.com> wrote:
 Lutger wrote:
 Justin Johansson wrote:

 Lutger Wrote:

 Justin Johansson wrote:

 I assert that the semantics of "toString" or similarly named/purposed
 methods/functions in many PL's (including and not limited to D) is
 ill-defined.

 To put this statement into perspective, I would be most appreciative =
of
 D NG readers responding with their own idea(s) of what the semantics =
of
 "toString" are (or should be) in a language agnostic ideology.
My other reply didn't take the language agnostic into account, sorry. Semantics of toString would depend on the object, I would think there are three general types of objects: 1. objects with only one sensible or one clear default string representations, like integers. Maybe even none of these exist (except strings themselves?) 2. objects that, given some formatting options or locale have a clear string representation. floating points, dates, curreny and the like. 3. objects that have no sensible default representation. toString() would not make sense for 3) type objects and only for 2) ty=
pe
 objects as part of a formatting / localization package.

 toString() as a debugging aid sometimes doubles as a formatter for 1)
 and
 2) class objects, but that may be more confusing than it's worth.
Thanks for that Lutger. Do you think it would make better sense if programming languages/their libraries separated functions/methods which are currently loosely purposed as "toString" into methods which are more specific to the types you suggest (leaving only the types/classifications and number thereof to argue about)? In my own D project, I've introduced a toDebugString method and left toString alone. There are times when I like D's default toString printi=
ng
 out the name of the object
 class. =A0For debug purposes there are times also when I like to see a
 string printed
 out in quotes so you can tell the difference between "123" and 123. =A0=
Then
 again, and since I'm working on a scripting language, sometimes I like =
to
 see debug output distinguish between different numeric types.

 Anyway going by the replies on this topic, looks like most people view
 toString as being good for debug purposes and that about it.

 Cheers
 Justin
Your design makes better sense (to me at least) because it is based on w=
hy
 you want a string from some object.
 Take .NET for example: it does provide very elaborate and nice formattin=
g
 options based and toString() with parameters. For some types however, th=
e
 default toString() gives you the name of the type itself which is in no =
way
 related to formatting an object. You learn to work with it, but I find i=
t a
 bit muddled.
 As a last note, I think people view toString as a debug thing mostly
 because it is very underpowered.
There is a definite use for such as thing. But the existing toString() is much, much worse than useless. People think you can do something with it, but you can't. eg, people have asked for BigInt to support toString(). That is an over-my-dead-body.
You can definitely do something with it -- printf debugging. And if I were using BigInt, that's exactly why I'd want BigInt to have a toString. Just out of curiousity, how does someone print out the value of a BigInt right now? --bb
Nov 10 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:

 Just out of curiousity, how does someone print out the
 value of a BigInt right now?
I have added a toString to my copy of the BigInt. Bye, bearophile
Nov 10 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Bill Baxter wrote:
 On Tue, Nov 10, 2009 at 2:51 AM, Don <nospam nospam.com> wrote:
 Lutger wrote:
 Justin Johansson wrote:

 Lutger Wrote:

 Justin Johansson wrote:

 I assert that the semantics of "toString" or similarly named/purposed
 methods/functions in many PL's (including and not limited to D) is
 ill-defined.

 To put this statement into perspective, I would be most appreciative of
 D NG readers responding with their own idea(s) of what the semantics of
 "toString" are (or should be) in a language agnostic ideology.
My other reply didn't take the language agnostic into account, sorry. Semantics of toString would depend on the object, I would think there are three general types of objects: 1. objects with only one sensible or one clear default string representations, like integers. Maybe even none of these exist (except strings themselves?) 2. objects that, given some formatting options or locale have a clear string representation. floating points, dates, curreny and the like. 3. objects that have no sensible default representation. toString() would not make sense for 3) type objects and only for 2) type objects as part of a formatting / localization package. toString() as a debugging aid sometimes doubles as a formatter for 1) and 2) class objects, but that may be more confusing than it's worth.
Thanks for that Lutger. Do you think it would make better sense if programming languages/their libraries separated functions/methods which are currently loosely purposed as "toString" into methods which are more specific to the types you suggest (leaving only the types/classifications and number thereof to argue about)? In my own D project, I've introduced a toDebugString method and left toString alone. There are times when I like D's default toString printing out the name of the object class. For debug purposes there are times also when I like to see a string printed out in quotes so you can tell the difference between "123" and 123. Then again, and since I'm working on a scripting language, sometimes I like to see debug output distinguish between different numeric types. Anyway going by the replies on this topic, looks like most people view toString as being good for debug purposes and that about it. Cheers Justin
Your design makes better sense (to me at least) because it is based on why you want a string from some object. Take .NET for example: it does provide very elaborate and nice formatting options based and toString() with parameters. For some types however, the default toString() gives you the name of the type itself which is in no way related to formatting an object. You learn to work with it, but I find it a bit muddled. As a last note, I think people view toString as a debug thing mostly because it is very underpowered.
There is a definite use for such as thing. But the existing toString() is much, much worse than useless. People think you can do something with it, but you can't. eg, people have asked for BigInt to support toString(). That is an over-my-dead-body.
You can definitely do something with it -- printf debugging. And if I were using BigInt, that's exactly why I'd want BigInt to have a toString.
I almost always want to print the value out in hex. And with some kind of digit separators, so that I can see how many digits it has. Just out of curiousity, how does someone print out the
 value of a BigInt right now?
In Tango, there's just .toHex() and .toDecimalString(). Needs proper formatting options, it's the biggest thing which isn't done. I hit one too many compiler segfaults and starting patching the compiler instead <g>. But I really want a decent toString(). Given a BigInt n, you should be able to just do writefln("%s %x", n, n); // Phobos formatln("{0} {0:X}", n); // Tango To solve this part of the issue, it would be enough to have toString() take a string parameter. (it would be "x" or "X" in this case). string toString(string fmt); But the performance would still be very poor, and that's much more difficult to solve.
Nov 10 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:
 But the performance would still be very poor, and that's much more 
 difficult to solve.
This may help: http://fredrik-j.blogspot.com/2008/07/making-division-in-python-faster.html http://fredrik-j.blogspot.com/2008/07/division-sequel-with-bonus-material.html http://bugs.python.org/issue3451 Bye, bearophile
Nov 10 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Tue, Nov 10, 2009 at 6:11 AM, bearophile <bearophileHUGS lycos.com> wrote:
 Don:
 But the performance would still be very poor, and that's much more
 difficult to solve.
This may help: http://fredrik-j.blogspot.com/2008/07/making-division-in-python-faster.html http://fredrik-j.blogspot.com/2008/07/division-sequel-with-bonus-material.html http://bugs.python.org/issue3451
Though they may be useful, those don't look to have anything to do with formatting user types into strings, which is the subject at hand. --bb
Nov 10 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:

 Though they may be useful, those don't look to have anything to do
 with formatting user types into strings, which is the subject at hand.
Don has said: "But the performance would still be very poor, and that's much more difficult to solve." And those links show a way to quickly convert a large multi-precision integer into a string. What is that I am missing? Bye, bearophile
Nov 10 2009
next sibling parent Don <nospam nospam.com> writes:
bearophile wrote:
 Bill Baxter:
 
 Though they may be useful, those don't look to have anything to do
 with formatting user types into strings, which is the subject at hand.
Don has said: "But the performance would still be very poor, and that's much more difficult to solve." And those links show a way to quickly convert a large multi-precision integer into a string. What is that I am missing?
It's problem 2 from my original posts: being able to output something large (eg an xml doc) in a piece-by-piece manner.
Nov 10 2009
prev sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Tue, Nov 10, 2009 at 7:04 AM, bearophile <bearophileHUGS lycos.com> wrote:
 Bill Baxter:

 Though they may be useful, those don't look to have anything to do
 with formatting user types into strings, which is the subject at hand.
Don has said: "But the performance would still be very poor, and that's much more difficult to solve." And those links show a way to quickly convert a large multi-precision integer into a string. What is that I am missing?
Maybe it's just my ignorance of BigNum issues, but those links look to me to be about divsion and not generating string representations. Are those somehow synonymous in BigInt land? --bb
Nov 10 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:
 Maybe it's just my ignorance of BigNum issues, but those links look to
 me to be about divsion and not generating string representations.  Are
 those somehow synonymous in BigInt land?
Look the numeral() function inside here from those blog posts: http://www.dd.chalmers.se/~frejohl/code/div.py To convert a positive integer to string you have to keep dividing a number by 10, and accumulate the modulus as the digit, converted to ['0', '9']. When the number is zero you are done: n = 541489 result = "" while n: n, digit = divmod(n, 10) But all those large divisions are slow if the number is huge. So that div.py python program shows a faster algorithm that does something smarter, to decrease the computational complexity of all that. Bye, bearophile
Nov 10 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Tue, Nov 10, 2009 at 9:16 AM, bearophile <bearophileHUGS lycos.com> wrot=
e:
 Bill Baxter:
 Maybe it's just my ignorance of BigNum issues, but those links look to
 me to be about divsion and not generating string representations. =A0Are
 those somehow synonymous in BigInt land?
Look the numeral() function inside here from those blog posts: http://www.dd.chalmers.se/~frejohl/code/div.py To convert a positive integer to string you have to keep dividing a numbe=
r by 10, and accumulate the modulus as the digit, converted to ['0', '9']. = When the number is zero you are done:
 n =3D 541489
 result =3D ""
 while n:
 =A0 =A0n, digit =3D divmod(n, 10)



 But all those large divisions are slow if the number is huge. So that div=
.py python program shows a faster algorithm that does something smarter, to= decrease the computational complexity of all that. Well, anyway, slowness of BigInt is not what Don was referring to. He was talking about the general slowness of a toString interface that forces allocating enough memory to hold the entire result, instead of being able to dole out the result piecemeal. --bb
Nov 10 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:
 Well, anyway, [...]
You are welcome. Bye, bearophile
Nov 10 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Tue, Nov 10, 2009 at 4:30 AM, Don <nospam nospam.com> wrote:
 =A0Just out of curiousity, how does someone print out the

 value of a BigInt right now?
In Tango, there's just .toHex() and .toDecimalString(). Needs proper formatting options, it's the biggest thing which isn't done. I hit one to=
o
 many compiler segfaults and starting patching the compiler instead <g>. B=
ut
 I really want a decent toString().
Ah, ok. So there is something, it's just not called "toString". --bb
Nov 10 2009
prev sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 10 Nov 2009 15:30:20 +0300, Don <nospam nospam.com> wrote:

 Bill Baxter wrote:
 On Tue, Nov 10, 2009 at 2:51 AM, Don <nospam nospam.com> wrote:
 Lutger wrote:
 Justin Johansson wrote:

 Lutger Wrote:

 Justin Johansson wrote:

 I assert that the semantics of "toString" or similarly  
 named/purposed
 methods/functions in many PL's (including and not limited to D) is
 ill-defined.

 To put this statement into perspective, I would be most  
 appreciative of
 D NG readers responding with their own idea(s) of what the  
 semantics of
 "toString" are (or should be) in a language agnostic ideology.
My other reply didn't take the language agnostic into account, sorry. Semantics of toString would depend on the object, I would think there are three general types of objects: 1. objects with only one sensible or one clear default string representations, like integers. Maybe even none of these exist (except strings themselves?) 2. objects that, given some formatting options or locale have a clear string representation. floating points, dates, curreny and the like. 3. objects that have no sensible default representation. toString() would not make sense for 3) type objects and only for 2) type objects as part of a formatting / localization package. toString() as a debugging aid sometimes doubles as a formatter for 1) and 2) class objects, but that may be more confusing than it's worth.
Thanks for that Lutger. Do you think it would make better sense if programming languages/their libraries separated functions/methods which are currently loosely purposed as "toString" into methods which are more specific to the types you suggest (leaving only the types/classifications and number thereof to argue about)? In my own D project, I've introduced a toDebugString method and left toString alone. There are times when I like D's default toString printing out the name of the object class. For debug purposes there are times also when I like to see a string printed out in quotes so you can tell the difference between "123" and 123. Then again, and since I'm working on a scripting language, sometimes I like to see debug output distinguish between different numeric types. Anyway going by the replies on this topic, looks like most people view toString as being good for debug purposes and that about it. Cheers Justin
Your design makes better sense (to me at least) because it is based on why you want a string from some object. Take .NET for example: it does provide very elaborate and nice formatting options based and toString() with parameters. For some types however, the default toString() gives you the name of the type itself which is in no way related to formatting an object. You learn to work with it, but I find it a bit muddled. As a last note, I think people view toString as a debug thing mostly because it is very underpowered.
There is a definite use for such as thing. But the existing toString() is much, much worse than useless. People think you can do something with it, but you can't. eg, people have asked for BigInt to support toString(). That is an over-my-dead-body.
You can definitely do something with it -- printf debugging. And if I were using BigInt, that's exactly why I'd want BigInt to have a toString.
I almost always want to print the value out in hex. And with some kind of digit separators, so that I can see how many digits it has. Just out of curiousity, how does someone print out the
 value of a BigInt right now?
In Tango, there's just .toHex() and .toDecimalString(). Needs proper formatting options, it's the biggest thing which isn't done. I hit one too many compiler segfaults and starting patching the compiler instead <g>. But I really want a decent toString(). Given a BigInt n, you should be able to just do writefln("%s %x", n, n); // Phobos formatln("{0} {0:X}", n); // Tango To solve this part of the issue, it would be enough to have toString() take a string parameter. (it would be "x" or "X" in this case). string toString(string fmt); But the performance would still be very poor, and that's much more difficult to solve.
Yes, it would solve half of the toString problems. Another part (i.e. memory allocation) could be solved by providing an optional buffer to the toString: char[] toString(string format = "s" /* comes from %s which is a default qualifier */, char[] buffer = null) { // operate on the buffer, possibly resizing it // which is safe and fast - it only allocates // when *really* necessary, instead of always, as now return buffer; } You can use it almost the same way you used it before: string s = assumeUnique(someObject.toString()); // because we return a mutable string now Optimization example: int sprintf(string format, ...) { char[512] preallocatedBuffer; char[] buffer = preallocatedBuffer[]; // buffer may grow, but // initially points to a preallocatedBuffer char[] storage = buffer[]; // storage for a current element ... for (...) { // iterate over qualifiers (and arguments) string currentQualifier = format[i..j]; auto currentArgument = argsTuple[n]; char[] result = currentArgument.toString(storage); if (result.ptr is storage.ptr) { // okay, string was constructed in-place storage = storage[result.length..$]; } else { // storage didn't have enough space for the whole // string (a reallocation occurred) int offset = buffer.length - storage.length; // increase the capacity buffer.length *= 2; // append our string to the buffer buffer[offset..offset+storage.length] = storage[]; // renew the temporary storage storage = preallocatedBuffer[]; } } ... } Another example: class Array(T) { // ... private T[] elements; char[] toString(string format, char[] buffer) { auto builder = StringBuilder(buffer); // reallocates when no space left builder.append("["); foreach (i, o; elements) { if (i > 0) builder.append(", "); // separator buffer = builder.getBuffer()[appender.length..$]; char[] result = o.toString(format, buffer); if (result.ptr is buffer.ptr) { // no reallocation builder.length += result.length; // without copying } else { builder.append(result); } } builder.append("]"); return builder.toString(); } } auto array = new Array!(int); array ~= [0, 1, 2, 3, 4]; assert(array.toString() == "[0, 1, 2, 3, 4]"); It's not very easy to take advantage of, but it's usable the old way (well, almost). Any ideas?
Nov 10 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
2009/11/10 Denis Koroskin <2korden gmail.com>:
 On Tue, 10 Nov 2009 15:30:20 +0300, Don <nospam nospam.com> wrote:

 Bill Baxter wrote:
 On Tue, Nov 10, 2009 at 2:51 AM, Don <nospam nospam.com> wrote:
 Lutger wrote:
 Justin Johansson wrote:

 Lutger Wrote:

 Justin Johansson wrote:

 I assert that the semantics of "toString" or similarly
 named/purposed
 methods/functions in many PL's (including and not limited to D) is
 ill-defined.

 To put this statement into perspective, I would be most appreciati=
ve
 of
 D NG readers responding with their own idea(s) of what the semanti=
cs
 of
 "toString" are (or should be) in a language agnostic ideology.
My other reply didn't take the language agnostic into account, sorr=
y.
 Semantics of toString would depend on the object, I would think the=
re
 are
 three general types of objects:

 1. objects with only one sensible or one clear default string
 representations, like integers. Maybe even none of these exist
 (except
 strings themselves?)

 2. objects that, given some formatting options or locale have a cle=
ar
 string representation. floating points, dates, curreny and the like=
.
 3. objects that have no sensible default representation.

 toString() would not make sense for 3) type objects and only for 2)
 type
 objects as part of a formatting / localization package.

 toString() as a debugging aid sometimes doubles as a formatter for =
1)
 and
 2) class objects, but that may be more confusing than it's worth.
Thanks for that Lutger. Do you think it would make better sense if programming languages/the=
ir
 libraries separated functions/methods which are currently loosely
 purposed
 as "toString" into methods which are more specific to the types you
 suggest (leaving only the types/classifications and number thereof t=
o
 argue about)?

 In my own D project, I've introduced a toDebugString method and left
 toString alone. There are times when I like D's default toString
 printing
 out the name of the object
 class. =A0For debug purposes there are times also when I like to see=
a
 string printed
 out in quotes so you can tell the difference between "123" and 123.
 =A0Then
 again, and since I'm working on a scripting language, sometimes I li=
ke
 to
 see debug output distinguish between different numeric types.

 Anyway going by the replies on this topic, looks like most people vi=
ew
 toString as being good for debug purposes and that about it.

 Cheers
 Justin
Your design makes better sense (to me at least) because it is based o=
n
 why
 you want a string from some object.
 Take .NET for example: it does provide very elaborate and nice
 formatting
 options based and toString() with parameters. For some types however,
 the
 default toString() gives you the name of the type itself which is in =
no
 way
 related to formatting an object. You learn to work with it, but I fin=
d
 it a
 bit muddled.
 As a last note, I think people view toString as a debug thing mostly
 because it is very underpowered.
There is a definite use for such as thing. But the existing toString() is much, much worse than useless. People think you can do something with it, but you can't. eg, people have asked for BigInt to support toString(). That is an over-my-dead-body.
=A0You can definitely do something with it -- printf debugging. =A0And =
if I
 were using BigInt, that's exactly why I'd want BigInt to have a
 toString.
I almost always want to print the value out in hex. And with some kind o=
f
 digit separators, so that I can see how many digits it has.

 =A0Just out of curiousity, how does someone print out the
 value of a BigInt right now?
In Tango, there's just .toHex() and .toDecimalString(). Needs proper formatting options, it's the biggest thing which isn't done. I hit one t=
oo
 many compiler segfaults and starting patching the compiler instead <g>. =
But
 I really want a decent toString().

 Given a BigInt n, you should be able to just do

 writefln("%s %x", n, n); =A0// Phobos
 formatln("{0} {0:X}", n); // Tango

 To solve this part of the issue, it would be enough to have toString()
 take a string parameter. (it would be "x" or "X" in this case).

 string toString(string fmt);
 But the performance would still be very poor, and that's much more
 difficult to solve.
Yes, it would solve half of the toString problems. Another part (i.e. memory allocation) could be solved by providing an optional buffer to the toString: char[] toString(string format =3D "s" /* comes from %s which is a default qualifier */, char[] buffer =3D null) { =A0 =A0// operate on the buffer, possibly resizing it =A0 =A0// which is safe and fast - it only allocates =A0 =A0// when *really* necessary, instead of always, as now =A0 =A0return buffer; }
With Don's delegate idea, if you do have a toString with special performance concerns, then it can use its own stack-allocated buffer. void toString(void delegate(const(char)[]) put, string format) { char[512] preallocBuffer; foreach( ... ) { ... put(preallocBuffer[0..lenUsed]); } } Which in some cases (like writefln) should be almost as efficient as passing a buffer in. It avoids willy-nilly unbounded allocations anyway. But the nice thing is that it's easy to upgrade to. You can keep it simple and leave toString pretty much like you had it before, just changing the signature and the return. void toString(void delegate(const(char)[]) put, string format) { char ret[]; foreach( ... ) { ... ret ~=3D "..."; } put(ret); // only this line needed to change for Don-style toString } And to get the string you just need to call format: assert(std.string.format(thing) =3D=3D "blah"); If the buffer is going to be passed in, then probably it should be passed in as a full fledged output stream object with .write() methods and such. I don't want to have to worry about buffer management to write a toString method. That should be encapsulated. But it seems to me that Don's method offers exactly the right minimality of interface to allow encapsulating that management without requiring it to be done in a heavy-handed way. --bb
Nov 10 2009
parent Don <nospam nospam.com> writes:
Bill Baxter wrote:
 2009/11/10 Denis Koroskin <2korden gmail.com>:
 On Tue, 10 Nov 2009 15:30:20 +0300, Don <nospam nospam.com> wrote:

 Bill Baxter wrote:
 On Tue, Nov 10, 2009 at 2:51 AM, Don <nospam nospam.com> wrote:
 Lutger wrote:
 Justin Johansson wrote:

 Lutger Wrote:

 Justin Johansson wrote:

 I assert that the semantics of "toString" or similarly
 named/purposed
 methods/functions in many PL's (including and not limited to D) is
 ill-defined.

 To put this statement into perspective, I would be most appreciative
 of
 D NG readers responding with their own idea(s) of what the semantics
 of
 "toString" are (or should be) in a language agnostic ideology.
My other reply didn't take the language agnostic into account, sorry. Semantics of toString would depend on the object, I would think there are three general types of objects: 1. objects with only one sensible or one clear default string representations, like integers. Maybe even none of these exist (except strings themselves?) 2. objects that, given some formatting options or locale have a clear string representation. floating points, dates, curreny and the like. 3. objects that have no sensible default representation. toString() would not make sense for 3) type objects and only for 2) type objects as part of a formatting / localization package. toString() as a debugging aid sometimes doubles as a formatter for 1) and 2) class objects, but that may be more confusing than it's worth.
Thanks for that Lutger. Do you think it would make better sense if programming languages/their libraries separated functions/methods which are currently loosely purposed as "toString" into methods which are more specific to the types you suggest (leaving only the types/classifications and number thereof to argue about)? In my own D project, I've introduced a toDebugString method and left toString alone. There are times when I like D's default toString printing out the name of the object class. For debug purposes there are times also when I like to see a string printed out in quotes so you can tell the difference between "123" and 123. Then again, and since I'm working on a scripting language, sometimes I like to see debug output distinguish between different numeric types. Anyway going by the replies on this topic, looks like most people view toString as being good for debug purposes and that about it. Cheers Justin
Your design makes better sense (to me at least) because it is based on why you want a string from some object. Take .NET for example: it does provide very elaborate and nice formatting options based and toString() with parameters. For some types however, the default toString() gives you the name of the type itself which is in no way related to formatting an object. You learn to work with it, but I find it a bit muddled. As a last note, I think people view toString as a debug thing mostly because it is very underpowered.
There is a definite use for such as thing. But the existing toString() is much, much worse than useless. People think you can do something with it, but you can't. eg, people have asked for BigInt to support toString(). That is an over-my-dead-body.
You can definitely do something with it -- printf debugging. And if I were using BigInt, that's exactly why I'd want BigInt to have a toString.
I almost always want to print the value out in hex. And with some kind of digit separators, so that I can see how many digits it has. Just out of curiousity, how does someone print out the
 value of a BigInt right now?
In Tango, there's just .toHex() and .toDecimalString(). Needs proper formatting options, it's the biggest thing which isn't done. I hit one too many compiler segfaults and starting patching the compiler instead <g>. But I really want a decent toString(). Given a BigInt n, you should be able to just do writefln("%s %x", n, n); // Phobos formatln("{0} {0:X}", n); // Tango To solve this part of the issue, it would be enough to have toString() take a string parameter. (it would be "x" or "X" in this case). string toString(string fmt); But the performance would still be very poor, and that's much more difficult to solve.
Yes, it would solve half of the toString problems. Another part (i.e. memory allocation) could be solved by providing an optional buffer to the toString: char[] toString(string format = "s" /* comes from %s which is a default qualifier */, char[] buffer = null) { // operate on the buffer, possibly resizing it // which is safe and fast - it only allocates // when *really* necessary, instead of always, as now return buffer; }
With Don's delegate idea, if you do have a toString with special performance concerns, then it can use its own stack-allocated buffer. void toString(void delegate(const(char)[]) put, string format) { char[512] preallocBuffer; foreach( ... ) { ... put(preallocBuffer[0..lenUsed]); } }
Thanks. 'put' is so much better than 'sink'. <g>
 If the buffer is going to be passed in, then probably it should be
 passed in as a full fledged output stream object with .write() methods
 and such.  I don't want to have to worry about buffer management to
 write a toString method.  That should be encapsulated.  But it seems
 to me that Don's method offers exactly the right minimality of
 interface to allow encapsulating that management without requiring it
 to be done in a heavy-handed way.
One thing it doesn't (easily) handle is the case where an int argument gives the length of another one. (eg the "%*s" writefln format). I guess this can still be handled (very inefficiently) by converting the parameter value into a text number -- generally, though, that'd only be for direct interchangability with a built-in type; you'd normally do such things by calling a member function on the struct. The other issue is grauzone's comment: perhaps compile-time varargs make this whole approach obsolete.
Nov 10 2009
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Don:

 It's problem 2 from my original posts: being able to output something 
 large (eg an xml doc) in a piece-by-piece manner.
See my post about vectorized lazyness. Bye, bearophile
Nov 10 2009
prev sibling next sibling parent Genghis Khan <genghis outer.mn> writes:
Andrei Alexandrescu Wrote:

 Steven Schveighoffer wrote:
 On Thu, 12 Nov 2009 11:46:48 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Steven Schveighoffer wrote:
 On Thu, 12 Nov 2009 10:29:17 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Tue, 10 Nov 2009 18:49:54 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 I think the best option for toString is to take an output range 
 and write to it. (The sink is a simplified range.)
Bad idea... A range only makes sense as a struct, not an interface/object. I'll tell you why: performance.
You are right. If range interfaces accommodate block transfers, this problem may be addressed. I agree that one virtual call per character output would be overkill. (I seem to recall it's one of the reasons why C++'s iostreams are so inefficient.)
IIRC, I don't think C++ iostreams use polymorphism
Oh yes they do. (Did you even google?) Virtual multiple inheritance, the works. http://www.deitel.com/articles/cplusplus_tutorials/20060225/virtualBaseClass/
From my C++ book, it appears to only use virtual inheritance. I don't know enough about virtual inheritance to know how that changes function calls. As far as virtual functions, only the destructor is virtual, so there is no issue there.
You're right, but there is an issue because as far as I can recall these functions' implementation do end up calling a virtual function per char; that might be streambuf.overflow. I'm not keen on investigating this any further, but I'd be grateful if you shared any related knowledge. At the end of the day, there seem to be violent agreement that we don't want one virtual call per character or one delegate call per character.
  void put(in char[] str)
 {
   foreach(dchar dc; str)
   {
      put((&dc)[0..1]);
   }
 }
  Note that you probably want to build a buffer of dchars instead of 
 putting one at a time, but you get the idea.
I don't get the idea. I'm seeing one virtual call per character.
You missed the note. I didn't implement it, but you could easily implement a stack-allocated buffer to cache the conversions, passing multiple converted code-points at once. But I don't think it's even worth discussing per my other points.
 That being said, one other point that makes all this moot is -- 
 toString is for debugging, not for general purpose.  We don't need to 
 support everything that is possible.  You should be able to say "hey, 
 toString only accepts char[], deal."  Of course, you could substitute 
 wchar[] or dchar[], but I think by far char[] is the most common (and 
 is the default type for string literals).
I was hoping we could elevate the usefulness of toString a bit.
Whatever kind of data the output stream gets, it's going to convert it to the format it wants anyways (as for stdout, I think that would be utf8), the only benefit is if you have data stored in a different width that you wanted to output. Calling a conversion function in that case I think is reasonable enough, and saves the output stream from having to convert/deal with it. In other words, I don't think it's going to be that common a case where you need anything other than utf8 output, and therefore the cost of creating an interface, making virtual calls, disallowing simple delegate passing etc is worth the convenience *just in case* you have data stored as wchar[] you want to output.
I'm not sure. http://www.gnu.org/s/libc/manual/html_node/Streams-and-I18N.html#Streams-and-I18N gnu defines means to set and detect a utf-16 console, which dmd observes (grep std/ for fwide). But then I'm not sure how many are using that kind of stuff.
 That's not to say there is no reason to have a TextOutputStream 
 object.  Such a thing is perfectly usable for a toString which takes 
 a char[] delegate sink, just pass &put.  In fact, there could be a 
 default toString function in Object that does just that:
  class Object
 {
    ...
    void toString(delegate void(in char[] buf) put, string fmt) const
    {}
    void toString(TextOutputStream tos, string fmt) const
    { toString(&tos.put, fmt); }
 }
I'd agree with the delegate idea if we established that UTF-8 is favored compared to all other formats.
D seems to favor UTF8 -- it is the default type for string literals. I don't think I've ever used dchar, and I usually only use wchar to talk to Win32 functions when required. The question I'd ask is -- how common is it where the versions other than char[] would be more convenient?
I don't know. I think Asian-language users might give a salient answer.
Nov 12 2009
prev sibling parent HOSOKAWA Kenchi <hskwk inter7.jp> writes:
Bill Baxter Wrote:

 On Thu, Nov 12, 2009 at 10:46 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 I'd agree with the delegate idea if we established that UTF-8 is favored
 compared to all other formats.
don't think I've ever used dchar, and I usually only use wchar to talk to Win32 functions when required. The question I'd ask is -- how common is it where the versions other than char[] would be more convenient?
I don't know. I think Asian-language users might give a salient answer.
This isn't authoritative, but I don't think utf-16 is commonly used in Japan (except for calling Windows APIs). If you look at Mozilla the default Japanese encoding listed is Shift-JIS. A lot of Japanese email still gets sent as ISO-2022-JP. Otherwise utf-8 I think. A quick look at www.asahi.com shows they're using EUC-JP. nicovideo.jp is using utf-8. I seem to recall that my Japanese Visual Studio even saved files in Utf-8, or at least could be set to use utf-8. In short, I think utf-8 is closer to being a widely accepted standard for documents over there than utf-16 is. --bb
That is true. UTF8 works well. Now few person believe dream of fixed length UTF16. Surrogate Pairs must die. We, maybe not only Japanese but all Asian users, also need converters between UTFs and traditional local encoding. Implementations are up to local users.
Nov 12 2009