알고리즘, 결정 방법, 성능 비교 - 페이지 14

새 코멘트
 
Sergey Dzyublik :

1. 무의미하다. 알고리즘 전체를 상대적인 결과로 비교합니다.
2. 솔루션이 이미 통합되어 있습니다. 표준 라이브러리 <Generic\ArrayList.mqh>입니다.

1. 즉, 알고리즘의 속도는 중요하지 않습니다. 솔루션은 "개념적으로 강력"하고 그것으로 충분합니다. 확인.

2. 즉, 포함을 통해 연결되고 그게 다야? 좋은.

//------------------------------------------------ --------------------

알고리즘을 평가하는 주요 기준이 " 개념적 힘 "이라면 나는 졌다.

알고리즘을 평가하는 주요 기준이 단순성, 속도 및 편의성 이면 이깁니다.

이 주제는 닫을 수 있습니다.

 
fxsaber :

  1. 인터페이스가 먼저 작성되고 그 다음에 클래스(해당 인터페이스의 상속자로서)가 작성되는 스타일인 이유는 무엇입니까?
  2. 이 작업이 수행되는 이유는 무엇입니까? (StringToUpper (생성기 이름);)
  3. 분명히 그냥 잊었어




CArrayList를 통해 수행하고 방금 논의한 HashMap을 사용하지 않았다는 사실에 다소 놀랐습니다. 거래가 티켓이 아니라 인덱스인 작가의 비뚤어진 원본에 집중할 가치가 없었습니다.

HashMap은 더 시각적이고 더 실용적이며 빠를 것입니다.


그런 코드를 쉽게 읽을 수 있다는 사실에 스스로도 놀랐습니다. 그러나 그 자신은 아직 프로그래밍에서 표시된 추상화 수준에 도달하지 못했습니다. 나에게 절차적 스타일 + OOP 동안. 이것은 순수한 OOP입니다. 분명히 이것은 잘 배운 프로그래밍 학교의 일종입니다. 나는 Stanislav Korotky에게서만 이 자원에 대해 비슷한 수준의 추상화를 보았습니다.


1) 스타일은 통합용입니다.
클래스를 테스트해야 합니다. 테스트를 위한 인터페이스를 상속하고 구현합니다.
자신의 발전기가 필요합니다 - 즐기십시오 ...


2) 예, 이것은 불필요하고 너무 영리합니다. 감사합니다.

 StringToUpper (generatorName);



3) 아니요, 잊지 않았습니다. 

       //TODO add shared_ptr / move out generator (Dependency Injection)
      IGenerator<T>* generator = CreateGenerator<T>();

그것은 원래 내가 구현하지 않은 shared_ptr 용으로 작성되었습니다.
그러나 테스트를 위해 함수 매개변수에서 IGenerator<T> 에 대한 종속성을 제거해야 합니다.

 
Sergey Dzyublik :

3) 아니요, 잊지 않았습니다.

그것은 원래 내가 구현하지 않은 shared_ptr 용으로 작성되었습니다.

알겠습니다. 눈치채지 못했습니다.

 
문자열 의 길이는 확실하지 않습니다. 최대 문자 수는 몇 개입니까?
 
Renat Akhtyamov :
문자열 의 길이는 확실하지 않습니다. 최대 문자 수는 몇 개입니까?

내가 기다리는 것은 다음과 같습니다.

문자열 길이가 유한하지 않습니까?

https://msdn.microsoft.com/en-us/library/sx08afx2.aspx

MQL5에 대한 이 제한을 찾을 수 없습니다...


 

커뮤니티에 대한 반복적인 무례함과 명백한 도발이 분명히 나타납니다.

이것을 읽지 않는 것이 항상 가능한 것은 아닙니다(다양한 건설적인 분야에 있는 사람의 게시물). 그 후에는 보지 않고 잊어버릴 수 있습니다.

도움의 손길에 트롤링 및 침 뱉기,이 자원을 긍정적 인면과 크게 구별하는 수.


아마도 내가 틀렸다.

 
Vladimir Karputov :

정정합니다. 하지만 문자열 길이가 유한하지 않습니까?

메모리에 의해서만 제한됨

 void OnStart ()
{
   string Str;
  
   Print ( StringInit (Str, 1 e8)); // true - 100 Mb
}
 
Реter Konow :

1. 즉, 알고리즘의 속도는 중요하지 않습니다. 솔루션은 "개념적으로 강력"하고 그것으로 충분합니다. 확인.

2. 즉, 포함을 통해 연결되고 그게 다야? 좋은.

//------------------------------------------------ --------------------

알고리즘을 평가하는 주요 기준이 " 개념적 힘 "이라면 나는 졌다.

알고리즘을 평가하는 주요 기준이 단순성, 속도 및 편의성 이면 이깁니다.

이 주제는 닫을 수 있습니다.


죄송합니다. 불가능합니다. 죄송합니다.
하지만 당신은 얼마나 어리석은 사람입니다.
문제는 누군가가 무언가를 모른다는 것이 아니라 최소한 무언가를 배우려는 완전한 의지가 없다는 것입니다.

10ms가 10ms인지 8ms가 다른지 차이가 무엇입니까?
누가 더 빠르고 얼마나 더 빠른지 상대적으로 비교해야한다면 작업의 정확성을 확인하는 것을 잊지 마십시오.

 
fxsaber :

메모리에 의해서만 제한됨

오오오오!!!!!

압도적 센큐!

내 문자열이 잘려서 길이를 늘리는 방법을 몰랐습니다.

가지를 부수지 말고 여기에서 다투지 말라

 

시트를 통한 솔루션 - 너무 많은 코드 .... 그러나 세부 사항을 어떻게 든 강조 표시하는 것은 불가능했습니다.

뭐, 이건 나니까 분명히 달랐다)

일반적으로 표준 라이브러리 를 사용하는 습관을 들이지 않을 것입니다. 동일한 시트의 고유한 버전을 가지고 있는 사람들이 많이 있다고 생각합니다.

일반적으로 동일한 작업

마법이 있는 시세 표시기가 옵니다. 저장한 다음 시세 또는 마법에서 편리한 방법으로 당겨야 합니다. 글쎄, 조금 복잡하게 하자 - 즉. 모든 값, 매직 티커 TR SL 주석, 시가, 시간, 종가를 저장합니다. - 가상 주문을 고려하기 위한 것이라고 가정해 보겠습니다.

사실, 가장 빠른 솔루션은 모든 정보를 구조에 저장합니다. 그리고 여기에 링크 인덱스의 정렬된 요약을 통해 액세스할 수 있습니다. 그리고 majik과 tekr에서. 저것들. 그 중 두 가지가 있을 것입니다. 기억으로는 물론 합리적이지 않습니다. 하지만 자주 주문을 받는다면 속도 면에서는 최고입니다.


그건 그렇고, 문제는 인쇄물에 정의를 사용해야하는 사람입니다. 아마도 몇 가지 솔루션이 있습니다. 간단히 말해서 자주 인쇄하는 것은 아니지만 충돌이 발생하기 전에 필요한 정보를 버리거나 이런 방식으로 편리하게 조정할 수 있으며 가급적이면 전역 변수 없이 인쇄해야 합니다.

1...789101112131415161718192021...23
새 코멘트