Typing question - page 3

New comment
 
Ilya Malev:

The template mismatch error should probably occur at compile time.


But in the situation when there is an array object

Such error shouldn't occur because in the first case call of Array[int] is used as the left parameter of operation = and is not variable of type double, while in the second case it is the right one, and the left parameter is variable of type double.

You don't hear, it shouldn't do anything - type overloading is forbidden and it's explicitly written in C++ standard (and µl as C++ similar - probably too):

Certain function declarations cannot be overloaded:

- Function declarations that differ only in the return type, the exception specification (18.4), or both
cannot be overloaded.

The probable reason is explained above. So your operator[] is invalid.

 
pavlick_:

You don't hear, it shouldn't do anything - overloading by type is forbidden and it's explicitly written in C++ standard:

The probable reason I gave above. So your operators[] are invalid.

I wasn't responding to you about the standard, but about logic based on common sense. Your definition of "probable" cause does not negate my arguments. The possibility of overloading a typing operation (including implicit) does not contradict the standard you quoted, because it is an overloading operation of casting to a particular explicitly defined type from the context.

Perhaps I was not too clear, but this clarification hopefully makes it clearer.


P.S. Of course, my fictitious code contradicts the standard. But if you need to decipher it (because I was figuring out for myself how to phrase the question more accurately), it should look like this:

class Array{

public:

Array *operator[] (int i){ id = i; return GetPointer( this ); }

double operator double(){ return data[i]; }

Array *operator=(double d){ data[id]=d; return GetPointer( this ); }

private:

double data[10];

int id;

};



int OnStart(){

  Array array;

  double d=123.456;

  array[5]=d;

  d=array[5];

}
 
If you advocate operator type(), fine. If you advocate indenting from pluses, then I'm against it (allowing overloading by return type) to solve some particular problem (which could probably be solved differently and more beautifully - somehow I never got around to it like in the first post).
 
pavlick_:
If you advocate operator type(), fine. If you advocate indenting from pluses, then I'm against it (allowing overloading by return type) to solve some particular problem (which surely can be solved differently and more beautifully - somehow I never twisted in such a way as in the first post).

Yes. In the end, I'm all for the introduction of the typing operator. Because it solves exactly the problem, which I stated in the initial post, only in a more "conventional" (fit into standards, and probably more correct in general) way.

 
Ilya Malev:

P.S. Of course my made-up code is against the standard.

Why does it contradict the standard, it's perfectly valid in the pluses. And there are no docks at all in mcl.
 
pavlick_:
Why is it contradictory, in pluses it's quite valid. And in mql there are no docks at all.

Because originally there were two identical operator[] functions with different return type (I fixed it in the second version). This is forbidden by the standard. But citing types (including implicitly) is not forbidden, they just haven't had time to implement it yet. Taking into account the impressive rate of development of mql5, I'm sure it will be implemented sooner or later. Especially if someone else besides me pays attention to it on the forum...

 
Ilya Malev:

Because there were two identical operator[] functions with different return type. This is forbidden by the standard. It is not forbidden to type (even implicitly), they just have not had time to implement it yet. Taking into account the great speed of mql5 development I'm sure it will be implemented sooner or later. Especially if someone else besides me will pay attention to it on the forum...

I mean the last code - it's fine.

 
pavlick_:

I mean the last code - it's okay.

It's OK, but it doesn't work in mql5 yet. Let's follow and hope for innovations in mql5. It is this inability to adequately implement an array object, because of the inability to handle a user type the same way as with an ordinary array, that has been bothering me personally for a long time. When you make your own array, it comes out to be defective from the very beginning, not possessing the same usability properties as the built-in ones.

 
Ilya Malev:

It's OK, but it doesn't work in mql5 yet. Let's follow and hope for innovations in mql5. It is this inability to adequately implement an array object, because of the inability to handle a user type the same way as with an ordinary array, that has been bothering me personally for a long time. When you make your own array, it initially turns out to be defective, not having the same usability as a built-in one.

Well, I'm not expecting big miracles, the language isn't really being developed anymore, I doubt they'll add a ghost operator. Here I am specifically stressed by the inability to do it that way:

class Q {};

Q q;
// что то делаем и решаем переинициализировать q
q = Q();  // ошибка, нужно извратиться:

Q temp;
q = temp;

but it's useless to say, I think.

 
pavlick_:

Well, I'm not expecting big miracles, the language isn't really developed anymore, I doubt they'll add a ghost operator. What bothers me in particular is the inability to do it that way:

But it's useless to talk about it, I think.

It's not quite clear what the problem is. Couldn't the initialization of the object be implemented in a separate method like Init(), maybe even in a virtual one?

12345678910
New comment
Reason: