Goodbye robot - hello marasmus - page 11

New comment
 

Regarding hiding the variable name:

simpleton already wrote about intel compiler, similar situation with gcc and clang. When compiling in a very strict mode (in terms of message presence):

gcc(clang) -Wall -Wextra

the compiler does not complain about this issue. Complaints about hiding are activated with a separate option -Wshadow. I.e. the check itself is not difficult on c++ compilers (except MSVC). But I haven't seen any ide (based on gcc, for example, qt creator, code blocks ...) where -Wshadow is activated by default.

Why? Probably because for most people the usefulness of this message is questionable.

 
Pavlick:

Regarding hiding the variable name:

simpleton already wrote about intel compiler, similar situation with gcc and clang. When compiling in very strict mode (in terms of message presence):

You seem to confuse the misleading "strict compiler mode" and actual work of static analyzers, as you have never used them.

The compiler completes the compilation in 1-2 minutes, while analyzers will work for several hours (PVS Studio) or dozens of hours (CPP Check) on the same code. Hence such different quality and depth of results.

 

Greetings all.

It's been almost a year since the "crazy" and marasmus of innovations in MQL4 hasn't stopped. "But it's still there! (с).

Before they used to blame "Metaquotes" for poor language, now they blame them for excessive "water". The problems have not diminished.

I can add the following from me.

For traders, non-programmers and novice programmers, a simple algorithm and code can be implemented.

If you have a large base of indices, owls, etc. that do not compile in the new builds, then it makes sense to look closely and "shake up your coffers". Make sure to save the most useful things and don't spare time to rewrite and debug them for new builds.

Real experienced programmers or those who want to become them, always follow innovations, bugs and glitches are 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.

 
Andrei01:

Test environments are widely used in software products for functional verification of software chip designs, where the requirements to the code quality are very high. Moreover, a functional shell is an integral part of any chip design code development. 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 saves time of debugging and code verification.

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

Test environments are test environments. A test environment is "confined" to the product it is testing.

I meant general tools - those which "have no idea" about the product being analyzed and therefore can analyze and find issues in any product.

 
Renat:

Simpleton, what nonsense.

"What nonsense" seems to imply a complete mismatch of attitudes.

Renat:

When you get to the level of total quality control, only then you will understand it. But meanwhile, as long as you remain at the level of perception of a single selfish programmer, you will continue to think "it is reasonable not to control me, let the control will be by separate never run utilities".

So why does "total quality control" allow such a low level of quality control?

For example:

#property strict

/******************************************************************************/
class A {
private:
  A() { Print("A::A()"); }

public:
  static void method1() {
    //A a; // 'A::A' - cannot call private member function      3.mq4   10      7
  }

  static void method2() {
    A *a = new A; // А здесь private member function великолепно вызывается
    delete a;
  }
};

/******************************************************************************/
void OnStart() {
  A::method1();
  A::method2();
}

The constructor is called when an object is created in method2:

00:50:23 Script 3 EURUSDm,M5: loaded successfully
00:50:23 3 EURUSDm,M5: initialized
00:50:23 3 EURUSDm,M5: A::A()
00:50:23 3 EURUSDm,M5: uninit reason 0
00:50:23 Script 3 EURUSDm,M5: removed

Why is everything fine when an object is dynamically created, i.e. the private constructor is available from the object method, but when the object is automatically created, the private constructor is suddenly unavailable?

I personally gave up doing anything a little more complicated than simple in MQL, because it's very difficult for me: I'm always bumping into something that doesn't work.

But I don't have such problems with C/C++ compilers.

And the problem "it is reasonable not to control me, let the control be separate never run utilities" is directly related to psychology. Here psychology needs to be corrected so that the programmer can force himself, rather than trying to adjust the technology to the psychology in order to circumvent this psychology.

I don't make it up, some utilities are successfully used on a regular basis in front of me, and the result of their work is also successfully used later to eliminate bugs.

Renat:

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

Perhaps the priorities are shifted towards adding and improving at the expense of quality. But then it is no longer a total control of it.

Renat:

On Friday there will be a release of MT4 with clear improvements in execution speed and testing.

In this case I mean the availability of private constructor from object methods not only for the case of dynamic object creation - will there be any improvements in language operability?

Renat:

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

Ok, let's assume that "C++ is dangerous and suicidal" and "MQL is absolutely safe".

Why would one take as a basis for MQL a language that is so far from the criterion of security from what one wanted, that is, to create a "absolutely safe" language based exactly on the "dangerous and suicidal" one?

 
Pavlick:

OK?


Hi, Pavlik!

it's me again panza!

I've been testing your code to call the script on different mt4

and i found out some strange things!

Your code works fine on MT4 build 670 by Pepperston

(Australia), but it does not want to work on MT4 build 670 Alpari!

user32.dll iscalledstrangelyon alpari!

First 2 dlls are called (although this was not in the code!)

thenuser32.dllis called,but it gets thrown into a library!

but you also need to call it from the library!

It seems that Alpari is struggling with the call.

i.e. there is an obvious code interference!

I attach 2 pictures for comparison!

i wish success!

Panza

oo-bild zu gross!

MT4-Pepperstone-user32.dll

MT4-Alpari-KERNEL32.dll,GDI.dll,E:\metaQuotes\Terminal\F................OBO\MQL4\Libraries\user32.dll

















 
simpleton:

"What nonsense" - this apparently means a complete mismatch of positions.

This means that someone is knowingly more experienced at directing the release of multiple software products to a competing market.


Why does "total quality control" allow for such a low level of quality control?

There is no need to move from a discussion of general quality control principles to the specific shortcomings of a particular solution. Such a method is unacceptable, because it is always possible to find any flaw in any product.

For example:

The constructor is called when an object is created in method2:

Why is everything fine when an object is dynamically created, i.e. private-constructor is available from object method, but when an object is automatically created, private-constructor is suddenly unavailable?

This is just a consequence of over-protection"static classmethod has no right to get into class contents". In this case, though, the access control needs to be loosened.

I personally have given up doing anything slightly more complex than simple in MQL, because it's very difficult for me: I'm always bumping into something that doesn't work.

Give me a working example, not a case of "I twisted things up on purpose, closed accesses and then started appealing to borderline behavior".


I don't have such problems with C/C++ compilers, though.

The problems there are of a different kind. And they are knowingly greater by orders of magnitude if you take into account that you don't use static analyzers.


And the problem "it is reasonable not to control me, let the control be separate never run utilities" is directly related to psychology. Here psychology needs to be corrected so that the programmer can force himself, rather than trying to adjust the technology to the psychology in order to circumvent this psychology.

I don't make it up, individual utilities are successfully used on a regular basis before my eyes, and the result of their work is also successfully used afterwards to eliminate bugs.

Perhaps the priorities are shifted towards adding and improving at the expense of quality. But then it is no longer a total control of it.

It is already just a word game. Your position has already been clearly outlined earlier "I cannot be controlled", so yes "in front of someone, somewhere is using, but no one is standing over me with a stick and I am not using".


And improvements in terms of language operability - in this case I mean availability of private constructor from object methods not only for the case of dynamic object creation - will it already have?

And you like to make deliberate tripping devices in your "simple" programs: "I'll hide the constructor in private, create a static method and then use it to chisel into the hidden constructor"?


Ok, let's assume that "C++ is dangerous and suicidal" and "MQL is absolutely safe".

Why would one take a language so far from the criterion of safety as the basis for MQL, that is, create "absolutely safe" language on the basis of the very "dangerous and suicidal" one?

Are you able to come up with a "different basis" for a generic language?

So that every other programmer can be given the language and start writing in it with pleasure after a couple of hours and not throw it away in disgust and scolding? Traders have looked at the Easy Language and threw it away, while MQL4/MQL5 are being used and developed with great pleasure.

Most commonly used languages are based on the basic principles of constructs as in C/C++. So we took the well-known framework, removed the most dangerous things with links, added DRM and received a secure and safe language.

As a result, we are on the up and the competitors are going in the wrong, but cheaper, directions, as they think.

 
Renat:
It means that someone has more experience in managing the release of a lot of software products in a competitive market.

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. Management experience does not guarantee against mistakes. Even if one has experience in an area, one can still make mistakes. On the subject of the competing market, or rather competitors, at the very end.

However, in this case, it is not a question of experience in many software products, but of the quality of the product and, in particular, the compiler and the tools and methods of achieving high quality.

Renat:
We shouldn't move the discussion from general quality control principles to specific flaws in a particular solution. You can't do this because you are always likely to find every flaw in every product.


This is just a consequence of overprotection "static class method has no right to get into class contents". Although in this case we need to loosen access control.

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.

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 this right?

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

#property strict

/******************************************************************************/
class A {
private:
  A() { Print("A::A()"); }
  ~A() { Print("A::~A()"); }

public:
  void method() { // Метод - обычный, никакой не статический
    A a;
  }

};

/******************************************************************************/
void OnStart() {
}

Same errors:

'3.mq4' 3.mq4   1       1
'A::~A' - cannot call private member function   3.mq4   11      7
'A::A' - cannot call private member function    3.mq4   11      7
2 error(s), 0 warning(s)                3       1

OK, let's consider a prohibition on "climbing into the contents of the class":

#property strict

/******************************************************************************/
class A {
private:
  A() { Print("A::A()"); }
  ~A() { Print("A::~A()"); }
  A(const A &a) { Print("A::A(const A &)"); }
  void operator =(const A &a) { Print("A::operator =()"); }
  void f() { Print("A::f()"); }

public:
  static void assign(A &l, const A &r) {
    l = r;
  }

  static void method() {
    A *p = new A, b(p);

    b = p;
    b.f();
    delete p;
  }

};

The object b is created by calling the copy constructor, then an assignment is performed by calling "operator =", method f() is called, and all these constructors, operators and methods are private, which means that the static method method() is allowed to "fondle the class":

00:59:18 Script 3 EURUSDm,M5: loaded successfully
00:59:18 3 EURUSDm,M5: initialized
00:59:18 3 EURUSDm,M5: A::A()
00:59:18 3 EURUSDm,M5: A::A(const A &)
00:59:18 3 EURUSDm,M5: A::operator =()
00:59:18 3 EURUSDm,M5: A::f()
00:59:18 3 EURUSDm,M5: A::~A()
00:59:18 3 EURUSDm,M5: A::~A()
00:59:18 3 EURUSDm,M5: uninit reason 0
00:59:18 Script 3 EURUSDm,M5: removed

Let's look at another example, very close to the first one:

#property strict

/******************************************************************************/
class A {
private:
  A(int i = 0) { Print("A::A(int i = ", i, ")"); }
  ~A() { Print("A::~A()"); }
public:

  static void method() {
    A a;
  }
};

/******************************************************************************/
void OnStart() {
  A::method();
}

Compilation error, - both constructor and destructor are unavailable:

'3.mq4' 3.mq4   1       1
'A::~A' - cannot call private member function   3.mq4   11      7
'A::A' - cannot call private member function    3.mq4   11      7
2 error(s), 0 warning(s)                3       1

Now, without changing anything at all, initialize the a variable with a value different from the default value in the constructor:

#property strict

/******************************************************************************/
class A {
private:
  A(int i = 0) { Print("A::A(int i = ", i, ")"); }
  ~A() { Print("A::~A()"); }
public:

  static void method() {
    A a(1);
  }
};

/******************************************************************************/
void OnStart() {
  A::method();
}

Now the example compiles and executes:

00:20:35 Script 3 EURUSDm,M5: loaded successfully
00:20:35 3 EURUSDm,M5: initialized
00:20:35 3 EURUSDm,M5: A::A(int i = 1)
00:20:35 3 EURUSDm,M5: A::~A()
00:20:35 3 EURUSDm,M5: uninit reason 0
00:20:35 Script 3 EURUSDm,M5: removed

How did a static method suddenly become allowed to "get into the contents of the class"?

It's pretty obvious that this is not an "over-protection" in this case, but a trivial bug. Total quality control is a rather loud statement, but facts are stubborn things.

Renat:
Give a working example, not a case of "I twisted things up that way on purpose, closed accesses, and then started appealing to boundary behaviour".

Please, a classic singleton, namely the Myers singleton described in the C++ example section of the link:

class OnlyOne
{
public:
        static const OnlyOne& Instance()
        {
                static OnlyOne theSingleInstance;
                return theSingleInstance;
        }
private:        
        OnlyOne(){};
        OnlyOne(const OnlyOne& root);
        OnlyOne& operator=(const OnlyOne&);
};

It even translates into MQL4++ with the newly opened feature:

#property strict

/******************************************************************************/
class OnlyOne
{
public:
        static OnlyOne *Instance()
        {
                static OnlyOne theSingleInstance(1);
                return GetPointer(theSingleInstance);
        }
private:        
        OnlyOne(int i = 0) { Print("Создан"); };
        ~OnlyOne() { Print("Уничтожен"); };
        OnlyOne(const OnlyOne &);
        void operator=(const OnlyOne &);
};

/******************************************************************************/
void OnStart() {
  OnlyOne *p = OnlyOne::Instance();
}

It compiles and executes:

01:31:49 Script 3 EURUSDm,M5: loaded successfully
01:31:49 3 EURUSDm,M5: Создан
01:31:49 3 EURUSDm,M5: initialized
01:31:49 3 EURUSDm,M5: uninit reason 0
01:31:49 3 EURUSDm,M5: Уничтожен
01:31:49 Script 3 EURUSDm,M5: removed

Attempts to create an object in any way other than calling OnlyOne::Instance() will result in a compilation error.

And on the subject of "I twisted things up so deliberately, closed accesses, and then started appealing to boundary behaviour" - was anything used improperly?

There are mechanisms in the language - I have the right to use it as I want within the limits allowed by the language. At least that's how it is with C++ compilers.

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

Renat:
And do you like putting deliberate footsteps in your "simple" programs "hide constructor in private, create static method and then chisel into hidden constructor from it"?

It's not about what I like or don't like. There's a tool. Why should I refuse to use all its capabilities?

It's not even "I like it" in this case. It's Myers, for that matter, who likes it so much. And somehow no one tries to accuse him of trying to "deliberately trip up" C++ compilers.

Renat:
Are you able to come up with a "different framework" for generic languages?

So that every other programmer could be given a language and start writing in it with pleasure after a couple of hours and not throw it away with disgust and scolding? Traders have looked at the Easy Language and threw it away, while MQL4/MQL5 are happily used and developed.

Most widespread languages are based on the basic principles of constructs as in C/C++. So we've taken a familiar framework, removed the most dangerous things with references, added DRM and got a secure and safe language.

As a result, we are on the top, while our competitors are going in the wrong direction, but cheaper, as they think.

It's not an easy task and cannot be solved right off the bat. You need to put some effort here, and a lot of it. The vast majority of MQL users are not programmers. 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 absence of "cleverness" of the language. This is not the case now. And there are much more errors in compiler implementation, because MQL4++ is much more complicated than the old MQL4 and the development team has hardly changed much.

Renat:
As a result we are on the upside while our competitors are going in the wrong direction, but cheaper, as they believe.

Here's where I agree with you, but I think it's mainly because the competitors are doing incomprehensible things.

 
Renat:
This means that someone is knowingly more experienced in directing the release of many software products to the competing market.


We don't need to shift the topic from discussing general quality control principles to specific flaws of a particular solution. Such a method is unacceptable, because it is always possible to find any flaw in any product.

This is just a consequence of over-protection "a static class method has no right to get into the contents of the class". Although in this case we need to loosen the access control.

Give us a working example, not a case of "I twisted everything on purpose, locked accesses, and then appealed to boundary behavior" type.


The problems there are of a different kind. And they are knowingly greater by orders of magnitude if you take into account that you don't use static analyzers.


This is just wordplay already. Your position has already been clearly outlined earlier "I can't be controlled", so yes "in front of someone, somewhere using, but no one is standing over me with a stick and I'm not using".


Do you like to put deliberate footsteps in your "simple" programs "hide constructor in private, create static method and then chisel into hidden constructor from it"?


Are you able to come up with a "different basis" for commonplan languages?

So that every other programmer can be given a language and start writing in it with pleasure after a couple of hours and not throw it away in disgust and scolding? Traders have looked at the Easy Language and threw it away, while MQL4/MQL5 are happily used and developed.

Most widespread languages are based on the basic principles of constructing as in C/C++. So we took the well-known framework, removed the most dangerous things with links, added DRM and got a secure and safe language.

As a result, we are on the top, while our competitors are going in the wrong direction, but cheaper, as they think.

 

Hello forum members!

I would like to take advantage of Renate's presence on this thread

I would like to make some suggestions for improving MT4!

Everyone knows over time MT4 works worse and worse.

then it does not obey the mouse - finito!

We need to move to a new MT4 and remove

all the stuff (indicators, eXperts)!

This is a day-long job!

Although now there are repair programs for DLL, Drever and others ...

Why not make a compiler for MT4?

You have to have 2 МТ4 (one a valid and the other one a working one)

and periodically compare them and correct errors in the working MT4.

The second suggestion is to build not only price charts but

produce price multiplied by volume growth charts!

that way you would be immediately visible what is going on (real trading or cashing

stopes)

i think it's easy for people with high level of understanding!

Panza

1...45678910111213141516
New comment