www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - overloading operators for I/O

reply Walter Bright <newshound digitalmars.com> writes:
Michiel wrote:
 And we should keep on frowning on attempts to use overloaded << for I/O
 purposes <g>.

Why? I think it's intuitive. The arrows point from the source of the

 the destination. Should the operator only be used for shifting 

 happens to have been its first purpose?

 I also like how you can send a message to an abstract object. And 

 cout, a cerr, an error console in a GUI, or something else. Same 

 way around.

Good question. C++ conventional wisdom is that's great, because it's always been done that way in C++. Few question it. Let's step back a bit. Suppose I overload '+' to be "launch nuclear missiles." You see some code: x = a + b; and what do you think? I think "add a and b, assign the result to x", but instead, nuclear missiles are launched. It is completely unexpected and unintuitive for '+' to mean anything other than 'add'. To do something completely unrelated to 'add', one should instead write: x = launchNuclearMissiles(a, b); where the meaning is plain, or at least, one isn't assuming it's adding a and b. So why overload operators at all? For the purposes of implementing UDTs (User Defined Types) that have legitimate arithmetic operations on them, such as matrices, extended precision numbers, etc. Now back to '<<' and '>>'. To me, they are arithmetic operators, and mean shift left and shift right. Shift is not an I/O operation. To say they are intuitive is not because they are, but because C++ users are simply accustomed to it. a << b << c << d; That doesn't scream I/O to me. And if a, b, etc. are non-trivial expressions, they wind up: 1) interacting with the operator precedence of << in unfortunate ways 2) suppose you want to print a variable shifted left by a few bits: a << (b << 3) << c << d; blech. 3) Suppose you've got some relational operators and templates thrown in: a << b<c<3>> << c < d << e; and things just go downhill from there. 4) Operators aren't very greppable, meaning it's hard to go grepping through source code looking to see if << has been overloaded. 5) The Spirit library for C++ uses operator overloading to create a specialized DSL for specifying grammar. The trouble is, the code looks exactly like regular C++ expressions (since new operators cannot be defined, nor can operator precedence be changed), and there are some big warning boxes that the resulting appearance may LOOK like C++ but is about as far removed from it as one can get. This doesn't enhance readability. And to sum up: writefln(a, b, c, d); seems pretty intuitive to me. There's just no advantage to overloading <<.
Feb 14 2007
next sibling parent reply Michiel <nomail hotmail.com> writes:
 Good question. C++ conventional wisdom is that's great, because it's
 always been done that way in C++. Few question it.

Sure. I can't deny that I'm used to it because of C++.
 Let's step back a bit.

 <nuclear missile example>

+ is intuitively addition because it's been that way in mathematics long before there were ever computers. Bitshifts, on the other hand, are a bit more recent. And using the << operator for them even more so. It might have been the << operator's first use, but not necessarily its best. << is an arrow. When you point an arrow from a to b, I assume that either a is going to b, or that a becomes b. Not that a is shifted right by b bits.
 So why overload operators at all? For the purposes of implementing UDTs
 (User Defined Types) that have legitimate arithmetic operations on them,
 such as matrices, extended precision numbers, etc.

I totally agree with you here. For example, the way you implemented the equality/inequality and comparison operators is great. Much less room for misuse. And in C++, I never deviated from that behavior.
 <some more examples>

Some good points (though you were using C++ templates as an example, not D templates). But I could make the same argument for writefln: writefln(add(5, 7, 8, pow(42, 3)), f("one", "two", "three, four")); That's not very clear to me either. People will just have to make their own code a bit nicer and use proper spacing or what have you.
 And to sum up:

  writefln(a, b, c, d);

 seems pretty intuitive to me. There's just no advantage to overloading <<.

What about the other reason I mentioned? About sending messages to abstract objects with a standard operator? "I also like how you can send a message to an abstract object. And that can be a cout, a cerr, an error console in a GUI, or something else. Same thing the other way around." I even missed an important one. File I/O. So if << isn't the right streaming operator, use another one. Like <- and ->. You don't use them anyway. To sum up: I love D. But I also like the streaming operator.
Feb 14 2007
next sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
Michiel wrote
 << is an arrow.

This is as true as "[", "(" and "{" are arrows. As a born french speaker one would "<<" primarily recognise as an opening parentheses: http://www.microsoft.com/typography/developers/fdsspec/punc.htm -manfred
Feb 14 2007
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Michiel wrote:
 What about the other reason I mentioned? About sending messages to abstract
 objects with a standard operator?
 
 "I also like how you can send a message to an abstract object. And that can be
a
 cout, a cerr, an error console in a GUI, or something else. Same thing the
other
 way around."
 
 I even missed an important one. File I/O.

This can be done using variadic functions or tuples.
 To sum up: I love D. But I also like the streaming operator.

I didn't expect to convince you <g>.
Feb 14 2007
next sibling parent reply Michiel <nomail hotmail.com> writes:
 This can be done using variadic functions or tuples.

It would just be good if there was a standard and universally recognizable way to do it. A standard abstract class for message-sending that you can subclass. With standard subclasses for std-out, std-err, std-in, file-out and file-in. If you really don't want to use an operator, then just some variadic functions?
 I didn't expect to convince you <g>.

Right back at you. :) But if you leave the streaming operator out of it, how about that class? I could of course write one myself, but it wouldn't be standardized. And I think it should be.
Feb 14 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Michiel wrote:
 This can be done using variadic functions or tuples.

It would just be good if there was a standard and universally recognizable way to do it. A standard abstract class for message-sending that you can subclass. With standard subclasses for std-out, std-err, std-in, file-out and file-in.

Have you looked at Tango's IO classes? I think Tango has that pretty much. --bb
Feb 14 2007
parent reply Michiel <nomail hotmail.com> writes:
 It would just be good if there was a standard and universally recognizable way
to
 do it.

 A standard abstract class for message-sending that you can subclass. With
standard
 subclasses for std-out, std-err, std-in, file-out and file-in.

Have you looked at Tango's IO classes? I think Tango has that pretty much.

I had actually not. :) I'll look into that, thanks. I still think it deserves to be in the standard library, though.
Feb 14 2007
parent BCS <BCS pathlink.com> writes:
Michiel wrote:
It would just be good if there was a standard and universally recognizable way
to
do it.

A standard abstract class for message-sending that you can subclass. With
standard
subclasses for std-out, std-err, std-in, file-out and file-in.

Have you looked at Tango's IO classes? I think Tango has that pretty much.

I had actually not. :) I'll look into that, thanks. I still think it deserves to be in the standard library, though.

that's what Tango is trying to be, *the* standard library.
Feb 14 2007
prev sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Wed, 14 Feb 2007 14:45:50 -0800, Walter Bright wrote:

 Michiel wrote:
 To sum up: I love D. But I also like the streaming operator.

I didn't expect to convince you <g>.

Moving away from the idea of *overloading* existing operators, is there any case for new operators that implement I/O? -- Derek (skype: derek.j.parnell) Melbourne, Australia "Justice for David Hicks!" 15/02/2007 11:36:07 AM
Feb 14 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:
 On Wed, 14 Feb 2007 14:45:50 -0800, Walter Bright wrote:
 
 Michiel wrote:
 To sum up: I love D. But I also like the streaming operator.


Moving away from the idea of *overloading* existing operators, is there any case for new operators that implement I/O?

Imho the only serious reason for overloading << in C++ for I/O was the lack of decent variadic functions. Andrei
Feb 14 2007
prev sibling next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Walter Bright wrote
 You see some code:
 
      x = a + b;
 
 and what do you think? I think "add a and b, assign the result to
 x"

What one thinks depends on the education. As soon as one has exposed ones thinking to abstract algebras, the mathematical structures of groups, rings and fields, etc., one looses the binding of addition to "+". It comes back, when one is assured, that the operands are indeed the usual numbers. "x = a + b;" may then very well mean: start rocket squads from locations a and b, combine them("+") to an attack formation and let them attack("=") location x. Please be aware that also D currently breaks your thinking: x = b; can currently assign a value to b. This contradicts your statement above. -manfred
Feb 14 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
Manfred Nowak wrote:
 Walter Bright wrote
 You see some code:

      x = a + b;

 and what do you think? I think "add a and b, assign the result to
 x"

What one thinks depends on the education.

Of course. I assume here a computer programming background, where the conventional meaning is, well, conventional. We can relate this to the Lisp thread here, where (1- x) means x-1. The unconventionality of the Lisp syntax makes it a hard sell.
 Please be aware that also D currently breaks your thinking:
   
   x = b;
 
 can currently assign a value to b. This contradicts your statement 
 above.

I disagree, because this is in the context of computer programming, not abstract algebra. C++ stands out alone in its use of << for such, and is therefore unconventional.
Feb 14 2007
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Walter Bright wrote

 I disagree, because this is in the context of computer
 programming, not abstract algebra. C++ stands out alone in its use
 of << for such, and is therefore unconventional.

I do not understand with what you disagree. However, I agree with you, that the semantics of << in C++ distorts at least my thinking as much as 1- x in the semantics of lisp. I understand your wish to have fixed meanings for several operators. But I do not understand that D does not provide similar operators for free usage. "+", "-" and all the others with fixed meaning could be prefixed for example by the degree symbol "°+", "°-" and provided with the same priorities as their unprefixed counter parts. Thus enabling a possibly interwoven parallel expression hierarchy. -manfred
Feb 14 2007
next sibling parent reply Michiel <nomail hotmail.com> writes:
 But I do not understand that D does not provide similar operators for
 free usage.

I would like that. Just some extra operators that you can use for your personalized types. I'm not sure if I like the prefix-idea, though. An operator should be intuitive (readable) and easy to use. A prefix pretty much removes that advantage, and I would rather use functions. (By the way, I think the operator-symbols should at least be on a standard keyboard.) But ->, <-, postfix !, !in, etc. would be good.
Feb 14 2007
parent Manfred Nowak <svv1999 hotmail.com> writes:
Michiel wrote

 An operator should
 be intuitive (readable) and easy to use. A prefix pretty much
 removes that advantage, and I would rather use functions. (By the
 way, I think the operator-symbols should at least be on a standard
 keyboard.) 
 
 But ->, <-, postfix !, !in, etc. would be good.

New operators are not intuitiv either, because one has to learn their priorities---or one will end up with fully parenthesed expressions. Whether a prefix or a postfix and what characters will be choosen are of minor importance. I referred to the degree sign, because it is on the german standard keyboard and reminds at the often used middle circle in abstract algebras. -manfred
Feb 14 2007
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Manfred Nowak wrote:
 I understand your wish to have fixed meanings for several operators. 
 But I do not understand that D does not provide similar operators for 
 free usage.
 
 "+", "-" and all the others with fixed meaning could be prefixed for 
 example by the degree symbol "°+", "°-" and provided with the same 
 priorities as their unprefixed counter parts.
 
 Thus enabling a possibly interwoven parallel expression hierarchy.

The problem with using unicode operators is that unicode isn't as well supported as it should be. It's one thing to support unicode in the language, it's another to require one to use a unicode capable text editor to edit source code.
Feb 14 2007
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Walter Bright wrote

 The problem with using unicode operators is that unicode isn't as
 well supported as it should be. It's one thing to support unicode
 in the language, it's another to require one to use a unicode
 capable text editor to edit source code.

The degree sign does not require unicode; it is in the normal ISO/IEC 8859-1 or latin1 table. Every editor should be capable to display it. Every system should be able to enter it. The degree sign "°" is under windows reachable via <alt>0176. The masculine ordinal indicator "º" via <alt>0186. The currency sign "¤" via <alt>0164. So: there is no such problem. -manfred
Feb 14 2007
next sibling parent Derek Parnell <derek nomail.afraid.org> writes:
On Thu, 15 Feb 2007 01:53:47 +0000 (UTC), Manfred Nowak wrote:

 Walter Bright wrote
 
 The problem with using unicode operators is that unicode isn't as
 well supported as it should be. It's one thing to support unicode
 in the language, it's another to require one to use a unicode
 capable text editor to edit source code.

The degree sign does not require unicode; it is in the normal ISO/IEC 8859-1 or latin1 table. Every editor should be capable to display it. Every system should be able to enter it.

LOL ... just because something *should* doesn't mean that it *will*.
 The degree sign "°" is under windows reachable via <alt>0176.
 
 The masculine ordinal indicator "º" via <alt>0186.
 
 The currency sign "¤" via <alt>0164.
 
 So: there is no such problem.

The editors I use all trap keystrokes and none of them allow 'raw' alt-xxx entry of characters. So: there is such a problem. <G> -- Derek (skype: derek.j.parnell) Melbourne, Australia "Justice for David Hicks!" 15/02/2007 1:15:44 PM
Feb 14 2007
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Manfred Nowak wrote:
 The degree sign does not require unicode; it is in the normal ISO/IEC 
 8859-1 or latin1 table.

All characters above 0x7F require unicode multibyte encodings. The latin1 table is not an encoding subset of unicode.
Feb 14 2007
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Walter Bright wrote

 All characters above 0x7F require unicode multibyte encodings. The
 latin1 table is not an encoding subset of unicode.

This invalidates the proposed character only, which is of minor importance. -manfred
Feb 14 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
Manfred Nowak wrote:
 Walter Bright wrote
 
 All characters above 0x7F require unicode multibyte encodings. The
 latin1 table is not an encoding subset of unicode.

This invalidates the proposed character only, which is of minor importance.

There isn't much left below 0x7F :-(
Feb 14 2007
parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Walter Bright wrote:
 Manfred Nowak wrote:
 
 Walter Bright wrote

 All characters above 0x7F require unicode multibyte encodings. The
 latin1 table is not an encoding subset of unicode.

This invalidates the proposed character only, which is of minor importance.

There isn't much left below 0x7F :-(

Hmmmm, abstract algebra... would this be easily parsable? other objections? a = b (+) c; a = b (-) c; a = b (*) c; a = b (^) c; a = b (|) c; a = b ($) c; a = b (?) c; etc... That first one kinda reminds me of the everyone's favorite circle-with-plus-inside.
Feb 14 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
Chad J wrote:
 Hmmmm, abstract algebra...
 would this be easily parsable?
 other objections?
 a = b (+) c;
 a = b (-) c;
 a = b (*) c;
 a = b (^) c;
 a = b (|) c;
 a = b ($) c;
 a = b (?) c;
 etc...

Yes.
Feb 14 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 Chad J wrote:
 Hmmmm, abstract algebra...
 would this be easily parsable?
 other objections?
 a = b (+) c;
 a = b (-) c;
 a = b (*) c;
 a = b (^) c;
 a = b (|) c;
 a = b ($) c;
 a = b (?) c;
 etc...

Yes.

You mean yes on both counts? It's kind of a controversial thing, I know, but for some types there really are multiple ways to interpret basic operations. Matlab, for example, defines .* to mean element-wise multiplication and * to mean matrix multiplication. Both forms get plenty of use. (Same for exponentiation too -- .^ and ^ both exist). I don't really care either way, but there is at least one example of a widely used language, specifically for math, in which there are more than the standard set of operators. Also Ocaml or Haskell or one of those guys, I forget which, allows definition of new operators using any combination of characters used in the built-in operators. E.g. **+ or */* or +++ or +- can all be made into custom operators. I have to admit, /That/ one seems like a pretty bad idea to me. :-) --bb
Feb 14 2007
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 Walter Bright wrote:
 Chad J wrote:
 Hmmmm, abstract algebra...
 would this be easily parsable?
 other objections?
 a = b (+) c;
 a = b (-) c;
 a = b (*) c;
 a = b (^) c;
 a = b (|) c;
 a = b ($) c;
 a = b (?) c;
 etc...

Yes.

You mean yes on both counts? It's kind of a controversial thing, I know, but for some types there really are multiple ways to interpret basic operations. Matlab, for example, defines .* to mean element-wise multiplication and * to mean matrix multiplication. Both forms get plenty of use. (Same for exponentiation too -- .^ and ^ both exist). I don't really care either way, but there is at least one example of a widely used language, specifically for math, in which there are more than the standard set of operators. Also Ocaml or Haskell or one of those guys, I forget which, allows definition of new operators using any combination of characters used in the built-in operators. E.g. **+ or */* or +++ or +- can all be made into custom operators. I have to admit, /That/ one seems like a pretty bad idea to me. :-)

Cecil too. Didn't have a problem with it. http://compilers.iecc.com/comparch/article/96-12-127 Andrei
Feb 14 2007
prev sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Walter Bright wrote

 would this be easily parsable?
 other objections?
 a = b (+) c;


And because we are at it: please provide the ability to abstract operators into families of operators by allowing an index. This might look like (+:0), (+:1), (+:2), ... where (+) is a shorthand for (+:0). Because of the overloading capabilities I do not see any other urgent need for this than to allow redundancy, but I might be wrong. -manfred
Feb 15 2007
parent Manfred Nowak <svv1999 hotmail.com> writes:
Manfred Nowak wrote

 Because of the overloading capabilities I do not see any other
 urgent need for this than to allow redundancy, but I might be
 wrong. 

Addendum: Bill has given the example of normal and dotwise matrix operations. Because these cannot be expressed by overloading, there is a need for indexing. -manfred
Feb 15 2007
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Manfred Nowak wrote:

 Walter Bright wrote
 
 The problem with using unicode operators is that unicode isn't as
 well supported as it should be. It's one thing to support unicode
 in the language, it's another to require one to use a unicode
 capable text editor to edit source code.

The degree sign does not require unicode; it is in the normal ISO/IEC 8859-1 or latin1 table. Every editor should be capable to display it. Every system should be able to enter it. The degree sign "°" is under windows reachable via <alt>0176. The masculine ordinal indicator "º" via <alt>0186. The currency sign "¤" via <alt>0164. So: there is no such problem. -manfred

Very good example of exactly why that would be a problem :) -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi Dancing the Tango
Feb 15 2007
parent Manfred Nowak <svv1999 hotmail.com> writes:
Lars Ivar Igesund wrote

 Very good example of exactly why that would be a problem :)

Thx. I simply should have edited a .d-file to avoid this stupid error. -manfred
Feb 15 2007
prev sibling next sibling parent Daniel Giddings <dgiddings bigworldtech.com> writes:
 3) Suppose you've got some relational operators and templates thrown in:
 
     a << b<c<3>> << c < d << e;

Won't that treat the >> in b<c<3>> as the shift right operator and fail compilation? a << b<c<3> > << c < d << e? which higlights how bad the syntax is I think. At least thats the only meaning of the code that makes sense to me ;-)
Feb 14 2007
prev sibling next sibling parent Alexander Panek <a.panek brainsware.org> writes:
Walter Bright wrote:
 [...]
 And to sum up:
 
     writefln(a, b, c, d);
 
 seems pretty intuitive to me. There's just no advantage to overloading <<.

I can just fully agree with you, though, I slightly like Tango's Cout better. But that's just me - used writefln back then, too. Frankly, using '>>' and '<<' for streams may seem appropriate, but it's just not any kind of arrow, or such. Bit shifting is a very good use for those operators, though maybe they should /actually/ be bit rotating..I always have to think of VHS cassettes and rewind/forward, when I see the operator. Best regards, Alex
Feb 14 2007
prev sibling next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
That's because you're a nerd, Walter <g>
I learned C++ I/O long long before I learned bit manipulation and bit 
shifting.

In fact, I was kinda surprised when I learned that C uses << as a bit 
shifting operator.

 Now back to '<<' and '>>'. To me, they are arithmetic operators, and 
 mean shift left and shift right. Shift is not an I/O operation. To say 
 they are intuitive is not because they are, but because C++ users are 
 simply accustomed to it.

Same goes for using them as bit shifting, to say it scream bit shifting is not because it does, but because you are accustomed to it. Walter Bright wrote:
 Michiel wrote:
  >> And we should keep on frowning on attempts to use overloaded << for I/O
  >> purposes <g>.
  >
  > Why? I think it's intuitive. The arrows point from the source of the 
 message to
  > the destination. Should the operator only be used for shifting 
 because that
  > happens to have been its first purpose?
  >
  > I also like how you can send a message to an abstract object. And 
 that can be a
  > cout, a cerr, an error console in a GUI, or something else. Same 
 thing the other
  > way around.
 
 Good question. C++ conventional wisdom is that's great, because it's 
 always been done that way in C++. Few question it.
 
 Let's step back a bit. Suppose I overload '+' to be "launch nuclear 
 missiles." You see some code:
 
     x = a + b;
 
 and what do you think? I think "add a and b, assign the result to x", 
 but instead, nuclear missiles are launched. It is completely unexpected 
 and unintuitive for '+' to mean anything other than 'add'. To do 
 something completely unrelated to 'add', one should instead write:
 
     x = launchNuclearMissiles(a, b);
 
 where the meaning is plain, or at least, one isn't assuming it's adding 
 a and b.
 
 So why overload operators at all? For the purposes of implementing UDTs 
 (User Defined Types) that have legitimate arithmetic operations on them, 
 such as matrices, extended precision numbers, etc.
 
 Now back to '<<' and '>>'. To me, they are arithmetic operators, and 
 mean shift left and shift right. Shift is not an I/O operation. To say 
 they are intuitive is not because they are, but because C++ users are 
 simply accustomed to it.
 
     a << b << c << d;
 
 That doesn't scream I/O to me. And if a, b, etc. are non-trivial 
 expressions, they wind up:
 
 1) interacting with the operator precedence of << in unfortunate ways
 
 2) suppose you want to print a variable shifted left by a few bits:
 
     a << (b << 3) << c << d;
 
 blech.
 
 3) Suppose you've got some relational operators and templates thrown in:
 
     a << b<c<3>> << c < d << e;
 
 and things just go downhill from there.
 
 4) Operators aren't very greppable, meaning it's hard to go grepping 
 through source code looking to see if << has been overloaded.
 
 5) The Spirit library for C++ uses operator overloading to create a 
 specialized DSL for specifying grammar. The trouble is, the code looks 
 exactly like regular C++ expressions (since new operators cannot be 
 defined, nor can operator precedence be changed), and there are some big 
 warning boxes that the resulting appearance may LOOK like C++ but is 
 about as far removed from it as one can get. This doesn't enhance 
 readability.
 
 And to sum up:
 
     writefln(a, b, c, d);
 
 seems pretty intuitive to me. There's just no advantage to overloading <<.

Feb 14 2007
parent Walter Bright <newshound digitalmars.com> writes:
Hasan Aljudy wrote:
 That's because you're a nerd, Walter <g>

Yup <g>.
 I learned C++ I/O long long before I learned bit manipulation and bit 
 shifting.
 
 In fact, I was kinda surprised when I learned that C uses << as a bit 
 shifting operator.
 
 Now back to '<<' and '>>'. To me, they are arithmetic operators, and 
 mean shift left and shift right. Shift is not an I/O operation. To say 
 they are intuitive is not because they are, but because C++ users are 
 simply accustomed to it.

Same goes for using them as bit shifting, to say it scream bit shifting is not because it does, but because you are accustomed to it.

Every other "C like" language uses << for shifting.
Feb 14 2007
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:
 Michiel wrote:
  >> And we should keep on frowning on attempts to use overloaded << for I/O
  >> purposes <g>.
  >
  > Why? I think it's intuitive. The arrows point from the source of the 
 message to
  > the destination. Should the operator only be used for shifting 
 because that
  > happens to have been its first purpose?
  >
  > I also like how you can send a message to an abstract object. And 
 that can be a
  > cout, a cerr, an error console in a GUI, or something else. Same 
 thing the other
  > way around.
 
 Good question. C++ conventional wisdom is that's great, because it's 
 always been done that way in C++. Few question it.
 
 Let's step back a bit. Suppose I overload '+' to be "launch nuclear 
 missiles." You see some code:
 
     x = a + b;
 
 and what do you think? I think "add a and b, assign the result to x", 
 but instead, nuclear missiles are launched. It is completely unexpected 
 and unintuitive for '+' to mean anything other than 'add'. To do 
 something completely unrelated to 'add', one should instead write:
 
     x = launchNuclearMissiles(a, b);
 
 where the meaning is plain, or at least, one isn't assuming it's adding 
 a and b.
 
 So why overload operators at all? For the purposes of implementing UDTs 
 (User Defined Types) that have legitimate arithmetic operations on them, 
 such as matrices, extended precision numbers, etc.
 
 Now back to '<<' and '>>'. To me, they are arithmetic operators, and 
 mean shift left and shift right. Shift is not an I/O operation. To say 
 they are intuitive is not because they are, but because C++ users are 
 simply accustomed to it.
 
     a << b << c << d;
 
 That doesn't scream I/O to me. 

I agree. There's another problem -- it really doesn't scale well. With printf, you can do "%3.5f" to print a floating point number with a given precision. With <<, that same operation is really horrible. I'd like to see a couple more clarifications in the spec, wrt operator overloading: * If both opAddAssign and opAdd are provided, the compiler is permitted to replace expressions of the form a = a+b; with a+=b; (that is, a+=b _must_ mean a=a+b). And similarly for the other operators. It's just insanity to make a+=b mean anything other that a = a + b. Incidentally, this would make my 'operator overloading without temporaries' proposal a non-breaking change. And if a, b, etc. are non-trivial
 expressions, they wind up:
 
 1) interacting with the operator precedence of << in unfortunate ways
 
 2) suppose you want to print a variable shifted left by a few bits:
 
     a << (b << 3) << c << d;
 
 blech.
 
 3) Suppose you've got some relational operators and templates thrown in:
 
     a << b<c<3>> << c < d << e;
 
 and things just go downhill from there.
 
 4) Operators aren't very greppable, meaning it's hard to go grepping 
 through source code looking to see if << has been overloaded.
 
 5) The Spirit library for C++ uses operator overloading to create a 
 specialized DSL for specifying grammar. The trouble is, the code looks 
 exactly like regular C++ expressions (since new operators cannot be 
 defined, nor can operator precedence be changed), and there are some big 
 warning boxes that the resulting appearance may LOOK like C++ but is 
 about as far removed from it as one can get. This doesn't enhance 
 readability.
 
 And to sum up:
 
     writefln(a, b, c, d);
 
 seems pretty intuitive to me. There's just no advantage to overloading <<.

Feb 14 2007
next sibling parent reply Michiel <nomail please.com> writes:
Don Clugston wrote:

 I agree. There's another problem -- it really doesn't scale well. With
 printf, you can do "%3.5f" to print a floating point number with a given
 precision. With <<, that same operation is really horrible.

But it has the added advantage that there is no need for run-time parsing of that string. C++ parses all << stuff at compile time. -- Michiel
Feb 15 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Michiel wrote:
 Don Clugston wrote:
 
 I agree. There's another problem -- it really doesn't scale well. With
 printf, you can do "%3.5f" to print a floating point number with a given
 precision. With <<, that same operation is really horrible.

But it has the added advantage that there is no need for run-time parsing of that string. C++ parses all << stuff at compile time.

I wonder how much difference that makes given that most IO tends to be slow anyway. On a 1 GHz proc, with a disk that has 10msec seek time that means a hit to the disk can cost you ten million cycles, right? Spending a few cycles to parse a format string at runtime isn't going to kill you. --bb
Feb 15 2007
parent reply Michiel <nomail please.com> writes:
Bill Baxter wrote:

 But it has the added advantage that there is no need for run-time
 parsing of that string. C++ parses all << stuff at compile time.

I wonder how much difference that makes given that most IO tends to be slow anyway. On a 1 GHz proc, with a disk that has 10msec seek time that means a hit to the disk can cost you ten million cycles, right? Spending a few cycles to parse a format string at runtime isn't going to kill you.

Well, you're right of course. But strictly speaking it's still an advantage. ;) -- Michiel
Feb 15 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
Michiel wrote:
 Bill Baxter wrote:
 
 But it has the added advantage that there is no need for run-time
 parsing of that string. C++ parses all << stuff at compile time.

slow anyway. On a 1 GHz proc, with a disk that has 10msec seek time that means a hit to the disk can cost you ten million cycles, right? Spending a few cycles to parse a format string at runtime isn't going to kill you.

Well, you're right of course. But strictly speaking it's still an advantage. ;)

C++ iostreams has the further "advantage" of being neither exception-safe nor thread-safe (since it manipulates global state in order to do formatting). This is only excusable because iostreams was added to C++ years before exception handling was and before anyone knew anything about threaded programming.
Feb 15 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Michiel wrote:
 Bill Baxter wrote:

 But it has the added advantage that there is no need for run-time
 parsing of that string. C++ parses all << stuff at compile time.

slow anyway. On a 1 GHz proc, with a disk that has 10msec seek time that means a hit to the disk can cost you ten million cycles, right? Spending a few cycles to parse a format string at runtime isn't going to kill you.

Well, you're right of course. But strictly speaking it's still an advantage. ;)

C++ iostreams has the further "advantage" of being neither exception-safe nor thread-safe (since it manipulates global state in order to do formatting). This is only excusable because iostreams was added to C++ years before exception handling was and before anyone knew anything about threaded programming.

It's a myth that iostreams benefit much the speed advantage of not needing to do type retrieval at runtime. They are marred by a convoluted design and the need to synchronize with C's stdio library. By the time you saved that penny, you've spent all of those pounds already. Andrei
Feb 15 2007
parent James Dennett <jdennett acm.org> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 Walter Bright wrote:
 Michiel wrote:
 Bill Baxter wrote:

 But it has the added advantage that there is no need for run-time
 parsing of that string. C++ parses all << stuff at compile time.

slow anyway. On a 1 GHz proc, with a disk that has 10msec seek time that means a hit to the disk can cost you ten million cycles, right? Spending a few cycles to parse a format string at runtime isn't going to kill you.

Well, you're right of course. But strictly speaking it's still an advantage. ;)

C++ iostreams has the further "advantage" of being neither exception-safe nor thread-safe (since it manipulates global state in order to do formatting).


Hmmmmn, the only global state is the standard stream objects, and you don't have to use those. The use of globals is certainly a nightmare for thread-safety (though exception safety is less of an issue), but it's limited to this one set of global variables.
 This is only excusable because iostreams was
 added to C++ years before exception handling was and before anyone
 knew anything about threaded programming.

It's a myth that iostreams benefit much the speed advantage of not needing to do type retrieval at runtime.

I think current implementations aren't very good. And given how long we've had since IOStreams was first used, that's not an optimistic picture.
 They are marred by a convoluted
 design and the need to synchronize with C's stdio library.

The latter is turned off with a function call, which does make a significant difference. The convoluted design is just unfortunate. IOStreams isn't useful for much serious work. Not for notational reasons though; the design is just lousy. -- James
Feb 17 2007
prev sibling parent reply renoX <renosky free.fr> writes:
Don Clugston a écrit :
 I agree. There's another problem -- it(<<) really doesn't scale well. With 
 printf, you can do "%3.5f" to print a floating point number with a given 
 precision. With <<, that same operation is really horrible.

Agreed, and writef is even better: writef("x is %d",vx," y is %g\n",vy); No need to put the format string on one side and variables on the other side.. It has still deficiencies: - a syntax 'a la Ruby' would permit to see better the resulting string: writef("x is %{vx}, y is %{vy}\n"); of course you could still specify the format if you want: writef("x is %08x{vx}\n"); - why writef doesn't call to_String on struct or on a type? I.e: typedef int foo; char[] toString(foo x) { return "foo"; } doesn't work as expected in a writef, same with a struct defining a toString function.. renoX
Feb 15 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
renoX wrote:
 - a syntax 'a la Ruby' would permit to see better the resulting string:
 writef("x is %{vx}, y is %{vy}\n"); of course you could still specify 
 the format if you want: writef("x is %08x{vx}\n");

A syntax like this may be possible with string mixins. I'm pretty sure you could write that like this: --- mixin(write!("x is %{vx}, y is %{vy}\n")); --- and get away with it, given the proper 'write' template. It might not even be very difficult, it'd just need to find the %{} groups, parse them out and generate the proper call(s) to other functions. The backend could be writef, or Tango's Stdout.format or something custom-written.
Feb 15 2007
next sibling parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Frits van Bommel wrote:
 renoX wrote:
 - a syntax 'a la Ruby' would permit to see better the resulting string:
 writef("x is %{vx}, y is %{vy}\n"); of course you could still specify 
 the format if you want: writef("x is %08x{vx}\n");

A syntax like this may be possible with string mixins. I'm pretty sure you could write that like this: --- mixin(write!("x is %{vx}, y is %{vy}\n")); --- and get away with it, given the proper 'write' template. It might not even be very difficult, it'd just need to find the %{} groups, parse them out and generate the proper call(s) to other functions. The backend could be writef, or Tango's Stdout.format or something custom-written.

Walter was talking about implementing this as an example :o). Andrei
Feb 15 2007
prev sibling parent renoX <renosky free.fr> writes:
Frits van Bommel a écrit :
 renoX wrote:
 - a syntax 'a la Ruby' would permit to see better the resulting string:
 writef("x is %{vx}, y is %{vy}\n"); of course you could still specify 
 the format if you want: writef("x is %08x{vx}\n");

A syntax like this may be possible with string mixins. I'm pretty sure you could write that like this: --- mixin(write!("x is %{vx}, y is %{vy}\n")); --- and get away with it, given the proper 'write' template. It might not even be very difficult, it'd just need to find the %{} groups, parse them out and generate the proper call(s) to other functions. The backend could be writef, or Tango's Stdout.format or something custom-written.

I know, that's in my TODO list, but I wanted to do 'printable enums' first and I had 'startup' problem (not being very familiar with template programming). Now that kevin bealer has provided 'reflexive enums', I want to refine the implementation (struct or not struct?), do the write stuff, then world domination. renoX
Feb 16 2007
prev sibling parent nazo <lovesyao gmail.com> writes:
I didn't see all posts. but "stdout ~= tuple(a,b,c,d)" is best for 
Output, I think. and need more short tuple syntax like a:b:c:d.

Example:
stdout ~= a:b:c:d; //call stdout.opCat(a,b,c,d)
stdout ~= e:f;
stdout ~= g:h;

I have no idea for Input best solution without opPopAssign_r.

Example:
int a; char[] b;
a:b = stdin.pop; //call stdin.opPopAssign_r!(typeof(a:b))();
                  //return type is typeof(a:b).
                  //"decide template from return type" is needed.

These ideas have problem for binary size :-(
#Sorry for my poor English
Feb 15 2007