OOP, mql5의 템플릿 및 매크로, 미묘함 및 사용 기술 - 페이지 13

새 코멘트
 

어제 우리는 추상 메소드로 이 버그에 대해 논의했고, 그래서 오늘 나는 내 코드에서 같은 것을 만났습니다) 이전에는 기본 클래스에서 가상 메소드가 추상이 아니었기 때문에 상속된 클래스에서 참조한 다음 만들기로 결정했습니다. 메서드가 추상화되었지만 컴파일러에서 더 이상 참조할 수 없다고 보고하지 않았습니다. 결과적으로 가장 사악하고 감지하기 어려운 재귀 오류로 인해 많은 시간이 소요되었습니다. 이제 기본 추상 메서드 본문이 있는 기능 이 적어도 버그가 수정될 때까지 여기에서 매우 유용할 것이라고 생각합니다.

 
Alexey Navoykov :

예, 파리를 커틀릿에 할당하는 것이 가능한 한 편리하고 아무도 눈을 깜박이지 않도록)

할당 과정에서 파리가 커틀릿으로 감소하면(또는 불가능한 경우 오류가 발생함) 아무 문제가 없습니다.

알렉세이 나보이코프 :

1. 글쎄요, 그럼 그냥 클래스 A입니다. 템플릿의 매개변수가 클래스의 동작과 아무 관련이 없는데 템플릿을 선언하는 이유는 무엇입니까?

2. 이것은 절대적으로 주석입니다. 유형 검사를 런타임으로 이동... 코드는 몇 년 후에 디버깅해야 합니다.

1. "Just class A"는 (class) 매개변수화 없이 임의 유형의 필드를 포함할 수 없습니다. 그리고 내가 설명한 탬버린과 함께 춤을 추지 않고는 참조 및 값으로 클래스 매개 변수로 균일한 작업을 수행할 수 없습니다.

2. 이미 만트라처럼 보입니다. 이 경우 F가 T, 즉 두 번째 템플릿 레코드가 없는 것처럼 보장하는 절대적으로 명확한 레코드입니다. 하지만. 다시, "나는 몇 년 후에 디버그할 것이다"))))))

 
Ilya Malev :

1. "Just class A"는 (class) 매개변수화 없이 임의 유형의 필드를 포함할 수 없습니다. 그리고 내가 설명한 탬버린과 함께 춤을 추지 않고는 참조 및 값으로 클래스 매개 변수로 균일한 작업을 수행할 수 없습니다.

2. 이미 만트라처럼 보입니다. 이 경우 F가 T, 즉 두 번째 템플릿 레코드가 없는 것처럼 보장하는 절대적으로 명확한 레코드입니다. 하지만. 다시, "나는 몇 년 후에 디버그할 것이다"))))))

왜 이 스레드에 답글을 달고 있습니까? 한 곳에서는 코드를, 다른 곳에서는 토론을...)

1. 예, 모든 것이 인간적인 방식으로 거의 춤 없이 수행될 수 있습니다.

 struct __A
{
   template < typename T>
   void f(T&) { }   // Сюда структуры и классы
};

struct A : __A
{
   template < typename T>  
   void f(T) { }   // Сюда простые типы и указатели
};

2. 거기에는 다른 것에 관한 것 같았습니다. 글쎄요, 요점은 아닙니다.

 
Alexey Navoykov :

이 스레드에 답장을 보내는 이유는 무엇입니까? 한 곳에서는 코드, 다른 곳에서는 토론...)

1. 예, 모든 것이 인간적인 방식으로 거의 춤 없이 수행될 수 있습니다.

2. 거기에는 다른 것에 관한 것 같았습니다. 글쎄요, 요점은 아닙니다.

귀하는 아직 어떤 분기가 더 적절한지 결정하는 중재자가 아닌 것 같습니다. 그리고 중재자는 기능에 대한 논의가 기능 자체의 스레드가 아니라 별도의 스레드, 즉 여기.

귀하의 설명에는 참조 및 유형 T의 값으로 클래스 메서드 에 균일하게 액세스하는 방법이 전혀 명확하지 않습니다. 무슨 말씀을 하시는지 모르겠지만 거기에 대해 이야기하고 있었습니다.

 
Ilya Malev :

귀하는 아직 어떤 분기가 더 적절한지 결정하는 중재자가 아닌 것 같습니다. 그리고 사회자는 기능에 대한 논의가 기능 자체의 스레드가 아니라 별도의 스레드, 즉 여기.

따라서 중재자가 이동하기를 원하는 경우 - 한 가지. 왜 스스로 혼란을 야기합니까? 예를 들어 가지를 따라 달리고 싶지 않아

 
Alexey Navoykov :

따라서 중재자가 이동하기를 원하는 경우 - 한 가지. 왜 스스로 혼란을 야기합니까? 예를 들어 가지를 따라 달리고 싶지 않아

중재자가 바로 그렇게 했을 가능성이 높다는 것을 이해한다면 중재자가 하기를 기다리지 않고 스스로 하는 것이 항상 더 좋습니다. 다만, 모더들의 행동에 대한 논의도 모더들의 즐겨찾기 메뉴에 포함되어 있지 않으니, 차라리 그만 두는 것이 좋을 것 같습니다.

 
Alexey Navoykov :
 Сюда простые типы и указатели

그런데 포인터의 경우 T * 인수를 사용하여 별도의 메서드를 만드는 것이 논리적입니다. 왜냐하면 분명히 혼동이 없을 것이고 대부분 포인터의 처리가 일반 유형과 다르다는 사실에서 이점이 있기 때문입니다. (유효성 확인, 삭제 등)

 
Alexey Navoykov :

한 곳에서 코드를 작성하고 다른 곳에서 토론

코드는 다음과 같습니다.

 template < typename T>
class A
 {
public :
  A* operator <<(T&p){ Print ( "<< &" , typename (T)); return & this ; }
   template < typename F>
  A* operator <<(F p){ Print ( "<< " , typename (F)); return & this ; }
 };

사실, 이 항목 외에도 하나의 솔루션이 더 있습니다. 값으로 전달된 모든 단순 유형을 이름으로 나열한 다음 &로 템플릿 메소드를 작성하면 오류가 발생하지 않습니다. 이 옵션은 자체 매개변수화가 없는 클래스에 적합합니다.

 
Ilya Malev :

중재자가 바로 그렇게 했을 가능성이 높다는 것을 이해한다면 중재자가 하기를 기다리지 않고 스스로 하는 것이 항상 더 좋습니다. 다만, 모더들의 행동에 대한 논의도 모더들의 즐겨찾기 메뉴에 포함되어 있지 않으니, 차라리 그만 두는 것이 좋을 것 같습니다.

사회자는 토론을 다른 가지로 나누지 않을 것입니다. 그러한 열심으로, " 중재자가 할 때까지 기다리지 않고" 자신을 금지할 준비가 되어 있을 수도 있습니다.))
 
Ilya Malev :

중재자가 바로 그렇게 했을 가능성이 높다는 것을 이해한다면 중재자가 하기를 기다리지 않고 스스로 하는 것이 항상 더 좋습니다. 다만, 모더들의 행동에 대한 논의도 모더들의 즐겨찾기 메뉴에 포함되어 있지 않으니, 차라리 그만 두는 것이 좋을 것 같습니다.

1. 그래도 이 "무언가"가 있는 것에 대해 즉시 이야기하고 중재자가 어떻게 할 것인지 생각하지 않는 것이 좋습니다. 그리고 나서 모든 것이 정말로 두 갈래로 흐려졌고, 이제 사회자가 토론이 있어야 한다고 결정하더라도 게시물의 순서와 의미를 유지하면서 토론 일정을 다시 잡는 것은 매우 시간 소모적인 작업입니다. .

2. 사회자의 행동에 대한 논의가 모든 재채기는 아닙니다 ... 이것은 그의 행동에 대한 일반 공개 경쟁이 시작되고 질서를 회복하거나 성난 사람들을 진정시키는 행동입니다. 그리고 자신의 의견이 있다면 누가 그것을 표현하는 것을 금지합니까? 어쩌면 당신의 의견은 매우 합리적인 제안이지만 모더레이터의 사랑받지 못하는 메뉴에 빠지지 않기 위해 말하기가 두려우신가요? 그래서 이것은 넌센스입니다 :)

1...67891011121314151617181920...28
새 코멘트