내 접근 방식. 코어 - 엔진. - 페이지 4

새 코멘트
 
OOP는 커널의 구현을 방해하지 않습니다. 오히려 그 반대입니다.
일반적으로 코드와 데이터가 있습니다. 우리의 경우 핵심은 데이터와 강력하게 분리된 코드입니다. 코드 자체를 데이터로 사용할 수도 있습니다. 커널은 일반적으로 특정 데이터 또는 최소한 자급자족할 수 있는 작업을 위한 더 완전한 기능을 가지고 있습니다.
이 접근 방식을 사용하면 가장 편리한 데이터 형식을 사용할 수 있으며 많은 데이터가 있을 것으로 가정합니다.
다음은 이 접근 방식을 적용할 수 있는 또 다른 예입니다. 어드바이저에 많은 전략이 있고 전략의 논리만 데이터 역할을 하며 핵심은 이를 관리하고 특히 주문 , 위험, 거래를 관리하는 기능입니다. 환경, 표시기, 오류 처리, 통계를 개별적으로 또는 집합적으로 표시, 후행/그리드/.....
 

Реter Konow :

배열을 만들고 생성하려는 버튼의 속성 값을 씁니다.

버튼은 Base, Text, Image의 세 가지 개체로 구성됩니다.

각 개체는 Button 요소 내부에 있으므로 배열은 2차원이어야 합니다.

그리고 배열을 사용하여 이러한 변태를 수행하는 이유는 무엇입니까? 이를 위해 구조를 사용할 수 있고 사용해야 합니다. 쉼표로 구분된 값으로 같은 방식으로 초기화됩니다. 그리고 이러한 값은 사람이 액세스할 수 있습니다. 필드 이름으로 액세스할 수 있으며 인덱스를 통해서는 액세스할 수 없습니다(많은 어리석은 실수로 가득 차 있음).

결과적으로 2차원 배열 대신 구조 배열이 생깁니다. 선언의 간결함은 동일하지만 편의성과 신뢰성이 훨씬 더 높고 메모리를 합리적으로 사용하기 때문에 각 필드에는 고유한 유형이 있습니다. 글쎄, OOP는 그것과 전혀 관련이 없습니다.

다음은 예입니다.

 struct TObject { char type;   string name;   int x;   int y;   int width;   int height;   color clr; };

TObject Objects[]= { { OBJ_BITMAP , "Bitmap" , 100 , 100 , 200 , 200 , clrRed },
                     { OBJ_BUTTON , "Button" , 150 , 150 , 50, 10 , clrWhite },
                   };
 
Alexey Navoykov :


결과적 으로 2차원 배열 대신 구조의 배열이 생깁니다 . 선언의 간결함은 동일하지만 편의성과 신뢰성이 훨씬 더 높고 메모리를 합리적으로 사용하기 때문에 각 필드에는 고유한 유형이 있습니다. 글쎄, OOP는 그것과 전혀 관련이 없습니다.


여기에서 두 가지 방법으로 .. 구조의 배열 또는 배열 구조 중 어느 것이 더 낫습니까?

그러나 MQL은 Fortran 어레이와 함께 작동하도록 설계되었습니다.

 
Maxim Kuznetsov :

여기에서 두 가지 방법으로 .. 구조의 배열 또는 배열 구조 중 어느 것이 더 낫습니까?

어떤 종류의 배열 구조에 대해 이야기하고 있습니까? 작성자는 배열만 가지고 있습니다.

 

Peter는 Visual C ++에서 DialogBox 템플릿이 어떻게 생성되는지 본 적이 없다고 생각합니다. Visual 모드에서는 Button, CheckBox, EditBox, ComboBox 등과 같은 모든 컨트롤이 거기로 드래그됩니다.

즉, 필드와 행을 조정할 수 있는 DB 행을 표시하기 위한 다양한 옵션을 포함하여 Windows에 있는 요소입니다.

그리고 MFC를 사용하면 아주 복잡한 대화 상자를 몇 분 만에 아주 간단하게 만들 수 있습니다.

 
Alexey Navoykov :

그리고 배열을 사용하여 이러한 변태를 수행하는 이유는 무엇입니까? 이를 위해 구조를 사용할 수 있고 사용해야 합니다. 쉼표로 구분된 값으로 같은 방식으로 초기화됩니다. 그리고 이러한 값은 사람이 액세스할 수 있습니다. 필드 이름으로 액세스할 수 있으며 인덱스를 통해서는 액세스할 수 없습니다(많은 어리석은 실수로 가득 차 있음).

결과적으로 2차원 배열 대신 구조 배열이 생깁니다. 선언의 간결함은 동일하지만 편의성과 신뢰성이 훨씬 더 높고 메모리를 합리적으로 사용하기 때문에 각 필드에는 고유한 유형이 있습니다. 글쎄, OOP는 그것과 전혀 관련이 없습니다.

다음은 예입니다.

좋은 솔루션입니다. 그러나 이 구조는 Core에 통합될 수 없습니다. 내 기술에 따라 Core를 빌드할 때 요소 프로토타입이 있는 배열을 반복하고 Core에서 다시 작성해야 하는 경우 결정의 경우 루프가 불가능합니다.

가능할 수도 있지만 각 요소를 별도의 구조로 래핑하려면 ... 그리고 이것을 전역 범위로 가져 오는 방법은 무엇입니까? 이 모든 것을 선언할 위치는 ... 명확하지 않습니다.

저에게는 모든 것이 간단합니다. 요소 프로토타입의 배열입니다. 내부 에 있는 개체의 모든 속성입니다 . 배열 자체는 전역적입니다. 액세스는 프로그램의 어느 곳에서나 가장 간단합니다.

 
그리고 복식을 사용할 때 장이 저항하지 않습니까? 결국 자체 메서드가 있는 복합 개체이기도 합니다. 그들은 정통 코어 어레이에서 설 자리가 없습니다! 보세요, 인상적입니다(가수, 지수, 기호). 
_NEW_OBJECT, тра-та-та-та-та-та, 3 , 10 , 1 , тра-та-та-та-та-та
 
pavlick_ :
그리고 복식을 사용할 때 장이 저항하지 않습니까? 결국 자체 메서드가 있는 복합 개체이기도 합니다. 그들은 정통 코어 어레이에서 설 자리가 없습니다! 보세요, 인상적입니다(가수, 지수, 기호).

아무것도 이해하지 못했습니다.

 

불필요한 구문을 제거하고 탬버린과 함께 춤을 추고 전역 프로토타입 배열의 요소 속성을 초기화하기만 하면 됩니다.

Core에서 요소 프로토타입을 다시 작성할 때 한 번만 사용됩니다.

재작성은 간단한 루프에서 수행됩니다.

결과적으로 구성 단계에서 Core는 사용자가 선택한 요소의 프로토타입을 포함하기 시작합니다.

또한 Core에서 새로운 주기가 시작됩니다. 그 안에 요소의 속성에 대한 사용자 정의 값을 씁니다.

결국 모든 요소가 포함된 기성품 사용자 창을 포함하는 완성된 Core를 얻습니다.

 

위에서 설명한 프로세스를 "커널 빌드 프로세스"라고 합니다.

커널을 빌드한 후 "엔진"이 작동하기 시작합니다.

엔진은 요소의 역학을 제어하는 코드입니다.

엔진은 Core에서만 작동하도록 설계되었습니다. 엔진은 다양한 이벤트(대부분 OnChartEvent() 에서 발생)입니다.

1234567891011...184
새 코멘트