MQL5의 OOP에 대한 질문 - 페이지 45

[fxsaber]

Dmitry Fedoseev :

그리고 누군가 이 필드 초기화가 무엇인지 설명합니다.

이것보다 더 나은:

그리고 어쨌든, 요점이 무엇입니까?

const 필드를 초기화할 수 있습니다.

[Vladimir Simakov]

Dmitry Fedoseev :

그리고 누군가 이 필드 초기화가 무엇인지 설명합니다.

이것보다 더 나은:

그리고 어쨌든, 요점이 무엇입니까?

첫 번째 경우에는 초기화가 있고 두 번째 경우에는 기본 초기화 필드에 대해 이미 작업이 수행됩니다. 따라서 여기에서는 차이 없이 컴파일러에 따라 달라지거나 런타임에 추가 작업이 많이 발생합니다. 플러스에서 두 번째 옵션은 나쁜 형태로 간주됩니다.

[Vladimir Simakov]

= 연산자는 예상대로 r-값(5<(val=7) 작동)을 반환하지만 전송 의미 체계와 함께일 뿐이며 여기에는 없지만 슬프게도 질문을 받았습니다. 그래서 전송 생성자가 없습니다.

[[삭제]]

Igor Makanu :

순전히 이론적인 질문.

아마도 SB에서 다음과 같은 생성자 호출을 보았습니다.

이 코드의 차이점은 무엇입니까?

나는 그것을 인쇄했지만 차이점을 보지 못했습니다. 그리고 조금 더 구체적으로 - 객체 a1 및 a2의 생성자에 대한 강제 호출을 사용할 수 있는 이유 또는 제공하는 것은 무엇입니까?

첫 번째 옵션의 "편의성"은 무엇입니까?

첫 번째 옵션은 - 값 초기화, 두 번째 옵션은 기본 초기화입니다. 개체의 유형(집합인지 여부, 기본 생성자가 있는 ...)에 따라 미묘함과 차이점이 있습니다. 예를 들어 대괄호를 사용할 때와 사용하지 않을 때 완전히 다른 결과가 나타납니다.

#include <iostream>
using namespace std;
struct S {
         int i;
         int q;
         int f;
};
struct Q : S {
        Q():S() {}
         //Q() {}
};
int main() {
        Q s;
        cout << s.i << s.q << s.f << endl;
}

이론에 대해 자세히 알고 싶다면 여기 https://en.cppreference.com/w/cpp/language/initialization

추신: µl의 경우 이 모든 것이 관련이 있는 것은 아니지만 참조 모델을 이해하기 위한 것입니다.

[Igor Makanu]

Vict :

이론에 대해 자세히 알고 싶다면 여기 https://en.cppreference.com/w/cpp/language/initialization

아직은 필요없지만 저장해둘께요 출처를 어디서 봐야하는지 알겠습니다

모두 감사합니다!

블라디미르 시마코프 :
플러스에서 두 번째 옵션은 나쁜 형태로 간주됩니다.

내가 겪었던 것과 동일한 문제가 있을 것입니다. 클래스에서 둘 이상의 생성자를 작성해야 할 때 필드 초기화 코드가 중복됩니다.

두 번째 옵션을 사용하면 반복되는 코드를 별도의 메서드에 넣을 수 있으며 이 메서드는 각 생성자에서 필요한 작업을 수행한 후 호출할 수 있습니다. 이 구조의 데이터가 기록되는 파일(백업 스토리지))

반복되는 코드를 작성하는 것은 좋지 않습니다... 흥미롭지는 않지만 문제는 클래스에 새 필드를 추가하면 생성자가 있는 횟수만큼 이 필드를 초기화하는 것을 기억해야 한다는 것입니다. 불편한게 포인트가 아니라 N번 하다보면 잊어버릴 수 있다는게 문제임호

[Vladimir Simakov]

Igor Makanu :

아직은 필요없지만 저장해둘께요 출처를 어디서 봐야하는지 알겠습니다

모두 감사합니다!

내가 겪었던 것과 동일한 문제가 있을 것입니다. 클래스에서 둘 이상의 생성자를 작성해야 할 때 필드 초기화 코드가 중복됩니다.

두 번째 옵션을 사용하면 반복되는 코드를 별도의 메서드에 넣을 수 있으며 이 메서드는 각 생성자에서 필요한 작업을 수행한 후 호출할 수 있습니다. 이 구조의 데이터가 기록되는 파일(백업 스토리지))

반복되는 코드를 작성하는 것은 좋지 않습니다... 흥미롭지는 않지만 문제는 클래스에 새 필드를 추가하면 생성자가 있는 횟수만큼 이 필드를 초기화하는 것을 기억해야 한다는 것입니다. 불편한게 포인트가 아니라 N번 하다보면 잊어버릴 수 있다는게 문제지 IMHO

매개변수가 될 수 있는 매크로입니다. 잊기 위해 (나 자신이 고통받습니다), 이것은 또한 치료됩니다)))).

[[삭제]]

Igor Makanu :

내가 겪었던 것과 동일한 문제가 있을 것입니다. 클래스에서 둘 이상의 생성자를 작성해야 할 때 필드 초기화 코드가 중복됩니다.

두 번째 옵션을 사용하면 반복되는 코드를 별도의 메서드에 넣을 수 있으며 이 메서드는 각 생성자에서 필요한 작업을 수행한 후 호출할 수 있습니다. 이 구조의 데이터가 기록되는 파일(백업 스토리지))

반복되는 코드를 작성하는 것은 좋지 않습니다... 흥미롭지는 않지만 문제는 클래스에 새 필드를 추가하면 생성자가 있는 횟수만큼 이 필드를 초기화하는 것을 기억해야 한다는 것입니다. 불편한게 포인트가 아니라 N번 하다보면 잊어버릴 수 있다는게 문제임호

자, 모든 것이 해결되었습니다.

 class Q {
     void ctr_base(T t, S s) { //make init tasks
        }
public :
    Q(T t, S s, int i) {
         // make base init
        ctr_base(t, s);
         // make additional tasks
        ...
    }
    Q(T t, S s, strint str) {
         // make base init
        ctr_base(t, s);
         // make additional tasks
        ...
    }
};

나는 기본 생성자(또는 기본 초기화)에 반대하지 않지만 생성자가 개체(무한 집계가 아닌 경우)를 무기한 상태로 두고 목발을 통해 미리 초기화하면 모든 것이 잘못되었습니다.

추신: 그건 그렇고, 프로에서는 위임 생성자를 가질 수 있지만 충분하지 않습니다. 물론

 class Foo {
public : 
  Foo( char x, int y) {}
  Foo( int y) : Foo( 'a' , y) {} // Foo(int) delegates to Foo(char,int)
};

[Igor Makanu]

Vict :

자, 모든 것이 해결되었습니다.

나보다 조금 앞서서 PC에만 앉아

@Vladimir Simakov 가 매크로를 사용하여 클래스 필드를 초기화하라는 조언은 올바르게 초기화하는 것을 잊지 않도록 하는 것입니다. 글쎄요, 좋은 트릭이지만 필드를 초기화하는 메서드를 호출하는 것과 유사하게 코드를 읽을 수는 있지만 얼마나 좋은지 상상하기 어렵습니다 ...

귀하의 예는 또한 가장 세련되지는 않지만 나 자신을 위해 한 것처럼 정확하게 문제를 해결합니다. 별도의 초기화 방법 \

IMHO, 여기서 질문은 목적을 위한 것입니다. 필요한 모든 필드가 있는 기본 클래스를 올바르게 작성하고, 이 클래스에서 상속하고, 생성자를 보호하고 상속인으로부터 기본 클래스를 초기화하여 "잊어버리는" 것을 방지합니다. 기본 생성자가 없나요? 제3자 호출에 의해 초기화되는 것을 방지할 수 있습니다. 생성자가 보호됩니까? - 최소한 Microsoft는 Google에서 "보호된 생성자"인지 확인할 수 있습니다.

내 작업은 약간 다릅니다. 특히 클래스 필드의 상태를 파일에 저장하기 위해 상속을 남겼고, 2개의 클래스에 2개의 필드가 있으며, 적절한 메서드를 호출하여 해당 상태를 동일한 파일에 저장합니다. 기본 클래스에서 상속받았을 때 이 모든 것을 저장하려고 했으나 매우 혼란스러운 계획으로 밝혀졌습니다. 상속 없이 다시 작성했습니다. 이제 모든 것이 "투명"하게 되었습니다.

[Vladimir Simakov]

Igor Makanu :

나보다 조금 앞서서 PC에만 앉아

@Vladimir Simakov 가 매크로를 사용하여 클래스 필드를 초기화하라는 조언은 올바르게 초기화하는 것을 잊지 않도록 하는 것입니다. 글쎄요, 좋은 트릭이지만 필드를 초기화하는 메서드를 호출하는 것과 유사하게 코드를 읽을 수는 있지만 얼마나 좋은지 상상하기 어렵습니다 ...

귀하의 예는 또한 가장 세련되지는 않지만 나 자신을 위해 한 것처럼 정확하게 문제를 해결합니다. 별도의 초기화 방법 \

IMHO, 여기서 질문은 목적을 위한 것입니다. 필요한 모든 필드가 있는 기본 클래스를 올바르게 작성하고, 이 클래스에서 상속하고, 생성자를 보호하고 상속인으로부터 기본 클래스를 초기화하여 "잊어버리는" 것을 방지합니다. 기본 생성자가 없나요? 제3자 호출에 의해 초기화되는 것을 방지할 수 있습니다. 생성자가 보호됩니까? - 최소한 Microsoft는 Google에서 "보호된 생성자"인지 확인할 수 있습니다.

내 작업은 약간 다릅니다. 특히 클래스 필드의 상태를 파일에 저장하기 위해 상속을 남겼고, 2개의 클래스에 2개의 필드가 있으며, 적절한 메서드를 호출하여 해당 상태를 동일한 파일에 저장합니다. 기본 클래스에서 상속받았을 때 이 모든 것을 저장하려고 했으나 매우 혼란스러운 계획으로 밝혀졌습니다. 상속 없이 다시 작성했습니다. 이제 모든 것이 "투명"하게 되었습니다.

여기서 혼란스러운 것은 무엇입니까?

...
virtual void CBase::Save(int hndl){...}
...
CObj:public CBase
...
void CObj::Save(int hndl){
   CBase::Save(hndl);
   ...
}

[Igor Makanu]

Vladimir Simakov :

여기서 혼란스러운 것은 무엇입니까?

이것은 정확히 내가 남긴 것입니다. 그러나 처음에 나는 그것을했습니다.

이 접근 방식으로 - "모든 것이 있는" 기본 클래스에서 상속 - 모든 것이 작동하지만 여러 클래스 필드를 만들고 각 클래스 필드에 여러 필드를 추가하려고 할 때까지는 모든 것을 이겨냅시다. 동적 클래스 배열

그리고 우리는 Save(int hndl) 메서드 자체를 얻습니다. 기본 클래스에서 구현할 수 없습니다. 이 메서드는 본질적으로 인터페이스가 될 것입니다. 논의한 바와 같이 전혀 필요하지 않습니다. 인터페이스 없이도 작성할 수 있습니다.

이것으로 괜찮습니다. 그것은 모두 취향과 작업의 문제입니다. 나는 일반적으로 코드 유연성에 대한 노력을 최대화합니다 - 최소한의 제스처 - 결과는 해결 된 새로운 문제입니다. 용어를 용서하십시오)))

문제는 파일에 저장을 구현할 때 서로 다른 유형의 총 레코드 수를 설명하는 데 필요한 파일 헤더를 개발해야 하고 논리를 잃지 않아야 한다는 것입니다. 모든 것을 올바르게 읽기 위해 데이터를 저장하는 순서 .... 그리고 마지막은 한 클래스에서 적어도 하나의 필드가 변경된 경우입니다.

기본 클래스에서 이러한 "가벼운" 상속의 복잡성인 IMHO는 작은 데이터베이스의 개발 및 유지 관리, 모든 클래스의 변경 사항에 대한 지속적인 모니터링으로 귀결됩니다.