Errors, bugs, questions - page 1358
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Personally, this is a constant problem for me, I have to be always on the lookout, or specify A.operator=(B), A.operator!=(B) everywhere, i.e. it loses conciseness and operator overloading actually makes no sense.
I raised this problem once before, but the topic got stalled. Let's finish this issue at last.
What's that for? It's upside down.
It makes more sense the other way around: < and > should lead to comparison of pointers.
This was already discussed back then (please reread that old thread). In my posts I assumed that you remembered it if you suggested: "let's finish this question".
Let me repeat - two operators are sacrificed (== and !=) in order to preserve the capabilities of all(!) others (not only < and >). Beauty to the detriment of functionality.
so you don't have to explicitly specify A.operator!=(B)
Well that will soon be solved, I hope, as the developers have finally heard me. Then it will be simple: *A != *B
This was already discussed back then (please re-read that old thread) - I repeat - two operators are sacrificed (== and !=) in order to preserve the capabilities of all(!) others (not just < and >)
I agree that all these operators should have equal status. But not the way you suggest. If both arguments are pointers, it's the pointers that must be compared to each other. Otherwise it would be illogical: both arguments are explicitly given by GetPointer, but for some reason class operators are executed. So, imho, the inequality signs would be more correctly applied to pointers in this case.
However, no one is going to change operators' behavior anyway, obviously. Otherwise there will be a general fuss over non-working programs.
Again, you keep forgetting about the assignment operator. Do you suggest that we implement it through a function too? Wouldn't it be too tiresome?
Hi all,
Such a question, signed up for a signal which is pretty reliable, then out of the blue trading started on crazy lots, everything would have been fine in the beginning as there was a profit which turned out to be a loss of money in the end. Can you tell me where the dog is buried (whose fault?) and who can help sort it out.
Hi all,
Such a question, signed up for a signal that is pretty reliable, here out of the blue started trading insane lots, everything would have been fine in the beginning, as there was a profit that turned out to be a loss of money in the end. Can you tell me where the dog is buried (whose fault?) and who can help sort it out.
A signal that is pretty reliable, here out of the blue started trading crazy lots
+100500
Can you tell me where the dog is buried (whose fault is it?) and who can help sort it out?
We'll tell you where the dog is buried: behind the garages, but whose fault it is - you should go to the telepath branch, it's somewhere on this forum, google it.
yes the thing is that the orders presented on the website in my signal section and what the platform on my phone uttered do not match.
it's not about the signal, the signal is reliable, it's about the transmission, what could be the reason?
and what can i do to provide the material if i don't understand it at all from a technical point of view
And again, you keep forgetting about the assignment operator. Do you offer to implement it through a function too? Wouldn't it be too tiresome?
In the case of operator=(...) there is no easier solution than to use a.operator=( b ) directly
If they make *A = *B - fine!