Goodbye robot - hello marasmus - page 12

New comment
 
simpleton:

By the way, about the management experience. 5 years ago we argued on the mql5 forum about the prospects of MT5, I said then that time will tell. Five years have passed and we see that the community has rejected MT5.

You have a lack of information. We never advertise our client base and implementations.


I'm not translating, general principles, theory, - not for theory itself, but for application in practice. You won't find such serious "flaws" in the same C/C++ compilers.

And have found and even reported to authors about them.


If you say that in this case "a static class method has no right to get into the contents of the class", then why in case of dynamic object creation does it already have that right?

I was saying "over-protection, let's fix it". In theory the conditions sound simple, but in practice the static/dynamic implementations work differently, which leads to discrepancies.


What about the fact that a non-static implementation behaves exactly the same way?

Same thing, the "private means private" rule has overridden the "for designer/developer we make an exception" nuance. we'll fix that.


If there are errors in the language implementation - well, yes, there are errors. You are talking about total quality control - so get rid of implementation errors in MQL4++ compiler in practice, so that it is almost as difficult to find errors as in C++ compilers, since you have such control. I still believe that a parser will not help to get rid of errors like the ones I demonstrated.

That's right, it's errors/mistakes in the compiler we wrote ourselves from scratch. So this is the usual way of collecting rakes.

Total quality control is a systematic approach to working on bugs and a clear focus on finding them. That is exactly what we do. You, in contrast, state that you are against coercion and do not want strict control by technical means.



It's not about like or dislike. There is a tool. Why should I refuse to use all its possibilities?

In this case, it's not even about "I like it". It's Myers, for that matter, who likes it so much. And for some reason nobody tries to accuse him of trying to "deliberately trip up" C++ compilers.

We have a good explanation - "this is not a C++ language, but a specialized MQL4/MQL5 language. So we don't have to support everything". But in any case, the behaviour will be reduced to familiar C/C++ as much as possible.


It's not an easy task that can't be solved right off the bat. You have to put some effort here, and not a small one at that. The vast majority of MQL users are not programmers. And this must be taken into account in language design. But the task can be solved, I'm sure.

If anything, it would be enough to add some structures to old MQL4 and clean up some stuff like priorities to operations, as it was done for MQL4++ and that would be a reasonable compromise. The success of MT4 was largely due to the lack of "cleverness" of the language. This is not the case now. And there are much more errors in the compiler implementation because MQL4++ is much more complex than the old MQL4 and the development team has hardly changed much.

Here I agree with you, but I think it is mainly because the competitors do not understand what they are doing.

We have rewritten 5 trading platforms from scratch 5 times in the last 14 years.

It's a better way to create something really cool than loading the old donkey with hover bricks. So both the release of MT5 and the new MQL5 have given us a huge future for another 10 years to come.

But those who sit around and pile on the old project thinking "let the bird in the hand, the main thing is that I won't get fired if I start a new one and fail", lose the respect of management, they are written off as impotent and slowly leave the scene.

 
Renat:
You have a lack of information. We never advertise our customer base and implementation.

I'm judging by public information and support for the previous version, i.e. MT4.

When MT4 came out, MT3 stopped being supported and offered quite quickly - everyone switched to MT4. This did not happen for the MT4 - MT5 pair, even though a lot of time has passed. And there is still a clear bias towards MT4.

You have even ported back from MT5 to MT4 including the compiler. Did you port anything from MT4 to MT3, 4 years after its release?

Renat:
And they did and even reported them to the authors.

But there is a difference: it is probably hundreds if not thousands of times harder to find an error in modern C/C++ compilers than in MQL4++.

Renat:

I used to say "over-protect, let's fix it". In theory the conditions sound simple, but in practice the static/dynamic implementations work differently, which leads to discrepancies.

The same thing - the rule "private means private" overrode the "make an exception for constructor/destructor" rule. We will fix that.

That's right, it's bugs/inconsistencies in the compiler we wrote from scratch ourselves. So this is the usual way of collecting rakes.

Total quality control is a systematic approach to working on bugs and a clear focus on finding them. That's exactly what we do.

It's enough to apply the usual regression tests, which don't even require any special "engine". There is access control in classes/structures in the language - write once tests for it in the form of compilable MQL programs. Some should compile successfully, others should compile with a certain error. That's the total quality control in this particular place. It's true, the tests that will cover all access control functionality must be written first...

Renat:
As opposed to this you say that you are against coercion and don't want strict control by technical means.

It's not the opposite. The MQL compiler for MQL programs could be made to include both warnings and what some C++ compilers call remarks by default. But I'm "stating" only that at least the remarks should be disabled. In MQL compiler for MQL programs. And now nothing can be disabled in this sense in MQL4++ compiler.

There is a lack of quality control when implementing, in particular, the MQL compiler, since errors in it are so easily detected. What do you mean by strict quality control of MQL programs?

Renat:
We have a good explanation - "this is not C++ language, but specialized MQL4/MQL5. Therefore, we are not obliged to support all of them". But in any case, the behavior will be reduced to familiar C/C++ as much as possible.

Great. You don't support everything. But what is supported must not contain so many errors in the simplest basic constructs.

Do you support access control to class/structure members? Support at least all basic cases in the simplest basic constructs without errors.

Take the same access control - in the simplest basic constructs:

/******************************************************************************/
class A {
private:
  class B { };
};

/******************************************************************************/
void OnStart() {
  A a;
  B b;
}

This compiles without errors:

'3.mq4' 3.mq4   1       1
0 error(s), 0 warning(s)                1       1

However, we see that this code does not compile in C++ for two reasons:

$ clang -c 3.cpp
3.cpp:10:3: error: unknown type name 'B'
  B b;
  ^
1 error generated.

Class B is defined inside class A, so it should be referenced in OnStart() as A::B:

class A {
private:
  class B { };
};

/******************************************************************************/
void OnStart() {
  A a;
  A::B b;
}

But that's not all - the modified code still won't compile with the C++ compiler:

$ clang -c 3.cpp
3.cpp:10:6: error: 'B' is a private member of 'A'
  A::B b;
     ^
3.cpp:4:9: note: declared private here
  class B { };
        ^
1 error generated.

For some reason access control in MQL4++ generally works for methods and data - class members, but not for types.

When specifying scope for the B class as A::B, the MQL4++ compiler generates the following errors:

'3.mq4' 3.mq4   1       1
'B' - struct member undefined   3.mq4   12      6
'b' - undeclared identifier     3.mq4   12      8
'b' - some operator expected    3.mq4   12      8
expression has no effect        3.mq4   12      6
3 error(s), 1 warning(s)                4       2

Why is this "struct member undefined"?

Again, the C++ compilers do not somehow have problems with types inside classes either. But the MQL4++ compiler does.

These errors were found by accident when trying to implement the Myers singleton. Some of the errors were found by me, and some were found by other discussion participants. It shows how easily one can stumble upon compiler implementation errors when programming in MQL4++. And you don't have to deliberately look for errors to stumble upon them, just try to solve the task.

Please note that these are all critical errors for serious use of MQL4++.

Obviously, there are no regression tests of the type I've mentioned above, at least for the simple access control to check whether the MQL4++ compiler works. Otherwise it would have all been detected and fixed by now.

Renat:
We've rewritten 5 trading platforms from scratch 5 times in the last 14 years.

That's a better way to create something really cool than to load up the old donkey with hover bricks. That's why both the release of MT5 and the new MQL5 have given us a huge future for another 10 years to come.

But those who sit and hammer away at an old project thinking "let the bird in the hand, the main thing is not to get fired if I start a new one and fail" are losing the respect of management, they are written off as impotent and slowly leave the scene.

I agree that proactive action with innovative type of development is the most important component, but it is not the only one. And you can spoil a barrel of honey with a fly in the ointment.

One such tinge is a distinct lack of quality. The reason for creating anything in MQL is lost because of it.

 

I about SSE2, maybe not in theme, but also with pleasure, something listened.

I've got to change one of the computers, not all of them, but it distracts from the topic, not for development, not for trade, except to read the forum.

 
MT5 Great! It's magic to build pyramids on it.
 

Hello forum users!

I'm upgrading to mt5 and would like to

to ask Pavlik.

Pavlik, if you see me, send me a message.

r.klassen.ruit@web.de

pansa

 
TimeMaster:

If you have a large base of indulgences, owls, etc. that do not compile in new builds, then it makes sense to take a closer look and "shake your chest". You should keep all the useful stuff and spare no time to rewrite and debug it for new builds.

At a certain moment I got bored).

TimeMaster:

Real experienced programmers or those who want to become them, always follow innovations, bugs and glitches their bread. It is writing code without bugs that counts as good programming. If you don't have the energy, time, possibility or desire to grasp all the innovations of "Metakvot", use the language that you are fluent in. DLLs have not been abolished, plug in your own fine-tuned algorithms.

What do real traders or those who want to become them follow? ) The available autotrading, the main MT feature, has sunk into oblivion and got lost among constant innovations of countless builds... Autotrading options available through more serious approach to programming, let's say - "is". I myself have only a small virtually forgotten account on MT. Spent 2 hours today rehabilitating MT tools, from the looks of it I need 10 times more. Not sure if I need it, maybe I'll do it again, but more like "from old memory". Basically, I've made up my mind.

 
Figar0:

The available autotrading, the main feature of MT - has sunk into oblivion and got lost amongst the constant innovations of countless builds... The autotrading options available through more serious programming approaches are, shall we say, "there". I myself have only a small virtually forgotten account left on MT. Spent 2 hours today rehabilitating MT tools, from the looks of it I need 10 times more. Not sure if I need it, maybe I'll do it again, but more like "from old memory". Basically, I've made up my mind.

Actually, even now everything works, if you only use the old features. Some things could be done much easier and more reliable, for example, history gaps accounting: before that (mcl++) the possibility of history calculation with gaps caused some "headache" (as a consequence of history "tail" being loaded first and then the missed bars being written inside), I had to use "crutches". Everything is much simpler now. You can not use any additional features and use MKL in its former/improved form, as before. The exceptions are the programs which have gone beyond the arrays (incorrectly calculated index or not allocated memory) - those did not work guaranteed and, most likely, incorrectly before.
 
Figar0:

Got bored at some point)

Whose fault is it that somebody's got a shitload of code???

Figar0:

Basically, I've made up my mind.

Is someone trying to hold back? Lassoed and held???

 
AlexeyVik:

Whose fault is it, then, that someone's got a shitload of code???

What has shit-code got to do with it? Some fundamental things have changed
 
TheXpert:
What's the shit code got to do with it? Some fundamental things have changed
Just wondering (I use the old code, it works): which fundamental things?
1...5678910111213141516
New comment