overload operator<<

  • Thread starter Thread starter Steve Richter
  • Start date Start date
S

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
 
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.
 
CSharper said:
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
 
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
 
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.
 
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
 
Compund assignment operators are overloaded indireclty.
f.e. overloading binary + also overloads +=

Christof
 
Christof said:
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
 
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 ;-)
 
Lebesgue said:
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 ) ;
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
 
puh!
table << row ;
is much cleaner looking than:
table.Add( row ) ;

puh!
It's your opinion, I believe many C# programmers would disagree
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 +=
 
Steve Richter said:
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.
 
Steve Richter said:
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.
 
Steve Richter said:
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 said:
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.

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
 
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"
 
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
 
Soren,

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

Rick
 
Rick Elbers said:
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 said:
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
 
Back
Top