overloading with the same parameter-set ?

New comment
 

As you can see in the code below I tried to overload the operator []. With that the polymorphism has to look at the result declaration. But it doesn't.

One way to work around may be a index in one declared as double, but it's ugly. Is there a better way ?

Code (not working because of: ''operator[]' - function already defined and has different type"

   //--- Indexing operator (right side)
   double            operator[](int i) { return(m_array[(int)i]); }


   //--- Indexing operator (left side)
   classType         *operator[](int i) { return(GetPointer(this)); }
 
  1. You can overload operators and functions (they must have different parameters.)  Your parameter was the same (int) You can never change the return type only. Which one should the compiler use?
  2. I have no idea what you are trying to do. aClass[i] returning aClass* makes no sense.
 
WHRoeder:
  1. You can overload operators and functions (they must have different parameters.)  Your parameter was the same (int) You can never change the return type only. Which one should the compiler use?
  2. I have no idea what you are trying to do. aClass[i] returning aClass* makes no sense.

1. that's what I was afraid of. It would be nice if the compiler has a look at the return-declaration. (void f.e. meens there is anyway only a 'set'-routine)

2. may be I'm on a wrong way. If I overload the operator[], it has to be usable on both sides of the =-Assignment. But on the left side it has to react on two parameters (value to set and the index) - while there is only one delivered. So I return the whole object on the first step and stack the int. The second overload (=) remembers the stacked index and sets the value in the array behind. But this is only my idea in touch with my objective.

Is there a simple / smarter way overloading both sides of a []-index without changing the typical use of an array on the 'consumer'-side ?

 
Abejorro: If I overload the operator[], it has to be usable on both sides of the =-Assignment.
  1. You have a single object. object[i] = value; makes no sense (it's not an array.) That can't be done in any language I know.
  2. If you have an array of objects and the object has a assignment operator, then you can
    class Object {
  public: 
    void operator=(const& Object that){ this.m = that.m; ... Object  o[]; ...
}
Object another;
o[i] = another; // o[i].operator=(another)
  3. If your object has an internal array, you have to create a set
    class Object {
  public: 
    DataType operator[](int i){ return get(i);    }
    DataType get(int i){ return mArr[i];          }
    void     put(int i, DataType v){ mArr[i] = v; }
 private:
   DataType mArr[];
}

 

WHRoeder:

If your object has an internal array, you have to create a set

That's what I did. An array with objects would be horrible on the memory. I do have a 'm_array' inside the class.

   //--- Indexing operator (right side)
   double            operator[](int i) { return(m_array[(int)i]); }

With that code you can use the object like a simple array:

   Print("Output..." + oTest[4]);  

But I want the Class also to be usable like a simple array on the left side.

oTest[4] = 23.5;    // this is NOT possible with the codes above.

This changes makes it possible:

PS: that's the reason why I return the pointer to the object itself with the operator[] - You asked above. The second step gives the sense.

private:
   int               pointerIndex;

public:
   //--- Indexing operator (left side)
   classType         *operator[](int i) { pointerIndex = i; return(GetPointer(this)); }

   void              operator=(const double value) { m_array[pointerIndex] = value; }      

Ok, but now we have the issue I've been asking on top. There had to be two different members - different only in the return declaration :-(

Without that option, I have to decide what to use. Left side or right side.


My other idea for the left side (EDIT: correct is RIGHT-side) based on the objectpointer is not working. But I don't know why ??

I like to differ left and right with the parameter on the overwritten operator=. The compiler is happy with that but the result is funny. First: The return is not a double as declared (?) but the routine is used. Second: It returns the whole object behind the = and then the values inside are random nonsense (?) 

// m_array & pointerIndex as public !

double            operator=(classType*  obj)
      {
         Print("Operator = Right requested - i: " + obj.pointerIndex);
         return(obj.m_array[obj.pointerIndex]);   
         // same with locals without obj.  
         // same object returns with  "return (double) 99.99;" (??)
         // (I create a pointer on an object and take this pointer. So there has to be only one object involved. But the return had to be a double ! The print makes clear I'm there)
      }

Not an award-winning code but may be nice to have.

The calling-code:

// '=' - illegal operation use
double t = oTest[6];

// possible but confusing:
classType t = oTest[6];


So, this is the whole story. I hope I have described my thoughts understandable ?

 

Well, it seems that all your effort is intended for adding a look to the object containing an array to resemble the array. From my point of view, I would declare the array public and use the array indexes directly rather than overloading operators. Unless you aim some other reason.

Or, some more inspiration:

http://stackoverflow.com/questions/27267328/overload-class-function-operator-twice-as-setter-and-getter

 
Ovo:

Well, it seems that all your effort is intended for adding a look to the object containing an array to resemble the array. From my point of view, I would declare the array public and use the array indexes directly rather than overloading operators. Unless you aim some other reason.

Or, some more inspiration:

http://stackoverflow.com/questions/27267328/overload-class-function-operator-twice-as-setter-and-getter

 

Yes, I also declared arrays as public and that's it. But all the security, checks and validating and so on has to be involved and tested every time again on the side. With the OOP-design I can cover all that in a smart class and forget. And with this realization here the update in code could be done only with a new declaration. (developers spend always hours and days to prevent 30 min of boring work ;-)

Thanks for the link. It is close to my wishes. Sadly the const didn't make any difference here. But I have to look a little deeper...

 

Abejorro: That's what I did.

My other idea for the left side based on the objectpointer is not working. But I don't know why ??

  1. Where did you write a set?
    void set(int i, double v){ m_array[i] = v; }
  2. There are no pointers to POD in MQ4. What you want can not be done. If your array was an class, then you could have operator[] return a pointer and it would work.
 
WHRoeder:
  1. Where did you write a set?
  2. There are no pointers to POD in MQ4. What you want can not be done. If your array was an class, then you could have operator[] return a pointer and it would work.

my false ! Now I've corrected it above. The problem with the pointer-version is not the left side (write) but the right side (read)

So there is a simple code for reading that thing, but this will be in conflict with the coding for writing in that kind of object-covered-array. And the conflict is not the compilation of the class but later at using compilation (?)

My confusion is the answer of the compiler. 1) It is possible to compile the class with all return-declarations. 2) But with the calling-code using the class the compiler dominates the given declaration and is asking for an object-variable instead of the double the code is returning. That is for sure the reason for the random nonsense values. There is no object returning but the compiler asked for. If there is a way to work around this compiler-irritation the thing is done.


I've seen your set(..) code but I'm not sure if I used it right. The only way I could use it was in this way, or is there another?

objName.set(index, value);


With the pointer-version I am able to write like an array:

oTest[4] = 23.5;
 
Abejorro: With the pointer-version I am able to write like an array:

What part of

There are no pointers to POD in MQ4. What you want can not be done.
is unclear?
 
WHRoeder:

What part of

is unclear?

We can start with that part in which I'm not looking for a pointer to data !

We can go further with that part in which I still use the only pointer to object successful and within its duties.

But you're right. We don't need to :-)

12
New comment
Reason: