when overloading a bit shift in c++, does it actually take one arguments or two?? how does the function looks like?
Printable View
when overloading a bit shift in c++, does it actually take one arguments or two?? how does the function looks like?
As all other operators look like:
lhs operator << (const lhs&, const rhs&)
Or
lhs operator >> (const lhs&, const rhs&)
Remove lhs& if you're overloading inside a class.
I think these operations don't modify the left-hand argument.
should it be something like:
obj operator<< (const obj& b1, const int b2)
Ah, right. I was thinking of something else. My mistake.
Uh that depends dude. Explain what your bitshift operator does.Quote:
Originally Posted by -EquinoX-
shifting array elements... basically
So let's say I have obj foo which is your array class. I also have bar, which is an element that I want to shift in by n places. I don't think you should use a shift operator here because it's a bit awkward.
I mean this is going to be common right?
foo >> n; // make a hole
foo[n] = bar;
Why not just make that a member function instead? It's obvious what shiftIntoPlace(bar, n); does. And you cannot possibly forget to assign something in the hole. Sorry if that is strange advice, but this is how I would write it; mainly so that I can guarantee that there is only empty space at the end of the array. Your way is a kludge to me.
We overload operators in order to make it easy to manipulate objects in a natural way. If it makes sense to be able to shift your object in some way, go ahead and do it. We don't need any stinking members functions ala Java.
If it doesn't make sense to do it, don't do it at all, or make a member function with a somewhat different name.
Huh :confused: I see it as an operation with three operands: the object, the element, and an offset. Unless I'm forgetting one, no operator that's overloadable takes three operands. Can still do it with two, I just don't think it's very good because you have to do something like what I showed before. It's like it only did half the work.Quote:
Originally Posted by Elysia
That is just a general purpose insertion of an element at some position anyway. The standard containers provide member function(s) named insert to do this kind of thing. I guess that if it takes one's fancy one could overload the bit shift operators to do this kind of insertion, but restricted to inserting value initialised elements at the front or the back, and this kind of fanciful operation is what I interpreted Elysia's comment to be about.Quote:
Originally Posted by whiteflags
It is the interpretation of what this should be:
foo >> n; // make a hole
foo[n] = bar;
Make a hole? Do something other than shifting? Then you have to be careful about what you do. I would only accept any kind of shifting and stream operations with those operators. And when you do either shifting or stream operators, overloading operator >> to do this is perfectly acceptable.
But if you want to create a whole or some other weird stuff, then make a member function.
When shifting or doing stream operations, we're only operating on two objects, not three.
:confused: Now it's like you changed opinions. Whatever, we agree, I guess.
You would shift everything by n spaces, you wouldn't create any holes. You decide if the elements that go out-of-bounds are cycled (go in front) or lost. If you had an array of strings lets say "boy" "loves "girl". Cycling you would have "girl" "boy" "loves". By losing elements you have "" "boy" "loves". Asumming left shifting of course.Quote:
Originally Posted by whiteflags
Shifting could do something similar with bitwise operators. Since this is an array you can have it not "lose" elements, but allocate one more space to save the element that would go out of bounds.
It could be useful. Not very efficient probably, since it would be easier "shifting" the indexes rather than the elements themselves if the object is bigger than an int.