Errors, bugs, questions - page 2532

New comment
 
Igor Makanu:

everything works, but arrays which will be indicator buffers should be described with modifier public

Yes, of course.

Of course, the public access to the class members is not good, but the main problem - the access to the array data without copying is solved.

Thank you, the issue is clarified.

 
If the question is figured out, can you help me? For you mammoths of programming, it's like a reed...
 
Georgiy Merts:

Of course, public access to class members is not good, but the main problem - access to array data without copying is solved.

I watch a lot of videos on YouTube, I came across a channel of an intelligent programmer, and I remember the phrase: "the code must, first of all, perform its task!

You do not work on a large project, do you? - You know why this class member is defined and you may control access to it without the help of the compiler, don't you? ;)

 

@Ilyas,updated build of mt4


code that worked fine after compiling and running errors


 
Igor Makanu:

I watch a lot of videos on YouTube, I came across a channel of a good programmer, and I remember the phrase: "the code must, first and foremost, fulfil its task!

You don't work on a large project, do you? - You know why this class member is defined and you may control access to it without the help of the compiler, don't you? ;)

Actually access to class members is better to be implemented through methods and to have less dereferencing in run-time, use inline with get methods.
 
Igor Makanu:

I watch a lot of videos on YouTube, I came across a channel of a good programmer, and I remember the phrase: "the code must, first and foremost, fulfil its task!

You don't work on a large project, do you? - You know why this class member is defined and you may control access to it without the help of the compiler, don't you? ;)

NO.

First of all, the code must be transparent and understandable, easy to maintain. And then if it fails to perform its task, it will be immediately visible.

But when code is filled with a lot of places with potentially unsafe constructs which cause very subtle non-obvious errors you can never be sure that "the code fulfills its task".

And when working on a large project you can not do without it at all, in many companies there are official guidelines regarding notation, declarations, what can and can not be declared as shares and so on. Of course, when you work alone, you declare a class member, you know what it's for and you know how you're going to use it. Except that any code, however complex, even when done by one programmer tends to change architecture. And I personally cannot remember what, where, how and for what. At the same time I generously overload the code with detailed comments. And still, coming back to other fragments after half a year I spend quite a lot of time to understand why it was done so and not in a different way. Without comments I wouldn't be able to understand my own code at all.

Of course, if you have Peter Konov's memory you don't have to worry about sharing access, make all variables global - and use everything you need, whenever you want. However, my memory is much worse, and I can already forget subtleties of a procedure in a week. Therefore I have long ago developed a principle that in any place of code there must be available exactly as much as I need here and not a single variable more. The best way is to convert everything into virtual interfaces and divide responsibility areas of each class as much as possible (but of course there must be a measure, so as not to deal with these wrappers more than with useful code).

Recall that the lack of pointers to arrays the developers justify "taking care of programmers", so that you don't accidentally use a pointer to an array that's no longer relevant. No problem for classes though. Well, they explained that "if you write with classes, you're already skilled enough to use pointers, while arrays are available to beginners, and we don't want them to have problems when they want to use pointers to arrays... no pointers, that's it"...

 
Vladimir Simakov:
Generally, it is better to implement access to class members via methods, and to avoid dereferencing in run-time, use inline with get methods.

That's right. And I'm usually inclined to do it. In general, I rarely use public class members, all access is via inline-methods. Only in special cases, as with these indicator arrays I have to use public...

 
Влад:
If the issue is figured out, can you help me out? For you mammoths of programming, it's like a moth...

In your case, organise a while() loop rather than a for() loop.

Check for some sign of end of blinking.

But about "blinking with variable frequency" - something strange... I don't see any errors on the fly, it should blink quite often.

Although, I doubt that it's wise to create and delete graphical objects instead of making them invisible. But, it seems you can't make an object invisible... So all that's left is deleting.

 
Georgiy Merts:

Of course, if you have a memory like Peter Konov's, you don't have to worry about access separation, make all variables global - and use everything you need, whenever you want.

I never train memory, use global variables only as a last resort, the code sometimes even seems redundant to me, but code fragments are portable to another project,

I usually use long function and variable names, so I can read what I've written before:

void CGrid::Scenario_01(int ordernumber)//------ Сценарий ReOpenBUY & ReOpenSELL
  {
   int set         = Order[ordernumber].StateOrderNumberSetting;
   double pr       = Order[ordernumber].StateOrderStartPrice;
   double vol      = Order[ordernumber].StateOrderLot;
   double volcoeff = dealssettings[set].volcoeff;
   double profit,openprice;
   Order[ordernumber].GetCloseOrderInfo(profit,openprice);
   double l=CalcLot(dealssettings[set].volratio,vol,volcoeff,profit);
   deal=new Cdeal(set,dealssettings[set].dealtype,l,pr,dealssettings[set].closepips,magic);
   Order.Delete(ordernumber); 
   Order.AddValue(deal);
  }
Another issue is that I do not adhere to OOP style - I do not wrap everything into classes, I use both procedural and OOP styles in one program simultaneously, it is more convenient and faster to form a program from ready-made blocks, whatever is missing I add or modify ready-made to the task
 
Vladimir Simakov:
and for less dereferencing in run-time, use inline with get methods.
Inline is a relic, in my opinion. The compiler inlines everything perfectly, so there is no need to overload the code. And in MQL this specifier is nothing at all, added only for compatibility purposes (I don't know what for, if one could declare such a macro by oneself).
1...252525262527252825292530253125322533253425352536253725382539...3190
New comment