Re: overload operator<<

Steve Richter <StephenRichter@xxxxxxxxx> wrote:
> > Just because an operator has been abused in one language doesn't mean
>
> > it should be abused in others too. You can get used to any number of
> > things, but bad habits should be broken. << and >> are not "suck" or
> > "blow" operators - they're bitshifting operators. Their purpose is in
>
> > the specification. That's what they should be used for, and all they
> > should be used for.
>
> placing the emphasis on names to indicate what a statement does has two
> problems. There is the obvious that if you dont know english the
> meaning will not be apparent. ( yeah, yeah - keep the name simple and
> consistent ). Another major problem is the designers of the .net
> framework might make confusing choices.

I think there are few choices as confusing as making a bitshifting
operator effectively stream data, personally. That was a bad choice on
the part of C++ library designers.

> on friday I had to deal with converting strings to and from ebcdic
> bytes. I am still new to .net and had not yet worked with the Encoding
> and Decoding classes. ( still dont know the difference between an
> Encoder and Encoding ).

The difference is basically that an Encoding is stateless, and an
Encoder/Decoder has state. For instance, if you are trying to read
characters from a stream, you might only get part of a character, if
you're reading a multi-byte character and only get the start of it. A
Decoder remembers the bytes which have been read but haven't formed a
full character yet, so that when the rest of the bytes turn up, the
whole character can be returned.

> I gave the MSDN documention 15 minutes and
> none of the method names made sense to me. Without the examples I
> found in google groups ( I think it was a post of Jon Skeets that was
> the best example I found ), I would still be at it.
>
> Here is the code that translate a string to ebcdic bytes:
> System.Text.Encoding encoding =
> System.Text.Encoding.GetEncoding( 37 ) ;
> byte[] bytes = encoding.GetBytes( InString ) ;
>
> "GetBytes" makes little sense to me. "TranslateTo" is more intuitive.
> But why rely on either. In my c++ class framework masterpiece the code
> reads:
>
> EbcdicBytes bytes( 37 ) ; // code page 37
> std::string InString ;
> bytes = InString ; // replace the contents of bytes with InString
> bytes << InString ; // add InString to the contents of bytes
>
> I think this second example is much more readable. That is just my
> opinion. What I dont agree with is the C# designers not allowing the
> choice between the two styles. I prefer symbols over words.

You find the above more readable, but I suggest that if you could write
the above in C#, pretty much *anyone* who hadn't used C++ but had read
the C# language specification would disagree - they'd wonder how on
earth you were expecting to shift something by a string.

The << and >> operators have a well-specified meaning, which has
nothing to do with streaming data. Language allows one to be much more
descriptive than symbols - symbols are just a shorter way of expressing
things *when everyone knows what the symbols mean*. As soon as you
start changing what the symbols mean, confusion enters.

I'm very glad that I'll never have to read code like the above in C#.

--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
.

Relevant Pages

  • Re: XML::LibXML UTF-8 toString() -vs- nodeValue()
    ... Wide character in print at -e line 1. ... The differences are in the encoding of the source file (UTF-8 vs. ... the string constant was converted to a character string: ...
    (comp.lang.perl.misc)
  • Re: Extra invisible characters in soap packet
    ... Converting the string to ASCII before truncating did the trick: ... "To get an accurate byte count, you need to know what encoding ... into the field data that take the field over the character limit. ...
    (microsoft.public.dotnet.framework.aspnet.webservices)
  • Re: diferences between 22 and python 23
    ... string objects have the same byte ... >representation that they originally had in the source code. ... Then they must have encoding info attached? ... behind the concrete character representations there are abstract entities ...
    (comp.lang.python)
  • =?iso-8859-1?B?UmU6IFRoZSBJcmlzaCBmYWRhICjh6e3z+i/Byc3T2ikgYW5kIGVuY3J5cHRpb24vZGVjcnlwdGlvb
    ... Almost immediately I suspect a problem with encoding. ... > Public Shared Function EncryptString(ByVal AString As String) As ... better distinction between character data and byte data. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: string to ascii on line feed
    ... first published ASCII as a standard in 1963. ... refer to multiple things, one of which might be "The encoding Java uses when we ask for the 'ASCII' encoding." ... Conceptually, we have a string in memory, and we wish to store that string to disk, using a specific encoding. ... Now when we say "Encoding FOO is n bits", what we usually mean is either "the encoding uses n bits per character to represent a given string" or the less restrictive "*on average*, the encoding uses n bits per character to represent a given string". ...
    (comp.lang.java.programmer)
Loading