Re: overload operator<<
- From: "Steve Richter" <StephenRichter@xxxxxxxxx>
- Date: 8 May 2005 08:47:59 -0700
Jon Skeet [ C# MVP ] wrote:
> 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.
I have written a lot of programs. the only time I have ever used bit
shift is in c and c++ for some low level functions. ( and even then it
is an unclear operator. where do the carry out bits go? are the carry
in bits set to zero or one or the carry bit from an ajacent factor?
better expressed as a function. )
an asp.net or win forms programmer is never going to use the bit shift
operator, so your assertion that the operator will be ambiguous does
not "carry"!
>
> > 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.
implementation details coerced by the CLI that illustrate the problems
with the do it all one way approach. A stateless operation is best
expressed as a standalone function defined in a namespace. The whole
reliance on static methods thing is something the programmer can become
accustomed to. I dont see the sense in claiming that the never used
bit shift operator has to remain unambiguous while at the same time
..NET makes heavy use of very ambiguous static and instance class
methods.
C# code would be easier to read if namespaces could contain standalone
functions.
-Steve
.
- Follow-Ups:
- Re: overload operator<<
- From: Jon Skeet [C# MVP]
- Re: overload operator<<
- References:
- Re: overload operator<<
- From: Rick Elbers
- Re: overload operator<<
- From: Jon Skeet [C# MVP]
- Re: overload operator<<
- From: Steve Richter
- Re: overload operator<<
- From: Jon Skeet [C# MVP]
- Re: overload operator<<
- Prev by Date: Re: byte [] manipulation
- Next by Date: Help understanding delegates?
- Previous by thread: Re: overload operator<<
- Next by thread: Re: overload operator<<
- Index(es):
Relevant Pages
|