오류, 버그, 질문 - 페이지 2532

새 코멘트
 
Igor Makanu :

모든 것이 작동하지만 표시기 버퍼 가 될 배열은 public 수정자로 선언해야 합니다.

물론이죠.

물론 클래스 멤버에 대한 공개 접근은 좋지 않지만, 가장 큰 문제는 복사 없이 배열 데이터에 접근하는 문제가 해결된다는 점이다.

감사합니다. 문제가 해결되었습니다.

 
문제가 명확하다면 저를 도와주시겠습니까? 매머드를 프로그래밍하는 당신에게 그것은 풀잎과 같습니다...
 
Georgiy Merts :

물론 클래스 멤버에 대한 공개 접근은 좋지 않지만, 가장 큰 문제는 복사 없이 배열 데이터에 접근하는 문제가 해결된다는 점이다.

나는 YouTube에서 많은 비디오를보고, 지능형 프로그래머의 채널을 만났습니다. "코드는 우선 작업을 수행해야합니다!"라는 문구를 기억합니다.

당신은 큰 프로젝트에서 일하지 않습니까? 팀워크가 아니라? - 이 클래스 멤버가 선언된 이유를 알고 있고 컴파일러 없이 액세스를 제어할 수 있다고 생각합니까? ;)

 

@Ilyas MT4 빌드가 업데이트되었습니다.


컴파일 및 실행 후 제대로 작동하는 코드는 오류를 제공합니다.


 
Igor Makanu :

나는 YouTube에서 많은 비디오를보고, 지능형 프로그래머의 채널을 만났습니다. "코드는 우선 작업을 수행해야합니다!"라는 문구를 기억합니다.

당신은 큰 프로젝트에서 일하지 않습니까? 팀워크가 아니라? - 이 클래스 멤버가 선언된 이유를 알고 있고 컴파일러 없이 액세스를 제어할 수 있다고 생각합니까? ;)

일반적으로 메서드를 통해 클래스 멤버에 대한 액세스를 구현하고 런타임에 역참조를 줄이려면 get 메서드와 함께 인라인으로 사용하는 것이 좋습니다.
 
Igor Makanu :

나는 YouTube에서 많은 비디오를보고, 지능형 프로그래머의 채널을 만났습니다. "코드는 우선 작업을 수행해야합니다!"라는 문구를 기억합니다.

당신은 큰 프로젝트에서 일하지 않습니까? 팀워크가 아니라? - 이 클래스 멤버가 선언된 이유를 알고 있고 컴파일러 없이 액세스를 제어할 수 있다고 생각합니까? ;)

음 ... 아니.

코드는 무엇보다도 투명하고 이해하기 쉬우며 유지 관리가 쉬워야 합니다. 그런 다음 그가 임무를 수행하지 않으면 즉시 볼 수 있습니다.

그러나 코드가 잠재적으로 위험한 구성을 가진 많은 장소로 채워지면 나중에 매우 까다롭고 명확하지 않은 오류가 발생하기 때문에 "코드가 작업을 수행하고 있는지"를 결코 확신할 수 없습니다.

그리고 대규모 프로젝트에서 작업할 때 그것 없이는 아무것도 없습니다. 많은 사무실에는 표기법, 공지 사항, 공개적으로 발표할 수 있는 것과 없는 것 등에 관한 공식 지침이 있습니다. 혼자 작업할 때 실제로 클래스의 구성원을 직접 선언하고 무엇을 위해, 어떻게 사용할지 알고 있다는 것이 분명합니다. 그러나 어느 정도 복잡한 코드는 한 명의 프로그래머가 수행하더라도 아키텍처를 변경하는 경향이 있습니다. 그리고 무엇을, 어디서, 어떻게, 무엇을 위해 기억하십시오 - 나는 개인적으로 할 수 없습니다. 동시에 - 나는 상세한 주석으로 코드를 아주 관대하게 뿌립니다. 그리고 어쨌든, 6개월 후에 다른 지역으로 돌아갑니다. 저는 그것이 왜 이런 방식으로 수행되고 다른 방식으로 수행되지 않았는지 이해하는 데 상당한 시간을 할애합니다. 코멘트 없음 - 양 고추 냉이가 내 자신의 코드를 알아 냈습니다.

물론 Peter Konov처럼 기억력이 있는 경우 액세스 공유에 신경 쓸 필요가 없으며 모든 변수를 전역 변수로 껍질을 벗기고 필요할 때 필요한 모든 것을 사용할 수 있습니다. 그러나 내 기억은 훨씬 더 나빠서 일주일 안에 특정 절차의 미묘함을 잊을 수 있습니다. 따라서 저는 코드의 어느 위치에서나 여기에 필요한 만큼만 사용할 수 있어야 하며 단일 변수를 더 이상 사용할 수 없다는 원칙을 오랫동안 스스로 해결해 왔습니다. 가장 좋은 것은 모든 것을 가상 인터페이스로 감싸고 가능한 한 각 클래스의 책임 영역을 분리하는 것입니다. ).

배열에 대한 포인터가 없는 것은 더 이상 관련이 없는 배열에 대한 포인터를 실수로 사용하지 않도록 개발자가 "프로그래머에 대한 우려"로 정당화한다는 것을 상기시켜 드리겠습니다. 그러나 수업의 경우 문제가 없습니다. 글쎄, 그들은 "클래스로 작성한다면 이미 포인터를 사용할 자격이 있고 배열은 초보자도 사용할 수 있으며 배열에 대한 포인터를 사용할 때 어려움을 겪지 않기를 바랍니다. ... 포인터가 없습니다 - 그게 전부입니다"...

 
Vladimir Simakov :
일반적으로 메서드를 통해 클래스 멤버에 대한 액세스를 구현하고 런타임에 역참조를 줄이려면 get 메서드와 함께 인라인으로 사용하는 것이 좋습니다.

정확히. 그리고 나는 보통 그것에 기대고 있습니다. 저는 클래스의 public 멤버를 거의 사용하지 않습니다. 모든 곳에서 인라인 메서드를 통해서만 액세스할 수 있습니다. 이러한 표시기 배열과 같은 특별한 경우에만 public...

 
Влад :
문제가 명확하다면 저를 도와주시겠습니까? 매머드를 프로그래밍하는 당신에게 그것은 풀잎과 같습니다...

귀하의 경우 for()가 아닌 while() 루프를 구성해야 합니다.

깜박임이 끝나는 징후가 있는지 확인하십시오.

그러나 "가변 주파수로 깜박임"이라는 사실에 대해 - 뭔가 이상합니다 ... 나는 박쥐에서 즉시 오류를 볼 수 없으며 꽤 자주 깜박일 것입니다.

그러나 그래픽 개체를 보이지 않게 만드는 대신 생성하고 삭제 하는 것이 합리적인지 의심스럽습니다. 하지만 개체를 보이지 않게 하는 것은 불가능해 보이는데... 그래서 삭제하는 일만 남았습니다.

 
Georgiy Merts :

물론 Peter Konov처럼 기억력이 있는 경우 액세스 공유에 신경 쓸 필요가 없으며 모든 변수를 전역 변수로 껍질을 벗기고 필요할 때 필요한 모든 것을 사용할 수 있습니다.

나는 메모리를 훈련하지 않으며 최후의 수단으로 전역 변수 를 사용합니다. 때로는 코드가 중복되는 것처럼 보이지만 코드 섹션은 다른 프로젝트로 이식할 수 있습니다.

나는 일반적으로 긴 함수 이름과 변수 이름을 사용하므로 이전에 쓴 것을 읽을 수 있습니다.

 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);
  }
또 다른 질문은 제가 이상적인 OOP 스타일을 고수하지 않는다는 것입니다. 저는 모든 것을 클래스로 묶지 않습니다. 하나의 프로그램에서 절차적 스타일과 OOP를 동시에 사용합니다. 누락 된 기성품 블록의 프로그램, 작업을 위해 완성 된 블록을 추가하거나 수정합니다.
 
Vladimir Simakov :
런타임에 역참조를 줄이려면 get 메소드와 함께 인라인을 사용하십시오.
인라인은 제 생각에 보류입니다. 컴파일러 자체가 모든 것을 완벽하게 인라인하므로 코드를 복잡하게 만들 필요가 없습니다. 이 모든 저수준 가젯은 과거로 남겨 둘 수 있습니다. 그리고 MQL에서 이 지정자는 일반적으로 비어 있으며 순전히 호환성을 위해 추가되었습니다(왜 그런 매크로를 직접 선언할 수 있었는지 모르겠습니다)
1...252525262527252825292530253125322533253425352536253725382539...3184
새 코멘트