Goodbye robot - hello marasmus - page 10

 
borilunad:

Sr. Pansa! Porqué no usa el botón SRC para poner su código? Así mejor o Ud. tiene alguna duda?

Buena suerte!

Hi, borilunad!
want to ask where do you get the SRC?
panza
 
 
pansa:
Hi borilunad!
want to ask where do you get the SRC?
pansa

When you reply, look up a bit and to the left of the video you'll see an SRC button! Click it and it will open a perimeter to paste the code! Good luck!

By the way, very accurately and "eloquently" pointed out the SRC location by Constantine!

 
7Konstantin7:

Hi Konstantin, how are you getting on in manual trading? I guess you've already become an assassin, haven't you?
 
Renat:

I understand that some people will get hysterical after getting acquainted with static analyzers.

But only after that some understand what a compiler must (exactly must) do. It's 2014 and ordinary compilers are at least 10 years behind in quality control and concentrate only on optimizations.

For information: the Intel C++ compiler still has not recovered from its defects - it constantly generates internal compiler errors on our projects. That is, it doesn't chew large projects and produces its own errors. And the myths about its extraordinary optimizing properties are outdated too - all the rest have tightened their optimization levels greatly.

In such a dangerous and suicidal language as C++ there are so many keys and compilation switches so that confident programmers could compile tons of ancient and copied from nowhere code without nervous cramps :)

A compiler, first of all, must compile rather than analyze and it should compile rather preferably with good quality, which usually requires flexibility and customizability.

It's reasonable to create static code analyzers and other similar tools as separate utilities whose functions can be performed with higher quality in this way than with the compiler.

It's reasonable to understand that static code analysis and other similar useful things help to detect only a few errors, i.e. those related both to inattention and low skill of a programmer. Errors of design, logical errors, errors of "forgot to implement" type and other similar errors are not detected by static analyzers or similar tools. Which is exactly what we can see in MT4.

At its time, Microsoft's compiler too was easy to "break" because of internal errors. Newer versions are also more stable, including Intel's. As for optimization, you usually don't need anything extraordinary - only good, solid optimization - and Intel's optimization is based on deep understanding of architecture and mechanisms of its own processors. It would be strange to think that it would be worse for Intel than for others.

Compilation switches are primarily intended to flexibly tune the compiler to (parts of) a project's requirements, and options to make it easier to compile ancient code are just an added bonus.

If C++ language is so dangerous and suicidal, then why early MQL4 based on C was "improved" to MQL4++ and MQL5 based exactly on C++?

 

simpleton:

It's reasonable to understand that static code analysis and other similar useful tools help to detect only a few errors, i.e. those related both to inattention and low skill of programmers. Errors of design, logical errors, errors of "forgot to implement" type and other similar errors are not detected by static analyzers or similar tools. Which is exactly what you can see in MT4.

Test environments are widely used in software products for functional verification of software chip designs where requirements to code quality are very high. Moreover, the functional shell is an integral part of development of any code for chip design. On the other hand, many programmers do not even have idea about such functional tests when writing usual software projects, it is because writing such tests from scratch may take more time than when writing the project itself and is justified only when there is a requirement to write high-quality code or there are many versions of the same project. On the other hand, a skillfully written test environment significantly reduces the time of code debugging and verification.

Static analysis is also used but only as a very superficial and primary syntax check.

 

Simpleton, what nonsense.

When you get to the level of total quality control, only then you will understand it. In the meantime, you remain at the level of perception of an individual narcissistic programmer, and will continue to think "it is reasonable not to control me, let the control be by separate never run utilities".

Unlike C++, MQL is absolutely safe (if there is no exit to dll) due to the rejection of raw links, and in general - it is a managed language.

 
Renat:

Unlike C++, MQL is not dangerous at all

Glitches in the C++ compiler itself are rather rare.

MQL compiler glitches are a regular occurrence now (I've seen internal compiler error for MQL much more often than for VS).

MQL code execution glitches are also a recurring phenomenon nowadays.

 

Glitches are being dealt with, but we are adding and improving a lot in parallel.

There will be an MT4 release on Friday with clear improvements in execution speed and testing.

 
Renat, I want: namespace, gluing in macros, multiple inclusion of header files, undef, union. Everything like in C++.