[CLOSED] : Compiler bug with template parameter = void* - page 10

 
Ilya Malev:
As for "normal programmers remember the priorities of C++ operations like a multiplication table",
No one has voiced such a thesis. I myself use the tab in the Documentation
 
fxsaber:

Exactly! Not a pro at all, such warnings have helped me 100 times.

Not a pro either, but I have been bothered by such warnings more than once, because among dozens (and sometimes hundreds) of such superfluous warnings the really important and necessary ones have been lost

And it is unclear what kind of warnings you may have if you put parentheses everywhere? And if it was about other cases, there is no need to mix things up

 
A100:

So that the concept can be implemented in the compiler. No one forbids putting extra brackets. The question is about unnecessary warnings

well, in the studio this is configured by a level.

And actually nobody will prevent you from removing these warnings by changing the code so that the compiler likes it

 
TheXpert:

Well, in the studio, it's set by a level.

And nobody actually prevents you from removing these warnings by changing the code so that the compiler likes it

It's a hindrance, because then you get extra brackets. But no one prevents lovers of this cause from putting extra parentheses, and most importantly - everyone would be happy with it

I doubt that it is configurable in studio - because there are no redundant warnings about allegedly forgotten parentheses (at least by default) and hence there is no subject to configuration

 
A100:

I don't mind. Just leave those warnings in the old MQL4.

That's how they remain for the most part

void OnStart()
 {
  int a=0,b=0,c=0,d=0,e=0,f=0;
  a=b|d/e^f|a^b&d^e%f|c;
 }

In µl4 it swears at everything, in µl5 only at operations << and >> which is quite logical, because their overload logic will most often be very different from the logic, based on which they were prioritized. These warnings have helped me many times, or at least not annoyed me too much. Well, and the logical operations defining the logic of && and || code, which should be delimited by parentheses anyway...

 
A100:

I am not a pro either, but I have been bothered by such warnings more than once because among dozens (and sometimes hundreds) of such superfluous warnings I have lost really important and necessary ones

And it's not clear what warnings you may have if you put brackets everywhere? And if it was about other cases, you don't need to lump everything together

Usually it happens so that you have to quickly fix some condition. For instance, I made a mistake in a condition where I wrote && in one place and should have replaced it with ||. I corrected it and pressed F7. Immediately I got a warning. I look accurately and see that the result with current changes is not what I expected. I corrected it - all is normal. That is, the compiler helped me very much with its message.


But if you have a whole lot of warnings, write your code more carefully. Or don't you edit them as a matter of principle, proving to the machine that it is wrong?

 
A100:

It prevents you from doing so because it creates unnecessary brackets. But putting extra brackets is not prevented by the amateurs, and the main thing is that everyone would be happy with it.

I doubt it's configurable in the studio - because there are no extra warnings about allegedly forgotten parentheses (at least by default), so there is no subject of configuration

Totally agree. Since you call yourself a programmer, be kind enough to learn the priorities of operations, at least remember that they exist. I've been asked to add a robot recently, but I was asked to add init() and start() and when I asked them when they wrote it they were told that it had been a week ago. So, there are still "coders", but for such people it's not worth leaving unnecessary warnings.

 
Vladimir Simakov:

I absolutely agree. Since you call yourself a programmer, be kind and learn operation priorities, at least remember they exist. I've been asked to finish writing a robot recently, but I've got init() and start() there and when I asked them when they wrote it they were told that it had been a week ago. So, there are still "coders", but for such people it's not worth leaving unnecessary warnings.

Knowledge of priorities has nothing to do with warnings. I write code quietly and don't call myself a programmer.

 
A100:

I doubt it's set up in the studio

it is available in the project properties. we used to have an iron rule on one of our projects - fix all warnings on release versions, including some paranoid W4

https://docs.microsoft.com/en-us/cpp/build/reference/compiler-option-warning-level?view=vs-2017

Seems to me - the more warnings the better, if they are somehow justified and can be switched off

 
fxsaber:

If you have a huge number of warnings, write the code more carefully. Or don't you correct them as a matter of principle, proving the machine wrong?

I use mostly C++ compatible code (and often even a single file). C++ doesn't have them, and unnecessary brackets, as already noticed here, make it difficult to understand

Reason: