일반 클래스 라이브러리 - 버그, 설명, 질문, 사용 기능 및 제안 사항 - 페이지 21

새 코멘트
 
fxsaber :

결국, 원하는 유형에 대해 GetHashCode를 오버로드하도록 요청하고 IEqualityComparable을 차단하기 시작하지 않습니다.

이 경우 끝이 매우 멀어지고 라이브러리 내부 어딘가에서 오류가 발생할 수 있습니다. 그리고 어떤 기능이 발견되지 않은 이유와 그것이 누구의 잘못인지 생각하는 사람들이 있습니다. 그리고 인터페이스는 필요한 모든 기능이 객체에 이미 정의되어 있는지 미리 확인합니다.

 
알렉세이 나보이코프 :

이 경우 끝이 너무 멀리 가고 라이브러리 내부 어딘가에서 오류가 발생할 수 있습니다. 그리고 어떤 기능이 발견되지 않은 이유와 그것이 누구의 잘못인지 생각하는 사람들이 있습니다. 그리고 인터페이스는 필요한 모든 기능이 객체에 이미 정의되어 있는지 미리 확인합니다.

MqlTick 에 대한 예를 보여줄 수 있습니까?

 
알렉세이 나보이코프 :

그리고 인터페이스는 필요한 모든 기능이 객체에 이미 정의되어 있는지 미리 확인합니다.

예, 이러한 클래스만 보편적이라고 주장하며 즉시 사용 가능한 모든 유형에 대해 작동해야 합니다.

 
fxsaber :

MqlTick 에 대한 예를 보여줄 수 있습니까?

 class CMqlTick : public IEqualityComparable<CMqlTick*>
{
 public : 
   MqlTick _tick;
   bool     Equals(CMqlTick* obj) { return obj!= NULL && obj._tick.time==_tick.time; }
   int      HashCode( void )        { return _tick.time; }
};
물론 여기에는 클래스에 배치해야 하는 오버헤드와 포인터 검사가 있습니다.
 
알렉세이 나보이코프 :
물론 여기에는 클래스에 배치해야 하는 오버헤드와 포인터 검사가 있습니다.

감사합니다. 하지만 실제로 이 접근 방식의 이점이 무엇인지 이해가 되지 않습니까?

SB에서 그러한 코드

 //+------------------------------------------------------------------+
//| Class CKeyValuePair<TKey, TValue>.                               |
//| Usage: Defines a key/value pair that can be set or retrieved.    |
//+------------------------------------------------------------------+
template<typename TKey,typename TValue>
class CKeyValuePair: public IComparable<CKeyValuePair<TKey,TValue>*>
  {
protected :
   TKey              m_key;
   TValue            m_value;

public :
                     CKeyValuePair( void )                                              {   }
                     CKeyValuePair(TKey key,TValue value ): m_key(key), m_value( value ) {   }
                    ~CKeyValuePair( void )                                              {   }
   //--- methods to access protected data
   TKey              Key( void )           { return (m_key);   }
   void               Key(TKey key)       { m_key=key;       }
   TValue            Value( void )         { return (m_value); }
   void               Value(TValue value ) { m_value= value ;   }
   //--- method to create clone of current instance
   CKeyValuePair<TKey,TValue>*Clone( void ) { return new CKeyValuePair<TKey,TValue>(m_key,m_value); }
   //--- method to compare keys
   int                Compare(CKeyValuePair<TKey,TValue>*pair) { return ::Compare(m_key,pair.m_key); }
   //--- method for determining equality
   bool               Equals(CKeyValuePair<TKey,TValue>*pair) { return ::Equals(m_key,pair.m_key); }
   //--- method to calculate hash code   
   int                HashCode( void ) { return ::GetHashCode(m_key); }

제안된 춤은 이 GetHashCode에 과부하가 걸리지 않도록 하기 위한 것일 뿐입니다. 그러나 이 경우 게임이 촛불의 가치가 있습니까?

 
fxsaber :

감사합니다. 하지만 실제로 이 접근 방식의 이점이 무엇인지 이해가 되지 않습니까?

SB에서 그러한 코드

제안된 춤은 이 GetHashCode에 과부하가 걸리지 않도록 하기 위한 것일 뿐입니다. 그러나 이 경우 게임이 촛불의 가치가 있습니까?

속도가 중요하다면 과부하가 더 나을 것입니다.

결론은 이 라이브러리가 이식된 .NET에서 모든 기본 제공 유형에는 처음에 이미 인터페이스가 있다는 것입니다. Int(Int32라고도 함)는 다음과 같이 정의됩니다.

 public struct Int32 : IComparable, IFormattable, IConvertible, 
        IComparable< int >, IEquatable< int >

따라서 거기에는 과부하가 없습니다.

그리고 CKeyValuePair 클래스 자체는 약간 다르게 선언되었을 것입니다.

자, 여기에서 그들은 MQL의 제한된 기능이 허용하는 한 이 모든 것을 구현하려고 합니다. 이 시간을 언어의 기능 을 개선하는 데 사용하는 것이 좋습니다. 그런 다음 전체 .Net 라이브러리를 복사하여 붙여넣는 것으로 충분하며 모든 것이 작동합니다.

 
알렉세이 나보이코프 :
물론 여기에는 클래스에 배치해야 하는 오버헤드와 포인터 검사가 있습니다.
이 코드를 GetHashCode 오버로드로 푸시하는 문제는 무엇입니까? 그러면 인터페이스에서 상속할 필요가 없습니다.
 
결합기 :
이 코드를 GetHashCode 오버로드로 푸시하는 문제는 무엇입니까? 인터페이스에서 상속할 필요가 없습니다.

물론 가능합니다. 그러나 이것은 프로세스를 제어하기 어렵게 만듭니다. 코드 전체에 다양한 GetHashCode가 흩어져 있고 여기에서 호출되는 GetHashCode가 무엇인지 파악하기 어려울 수 있다고 가정해 보겠습니다. 예를 들어, 함수가 호출되면 인수가 다른 유형으로 캐스트됩니다. 따라서 C#에서는 분명히 템플릿의 가능성이 C++에 비해 축소됩니다.

 
알렉세이 나보이코프 :

물론 가능합니다. 그러나 이것은 프로세스를 제어하기 어렵게 만듭니다.

좋아. C++에서는 이 인터페이스가 필요하지 않으며, < 연산자를 단순히 오버로드하여 정상적인 상호 작용이 이루어지며 이 연산자는 클래스 외부에서 정의할 수 있습니다.

제 생각에는 그러한 구성을 되돌리는 것보다 훨씬 간단하고 간결합니다. 그러나 우리는 클래스 외부에서 < 연산자를 오버로딩하기 위한 기본 지원이 필요합니다.

내장 구조의 경우 GetHashCode 오버로드 외에는 아무것도 남지 않습니다. 스텁은 끔찍하며 상속받을 방법이 없습니다. 구조로부터의 상속은 목발 솔루션입니다. 표준 기능을 사용할 때 모든 것이 의도한 대로 갈 수 있도록 구조를 사용자 정의 상속인에게 수동으로 캐스트해야 하기 때문입니다.
 
결합기 :

구조로부터의 상속은 목발 솔루션입니다. 표준 기능을 사용할 때 모든 것이 의도한 대로 갈 수 있도록 구조를 사용자 정의 상속인에게 수동으로 캐스트해야 하기 때문입니다.

분명히 상속이 아니라 구조에 대한 클래스의 래퍼를 의미합니까?

사실 이러한 "강압"은 MQL 기능의 단점이기도 합니다. 캐스트 연산자를 오버로드할 가능성은 없습니다. 그렇지 않으면 클래스가 암시적으로 구조에 쉽게 캐스트됩니다.

일반적으로 언어는 세련되고 세련되어야 합니다. 하지만 웬일인지 아무도 가렵지 않습니다 ... 개발, 개선 및 혁신이없는 2 년 동안 침체되었습니다.

여기 개발자들 자신이 여러 인터페이스 및 기타 기능의 부족에 대해 불평하지만 계속 선인장을 먹고 있다는 사실에도 불구하고)

1...141516171819202122232425262728...38
새 코멘트