여기에는 모호함이 없습니다. GetPrime 메서드는 위에서 가장 가까운 소수를 반환해야 하지만 INT_MAX - 10과 INT_MAX 사이에 아무 것도 없으므로 INT_MAX - 10이 반환됩니다. ExpandPrime 메서드는 처음부터 입력 값을 두 배로 늘리고 GetPrime 메서드는 수신된 번호에서 호출됩니다. 또한 ExpandPrime에는 INT_MAX를 넘어서는 검사가 있습니다. 제 생각에는 이러한 방법의 동작 논리가 절대적으로 명확하고 정확합니다.
1. 함수는 소수가 아닌 숫자를 반환할 수 있지만 어떤 숫자인지 명확하지 않습니다. 사용자가 이 데이터를 어떻게 사용하느냐가 그의 문제입니다. 아마도 그는 그것을 long으로 캐스트한 다음 그것을 슈퍼컴퓨팅 기능으로 전송합니다. 차이점은 무엇입니까? 사실 반환은 함수에서 기본적으로 선언되고 예상되는 것이 아닐 수 있습니다.
2. 함수 호출이 난수가 아닌 소수를 반환했는지 확인하는 방법은 무엇입니까? INT_MAX와 비교하는 것만으로는 작동하지 않습니다. INT_MAX보다 작은 마지막 사용 가능한 소수와 비교해야 합니다. 모든 것이 올바르게 작동하는지 확인하기 위해 이러한 함수를 호출한 결과를 마법의 숫자와 비교할 때마다 이것은 말도 안되는 소리입니다.
1. 함수는 소수가 아닌 숫자를 반환할 수 있지만 어떤 숫자인지 명확하지 않습니다. 사용자가 이 데이터를 어떻게 사용하느냐가 그의 문제입니다. 아마도 그는 그것을 long으로 캐스트한 다음 그것을 슈퍼컴퓨팅 기능으로 전송합니다. 차이점은 무엇입니까? 사실 반환은 함수에서 기본적으로 선언되고 예상되는 것이 아닐 수 있습니다.
2. 함수 호출이 난수가 아닌 소수를 반환했는지 확인하는 방법은 무엇입니까? INT_MAX와 비교하는 것만으로는 작동하지 않습니다. INT_MAX보다 작은 마지막 사용 가능한 소수와 비교해야 합니다. 모든 것이 올바르게 작동하는지 확인하기 위해 이러한 함수를 호출한 결과를 마법의 숫자와 비교할 때마다 이것은 말도 안되는 소리입니다.
1. GetPrime 메서드로 소수가 아닌 번호를 얻은 경우는 지금까지 본 유일한 사례입니다. 이 사건은 소수를 생성할 때 수표를 변경하여 수정됩니다.
일반 컬렉션이 클래스 개체와 올바르게 작동하려면 이러한 클래스가 Equals 및 HashCode 메서드를 정의하는 IEqualityComparable 인터페이스를 구현해야 합니다. 저것들. 사용자 자신이 해시 코드 계산 방법을 설정해야 하며, MQL5 도구를 사용하여 예를 들어 .Net에서와 같이 이러한 방법을 자동으로 구현하는 것이 불가능하기 때문에 이것이 지금까지 유일한 옵션입니다.
그렇다면 템플릿이 모든 유형에서 작동하여 프로그래머를 오도하는 이유는 무엇입니까? IEqualityComparable에서 상속된 클래스만 올바르게 작동하는 경우 컴파일러 수준에서 다른 유형으로 작업하는 것을 금지해야 합니다.
다음 코드를 기억하십시오.
//+------------------------------------------------------------------+//| Returns a hashcode for custom object. |//+------------------------------------------------------------------+template < typename T>
int GetHashCode(T value)
{
//--- try to convert to equality comparable object
IEqualityComparable<T>*equtable= dynamic_cast <IEqualityComparable<T>*>(value);
if (equtable)
{
//--- calculate hash by specied method return equtable.HashCode();
}
else
{
//--- calculate hash from name of objectreturn GetHashCode( typename (value));
}
}
이것은 작업하기에 불편할 것입니다. 표준 형식에 대한 GetHashCode 오버로드는 해시 코드를 얻기 위한 인터페이스를 제공합니다.
지금 편리함이란? 이 함수에 인터페이스를 지원하지 않는 클래스에 대한 열거형이나 포인터를 전달하면 클래스의 이름만 얻을 수 있다는 사실이 사실입니까? 멋진 해시 ) 그리고 가장 중요한 것은 모든 것이 괜찮은 것처럼 코드가 작동하고 컴파일된다는 것입니다. 그것은 요점이 아니다.
지금 편리함이란? 이 함수에 인터페이스를 지원하지 않는 클래스에 대한 열거형이나 포인터를 전달하면 클래스의 이름만 얻을 수 있다는 사실이 사실입니까? 멋진 해시 ) 그리고 가장 중요한 것은 모든 것이 괜찮은 것처럼 코드가 작동하고 컴파일된다는 것입니다. 그것은 요점이 아니다.
예, 그들은 속임수를 썼습니다. NetFramework에서 아무 생각 없이 복사하여 붙여넣었지만 언어 수준에서 인터페이스를 지원하지 않으면 제대로 작동할 수 없습니다. 6~7년 전과 지금의 MQ 코드 수준을 기억합니다. 그 때와 비교하면 오늘날에는 일종의 어둠이 있습니다.
지금 편리함이란? 이 함수에 인터페이스를 지원하지 않는 클래스에 대한 열거형이나 포인터를 전달하면 클래스의 이름만 얻을 수 있다는 사실이 사실입니까? 멋진 해시 ) 그리고 가장 중요한 것은 모든 것이 괜찮은 것처럼 코드가 작동하고 컴파일된다는 것입니다. 그것은 요점이 아니다.
동의합니다. 컴파일 오류가 오랫동안 작동하지 않는 이유를 파악하는 것보다 즉시 컴파일 오류가 발생 하는 것이 좋습니다.
솔직히 말해서 인터페이스가 왜 거기에 붙어 있는지 즉시 명확하지 않습니다. 결국, 원하는 유형에 대해 GetHashCode를 오버로드하도록 요청하고 IEqualityComparable을 차단하기 시작하지 않습니다.
1. 명확한 행동:
"INT_MAX - 10"을 매개변수로 CPrimeGenerator::ExpandPrime에 전달하면 "INT_MAX" 결과가 반환됩니다.
"INT_MAX - 10"을 매개변수로 CPrimeGenerator::GetPrime에 전달하면 "INT_MAX - 10"과 같은 결과가 반환됩니다.
또한 두 경우 모두 반환된 값은 사용자를 오도하는 소수가 아닙니다.
첫 번째 요점:
여기에는 모호함이 없습니다.
GetPrime 메서드는 위에서 가장 가까운 소수를 반환해야 하지만 INT_MAX - 10과 INT_MAX 사이에 아무 것도 없으므로 INT_MAX - 10이 반환됩니다.
ExpandPrime 메서드는 처음부터 입력 값을 두 배로 늘리고 GetPrime 메서드는 수신된 번호에서 호출됩니다.
또한 ExpandPrime에는 INT_MAX를 넘어서는 검사가 있습니다.
제 생각에는 이러한 방법의 동작 논리가 절대적으로 명확하고 정확합니다.
두 번째 및 세 번째 사항에 대해:
제안한 변경 사항은 대부분 CHashMap 크기가 매우 큰 경우에만 관련이 있습니다. 그러나 성능에 긍정적인 영향을 미친다는 보장은 없으므로 제안한 변경 사항의 정확성을 확인하기 위해 별도의 연구를 수행해야 합니다.
여기에는 모호함이 없습니다.
GetPrime 메서드는 위에서 가장 가까운 소수를 반환해야 하지만 INT_MAX - 10과 INT_MAX 사이에 아무 것도 없으므로 INT_MAX - 10이 반환됩니다.
ExpandPrime 메서드는 처음부터 입력 값을 두 배로 늘리고 GetPrime 메서드는 수신된 번호에서 호출됩니다.
또한 ExpandPrime에는 INT_MAX를 넘어서는 검사가 있습니다.
제 생각에는 이러한 방법의 동작 논리가 절대적으로 명확하고 정확합니다.
1. 함수는 소수가 아닌 숫자를 반환할 수 있지만 어떤 숫자인지 명확하지 않습니다.
사용자가 이 데이터를 어떻게 사용하느냐가 그의 문제입니다. 아마도 그는 그것을 long으로 캐스트한 다음 그것을 슈퍼컴퓨팅 기능으로 전송합니다. 차이점은 무엇입니까?
사실 반환은 함수에서 기본적으로 선언되고 예상되는 것이 아닐 수 있습니다.
2. 함수 호출이 난수가 아닌 소수를 반환했는지 확인하는 방법은 무엇입니까?
INT_MAX와 비교하는 것만으로는 작동하지 않습니다.
INT_MAX보다 작은 마지막 사용 가능한 소수와 비교해야 합니다.
모든 것이 올바르게 작동하는지 확인하기 위해 이러한 함수를 호출한 결과를 마법의 숫자와 비교할 때마다 이것은 말도 안되는 소리입니다.
1. 함수는 소수가 아닌 숫자를 반환할 수 있지만 어떤 숫자인지 명확하지 않습니다.
사용자가 이 데이터를 어떻게 사용하느냐가 그의 문제입니다. 아마도 그는 그것을 long으로 캐스트한 다음 그것을 슈퍼컴퓨팅 기능으로 전송합니다. 차이점은 무엇입니까?
사실 반환은 함수에서 기본적으로 선언되고 예상되는 것이 아닐 수 있습니다.
2. 함수 호출이 난수가 아닌 소수를 반환했는지 확인하는 방법은 무엇입니까?
INT_MAX와 비교하는 것만으로는 작동하지 않습니다.
INT_MAX보다 작은 마지막 사용 가능한 소수와 비교해야 합니다.
모든 것이 올바르게 작동하는지 확인하기 위해 이러한 함수를 호출한 결과를 마법의 숫자와 비교할 때마다 이것은 말도 안되는 소리입니다.
1. GetPrime 메서드로 소수가 아닌 번호를 얻은 경우는 지금까지 본 유일한 사례입니다. 이 사건은 소수를 생성할 때 수표를 변경하여 수정됩니다.
2. 숫자가 소수인지 확인 하기 위해 CPrimeGenerator::IsPrime 메서드가 구현됩니다.
내 ArrayList에서 Generic/ArrayList.mqh에 있는 귀하의 ArrayList로 전환하려고 했습니다.
"." 뒤에 ME 아무것도 생산하지 않습니다.
값을 얻는 방법? Get() 및 []가 클래스에서 누락되었습니다.
그리고 포인터 배열이 있을 수 있다는 점은 고려하지 않습니다.
누가 이 도서관을 만들까요?
다음은 Java ArrayList 변형입니다.
일반 컬렉션이 클래스 개체와 올바르게 작동하려면 이러한 클래스가 Equals 및 HashCode 메서드를 정의하는 IEqualityComparable 인터페이스를 구현해야 합니다. 저것들. 사용자 자신이 해시 코드 계산 방법을 설정해야 하며, MQL5 도구를 사용하여 예를 들어 .Net에서와 같이 이러한 방법을 자동으로 구현하는 것이 불가능하기 때문에 이것이 지금까지 유일한 옵션입니다.
그렇다면 템플릿이 모든 유형에서 작동하여 프로그래머를 오도하는 이유는 무엇입니까? IEqualityComparable에서 상속된 클래스만 올바르게 작동하는 경우 컴파일러 수준에서 다른 유형으로 작업하는 것을 금지해야 합니다.
다음 코드를 기억하십시오.
이 기능은 다음으로 대체되어야 한다고 생각합니다.
그렇다면 템플릿이 모든 유형에서 작동하여 프로그래머를 오도하는 이유는 무엇입니까? IEqualityComparable에서 상속된 클래스만 올바르게 작동하는 경우 컴파일러 수준에서 다른 유형으로 작업하는 것을 금지해야 합니다.
이것은 작업하기에 불편할 것입니다. 표준 형식에 대한 GetHashCode 오버로드는 해시 코드를 얻기 위한 인터페이스를 제공합니다.
없어서 짜증난다.
저것들. 지금 물건이 엉망입니다.
이것은 작업하기에 불편할 것입니다. 표준 형식에 대한 GetHashCode 오버로드는 해시 코드를 얻기 위한 인터페이스를 제공합니다.
지금 편리함이란? 이 함수에 인터페이스를 지원하지 않는 클래스에 대한 열거형이나 포인터를 전달하면 클래스의 이름만 얻을 수 있다는 사실이 사실입니까? 멋진 해시 ) 그리고 가장 중요한 것은 모든 것이 괜찮은 것처럼 코드가 작동하고 컴파일된다는 것입니다. 그것은 요점이 아니다.
지금 편리함이란? 이 함수에 인터페이스를 지원하지 않는 클래스에 대한 열거형이나 포인터를 전달하면 클래스의 이름만 얻을 수 있다는 사실이 사실입니까? 멋진 해시 ) 그리고 가장 중요한 것은 모든 것이 괜찮은 것처럼 코드가 작동하고 컴파일된다는 것입니다. 그것은 요점이 아니다.
예, 그들은 속임수를 썼습니다. NetFramework에서 아무 생각 없이 복사하여 붙여넣었지만 언어 수준에서 인터페이스를 지원하지 않으면 제대로 작동할 수 없습니다. 6~7년 전과 지금의 MQ 코드 수준을 기억합니다. 그 때와 비교하면 오늘날에는 일종의 어둠이 있습니다.
지금 편리함이란? 이 함수에 인터페이스를 지원하지 않는 클래스에 대한 열거형이나 포인터를 전달하면 클래스의 이름만 얻을 수 있다는 사실이 사실입니까? 멋진 해시 ) 그리고 가장 중요한 것은 모든 것이 괜찮은 것처럼 코드가 작동하고 컴파일된다는 것입니다. 그것은 요점이 아니다.
동의합니다. 컴파일 오류가 오랫동안 작동하지 않는 이유를 파악하는 것보다 즉시 컴파일 오류가 발생 하는 것이 좋습니다.
솔직히 말해서 인터페이스가 왜 거기에 붙어 있는지 즉시 명확하지 않습니다. 결국, 원하는 유형에 대해 GetHashCode를 오버로드하도록 요청하고 IEqualityComparable을 차단하기 시작하지 않습니다.