overload operator<<

[Steve Richter]

is it possible to overload the << operator in c# similar to the way it
is done in c++ ?

MyTable table = new MyTable( ) ;
MyTableRow row = new MyTableRow( ) ;
row << new MyTableCell( "cell1 text contents" ) ;
row << new MyTableCell( "cell2 text contents" ) ;
table << row ;

thanks,

-Steve

[CSharper]

It seems possible to overload any of the following binary-operators:

+ - * / % & | ^ << >> == != > < >= <=

Hope this helps,

Dan Cox
DISCLAIMER: Don't take it to the bank, I'm just trying to help.

"Steve Richter" <St************@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

is it possible to overload the << operator in c# similar to the way it
is done in c++ ?

MyTable table = new MyTable( ) ;
MyTableRow row = new MyTableRow( ) ;
row << new MyTableCell( "cell1 text contents" ) ;
row << new MyTableCell( "cell2 text contents" ) ;
table << row ;

thanks,

-Steve

[Steve Richter]

CSharper wrote:

It seems possible to overload any of the following binary-operators:

+ - * / % & | ^ << >> == != > < >= <=

Hope this helps,

Dan Cox
DISCLAIMER: Don't take it to the bank, I'm just trying to help.
trust but verify, right? I appreciate the help!

I dont think it will work the way I want it to. I got a compile error
saying the first argument for operator<< had to be an int. as in, the
number of positions to shift to the left.

Funny why the language does not allow full c++ like operator
overloading. It really is a good feature.

thanks,

-Steve


"Steve Richter" <St************@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

is it possible to overload the << operator in c# similar to the way it is done in c++ ?

MyTable table = new MyTable( ) ;
MyTableRow row = new MyTableRow( ) ;
row << new MyTableCell( "cell1 text contents" ) ;
row << new MyTableCell( "cell2 text contents" ) ;
table << row ;

thanks,

-Steve

[CSharper]

From MSDN: C# vs. C++ Overloading

Compared to C++, C# allows overloading of fewer operators. There are two
sets of restrictions. First, member access, member invocation (that is,
function calling), assignment, and "new" cannot be overloaded because such
operations are defined by the runtime.

Second, operators such as "&&", "||", "?:", and compound
assignment operators such as "+=" cannot be overloaded because the added
complexity is not worth the benefit.

Dan Cox

"Steve Richter" <St************@gmail.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...

CSharper wrote:

It seems possible to overload any of the following binary-operators:

+ - * / % & | ^ << >> == != > < >= <=

Hope this helps,

Dan Cox
DISCLAIMER: Don't take it to the bank, I'm just trying to help.

trust but verify, right? I appreciate the help!

I dont think it will work the way I want it to. I got a compile error
saying the first argument for operator<< had to be an int. as in, the
number of positions to shift to the left.

Funny why the language does not allow full c++ like operator
overloading. It really is a good feature.

thanks,

-Steve

"Steve Richter" <St************@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

> is it possible to overload the << operator in c# similar to the way it > is done in c++ ?
>
> MyTable table = new MyTable( ) ;
> MyTableRow row = new MyTableRow( ) ;
> row << new MyTableCell( "cell1 text contents" ) ;
> row << new MyTableCell( "cell2 text contents" ) ;
> table << row ;
>
> thanks,
>
> -Steve
>

[Christof Nordiek]

Conditions for overloading shiftoperators(<< and >>) in C#:
The type of the first operand must always be the type containing the
operator declaration.
The type of the second operand must always be int.
"Steve Richter" <St************@gmail.com> schrieb im Newsbeitrag
news:11**********************@z14g2000cwz.googlegr oups.com...

is it possible to overload the << operator in c# similar to the way it
is done in c++ ?

MyTable table = new MyTable( ) ;
MyTableRow row = new MyTableRow( ) ;
row << new MyTableCell( "cell1 text contents" ) ;
row << new MyTableCell( "cell2 text contents" ) ;
table << row ;

thanks,

-Steve

[Christof Nordiek]

Also overloadable are following unary operators: + - ! ~ ++ -- true false.
The operators true and false aren't called explicitly in code, bat are used
to indirectly overload the operators && || ?:

Christof

"CSharper" <do**@botherme.com> schrieb im Newsbeitrag
news:PN********************@bignews4.bellsouth.net ...

It seems possible to overload any of the following binary-operators:

+ - * / % & | ^ << >> == != > < >= <=

Hope this helps,

Dan Cox
DISCLAIMER: Don't take it to the bank, I'm just trying to help.

"Steve Richter" <St************@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

is it possible to overload the << operator in c# similar to the way it
is done in c++ ?

MyTable table = new MyTable( ) ;
MyTableRow row = new MyTableRow( ) ;
row << new MyTableCell( "cell1 text contents" ) ;
row << new MyTableCell( "cell2 text contents" ) ;
table << row ;

thanks,

-Steve

[Christof Nordiek]

Compund assignment operators are overloaded indireclty.
f.e. overloading binary + also overloads +=

Christof

"CSharper" <do**@botherme.com> schrieb im Newsbeitrag
news:Ob********************@bignews4.bellsouth.net ...

From MSDN: C# vs. C++ Overloading

Compared to C++, C# allows overloading of fewer operators. There are two
sets of restrictions. First, member access, member invocation (that is,
function calling), assignment, and "new" cannot be overloaded because such
operations are defined by the runtime.

Second, operators such as "&&", "||", "?:", and compound
assignment operators such as "+=" cannot be overloaded because the added
complexity is not worth the benefit.

Dan Cox

"Steve Richter" <St************@gmail.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...

CSharper wrote:

It seems possible to overload any of the following binary-operators:

+ - * / % & | ^ << >> == != > < >= <=

Hope this helps,

Dan Cox
DISCLAIMER: Don't take it to the bank, I'm just trying to help.

trust but verify, right? I appreciate the help!

I dont think it will work the way I want it to. I got a compile error
saying the first argument for operator<< had to be an int. as in, the
number of positions to shift to the left.

Funny why the language does not allow full c++ like operator
overloading. It really is a good feature.

thanks,

-Steve

"Steve Richter" <St************@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
> is it possible to overload the << operator in c# similar to the way

it

> is done in c++ ?
>
> MyTable table = new MyTable( ) ;
> MyTableRow row = new MyTableRow( ) ;
> row << new MyTableCell( "cell1 text contents" ) ;
> row << new MyTableCell( "cell2 text contents" ) ;
> table << row ;
>
> thanks,
>
> -Steve
>

[Steve Richter]

Christof Nordiek wrote:

Conditions for overloading shiftoperators(<< and >>) in C#:
The type of the first operand must always be the type containing the
operator declaration.
The type of the second operand must always be int.
big mistake by Microsoft!

operator<< is a great way to indicate that you are adding one object to
the collection of another.

What about operator+= ? Can I overload it?
collection += object ;

-Steve

"Steve Richter" <St************@gmail.com> schrieb im Newsbeitrag
news:11**********************@z14g2000cwz.googlegr oups.com...

is it possible to overload the << operator in c# similar to the way it is done in c++ ?

MyTable table = new MyTable( ) ;
MyTableRow row = new MyTableRow( ) ;
row << new MyTableCell( "cell1 text contents" ) ;
row << new MyTableCell( "cell2 text contents" ) ;
table << row ;

thanks,

-Steve

[Lebesgue]

> big mistake by Microsoft!

operator<< is a great way to indicate that you are adding one object to
the collection of another. No mistake by Microsoft!
Method IList.Add is a great way to indicate that you are adding one object
to the collection of another
What about operator+= ? Can I overload it?
collection += object ;

Yes, you can, and I believe that if you read what somenon has written a few
posts below, you would find out the same ;-)

[Steve Richter]

Lebesgue wrote:

big mistake by Microsoft!
operator<< is a great way to indicate that you are adding one object to the collection of another. No mistake by Microsoft!
Method IList.Add is a great way to indicate that you are adding one

object to the collection of another
puh!
table << row ;
is much cleaner looking than:
table.Add( row ) ;

What about operator+= ? Can I overload it?
collection += object ; Yes, you can, and I believe that if you read what somenon has written

a few posts below, you would find out the same ;-)

Show me the code!

As I understand it, operator+= will be provided by the c# compiler as
an abbreviated form of
public static ReturnType operator+( arg1, arg2 ) ;

so you would have to provide operator+ as a way to add an object to a
collection:
table = table + row ;

which is not very intuitive. Adding a row to a table does not create a
new table object.

-Steve

[Lebesgue]

> puh!

table << row ;
is much cleaner looking than:
table.Add( row ) ;

puh!
It's your opinion, I believe many C# programmers would disagree

What about operator+= ? Can I overload it?
collection += object ;

Yes, you can, and I believe that if you read what somenon has written

a few

posts below, you would find out the same ;-)

Show me the code!

public static Table operator +(Table t, Row row)
{
Table res = (Table)t.Clone();
res.Add(row);
return res;
}

so you would have to provide operator+ as a way to add an object to a
collection:
table = table + row ;

which is not very intuitive. Adding a row to a table does not create a
new table object.

I hope you know i = i + n is absolutely the same as i += n
and you can overload + and use +=

[Jon Skeet [C# MVP]]

Steve Richter <St************@gmail.com> wrote:

CSharper wrote:

It seems possible to overload any of the following binary-operators:

+ - * / % & | ^ << >> == != > < >= <=

Hope this helps,

Dan Cox
DISCLAIMER: Don't take it to the bank, I'm just trying to help.

trust but verify, right? I appreciate the help!

I dont think it will work the way I want it to. I got a compile error
saying the first argument for operator<< had to be an int. as in, the
number of positions to shift to the left.

Funny why the language does not allow full c++ like operator
overloading. It really is a good feature.

I disagree - I'm rather glad that arbitrary operator overloading isn't
supported, precisely because it means we *don't* get code where are
DataRow is shifted left by a MyTableCell - an operation which simply
doesn't make sense.

Using a method call would make the code far clearer here, IMO.

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

[Jon Skeet [C# MVP]]

Steve Richter <St************@gmail.com> wrote:

Christof Nordiek wrote:

Conditions for overloading shiftoperators(<< and >>) in C#:
The type of the first operand must always be the type containing the
operator declaration.
The type of the second operand must always be int.
big mistake by Microsoft!

operator<< is a great way to indicate that you are adding one object to
the collection of another.

No it's not. It's a shift operator. When you apply it to two ints, are
you adding one object to the collection of another? No. Just because
C++ libraries often (ab)use it that way doesn't make it a good thing.
What about operator+= ? Can I overload it?
collection += object ;

You can override +. Fortunately,

x += y;

is the same as

x = x + y;

Any other semantics would be highly confusing IMO.

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

[Jon Skeet [C# MVP]]

Steve Richter <St************@gmail.com> wrote:

No mistake by Microsoft!
Method IList.Add is a great way to indicate that you are adding one object

to the collection of another

puh!
table << row ;
is much cleaner looking than:
table.Add( row ) ;

Ask a non-C++ programmer (remembering that you're talking about C#, not
C++ here) what he'd expect the first snippet to do, then the second.
There'd be a *lot* less guesswork for the second - the intention is
absolutely clear.
As I understand it, operator+= will be provided by the c# compiler as
an abbreviated form of
public static ReturnType operator+( arg1, arg2 ) ;
Yup.
so you would have to provide operator+ as a way to add an object to a
collection:
table = table + row ;
Yup.
which is not very intuitive. Adding a row to a table does not create a
new table object.

So you shouldn't overload an operator to do it; you should provide a
method instead which doesn't return anything. *That* is the intuitive
way of doing it.

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

[Steve Richter]

Jon Skeet [ C# MVP ] wrote:

Steve Richter <St************@gmail.com> wrote:

No mistake by Microsoft!
Method IList.Add is a great way to indicate that you are adding

one object

to the collection of another
puh!
table << row ;
is much cleaner looking than:
table.Add( row ) ;

Ask a non-C++ programmer (remembering that you're talking about C#,

not C++ here) what he'd expect the first snippet to do, then the second.
There'd be a *lot* less guesswork for the second - the intention is
absolutely clear.

As I understand it, operator+= will be provided by the c# compiler as an abbreviated form of
public static ReturnType operator+( arg1, arg2 ) ;
Yup.

so you would have to provide operator+ as a way to add an object to a collection:
table = table + row ;

Yup.

which is not very intuitive. Adding a row to a table does not create a new table object.

So you shouldn't overload an operator to do it; you should provide a
method instead which doesn't return anything. *That* is the intuitive

way of doing it.
ah, you all are hopeless. I would go back to C++ but having to use
"->" for all my reference types is a bit much.

What is the degree of difficulty to writing your own .NET programming
language? Someone has to do something about the crap in .NET. Things
like boxing, StringBuilder, value types have to go. The class
destructor, of course, must be restored to its place of central
importance.

-Steve

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

[Lebesgue]

> ah, you all are hopeless. I would go back to C++ but having to use

"->" for all my reference types is a bit much.

What is the degree of difficulty to writing your own .NET programming
language? Someone has to do something about the crap in .NET. Things
like boxing, StringBuilder, value types have to go. The class
destructor, of course, must be restored to its place of central
importance.

-Steve

Steve,
There are quite a few "alternative" .NET languages. Check out for Nemerle or
Boo to see how it is done when someone decides to write language on his own.
Try not to say things like "you all are hopeless" because then it starts to
seem that the only hopeless is you `-)
The class destructor, of course, has nothing to do in a modern language.
What would be the next to ask for? Macros and header files?
I think you should go back to C++ and write something like #define .. -> if
it bothers you writing -> all the time and use instance..Member "syntax"

[Søren Reinke]

>

puh!
table << row ;
is much cleaner looking than:
table.Add( row ) ;

I must disagree.

<< and >> is used for bitshiftning not adding or something like that.

table.Add(row);
Tells you easilly readable that you 'Add' a 'row' to a 'table'

But off course it is a matter of choice.

But in my oppinion overloading is a two edge sword, it can be a good thing
but also a very bad thing.

Best regards
Søren Reinke
www.Xray-Mag.com
A free Dive Magazine, 99 pages with huge section about diving in North
America
Download it in PDF

[Rick Elbers]

Soren,

Interestingly people who used to cout a lot might
feel the same way about your table << row;

Rick
On Fri, 29 Apr 2005 09:44:55 +0200, "Søren Reinke"
<so***@reinke.fjernmig.dk> wrote:

puh!
table << row ;
is much cleaner looking than:
table.Add( row ) ;

I must disagree.

<< and >> is used for bitshiftning not adding or something like that.

table.Add(row);
Tells you easilly readable that you 'Add' a 'row' to a 'table'

But off course it is a matter of choice.

But in my oppinion overloading is a two edge sword, it can be a good thing
but also a very bad thing.

Best regards
Søren Reinke
www.Xray-Mag.com
A free Dive Magazine, 99 pages with huge section about diving in North
America
Download it in PDF

[Jon Skeet [C# MVP]]

Rick Elbers <ri*********@chello.nl> wrote:

Interestingly people who used to cout a lot might
feel the same way about your table << row;

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.

If I got into a habit of naming all my C++ methods backwards, would
that make it a good idea to do in C# too? Nope - it just means it was a
bad idea even in C++.

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

[Steve Richter]

Jon Skeet [ C# MVP ] wrote:

Rick Elbers <ri*********@chello.nl> wrote:

Interestingly people who used to cout a lot might
feel the same way about your table << row;
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.

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 ). 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.

-Steve

If I got into a habit of naming all my C++ methods backwards, would
that make it a good idea to do in C# too? Nope - it just means it was a bad idea even in C++.

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

[Jon Skeet [C# MVP]]

Steve Richter <St************@gmail.com> 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 - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Rick Elbers]

Hi Jon,

Your reaction about confusing symbols is understandable I think, what
I dont understand is the hidden agressive part. In my experience with
c++ I have had never any problem with the overloaded meaning of
operator << and >>.
Like most truths in a human world its overloaded with respect to some
context. I dont understand why your c# spec is the wholy grail when
compaired to a completely vendor independent c++ language spec and
comite.

Rick

On Sat, 7 May 2005 18:52:46 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote:

Steve Richter <St************@gmail.com> 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 [C# MVP]]

Rick Elbers <ri*********@chello.nl> wrote:

Your reaction about confusing symbols is understandable I think, what
I dont understand is the hidden agressive part. In my experience with
c++ I have had never any problem with the overloaded meaning of
operator << and >>.
I guess I am a bit overzealous about it, just because readability is
such a big issue for me - and when symbols don't have clearly defined
meanings, readability goes down.

I dare say it's hard to remember, but do you know what your reaction
was the *first* time you saw the bitshifting operators being used for
something other than bitshifting.

Suppose someone didn't follow the accepted naming conventions for the
environment they're working on. It's not an immediate *problem* as such
- it doesn't make things completely unreadable - but it just makes
everything that *little* bit harder.
Like most truths in a human world its overloaded with respect to some
context. I dont understand why your c# spec is the wholy grail when
compaired to a completely vendor independent c++ language spec and
comite.

There are certainly things wrong with C# too - but I think it was the
right decision to keep bitshifting operators as just that. There are
many ways in which C++ is a real pig to read, IMO, and I think C# has
improved things significantly on that front. One of the contributing
factors to that is the restrictions on what can be overloaded where.

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

[Steve Richter]

Jon Skeet [ C# MVP ] wrote:

Steve Richter <St************@gmail.com> 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

[Jon Skeet [C# MVP]]

Steve Richter <St************@gmail.com> wrote:

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"!

It's not a case of ambiguity so much as plain confusion. A C#
programmer who sees a shift operator being used for something other
than shifting is likely to

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.

They're not implementation details - they're part of the documented
interface. I don't see why it's a bad thing to have an object which can
be used safely in multiple threads with no locking, and a separate
object which carries state and should therefore be used more carefully.
They're very closely related, of course, but they do perform slightly
different roles.

I can't see how being able to have standalone functions would help
there at all.
A stateless operation is best expressed as a standalone function
defined in a namespace.
There we'll have to disagree - do you think it's inconceivable that two
functions which perform different operations but have the same name
would be in the same namespace? How about int.Parse and double.Parse,
for instance? I don't see what's wrong with those being static methods.

Mind you, the Encoding methods aren't static anyway. Describing an
Encoding as stateless was slightly wrong - they're immutable, but can
carry state such as whether or not to use a preamble. Of course, they
also have properties which may or may not vary between two different
instances, depending on the implementation.
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.
I don't see anything ambiguous about the method names - there are no
predefined names in the specification, so you can't assume that a
method has anything to do with the specified behaviour. That isn't true
for operators.

(Actually, there are a very few predefined method names in the
specification, to do with Dispose and Monitor.Enter/Exit, but I don't
think they're particularly relevant to the point in question.)
C# code would be easier to read if namespaces could contain standalone
functions.

I'm afraid we'll have to disagree.

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

[Jon Skeet [C# MVP]]

Jon Skeet [C# MVP] <sk***@pobox.com> wrote:

Steve Richter <St************@gmail.com> wrote:

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"!

It's not a case of ambiguity so much as plain confusion. A C#
programmer who sees a shift operator being used for something other
than shifting is likely to

Sorry - I didn't finish that bit, clearly.

It should be continued:

.... is likely to get confused or make invalid assumptions about what's
actually going on. It doesn't matter whether it's in ASP.NET, a console
app, a web service or Windows Forms, << and >> are shift operators.
That's how they're defined, and it's reasonable for people to expect
that to be how they're used.

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