Runtime: 해시 코드 결합에 도움이 되도록 HashCode 유형 추가

빠르고 더러운 것을 원하면 ValueTuple.Create(field1, field2).GetHashCode() 사용할 수 있습니다. Tuple 에서 사용된 것과 동일한 알고리즘이며(이 점에 있어서는 Objects 에서와 유사함) 할당 오버헤드가 없습니다.

그렇지 않으면 얼마나 좋은 해시가 필요한지, 필드 값이 어떤 가능성이 있는지(어떤 알고리즘이 좋은 결과 또는 나쁜 결과를 줄 것인지에 영향을 미침), hashDoS 공격의 가능성이 있는지, 모듈로 충돌을 수행하는지에 대한 질문이 있습니다. 짝수 해쉬(이진 짝수 해시 테이블에서와 같이) 등으로 인해 만능이 적용되지 않습니다.

@JonHanna 나는 그 질문이 예를 들어 string.GetHashCode() 에도 적용 된다고 생각합니다. Hash 제공하는 것이 그보다 더 어려운 이유를 모르겠습니다.

사실 특별한 요구 사항을 가진 사용자는 Hash 사용을 쉽게 중단할 수 있지만 string.GetHashCode() 사용을 중단하는 것이 더 어렵기 때문에 더 간단해야 합니다.

+1

ASP.NET에는 https://github.com/aspnet/Common/blob/dev/src/Microsoft.Extensions.HashCodeCombiner.Sources/HashCodeCombiner.cs 중 하나가

빠르고 더러운 것을 원하면 ValueTuple.Create(field1, field2).GetHashCode()를 사용할 수 있습니다.

아, 좋은 생각이군요. 이 글을 작성할 때 ValueTuple 생각하지 못했습니다. 불행히도 나는 그것이 C# 7/다음 프레임워크 릴리스까지 사용 가능할 것이라고 생각하지 않습니다. 또는 그것이 그 성능이 될 것인지조차 알 수 없습니다( EqualityComparer 속성/메서드 호출 은 합산될 수 있음). 그러나 나는 이것을 측정하기 위해 어떤 벤치마크도 취하지 않았기 때문에 나는 정말로 알지 못할 것입니다. 사람들이 튜플을 해킹 해결 방법으로 사용하지 않고 사용할 수 있는 해싱 전용/단순 클래스가 있어야 한다고 생각합니다.

그렇지 않으면 얼마나 좋은 해시가 필요한지, 필드 값이 어떤 가능성이 있는지(어떤 알고리즘이 좋은 결과 또는 나쁜 결과를 줄 것인지에 영향을 미침), hashDoS 공격의 가능성이 있는지, 모듈로 충돌을 수행하는지에 대한 질문이 있습니다. 짝수 해쉬(이진 짝수 해시 테이블에서와 같이) 등으로 인해 만능이 적용되지 않습니다.

절대적으로 동의하지만 대부분의 구현이 이를 고려하지 않는다고 생각합니다. 예를 들어 ArraySegment 의 현재 구현 은 매우 순진합니다. 이 클래스의 주요 목적은 (할당을 피하는 것과 함께) 해싱에 대해 잘 모르는 사람들 이 이와 같은 어리석은 일을 하는 것을 방지하기 위해 go-to 구현을 제공하는 것입니다. 귀하가 설명한 상황을 처리해야 하는 사람들은 자신의 해싱 알고리즘을 구현할 수 있습니다.

불행히도 C# 7/다음 프레임워크 릴리스까지 사용할 수 있다고 생각하지 않습니다.

기본 제공 지원이 아닌 C# 2에서 사용할 수 있다고 생각합니다.

또는 성능이 좋은지 알 수도 있습니다(EqualityComparer에 대한 속성/메서드 호출이 합산될 수 있음)

이 수업은 어떻게 다를까요? obj == null ? 0 : obj.GetHashCode() 명시적으로 호출하는 것이 더 빠르면 그보다 더 빨리 ValueTuple 로 이동해야 합니다.

나는 몇 주 전에 이 제안을 +1하는 경향이 있었지만 ValueTuple 를 위해 Tuple 를 사용하는 트릭의 할당 오버헤드를 줄이는 것에 비추어 덜 의향이 있습니다. 이것은 나에게 두 개의 의자 사이에있는 것 같습니다. 특별히 전문화 된 것이 필요하지 않은 경우 ValueTuple 사용할 수 있지만 그 이상의 것이 필요한 경우 이와 같은 클래스는 멀리 가지 않을 것입니다. 충분한.

그리고 우리가 C#7을 갖게 되면 더 쉽게 하기 위해 문법적인 설탕을 갖게 될 것입니다.

@JonHanna

이 수업은 어떻게 다를까요? 명시적으로 obj == null 을 호출하는 경우? 0 : obj.GetHashCode()가 ValueTuple로 이동해야 하는 것보다 더 빠릅니다.

ValueTuple 에 해시 코드를 가져오기 위해 Hash 클래스를 사용하지 않는 이유는 무엇입니까? 그것은 또한 파일의 LOC를 상당히 감소시킬 것입니다(현재 약 2000줄 정도입니다).

편집하다:

특별히 전문화된 것이 필요하지 않은 경우 ValueTuple을 사용할 수 있습니다.

사실이지만 문제는 많은 사람들이 그것을 깨닫지 못하고 자신의 열등한 순진한 해싱 기능(위에 링크된 것과 같은)을 구현할 수 있다는 것입니다.

내가 정말로 뒤처질 수 있다는 것을.

아마도 이 문제의 범위 밖일 것입니다. 그러나 전문가가 작성한 고성능 암호화 및 비암호화 해시를 찾을 수 있는 해싱 네임스페이스가 있으면 여기서 승리할 수 있습니다.

예를 들어 xxHash32, xxHash64, Metro128을 코딩하고 128에서 64로, 64에서 32비트로 다운샘플링해야 했습니다. 최적화된 함수의 배열을 갖는 것은 개발자가 최적화되지 않았거나 버그가 있는 함수를 작성하는 것을 피하는 데 도움이 될 수 있습니다. 그러나 여전히 필요에 따라 선택할 수 있습니다.

관심이 있는 경우 구현을 기꺼이 기부하여 전문가가 검토하고 최적화할 수 있습니다.

@redknightlois 그런 노력에 내 SpookyHash 구현을 추가하게 되어 기쁩니다.

@svick string.GetHashCode()에 주의하세요. 하지만 이는 매우 구체적입니다. 아주 좋은 이유는 Hash DoS 공격입니다.

@terrajobst , API 분류/검토 대기열에서 이것이 얼마나 멀리 있습니까? 우리가 항상 플랫폼에 추가하고 싶었던 단순한 API라고 생각합니다. 이제 실제로 이를 수행하기에 충분한 임계량을 갖게 되었을까요?

참조: @ellismg

현재 상태에서 검토할 준비가 되었다고 생각합니다.

@mellinoe 굉장해 ! 나는 제안을 좀 더 간결하게 만들기 위해 약간 정리했고 마지막에 해결해야 한다고 생각하는 몇 가지 질문을 추가했습니다.

@jamesqo long 기반도 있어야 합니다.

@redknightlois , 합리적으로 들립니다. Combine long 오버로드를 포함하도록 제안을 업데이트했습니다.

@JonHanna 의 제안이 충분하지 않습니까?

C# return ValueTuple.Create(a, b, c).GetHashCode();

그것이 충분하지 않은 충분한 충분한 이유가 있지 않는 한, 우리는 그것이 컷을 만들고 있다고 생각하지 않습니다.

생성된 코드가 몇 배 더 나빠졌다는 것 외에 다른 충분한 이유가 생각나지 않습니다. 물론 이 특정 경우를 염두에 두고 처리하는 새 런타임에 최적화가 없는 한 이 분석은 무의미합니다. 내가 1.0.1에서 이것을 시도했다고 말하면서.

예를 들어 설명하겠습니다.

ValueTuple 에 사용되는 실제 코드를 가져와 상수를 사용하여 호출한다고 가정해 보겠습니다.

        internal static class HashHelpers
        {
            public static int Combine(int h1, int h2)
            {
                // The jit optimizes this to use the ROL instruction on x86
                // Related GitHub pull request: dotnet/coreclr#1830
                uint shift5 = ((uint)h1 << 5) | ((uint)h1 >> 27);
                return ((int)shift5 + h1) ^ h2;
            }
        }

        [MethodImpl(MethodImplOptions.NoInlining)]
        public static int TryStaticCall()
        {
            return HashHelpers.Combine(10202, 2003);
        }

        [MethodImpl(MethodImplOptions.NoInlining)]
        public static int TryValueTuple()
        {
            return ValueTuple.Create(10202, 2003).GetHashCode();
        }
    }

이제 최적화 컴파일러 기회는 차이가 없어야 하지만 실제로는 존재합니다.

ValueTuple 의 실제 코드입니다.

이제 여기서 무엇을 볼 수 있습니까? 먼저 스택에 구조체를 만든 다음 실제 해시 코드를 호출합니다.

이제 Hash.Combine 의 실제 구현이 될 수 있는 HashHelper.Combine 의 사용과 비교하십시오.

알아요!!!
하지만 여기서 멈추지 말고... 실제 매개변수를 사용할 수 있습니다.

        [MethodImpl(MethodImplOptions.NoInlining)]
        public static int TryStaticCall(int h1, int h2)
        {
            return HashHelpers.Combine(h1, h2);
        }

        [MethodImpl(MethodImplOptions.NoInlining)]
        public static int TryValueTuple(int h1, int h2)
        {
            return ValueTuple.Create(h1, h2).GetHashCode();
        }

        static unsafe void Main(string[] args)
        {
            var g = new Random();
            int h1 = g.Next();
            int h2 = g.Next(); 
            Console.WriteLine(TryStaticCall(h1, h2));
            Console.WriteLine(TryValueTuple(h1, h2));
        }

좋은 점은 매우 안정적입니다. 그러나 대안과 비교해 보겠습니다.

이제 선을 넘자...

        internal static class HashHelpers
        {
            public static int Combine(int h1, int h2)
            {
                // The jit optimizes this to use the ROL instruction on x86
                // Related GitHub pull request: dotnet/coreclr#1830
                uint shift5 = ((uint)h1 << 5) | ((uint)h1 >> 27);
                return ((int)shift5 + h1) ^ h2;
            }
            public static int Combine(int h1, int h2, int h3, int h4)
            {
                return Combine(Combine(h1, h2), Combine(h3, h4));
            }
        }

        [MethodImpl(MethodImplOptions.NoInlining)]
        public static int TryStaticCall(int h1, int h2, int h3, int h4)
        {
            return HashHelpers.Combine(h1, h2, h3, h4);
        }

그리고 그 결과는 꽤 예시적입니다

JIT가 호출에 대해 생성하는 실제 코드를 실제로 검사할 수는 없지만 프롤로그와 에필로그만 있으면 제안을 포함하는 것을 정당화하기에 충분합니다.

분석의 핵심은 간단 합니다. 보유 유형이 struct 라는 것이 무료라는 의미는 아닙니다. :)

회의 중에 성과가 거론되었습니다. 문제는 이 API가 핫 경로에 있을 가능성이 있는지 여부입니다. 분명히 하자면, API가 없어야 한다는 말은 아닙니다. 구체적인 시나리오가 없는 한 API를 설계하는 것이 더 어렵다는 말을 하는 것뿐입니다. "X에 필요하므로 X가 사용할 수 있는지 여부가 성공의 척도"라고 말할 수 없기 때문입니다. 이는 새로운 작업을 허용하지 않고 동일한 작업을 보다 최적화된 방식으로 수행하는 API에 중요합니다.

빠르고 좋은 품질의 해시를 갖는 것이 더 중요할수록 개체에 사용되는 알고리즘과 표시될 값의 범위를 조정하는 것이 더 중요하므로 이러한 해시가 더 많이 필요하다고 생각합니다. 도우미일수록 그런 도우미를 사용하지 않아야 합니다.

@terrajobst , 성능이 이 제안의 주요 동기였지만 유일한 것은 아닙니다. 전용 유형이 있으면 검색 가능성에 도움이 됩니다. C# 7에서 기본 제공 튜플 지원을 사용하더라도 개발자는 자신이 값으로 동일하다는 사실을 반드시 알지 못할 수 있습니다. 그렇게 하더라도 튜플이 GetHashCode 재정의한다는 사실을 잊어버릴 수 있으며 결국 .NET에서 GetHashCode 를 구현하는 방법을 Google에 알려야 할 것입니다.

또한 ValueTuple.Create.GetHashCode 사용 시 미묘한 정확성 문제가 있습니다. 과거 8개 요소, 마지막 8개 요소만 해시됩니다. 나머지는 무시됩니다.

@terrajobst RavenDB GetHashCode 성능은 우리의 수익에 큰 타격을 주어 결국 고도로 최적화된 전체 루틴 세트를 구현하게 되었습니다. Roslyn에도 자체 내부 해싱이 있습니다. https://github.com/dotnet/roslyn/blob/master/src/Compilers/Core/Portable/InternalUtilities/Hash.cs 또한 여기에서 Roslyn에 대한 토론을 확인하세요. https://github .com/dotnet/coreclr/issues/1619 ... 따라서 성능이 핵심일 때 우리는 제공된 플랫폼을 사용할 수 없으며 자체적으로 롤백해야 합니다(및 결과를 지불해야 함).

또한 @jamesqo 문제는 완전히 유효합니다. 그렇게 많은 해시를 결합할 필요는 없지만 1M의 경우 해당 해시로 절벽을 넘어설 사람이 있습니다.

@JonHanna

빠르고 좋은 품질의 해시를 갖는 것이 더 중요할수록 개체에 사용되는 알고리즘과 표시될 값의 범위를 조정하는 것이 더 중요하므로 이러한 해시가 더 많이 필요하다고 생각합니다. 도우미일수록 그런 도우미를 사용하지 않아야 합니다.

따라서 적절한 해시를 수행하는 방법에 대해 생각하지 않고 도우미 함수를 입력하도록 권장하기 때문에 도우미 클래스를 추가하는 것이 좋지 않다는 말씀이신가요?

실제로는 그 반대가 사실인 것 같습니다. Hash.Combine 는 일반적으로 GetHashCode 구현을 개선해야 합니다. 해싱을 할 줄 아는 사람은 Hash.Combine 를 평가하여 자신의 사용 사례에 맞는지 확인할 수 있습니다. 해싱에 대해 잘 모르는 초보자는 적절한 해시를 수행하는 방법을 모르기 때문에 구성 필드를 xor-ing(또는 더 나쁘게는 추가)하는 대신 Hash.Combine 사용합니다.

우리는 이것을 조금 더 논의했고 당신은 우리를 확신시켰습니다 :-)

몇 가지 추가 질문:

1. 이 유형을 어디에 둘지 결정해야 합니다. 새 네임스페이스를 소개하는 것은 이상해 보입니다. System.Numerics 는 작동할 수 있습니다. System.Collections.Generic 도 작동할 수 있습니다. 비교자가 있고 해싱이 컬렉션 컨텍스트에서 가장 자주 사용되기 때문입니다.
2. 알 수 없는 수의 해시 코드를 결합하기 위해 할당 없는 빌더 패턴을 제공해야 합니까?

(2) @Eilon 은 다음과 같이 말했습니다.

참고로 ASP.NET Core(및 그 이전 버전 및 관련 프로젝트)는 HashCodeCombiner를 사용합니다. https://github.com/aspnet/Common/blob/dev/src/Microsoft.Extensions.HashCodeCombiner.Sources/HashCodeCombiner.cs

( @David Fowler는 몇 달 전에 GitHub 스레드에서 언급했습니다.)

그리고 이것이 사용 예는 다음과 같습니다 https://github.com/aspnet/Mvc/blob/760c8f38678118734399c58c2dac981ea6e47046/src/Microsoft.AspNetCore.Mvc.Razor/Internal/ViewLocationCacheKey.cs#L129 -L144

``` C#
var hashCodeCombiner = HashCodeCombiner.Start();
hashCodeCombiner.Add(IsMainPage? 1:0);
hashCodeCombiner.Add(ViewName, StringComparer.Ordinal);
hashCodeCombiner.Add(컨트롤러 이름, StringComparer.Ordinal);
hashCodeCombiner.Add(AreaName, StringComparer.Ordinal);

if (ViewLocationExpanderValues ​​!= null)
{
foreach(ViewLocationExpanderValues의 var 항목)
{
hashCodeCombiner.Add(항목.키, StringComparer.Ordinal);
hashCodeCombiner.Add(항목.값, StringComparer.Ordinal);
}
}

hashCodeCombiner를 반환합니다.
```

우리는 이것을 조금 더 논의했고 당신은 우리를 확신시켰습니다 :-)

🎉

새 네임스페이스를 소개하는 것은 이상해 보입니다. System.Numerics가 작동할 수도 있습니다.

새 네임스페이스를 추가하지 않기로 결정한 경우 Hash 라는 클래스와 using System.Numerics 지시문이 있는 모든 코드는 모호한 유형 오류로 컴파일에 실패합니다.

알 수 없는 수의 해시 코드를 결합하기 위해 할당 없는 빌더 패턴을 제공해야 합니까?

이것은 좋은 생각처럼 들립니다. 초기 몇 가지 제안으로, 아마도 우리는 그것을 이름을 지정한다 HashBuilder (라 StringBuilder )과이 return this 모든 후 Add 방법보다 쉽게 할 수 다음과 같이 해시를 추가합니다.

public override int GetHashCode()
{
    return HashBuilder.Create(_field1)
        .Add(_field2)
        .Add(_field3)
        .ToHash();
}

@jamesqo 스레드에 대한 합의가 있을 때 상단의 제안을 업데이트하십시오. 그런 다음 최종 검토를 수행할 수 있습니다. 당신이 디자인을 주도하면서 지금 당신에게 할당 ;-)

새 네임스페이스를 추가하지 않기로 결정한 경우 Hash 라는 클래스와 using System.Numerics 지시문이 있는 모든 코드는 모호한 유형 오류로 컴파일에 실패합니다.

실제 시나리오에 따라 다릅니다. 많은 경우 컴파일러는 지시문 사용을 고려하기 전에 컴파일 단위의 정의된 네임스페이스 계층이 진행되기 때문에 사용자 유형을 선호합니다.

하지만 그렇다 하더라도 API를 추가하는 것은 소스 브레이킹 체인지가 될 수 있습니다. 그러나 앞으로 나아가고 싶다고 가정할 때 이것을 피하는 것은 비현실적입니다. 😄 우리는 일반적으로 너무 일반적이지 않은 이름을 사용하여 충돌을 피하기 위해 노력합니다. 예를 들어 Hash 유형을 호출해서는 안 된다고 생각합니다. HashCode 가 더 나을 것 같아요.

몇 가지 초기 제안으로 아마도 이름을 HashBuilder로 지정해야 할 것입니다.

첫 번째 근사치로 다음과 같이 정적 및 빌더를 단일 유형으로 결합하는 방법을 생각했습니다.

``` C#
네임스페이스 System.Collections.Generic
{
공개 구조체 해시 코드
{
공개 정적 정수 결합(int 해시1, 정수 해시2);
공개 정적 정수 결합(int 해시1, 정수 해시2, 정수 해시3);
공개 정적 정수 결합(int 해시1, 정수 해시2, 정수 해시3, 정수 해시4);
공개 정적 정수 결합(int 해시1, 정수 해시2, 정수 해시3, 정수 해시4, 정수 해시5);
공개 정적 정수 결합(int 해시1, 정수 해시2, 정수 해시3, 정수 해시4, 정수 해시5, 정수 해시6);

    public static long Combine(long hash1, long hash2);
    public static long Combine(long hash1, long hash2, long hash3);
    public static long Combine(long hash1, long hash2, long hash3, long hash4);
    public static long Combine(long hash1, long hash2, long hash3, long hash4, long hash5);
    public static long Combine(long hash1, long hash2, long hash3, long hash4, long hash5, longhash6);

    public static int CombineHashCodes<T1, T2>(T1 o1, T2 o2);
    public static int CombineHashCodes<T1, T2, T3>(T1 o1, T2 o2, T3 o3);
    public static int CombineHashCodes<T1, T2, T3, T4>(T1 o1, T2 o2, T3 o3, T4 o4);
    public static int CombineHashCodes<T1, T2, T3, T4, T5>(T1 o1, T2 o2, T3 o3, T4 o4, T5 o5);
    public static int CombineHashCodes<T1, T2, T3, T4, T5, T6>(T1 o1, T2 o2, T3 o3, T4 o4, T5 o5, T6 o6);

    public void Combine(int hashCode);
    public void Combine(long hashCode);
    public void Combine<T>(T obj);
    public void Combine(string text, StringComparison comparison);

    public int Value { get; }
}

}

This allows for code like this:

``` C#
return HashCode.Combine(value1, value2);

게다가:

``` C#
var hashCode = 새로운 HashCode();
hashCode.Combine(IsMainPage? 1:0);
hashCode.Combine(보기 이름, StringComparer.Ordinal);
hashCode.Combine(컨트롤러 이름, StringComparer.Ordinal);
hashCode.Combine(영역 이름, StringComparer.Ordinal);

if (ViewLocationExpanderValues ​​!= null)
{
foreach(ViewLocationExpanderValues의 var 항목)
{
hashCode.Combine(item.Key, StringComparer.Ordinal);
hashCode.Combine(항목.값, StringComparer.Ordinal);
}
}

해시 코드.값을 반환합니다.
```

생각?

나는 @jamesqo 의 연쇄 호출에 대한 아이디어를 좋아합니다(인스턴스 메소드 Combine 에서 this 반환).

정적 메서드를 완전히 제거하고 인스턴스 메서드만 유지하는 한 ...

Combine(long hashCode) 는 int 캐스팅됩니다. 우리가 진정으로 그것을 원하는가?
long 오버로드의 사용 사례는 무엇입니까?

@karelz 제거하지 마십시오. 구조체는 무료가 아닙니다. 해시는 매우 핫한 경로에서 사용할 수 있습니다. 정적 메서드가 본질적으로 무료일 때 명령을 낭비하고 싶지는 않을 것입니다. 내가 둘러싸는 구조체의 실제 영향을 보여준 코드 분석을 보십시오.

이름 충돌을 피하기 위해 Hashing 정적 클래스를 사용했으며 코드가 좋아 보입니다.

@redknightlois 하나의 int 필드가 있는 일반 구조체가 아닌 경우에도 동일한 '나쁜' 코드를 예상해야 하는지 궁금합니다.
그것이 여전히 '나쁜' 어셈블리 코드라면 여기에서 최적화 작업을 더 잘 수행하기 위해 JIT를 개선할 수 있는지 궁금합니다. 몇 가지 지침을 저장하기 위해 API를 추가하는 것은 최후의 수단 IMO가 되어야 합니다.

@redknightlois 궁금합니다. 구조체(이 경우 HashCode )가 레지스터에 들어갈 수 있으면 JIT가 더 나쁜 코드를 생성합니까? int 정도만 됩니다.

또한 최근 구조체 주변에서 생성된 코드를 개선하기 위해 coreclr에서 많은 pull 요청을 보고 있으며 dotnet/coreclr#8057이 이러한 최적화를 가능하게 할 것 같습니다. 아마도 JIT가 생성하는 코드는 이 변경 후에 더 나아질 것입니까?

편집: @karelz 가 이미 여기에서 내 요점을 언급한 것을 봅니다.

@karelz , 나는 당신에게 동의합니다. JIT가 int 크기의 구조체에 대해 괜찮은 코드를 생성한다고 가정하면(예를 들어 ImmutableArray 에는 오버헤드가 없음) 정적 오버로드는 다음과 같습니다. 중복되며 제거할 수 있습니다.

@terrajobst 더 많은 아이디어가 있습니다.

• 나는 우리가 당신과 나의 아이디어를 약간 결합할 수 있다고 생각합니다. HashCode 좋은 이름 같습니다. 빌더 패턴을 따르는 변경 가능한 구조체일 필요는 없습니다. 대신 int 의 변경할 수 없는 래퍼가 될 수 있으며 모든 Combine 작업은 새 HashCode 값을 반환할 수 있습니다. 예를 들어

public struct HashCode
{
    private readonly int _hash;

    public HashCode Combine(int hash) => return new HashCode(CombineCore(_hash, hash));

    public HashCode Combine<T>(T item) => Combine(EqualityComparer<T>.Default.GetHashCode(item));
}

// Usage
HashCode combined = new HashCode(_field1)
    .Combine(_field2)
    .Combine(_field3);

• 사람들이 마지막 .Value 호출을 할 필요가 없도록 int 로의 변환을 위한 암시적 연산자만 있으면 됩니다.
• Re Combine , 그게 최고의 이름인가요? 더 설명적으로 들리지만 Add 는 더 짧고 입력하기 쉽습니다. ( Mix 는 또 다른 대안이지만 입력하기가 약간 어렵습니다.)
  
  
  
  • public void Combine(string text, StringComparison comparison) : 이것은 문자열과 관련이 없기 때문에 실제로 같은 유형에 속한다고 생각하지 않습니다. 게다가, 그렇게 해야 하는 드문 경우를 위해 StringComparer.XXX.GetHashCode(str) 를 작성하는 것은 충분히 쉽습니다.
  
  
  • 이 유형에서 긴 오버로드를 제거하고 long에 대해 별도의 HashCode 유형이 있어야 합니다. Int64HashCode 또는 LongHashCode 입니다.
  
  

TryRoslyn에서 작은 샘플 구현을 만들었습니다. http://tinyurl.com/zej9yux

다행히 쉽게 확인할 수 있습니다. 그리고 좋은 소식은 그대로 잘 작동한다는 점👍

사람들이 마지막 .Value 호출을 가질 필요가 없도록 int로 변환하기 위한 암시적 연산자가 있어야 합니다.

아마도 코드는 거의 간단하지 않을 것입니다. 암시적 변환을 사용하면 코드가 약간 정리될 것입니다. 나는 여전히 여러 매개변수 인터페이스를 가질 수 있다는 아이디어를 좋아합니다.

        [MethodImpl(MethodImplOptions.NoInlining)]
        public static int TryHashCombiner(int h1, int h2, int h3, int h4)
        {
            var h = new HashCode(h1).Combine(h2).Combine(h3).Combine(h4);
            return h.Value;
        }

리 콤바인, 그게 최고의 이름인가요? 더 설명적으로 들리지만 Add가 더 짧고 입력하기 쉽습니다. (Mix는 또 다른 대안이지만 입력하기가 약간 어렵습니다.)

Combine은 해싱 커뮤니티 afaik에서 사용되는 실제 이름입니다. 그리고 그것은 당신에게 그것이 무엇을 하고 있는지에 대한 명확한 아이디어를 제공합니다.

@jamesqo 많은 해싱 함수가 있으며

다음과 같은 확장 가능한 메커니즘을 사용하여 이 디자인에서 앞으로 생각할 수 있습니다.

        internal interface IHashCode<T> where T : struct
        {
            T Combine(T h1, T h2);
        }

        internal struct RotateHashCode : IHashCode<int>, IHashCode<long>
        {
            long IHashCode<long>.Combine(long h1, long h2)
            {
                // The jit optimizes this to use the ROL instruction on x86
                // Related GitHub pull request: dotnet/coreclr#1830
                ulong shift5 = ((ulong)h1 << 5) | ((ulong)h1 >> 27);
                return ((int)shift5 + h1) ^ h2;
            }

            int IHashCode<int>.Combine(int h1, int h2)
            {
                // The jit optimizes this to use the ROL instruction on x86
                // Related GitHub pull request: dotnet/coreclr#1830
                uint shift5 = ((uint)h1 << 5) | ((uint)h1 >> 27);
                return ((int)shift5 + h1) ^ h2;
            }
        }

        internal struct HashCodeCombiner<T, W> where T : struct, IHashCode<W>
                                               where W : struct
        {
            private static T hasher;
            public W Value;

            static HashCodeCombiner()
            {
                hasher = new T();
            }

            [MethodImpl(MethodImplOptions.AggressiveInlining)]
            public HashCodeCombiner(W seed)
            {
                this.Value = seed;
            }

            [MethodImpl(MethodImplOptions.AggressiveInlining)]
            public HashCodeCombiner<T,W> Combine( W h1 )
            {
                Value = hasher.Combine(this.Value, h1);
                return this;
            }
        }

        [MethodImpl(MethodImplOptions.NoInlining)]
        public static int TryHashCombinerT(int h1, int h2, int h3, int h4)
        {
            var h = new HashCodeCombiner<RotateHashCode, int>(h1).Combine(h2).Combine(h3).Combine(h4);
            return h.Value;
        }

JIT가 이에 대해 매우 성가신 프롤로그 코드를 생성하는 이유를 모르겠습니다. 아마도 최적화될 수 있을 것이므로 JIT 개발자에게 요청해야 합니다. 그러나 나머지는 단일 명령을 낭비하지 않고 원하는 만큼 다양한 Combiner를 구현할 수 있습니다. 그렇긴 하지만 이 방법은 결합기보다 실제 해시 함수에 더 유용할 수 있습니다. cc @CarolEidt @AndyAyersMS

편집: 여기에서 단일 해싱 개념 우산 아래에서 암호화 및 비암호화 해시 기능을 결합하는 일반적인 메커니즘에 대해 크게 생각합니다.

@jamesqo

빌더 패턴을 따르는 변경 가능한 구조체일 필요는 없습니다.

아 예. 그런 경우에는 그 패턴이 좋습니다. 나는 일반적으로 작업에 부작용이 있는 경우 인스턴스를 반환하는 패턴을 좋아하지 않습니다. API가 변경할 수 없는 WithXxx 패턴을 따르는 경우 특히 나쁩니다. 하지만 이 경우 패턴은 기본적으로 변경할 수 없는 데이터 구조이므로 패턴이 제대로 작동합니다.

나는 우리가 당신과 나의 아이디어를 약간 결합할 수 있다고 생각합니다.

👍, 그럼 어떨까요?

``` C#
공개 구조체 해시 코드
{
공개 정적 HashCode 만들기(T obj);

[Pure] public HashCode Combine(int hashCode);
[Pure] public HashCode Combine(long hashCode);
[Pure] public HashCode Combine<T>(T obj);
[Pure] public HashCode Combine(string text, StringComparison comparison);

public int Value { get; }

public static implicit operator int(HashCode hashCode);

}

This allows for code like this:

``` C#
public override int GetHashCode()
{
    return HashCode.Create(value1).Combine(value2);
}

뿐만 아니라 이것:

``` C#
var hashCode = 새로운 HashCode()
.Combine(IsMainPage ? 1:0)
.Combine(ViewName, StringComparer.Ordinal)
.Combine(컨트롤러 이름, StringComparer.Ordinal)
.Combine(영역 이름, StringComparer.Ordinal);

if (ViewLocationExpanderValues ​​!= null)
{
foreach(ViewLocationExpanderValues의 var 항목)
{
hashCode = hashCode.Combine(item.Key, StringComparer.Ordinal);
hashCode = hashCode.Combine(항목.값, StringComparer.Ordinal);
}
}

해시 코드.값을 반환합니다.
```

@terrajobst 생각:

1. Create<T> 팩토리 메소드를 제거해야 합니다. 그렇지 않으면 HashCode.Create(_val) 또는 new HashCode().Combine(_val) 같은 2가지 방법이 있습니다. 또한 Create / Combine 대해 다른 이름을 사용하면 첫 번째 필드를 새로 추가하면 2줄을 변경해야 하므로 diff 친화적이지 않습니다.
2. string/StringComparison을 허용하는 오버로드가 여기에 속하지 않는다고 생각합니다. HashCode 는 문자열과 관련이 없습니다. 대신 문자열에 GetHashCode(StringComparison) API를 추가해야 할까요? (또한 이들 모두는 string.GetHashCode 의 기본 동작인 서수 비교입니다.)
3. 가지고있는 점 무엇 Value 이미로 변환 암시 적 연산자가있는 경우, int ? 다시 말하지만, 이것은 다른 사람들이 다른 것을 작성하게 할 것입니다.
4. long 오버로드를 새 유형으로 이동해야 합니다. HashCode 너비는 32비트입니다. 길지 않습니다.
5. 해싱에서 더 일반적이기 때문에 서명되지 않은 유형을 사용하는 오버로드를 추가해 보겠습니다.

제안한 API는 다음과 같습니다.

public struct HashCode
{
    public HashCode Combine(int hash);
    public HashCode Combine(uint hash);
    public HashCode Combine<T>(T obj);

    public static implicit operator int(HashCode hashCode);
    public static implicit operator uint(HashCode hashCode);
}

public struct Int64HashCode
{
    public Int64HashCode Combine(long hash);
    public Int64HashCode Combine(ulong hash);

    public static implicit operator long(Int64HashCode hashCode);
    public static implicit operator ulong(Int64HashCode hashCode);
}

이러한 방법만으로 ASP.NET의 예제는 여전히 다음과 같이 작성할 수 있습니다.

var hashCode = new HashCode()
    .Combine(IsMainPage ? 1 : 0)
    .Combine(ViewName)
    .Combine(ControllerName)
    .Combine(AreaName);

if (ViewLocationExpanderValues != null)
{
    foreach (var item in ViewLocationExpanderValues)
    {
        hashCode = hashCode.Combine(item.Key);
        hashCode = hashCode.Combine(item.Value);
    }
}

return hashCode;

@jamesqo

int 로의 변환을 위한 암시적 연산자가 이미 있는 경우 Value 가 무슨 의미가 있습니까? 다시 말하지만, 이것은 다른 사람들이 다른 것을 작성하게 할 것입니다.

연산자 오버로드에 대한 프레임워크 디자인 지침은 다음과 같이 말합니다.

오버로드된 각 연산자에 해당하는 친숙한 이름으로 메서드를 제공하는 것을 고려하십시오.

많은 언어가 연산자 오버로딩을 지원하지 않습니다. 이러한 이유로 연산자를 오버로드하는 형식에는 동등한 기능을 제공하는 적절한 도메인별 이름이 있는 보조 메서드를 포함하는 것이 좋습니다.

특히 F#은 암시적 변환 연산자를 호출하기 어렵게 만드는 언어 중 하나입니다.

또한, 일을 하는 방법이 한 가지만 있는 것이 그렇게 중요하다고 생각하지 않습니다. 제 생각에는 API를 편리하게 만드는 것이 더 중요합니다. 난 그냥 몇 가지 값의 해시 코드를 결합하려는 경우에, 나는 생각 HashCode.CombineHashCodes(value1, value2, value3) 보다 이해하기, 간단한 짧고 쉽게 new HashCode().Combine(value1).Combine(value2).Combine(value3) .

인스턴스 메소드 API는 여전히 복잡한 경우에 유용하지만 더 일반적인 경우에는 더 간단한 정적 메소드 API가 있어야 한다고 생각합니다.

@svick , 합법적인 연산자를 지원하지 않는 다른 언어에 대한 귀하의 요점. 양보합니다. 그러면 Value 를 추가해 보겠습니다.

일을 하는 방법이 한 가지만 있는 것이 그렇게 중요하다고 생각하지 않습니다.

그것은 중요하다. 누군가가 한 가지 방법으로 수행하고 다른 방법으로 수행하는 사람의 코드를 읽으면 다른 방법으로 Google에 검색해야 합니다.

몇 가지 값의 해시 코드를 결합하려는 경우 HashCode.CombineHashCodes(value1, value2, value3)가 new HashCode().Combine(value1).Combine(value2).Combine( 가치3).

• 정적 메서드의 문제는 params int[] 오버로드가 없기 때문에 각각 다른 arity에 대해 오버로드를 추가해야 하므로
• 두 번째 형태는 한두 번 보면 이해하기 쉬울 것입니다. 사실, 수직으로 연결하는 것이 더 쉽기 때문에 더 읽기 쉽다고 주장할 수 있습니다(따라서 필드가 추가/제거될 때 diff를 최소화함).

public override int GetHashCode()
{
    return new HashCode()
        .Combine(_field1)
        .Combine(_field2)
        .Combine(_field3)
        .Combine(_field4);
}

[@svick] 일을 하는 방법이 한 가지만 있는 것이 그렇게 중요하다고 생각하지 않습니다.

혼란을 피하기 때문에 같은 일을 할 수 있는 방법의 수를 최소화하는 것이 중요하다고 생각합니다. 동시에 우리의 목표는 검색 가능성, 편의성, 성능 또는 가독성과 같은 다른 목표를 실현하는 데 도움이된다면 100% 중복되지 않는 것이 아닙니다. 일반적으로 우리의 목표는 API보다는 개념을 최소화하는 것입니다. 예를 들어, 다중 오버로드는 분리된 용어를 사용하는 여러 가지 방법을 사용하는 것보다 문제가 적습니다.

내가 팩토리 메소드를 추가한 이유는 초기 해시 코드를 얻는 방법을 명확히 하기 위해서입니다. Combine 뒤에 오는 빈 구조체를 만드는 것은 매우 직관적이지 않습니다. 논리적인 것은 .ctor를 추가하는 것이지만 boxing을 피하기 위해서는 .ctor로는 할 수 없는 일반적이어야 합니다. 제네릭 팩토리 메소드가 차선책입니다.

좋은 부작용은 프레임워크에서 불변 데이터 구조가 어떻게 보이는지 매우 유사하게 보인다는 것입니다. 그리고 API 디자인에서 우리는 거의 모든 것보다 일관성을 강력히 선호합니다.

[@svick] 적은 수의 해시 코드를 결합하고 싶다면 HashCode.CombineHashCodes(value1, value2, value3)가 new HashCode().Combine(value1).Combine(value2)보다 더 간단하고 짧고 이해하기 쉽다고 생각합니다. ).결합(값3).

@jamesqo에 동의합니다. 최소한의 성능 패널티로 임의의 양의 인수로 확장되는 빌더 패턴에 대해 제가 좋아하는 점(있는 경우 인라인이 얼마나 좋은지에 따라 다름).

[@jamesqo] string/StringComparison을 수락하는 오버로드가 여기에 속하지 않는다고 생각합니다. HashCode는 문자열과 관련이 없습니다.

공정한 지적입니다. @Eilon 의 코드에서 참조했기 때문에 추가했습니다. 경험에 따르면 문자열은 매우 일반적입니다. 반면에 비교를 지정하는 것이 확실하지 않습니다. 일단은 놔두자.

[@jamesqo] 긴 오버로드를 새로운 유형으로 옮겨야 합니다. HashCode 너비는 32비트입니다. 길지 않습니다.

그건 좋은 지적이야. long 버전이 필요합니까? 위에서 언급한 내용이라 별 생각 없이 그냥 두었습니다.

이제 .NET GetHashCode() 에 대한 것이기 때문에 32비트만 남겨야 합니다. 그런 맥락에서 uint 버전을 추가해야 하는지도 잘 모르겠습니다. 해당 영역 외부에서 해싱을 사용하는 경우 System.Security.Cryptography 에 있는 보다 일반적인 목적의 해싱 알고리즘을 사람들에게 알려주는 것이 좋습니다.

```C#
공개 구조체 해시 코드
{
공개 정적 HashCode 만들기(T obj);

[Pure] public HashCode Combine(int hashCode);
[Pure] public HashCode Combine<T>(T obj);

public int Value { get; }

public static implicit operator int(HashCode hashCode);

}
```

이제 .NET GetHashCode()가 바로 32비트이기 때문에 32비트만 남겨야 할 것 같습니다. 그런 점에서 uint 버전을 추가해야 하는지도 잘 모르겠습니다. 해당 영역 외부에서 해싱을 사용하는 경우 System.Security.Cryptography에 있는 보다 일반적인 목적의 해싱 알고리즘을 사람들에게 알려주는 것이 좋습니다.

@terrajobst 실제 동물원인 해싱 알고리즘에는 매우 다양한 유형이 있습니다. 사실, 아마도 70%는 설계상 비암호화입니다. 그리고 아마도 그 중 절반 이상이 64+ 비트를 처리하도록 설계되었을 것입니다(공통 목표는 128/256). 프레임워크가 내가 장담하는 32비트를 사용하기로 결정한 것은 (나는 거기에 가지 않았음) 당시 x86은 여전히 ​​거대한 소비자였고 해시는 모든 곳에서 사용되었기 때문에 낮은 하드웨어에서 성능이 가장 중요했기 때문입니다.

또한 정말 이상 정의 된 해시 함수의 가장 엄격하기 uint 도메인을, 그리고에 int 변화의 규칙이 다르기 때문이다. 사실 제가 예전에 올렸던 코드를 확인해보면 int 가 바로 uint 로 변환됩니다. (그리고 ror/rol 최적화 사용) 만일 우리가 엄격하게 하고 싶다면 유일한 해시는 uint 이어야 합니다. 프레임워크가 해당 조명 아래에서 int 반환하는 것은 간과로 볼 수 있습니다.

이것을 int 로 제한하는 것은 오늘날 우리가 가지고 있는 것보다 낫지 않습니다. 제 요청이라면 디자인 팀에 요청하여 128개 및 256개 변종과 다양한 해시 기능을 지원하는 방법을 검토할 것입니다.

과도한 단순화로 인해 발생하는 문제는 복잡한 것을 처리해야 할 때 발생하는 설계 문제보다 더 나쁠 때가 있습니다. 개발자가 not being able to deal with having multiple options 로 인식되기 때문에 기능을 크게 단순화하면 현재 SIMD 상태의 경로로 쉽게 이어질 수 있습니다. 성능을 중시하는 대부분의 개발자는 이를 사용할 수 없으며 다른 사람들도 사용하지 않을 것입니다. 왜냐하면 대부분은 어쨌든 그렇게 미세한 처리량 목표를 가진 성능에 민감한 응용 프로그램을 다루지 않기 때문입니다.

해싱의 경우도 비슷합니다. 32비트를 사용하는 도메인은 매우 제한적이며(대부분은 이미 프레임워크 자체에서 다루고 있음) 나머지는 운이 좋지 않습니다.

또한 75000개 이상의 요소를 처리해야 하는 즉시 충돌이 발생할 확률이 50%이며, 이는 대부분의 시나리오에서 좋지 않습니다(잘 설계된 해시 함수가 있다고 가정). 이것이 64비트와 128비트가 런타임 구조의 경계 밖에서 사용되는 이유입니다.

int 에 고정된 디자인으로 우리는 2000년에 먼데이 신문이 없었기 때문에 발생한 문제만 다루고 있습니다(이제 모두가 스스로 가난한 해싱을 작성합니다). 예술도.

그것은 토론에 내 2 센트입니다.

@redknightlois , int 해시의 한계를 이해하고 있다고 생각합니다. 하지만 @terrajobst에 동의합니다. 이 기능은 Object.GetHashCode 재정의에서 해시를 반환할 목적으로 해시를 계산하는 API에 관한 것이어야 합니다. 우리는 또한 더 현대적인 해싱을 위한 별도의 라이브러리를 가질 수 있지만 Object.GetHashCode 및 기존의 모든 해싱 데이터 구조로 수행할 작업을 결정하는 것이 포함되어야 하므로 별도의 논의가 필요하다고 말하고 싶습니다.

128비트에서 해시 결합을 수행한 다음 GetHahsCode에서 결과를 반환할 수 있도록 int로 변환하는 것이 여전히 유익하다고 생각하지 않는 한.

@KrzysztofCwalina 나는 그것이 두 가지 다른 접근 방식이라는 데 동의합니다. 하나는 2000년에 발생한 문제를 수정하는 것입니다. 다른 하나는 일반적인 해싱 문제를 해결하는 것입니다. 우리 모두가 이것이 전자에 대한 해결책이라는 데 동의한다면 토론은 끝난다. 그러나 "미래" 이정표에 대한 설계 토론의 경우, 대부분 여기서 우리가 할 일이 향후 토론에 영향을 미치기 때문에 부족할 것이라고 생각합니다. 여기서 실수를 하면 영향을 미칩니다.

@redknightlois , 저는 다음을 제안합니다: 미래에 대해 걱정할 필요가 없는 것처럼 API를 설계합시다. 그런 다음 미래 API에 문제를 일으킬 것으로 생각되는 디자인 선택에 대해 논의해 보겠습니다. 또한 우리가 할 수 있는 일은 c2000 API를 corfx에 추가하는 것과 동시에 corfxlab에서 미래 API를 실험하는 것입니다.

@redknightlois

여기서 실수를 하면 영향을 미칩니다.

앞으로 더 고급 시나리오를 지원하려는 경우 HashCode 에서 별도의 유형으로 지원할 수 있다고 생각합니다. 여기에서의 결정은 이러한 경우에 실제로 영향을 미치지 않아야 합니다.

이를 해결하기 위해 다른 문제를 만들었습니다.

@redknightlois :+1:. Btw, 당신은 내가 내 의견을 편집하기 전에 응답했지만 실제로 해시가 모든 유형(int, long, decimal 등)과 함께 작동하도록 하고 핵심 해싱 논리를 구조체로 캡슐화하는 아이디어(위)를 시도했습니다. https://github.com/jamesqo/HashApi (샘플 사용법은 여기 ). 그러나 두 개의 제네릭 유형 매개변수를 사용하는 것은 너무 복잡하고 API를 사용하려고 할 때 컴파일러 유형 유추가 작동하지 않게 되었습니다. 예, 지금은 별도의 문제로 고급 해싱을 하는 것이 좋습니다.

@terrajobst API가 거의 준비된 것 같지만 1~2가지 더 변경하고 싶은 사항이 있습니다.

• HashCode.Create(x) 는 new HashCode().Combine(x) 와 동일한 효과를 Create 을 Combine 바꾸지 않겠습니까? 첫 번째 필드에 하나를 입력하고 두 번째 필드에 다른 것을 입력해야 하는 것은 다소 성가신 일인 것 같습니다.
• HashCode 가 IEquatable<HashCode> 를 구현하고 등호 연산자를 구현해야 한다고 생각합니다. 이의가 있는 경우 언제든지 알려주십시오.

(잘하면) 최종 제안:

public struct HashCode : IEquatable<HashCode>
{
    public static HashCode Combine(int hash);
    public static HashCode Combine<T>(T obj);

    public HashCode Combine(int hash);
    public HashCode Combine<T>(T obj);

    public int Value { get; }

    public static implicit operator int(HashCode hashCode);

    public static bool operator ==(HashCode left, HashCode right);
    public static bool operator !=(HashCode left, HashCode right);

    public override bool Equals(object obj);
    public override bool Equals(HashCode other);
    public override int GetHashCode();
}

// Usage:

public override int GetHashCode()
{
    return HashCode
        .Combine(_field1)
        .Combine(_field2)
        .Combine(_field3)
        .Combine(_field4);
}

@terrajobst 는 다음과

공정한 지적입니다. @Eilon 의 코드에서 참조했기 때문에 추가했습니다. 경험에 따르면 문자열은 매우 일반적입니다. 반면에 비교를 지정하는 것이 확실하지 않습니다. 일단은 놔두자.

실제로 매우 중요합니다. 문자열에 대한 해시를 생성할 때 문화권과 대소문자 구분을 모두 포함하는 해당 문자열의 목적을 고려해야 하는 경우가 많습니다. StringComparer는 비교 자체에 관한 것이 아니라 문화/대소문자를 인식하는 특정 GetHashCode 구현을 제공하는 것입니다.

이 API가 없으면 다음과 같은 이상한 작업을 수행해야 합니다.

HashCode.Combine(str1.ToLowerInvariant()).Combine(str2.ToLowerInvariant())

그리고 그것은 할당으로 가득 차 있고 문화에 민감한 패턴을 따르지 않습니다.

@Eilon 이 경우 코드는 문화/대소문자를 인식하는 string.GetHashCode(StringComparison comparison) 를 명시적으로 호출하고 결과를 int 로 Combine 합니다.

c# HashCode.Combine(str1.GetHashCode(StringComparer.Ordinal)).Combine(...)

@Eilon , StringComparer.InvariantCultureIgnoreCase.GetHashCode를 사용할 수 있습니다.

할당 측면에서는 확실히 더 좋지만 이러한 호출은 보기에 좋지 않습니다... 우리는 해시에 문화/대소문자 인식 문자열을 포함해야 하는 ASP.NET 전체에서 사용하고 있습니다.

충분히 공평합니다. 위에서 말한 모든 것을 결합하면 이 모양은 어떻습니까?

``` C#
네임스페이스 System.Collections.Generic
{
공개 구조체 해시 코드: IEquatable
{
공개 정적 HashCode 결합(int 해시);
공개 정적 HashCode 결합(T obj);
public static HashCode Combine(문자열 텍스트, StringComparison 비교);

    public HashCode Combine(int hash);
    public HashCode Combine<T>(T obj);
    public HashCode Combine(string text, StringComparison comparison);

    public int Value { get; }

    public static implicit operator int(HashCode hashCode);

    public static bool operator ==(HashCode left, HashCode right);
    public static bool operator !=(HashCode left, HashCode right);

    public override bool Equals(object obj);
    public override bool Equals(HashCode other);
    public override int GetHashCode();
}

}

// 용법:

공개 재정의 int GetHashCode()
{
반환 HashCode.Combine(_field1)
.결합(_field2)
.결합(_field3)
.결합(_field4);
}
```

배송! :-)

@terrajobst _ 잠시만--_ Combine(string, StringComparison) 확장 방법으로 구현할 수 없습니까?

public static class HashCodeExtensions
{
    public static HashCode Combine(this HashCode hashCode, string text, StringComparison comparison)
    {
        switch (comparison)
        {
            case StringComparison.Ordinal:
                return HashCode.Combine(StringComparer.Ordinal.GetHashCode(text));
            case StringComparison.OrdinalIgnoreCase:
                ...
        }
    }
}

유형 서명의 일부보다 확장 방법을 훨씬 더 선호합니다. 그러나 당신이나 @Elion 이 이것이 내장된 방법이어야 한다고 절대적으로 생각한다면 나는 이 제안을 차단하지 않을 것입니다.

( 편집 : 오늘날 내가 알지 못하는 Collection.Generic 에 해시 관련 유형이 없는 한 System.Numerics 도 아마도 더 나은 네임스페이스일 것입니다.)

LGTM. 나는 확장을 갈 것이다.

예, 확장 방법일 수 있지만 어떤 문제를 해결합니까?

@terrajobst

예, 확장 방법일 수 있지만 어떤 문제를 해결합니까?

ASP.NET 코드에서 제안했습니다. 사용 사례에 일반적인 경우 괜찮지만 다른 라이브러리/앱에는 해당되지 않을 수 있습니다. 이것이 나중에 충분히 일반적인 것으로 판명되면 언제든지 재평가하고 별도의 제안에 추가하기로 결정할 수 있습니다.

음 이건 어쨌든 핵심입니다. 일단 정의되면 어쨌든 서명의 일부가 됩니다. 댓글을 스크랩합니다. 그대로입니다.

확장 메서드를 사용하면 다음과 같은 경우에 유용합니다.

1. 유형 자체에 대한 업데이트를 제공하지 않고 보강하려는 기존 유형입니다.
2. 레이어링 문제 해결
3. 훨씬 덜 사용되는 API에서 슈퍼 공통 API를 분리합니다.

나는 (1) 또는 (2)가 여기에 적용되지 않는다고 생각합니다. (3) HashCode 아닌 다른 어셈블리로 코드를 이동하거나 다른 네임스페이스로 이동하는 경우에만 도움이 됩니다. 나는 문자열이 가치가 없을 만큼 충분히 일반적이라고 주장합니다. 사실, 나는 그것들이 너무 일반적이어서 그것들을 확장 유형에서 인위적으로 분리하려고 시도하는 것보다 일급으로 취급하는 것이 더 합리적이라고 주장하기도 합니다.

@terrajobst , 분명히 string API를 완전히 버리고 문자열에 대한 자체 확장 방법을 작성하도록 ASP.NET에 맡길 것을 제안했습니다.

나는 문자열이 가치가 없을 만큼 충분히 일반적이라고 주장합니다. 사실, 나는 그것들이 너무 일반적이어서 그것들을 확장 유형에서 인위적으로 분리하려고 시도하는 것보다 일급으로 취급하는 것이 더 합리적이라고 주장하기도 합니다.

예, 하지만 기존 Combine<T> 오버로드가 처리하지 않는 유일한 시나리오인 문자열의 비서수 해시 코드를 원하는 사람이 얼마나 흔한가요? (예: 재정의에서 StringComparer.CurrentCulture.GetHashCode 를 호출하는 사람?) 제가 틀릴 수도 있지만 많이 보지는 못했습니다.

이에 대한 반발에 대해 죄송합니다. API가 추가되면 되돌릴 수 없습니다.

예, 하지만 누군가가 문자열의 비서수 해시 코드를 얻고 싶어하는 것은 얼마나 흔한 일입니까?

나는 편향될 수 있지만 대소문자 불변성은 꽤 인기가 있습니다. 물론, 문화별 해시 코드에 관심이 있는 사람은 많지 않지만 대소문자를 무시하는 해시 코드는 제가 완전히 볼 수 있습니다. 그리고 @Eilon 이 StringComparison.OrdinalIgnoreCase ).

이에 대한 반발에 대해 죄송합니다. API가 추가되면 되돌릴 수 없습니다.

농담이 아니라 😈 동의하지만 API를 많이 사용하지 않아도 유용하고 해를 끼치 지 않습니다.

@terrajobst 좋아, 그럼 추가하자 @redknightlois가 제안한 것처럼 앞으로 해싱 관련 유형을 더 추가한다면 Collections에서 잘못된 이름이 될 것이라고 생각합니다.

나는 그것을 좋아해. 🍔

나는 해싱이 개념적으로 컬렉션에 속한다고 생각하지 않습니다. System.Runtime은 어떻습니까?

나는 동일하거나 심지어 시스템을 제안하려고했습니다. 숫자도 아닙니다.

@karelz , System.Runtime이 작동할 수 있습니다. @redknightlois 시스템은 이미 해당 네임스페이스를 가져왔을 가능성이 있으므로 편리할 것입니다. 그러나 그것이 적절한지 여부는 알 수 없습니다(다시 말하지만 더 많은 해싱 유형이 추가되는 경우).

난해하고 매우 전문적인 경우를 위한 것이므로 System.Runtime 에 넣으면 안 됩니다. 나는 @KrzysztofCwalina 와 이야기했고 우리는 그것이 둘 중 하나라고 생각합니다.

• System
• System.Collections.*

우리는 둘 다 System 쪽으로 기울고 있습니다.

우리에게 필요한 것이 System 하는 이유라면 정당화를 시도할 수 있습니다. 우리는 object.GetHashCode() 구현을 돕기 위해 HashCode 를 만들었습니다. 둘 다 네임스페이스를 공유하는 것이 적절해 보입니다.

@terrajobst 그러면 System 가 네임스페이스여야 한다고 생각합니다. 하자 :shipit:

설명에서 API 사양을 업데이트했습니다.

[@redknightlois] 우리에게 필요한 것이 System 하는 이유라면 정당화를 시도할 수 있습니다. 우리는 object.GetHashCode() 구현을 돕기 위해 HashCode 를 만들었습니다. 둘 다 네임스페이스를 공유하는 것이 적절해 보입니다.

저와 @KrzysztofCwalina 도 사용한 근거였습니다. 판매 된!

@jamesqo

나는 당신이 구현과 함께 PR도 제공하고 싶다고 가정합니까?

@terrajobst 네, 물론입니다. 시간을 내어 검토해 주셔서 감사합니다.

네, 물론입니다.

달콤한. 그런 경우에는 귀하에게 맡기겠습니다. @karelz님 잘 지내시죠?

시간을 내어 검토해 주셔서 감사합니다.

시간을 내어 API 형태에 대해 작업해 주셔서 감사합니다. 왔다 갔다 하는 것은 고통스러운 과정일 수 있습니다. 양해해 주셔서 감사합니다.

그리고 저는 ASP.NET Core 구현을 삭제하고 대신 이것을 사용하기를 고대하고 있습니다 😄

public static HashCode Combine(문자열 텍스트, StringComparison 비교);
public HashCode Combine(문자열 텍스트, StringComparison 비교);

NIT 다음 메소드 String 이 걸릴 StringComparison (예 Equals , Compare , StartsWith , EndsWith 등 .)를 사용하여 comparisonType 매개 변수의 이름,하지로 comparison . 여기에서도 매개변수의 이름을 comparisonType 로 지정해야 일관성이 있습니까?

@justinvp , 그것은 String 메소드의 명명 결함처럼 보입니다. Type 은(는) 중복됩니다. 이전 API의 "선례를 따르기" 위해 새 API의 매개변수 이름을 더 장황하게 만들어야 한다고 생각하지 않습니다.

또 다른 데이터 포인트로 xUnit 은 comparisonType 도 사용하기로 했습니다.

@justinvp 당신은 나를 설득했습니다. 이제 직관적으로 생각해보면 "대소문자 구분하지 않음" 또는 "문화 종속적"은 비교의 '유형'입니다. 이름을 바꾸겠습니다.

나는 이것의 모양에 문제가 없지만 가능한 대안인 StringComparison에 관해서는 다음과 같습니다.

다음을 포함하지 마십시오.

``` C#
public static HashCode Combine(문자열 텍스트, StringComparison 비교);
public HashCode Combine(문자열 텍스트, StringComparison 비교);

Instead, add a method:

``` C#
public class StringComparer
{
    public static StringComparer FromComparison(StringComparison comparison);
    ...
}

그런 다음 작성하는 대신:

``` C#
공개 재정의 int GetHashCode()
{
반환 HashCode.Combine(_field1)
.결합(_field2)
.결합(_field3)
.Combine(_field4, _비교);
}

you write:

``` C#
public override int GetHashCode()
{
    return HashCode.Combine(_field1)
                   .Combine(_field2)
                   .Combine(_field3)
                   .Combine(StringComparer.FromComparison(_comparison).GetHashCode(_field4));
}

예, 조금 더 길지만 HashCode(방금 시스템으로 승격한)에 대한 두 가지 특수 메서드 없이 동일한 문제를 해결하고 관련 없는 다른 상황에서 사용할 수 있는 정적 도우미 메서드를 얻습니다. 또한 이미 StringComparer가 있는 경우 사용하는 방법과 유사하게 유지합니다(비교자 오버로드에 대해 이야기하지 않기 때문에).

C# public override int GetHashCode() { return HashCode.Combine(_field1) .Combine(_field2) .Combine(_field3) .Combine(_comparer.GetHashCode(_field4)); }

@stephentoub , FromComparison 좋은 생각 같습니다. 실제로 스레드에서 위쪽으로 제안하여 string.GetHashCode(StringComparison) API를 추가하여 예제를 훨씬 더 간단하게 만들었습니다(null이 아닌 문자열로 가정).

public override int GetHashCode()
{
    return HashCode.Combine(_field1)
                   .Combine(_field2)
                   .Combine(_field3)
                   .Combine(_field4.GetHashCode(_comparison));
}

@Elion 은 너무 많은 호출을 추가했다고 말했습니다.

(편집: 귀하의 API에 대한 제안을 했습니다.)

또한 문자열에 대해 HashCode 에 2개의 특수 메서드를 추가하는 것도 싫어합니다.
@Eilon 당신이 언급한 패턴은 ASP.NET Core 자체에서 사용됩니다. 외부 개발자가 얼마나 사용할 것이라고 생각합니까?

@jamesqo 디자인을 @terrajobst가 말했듯이 귀하의 도움과 인내에 감사드립니다. 기본적인 작은 API는 때때로 반복하는 데 시간이 걸릴 수 있습니다. :)

이 API 피드백의 마지막 부분이 어디에 있는지 확인한 다음 구현을 계속 진행할 수 있습니다.

다음이 있어야 합니다.

C# public static HashCode Combine<T>(T obj, IEqualityComparer<T> cmp);

?

(이미 삭제되어 여기에서 누락된 경우 죄송합니다.)

@stephentoub 는 다음과

쓰다:

c# public override int GetHashCode() { return HashCode.Combine(_field1) .Combine(_field2) .Combine(_field3) .Combine(StringComparer.FromComparison(_comparison).GetHashCode(_field4)); }

예, 조금 더 길지만 HashCode(방금 시스템으로 승격한)에 대한 두 가지 특수 메서드 없이 동일한 문제를 해결하고 관련 없는 다른 상황에서 사용할 수 있는 정적 도우미 메서드를 얻습니다. 또한 이미 StringComparer가 있는 경우 사용하는 방법과 유사하게 유지합니다(비교자 오버로드에 대해 이야기하지 않기 때문에).

글쎄요, 그것은 단지 조금 더 긴 것이 아니라 정말 더 길어지고 발견 가능성이 전혀 없는 것과 같습니다.

이 방법을 추가하는 것에 대한 저항은 무엇입니까? 유용하고 정확하게 구현될 수 있고 하는 일에 모호함이 없다면 추가하지 않는 이유는 무엇입니까?

정적 도우미/변환 방법을 추가로 사용하는 것은 괜찮습니다. 사용할지는 모르겠지만 편리한 방법을 희생하는 이유는 무엇입니까?

편의 방법을 희생하는 이유는 무엇입니까?

나에게 편리한 방법이 명확하지 않기 때문에 여기에 정말 필요합니다. ASP.NET이 다양한 위치에서 수행한다는 것을 알았습니다. 몇 군데? 그리고 그 중 얼마나 많은 곳에서 알려진 값이 아니라 실제로 변수 StringComparison이 있습니까? 이 경우 내가 언급한 도우미가 필요하지 않으며 다음을 수행할 수 있습니다.

``` C#
.Combine(StringComparer.InvariantCulture.GetHashCode(_field4))

which in no way seems onerous to me or any more undiscoverable than knowing about StringComparison and doing:

``` C#
.Combine(_field4, StringComparison.InvariantCulture);

개발자가 작성할 수 있는 것과 똑같은 작업을 수행하기 위해 Combine 내부에서 분기할 필요가 없기 때문에 실제로 더 빠릅니다. 추가 코드가 그 한 가지 경우에 대해 특수 오버로드를 추가할 가치가 있는 불편함이 있습니까? StringComparer에 대한 오버로드가 아닌 이유는 무엇입니까? EqualityComparer에 과부하가 걸리지 않는 이유는 무엇입니까? Func<T, int> 를 사용하는 오버로드가 아닌 이유는 무엇입니까? 어느 시점에서 당신은 선을 그리고 "이 과부하가 제공하는 가치는 그만한 가치가 없다"고 말합니다. 왜냐하면 우리가 추가하는 모든 것은 유지 비용이든, 코드 크기 비용이든, 무엇이든 비용이 들기 때문입니다. , 개발자가 이 케이스를 정말로 필요로 한다면, 개발자가 더 적은 수의 특수 케이스로 처리할 추가 코드가 거의 없습니다. 그래서 나는 선을 그을 수 있는 적절한 장소가 오버로드 이후가 아니라 이러한 오버로드 이전일 것이라고 제안하고 있었습니다(그러나 이전 응답의 시작 부분에서 언급했듯이 "나는 이 모양으로 괜찮습니다"하고 대안을 제안하고 있었습니다) .

내가 한 검색은 다음과 같습니다. https://github.com/search?p=2&q=user%3Aaspnet+hashcodecombiner&type=Code&utf8=%E2%9C%93

~100개의 일치 항목 중 처음 몇 페이지부터 거의 모든 사용 사례에는 문자열이 있으며 여러 경우에는 다양한 종류의 문자열 비교를 사용합니다.

1. 서수: https://github.com/aspnet/Razor/blob/77ed9f22fc8894fbce796bb8a704d6cd03a3b226/src/Microsoft.AspNetCore.Razor.TagHelpers.Testing.Sources/TagHelperAttributeDescriptorComparer.cs
2. 서수 + IgnoreCase: https://github.com/aspnet/Razor/blob/bdbb854bdbde260b3c70f565a93ebbb185a7c5a7/src/Microsoft.AspNetCore.Razor/Compilation/TagHelpers/TagHelperRequiredAttributeDescriptor
3. 서수: https://github.com/aspnet/Razor/blob/bdbb854bdbde260b3c70f565a93ebbb185a7c5a7/src/Microsoft.AspNetCore.Razor/Chunks/Generators/AttributeBlockChunkGenerator.cs#L58
4. 서수: https://github.com/aspnet/Razor/blob/77ed9f22fc8894fbce796bb8a704d6cd03a3b226/src/Microsoft.AspNetCore.Razor.TagHelpers.Testing.Sources/TagHelperDesignTimeDescriptor.cs#L4Comparer.
5. 서수: https://github.com/aspnet/Razor/blob/dbcb6901209859e471c9aa978912cf7d6c178668/src/Microsoft.AspNetCore.Razor.Evolution/Legacy/AttributeBlockChunkGenerator.cs#L56
6. 서수: https://github.com/aspnet/Razor/blob/77ed9f22fc8894fbce796bb8a704d6cd03a3b226/src/Microsoft.AspNetCore.Razor.TagHelpers.Testing.Sources/CaseSensitiveTagHelper.cs#L6Compar2
7. 서수 + 케이스 무시: https://github.com/aspnet/dnx/blob/bebc991012fe633ecac69675b2e892f568b927a5/src/Microsoft.Dnx.Tooling/NuGet/Core/PackageSource/PackageSource.cs#L107
8. 서수: https://github.com/aspnet/Razor/blob/bdbb854bdbde260b3c70f565a93ebbb185a7c5a7/src/Microsoft.AspNetCore.Razor/Tokenizer/Symbols/SymbolBase.cs#L52
9. 서수: https://github.com/aspnet/Razor/blob/77ed9f22fc8894fbce796bb8a704d6cd03a3b226/src/Microsoft.AspNetCore.Razor.TagHelpers.Testing.Sources/CaseSensitiveTagHelperAttributeComparer.
10. 서수: https://github.com/aspnet/Razor/blob/77ed9f22fc8894fbce796bb8a704d6cd03a3b226/src/Microsoft.AspNetCore.Razor.TagHelpers.Testing.Sources/TagHelperAttributeDesignTimeDescriptor4Comparer

(그리고 수십명의 다른 사람들.)

따라서 확실히 ASP.NET Core 코드베이스 내에서 이것은 매우 일반적인 패턴인 것 같습니다. 물론 다른 시스템과 대화할 수는 없습니다.

~100경기 중

당신이 나열한 10개 중 하나(나머지 검색은 보지 않았습니다)는 변수에서 가져오는 것이 아니라 문자열 비교를 명시적으로 지정하므로 다음과 같은 차이점에 대해 이야기하고 있는 것이 아닙니다.

``` C#
.Combine(이름, StringComparison.OrdinalIgnoreCase)

``` C#
.Combine(StringComparer.OrdinalIgnoreCase.GetHashCode(Name))

? 내가 뭔가를 놓치고 있지 않는 한 "정말 더 이상"이 아니며 더 효율적입니다.

어쨌든, 내가 말했듯이, 나는 단순히 우리가 이러한 과부하가 필요한지 여부를 정말로 고려할 것을 제안하는 것입니다. 대부분의 사람들이 그렇다고 믿고 있고 우리 자신의 ASP.NET 코드베이스를 고려하고 있지 않다면 괜찮습니다.

관련하여 null 입력에 대해 계획 중인 동작은 무엇입니까? int==0은 어떻습니까? StringComparer.GetHashCode가 일반적으로 null 입력에 대해 throw한다고 생각하므로 null을 전달하도록 허용하면 문자열 오버로드에 대한 더 많은 이점을 볼 수 있습니다. 따라서 이것이 실제로 일반적인 경우 호출자가 특별한 경우 null. 그러나 그것은 또한 null이 제공될 때 동작이 무엇인지에 대한 질문을 제기합니다. 다른 값과 마찬가지로 해시 코드에 0이 혼합되어 있습니까? 그것은 nop 및 해시 코드로 처리됩니까?

null에 대한 가장 일반적인 접근 방식은 0을 혼합하는 것입니다. 추가된 단일 null 요소의 경우 nop으로 사용하는 것이 더 좋지만 누군가 시퀀스로 공급하는 경우 10개의 null 해시를 20과 다르게 사용하는 것이 더 유리합니다.

실제로 내 투표는 문자열을 인식하는 오버로드가 있으면 매우 도움이 되는 ASP.NET Core의 코드베이스 관점에서 나온 것입니다. 줄 길이에 관한 것은 내 주요 관심사가 아니라 검색 가능성에 관한 것이었습니다.

시스템에서 문자열 인식 오버로드를 사용할 수 없는 경우 ASP.NET Core에 내부 확장 메서드를 추가하고 사용하면 됩니다.

시스템에서 문자열 인식 오버로드를 사용할 수 없는 경우 ASP.NET Core에 내부 확장 메서드를 추가하고 사용하면 됩니다.

이러한 API가 일반적으로 ASP.NET Core 코드 기반 외부에서도 필요하다는 더 많은 증거를 볼 때까지는 이것이 현재로서는 훌륭한 솔루션이 될 것이라고 생각합니다.

string 오버로드를 제거할 때 값을 볼 수 없다고 말하고 싶습니다. 복잡성을 줄이지 않고 코드를 더 효율적으로 만들지 않으며 StringComparison 에서 StringComparer 를 반환하는 메서드를 제공하는 것과 같이 다른 영역을 개선하는 데 방해가 되지 않습니다. StringComparison . .NET은 항상 일반적인 경우를 쉽게 만드는 것에 중점을 두었기 때문에 구문 설탕은 _중요합니다_. 또한 개발자가 올바른 일을 하고 성공의 구덩이에 빠지도록 안내하고 싶습니다.

우리는 문자열이 특별하고 믿을 수 없을 정도로 흔하다는 것을 인식해야 합니다. 그것들을 전문화하는 오버로드를 추가함으로써 우리는 두 가지를 달성합니다:

1. @Eilon 과 같은 시나리오를 훨씬 쉽게 만듭니다.
2. 문자열, 특히 대소문자 비교를 고려하는 것이 중요하다는 것을 발견할 수 있습니다.

또한 위에서 언급한 @Eilon 확장 메서드와 같은 일반적인 상용구 도우미는 좋은 것이 아니라 나쁜 것임을 고려해야 합니다. 그 결과 도우미 메서드를 복사하여 붙여넣는 데 시간이 낭비되고 제대로 수행되지 않으면 불필요한 코드 팽창과 버그가 발생할 수 있습니다.

그러나 주요 관심사가 특수 대/소문자 string 경우 다음은 어떻습니까?

``` C#
공개 구조체 해시 코드: IEquatable
{
공개 HashCode 결합(T obj, IEqualityComparer비교자);
}

// 용법
반환 HashCode.Combine(_numberField)
.Combine(_stringField, StringComparer.OrdinalIgnoreCase);
```

@terrajobst , 당신의 타협은 영리한 것입니다. 더 이상 GetHashCode 명시적으로 호출하거나 사용자 정의 비교자를 사용하여 추가 괄호 세트를 중첩할 필요가 없다는 점이 마음에 듭니다.

(편집: 스레드에서 앞서 언급한 @JonHanna 덕분에 정말 크레딧을 같은데요 ? 😄 )

@JonHanna 예, null 입력도 0으로 해시할 것입니다.

여기서 대화를 방해해서 죄송합니다. 그러나 새 유형을 어디에 넣어야 합니까? @mellinoe @ericstj @weshaggard , System.HashCode 와 같은 이 유형에 대한 새 어셈블리/패키지를 만들거나 System.Runtime.Extensions 와 같은 기존 어셈블리에 추가해야 합니까? 감사 해요.

우리는 최근에 .NET Core의 어셈블리 레이아웃을 상당히 리팩토링했습니다. System.Runtime.Extensions 를 나타내는 것으로 보이는 구체적인 비교자가 있는 곳에 두는 것이 좋습니다.

@weshaggard?

@terrajobst 제안 자체와 관련하여 Combine 모두 지정할 수 없다는 것을 방금 알았습니다. 😢

다음은 인스턴스 및 정적 메서드의 이름이 같을 수 없기 때문에 컴파일러 오류가 발생 합니다.

using System;
using System.Collections.Generic;

public struct HashCode
{
    public void Combine(int i)
    {
    }

    public static void Combine(int i)
    {
    }
}

이제 2가지 옵션이 있습니다.

• 정적 오버로드의 이름을 Create , Seed 등과 같은 다른 이름으로 바꿉니다.
• 정적 오버로드를 다른 정적 클래스로 이동합니다.

public static class Hash
{
    public static HashCode Combine(int hash);
}

public struct HashCode
{
    public HashCode Combine(int hash);
}

// Usage:
return Hash.Combine(_field1)
           .Combine(_field2)
           .Combine(_field3);

저는 후자를 선호합니다. 이 문제를 해결해야 하는 것은 유감이지만... 생각은?

논리를 2가지 유형으로 분리하는 것은 나에게 이상하게 들립니다. HashCode 를 사용하려면 연결을 만들고 대신 Hash 클래스로 시작해야 합니다.

차라리 Create 메서드(또는 Seed 또는 Init )를 추가하고 싶습니다.
나는 또한 no-args 오버로드 HashCode.Create().Combine(_field1).Combine(_field2) 추가할 것입니다.

@karelz , 같은 이름이 아닌 경우 팩토리 메서드를 추가해야 한다고 생각하지 않습니다. 매개변수가 없는 생성자 new 가 더 자연스럽기 때문에 제공해야 합니다. 게다가 e는 구조체이기 때문에 사람들이 new HashCode().Combine 를 쓰는 것을 막을 수 없습니다.

public override int GetHashCode()
{
    return new HashCode()
        .Combine(_field1)
        ...
}

이것은 해시 코드에서 직접 초기화하는 대신 0 및 _field1 의 해시 코드와 추가 결합을 수행합니다. 그러나 우리가 사용 하고 있는

제안된 API(업데이트된 사양):

namespace System
{
    public struct HashCode : IEquatable<HashCode>
    {
        public HashCode Combine(int hash);
        public HashCode Combine<T>(T obj);
        public HashCode Combine<T>(T obj, IEqualityComparer<T> comparer);

        public int Value { get; }

        public static implicit operator int(HashCode hashCode);

        public static bool operator ==(HashCode left, HashCode right);
        public static bool operator !=(HashCode left, HashCode right);

        public override bool Equals(object obj);
        public override bool Equals(HashCode other);
        public override int GetHashCode();
    }
}

@redknightlois @JonHanna @stephentoub @Eilon , 팩토리 메소드와 기본 생성자를 사용하는 것에 대한 의견이 있습니까? 컴파일러는 인스턴스 메서드와 충돌하기 때문에 정적 Combine 오버로드를 허용하지 않으므로 다음 중 하나의 옵션이 있습니다.

HashCode.Create(field1).Combine(field2) // ...

// or, using default constructor

new HashCode().Combine(field1).Combine(field2) // ...

첫 번째의 장점은 조금 더 간결하다는 것입니다. 두 번째의 장점은 일관된 이름 지정을 가지므로 첫 번째 필드에 대해 다른 것을 작성할 필요가 없다는 것입니다.

또 다른 가능성은 Combine 팩토리가 있는 유형과 Combine 인스턴스가 있는 유형(또는 첫 번째 유형의 확장인 두 번째 유형)의 두 가지 다른 유형입니다.

어느 것이 TBH를 선호하는지 잘 모르겠습니다.

@JonHanna , 인스턴스 오버로드가 확장 메소드라는 두 번째 아이디어는 훌륭하게 들립니다. 즉, hc.Combine(obj) 이 경우 정적 과부하: TryRoslyn 을 선택하려고 합니다.

위의 몇 가지 의견을 시작점 으로 정적 클래스를 사용하는 것을 제안했는데, 이는 저에게 상기시켜줍니다...

논리를 2가지 유형으로 분리하는 것은 나에게 이상하게 들립니다. HashCode를 사용하려면 연결을 만들고 대신 Hash 클래스로 시작해야 합니다.

사람들은 어떤 연결을 해야 할까요? 먼저 Hash 를 소개한 다음 거기에서 HashCode 이동할 수 있습니까? 새로운 정적 클래스를 추가하는 것이 문제가 될 것이라고 생각하지 않습니다.

논리를 2가지 유형으로 분리하는 것은 나에게 이상하게 들립니다. HashCode를 사용하려면 연결을 만들고 대신 Hash 클래스로 시작해야 합니다.

최상위 유형을 HashCode 하고 구조체를 중첩할 수 있습니다. 이렇게 하면 API의 "진입점"을 하나의 최상위 유형으로 유지하면서 원하는 사용을 허용할 수 있습니다. 예:

``` C#
네임스페이스 시스템
{
공개 정적 클래스 HashCode
{
공개 정적 HashCodeValue 결합(int 해시);
공개 정적 HashCodeValue 결합(T obj);
공개 정적 HashCodeValue 결합(T obj, IEqualityComparer비교자);

    public struct HashCodeValue : IEquatable<HashCodeValue>
    {
        public HashCodeValue Combine(int hash);
        public HashCodeValue Combine<T>(T obj);
        public HashCodeValue Combine<T>(T obj, IEqualityComparer<T> comparer);

        public int Value { get; }

        public static implicit operator int(HashCodeValue hashCode);

        public static bool operator ==(HashCodeValue left, HashCodeValue right);
        public static bool operator !=(HashCodeValue left, HashCodeValue right);

        public bool Equals(HashCodeValue other);
        public override bool Equals(object obj);
        public override int GetHashCode();
    }
}

}
```

편집: HashCodeValue.Value 가 약간 중복되기 때문에 중첩 유형에 대해 HashCodeValue 보다 더 나은 이름이 필요할 수 있지만 Value 가 많이 사용되지는 않습니다. 자주. 어쩌면 우리는 심지어 필요가 없습니다 Value 속성을 - 당신이 얻을 수있는 Value 를 통해 GetHashCode() 당신을 캐스팅하지 않으려면 int .

@justinvp 하지만 처음에 두 개의 개별 유형을 갖는 데 문제가 무엇입니까? 이 시스템은 예를 들어 LinkedList<T> 및 LinkedListNode<T> 에 대해 잘 작동하는 것 같습니다.

그러나 처음에 두 개의 별도 유형을 갖는 데 문제가 무엇입니까?

두 가지 최상위 유형에는 두 가지 우려 사항이 있습니다.

1. API의 "진입점" 유형은 무엇입니까? 이름이 Hash 및 HashCode 경우 어느 것으로 시작합니까? 그 이름에서 명확하지 않습니다. LinkedList<T> 및 LinkedListNode<T> 하면 어느 것이 주요 진입점 LinkedList<T> 이고 어느 것이 도우미인지 매우 명확합니다.
2. System 네임스페이스를 오염시킵니다. (1)만큼 우려할 사항은 아니지만 System 네임스페이스에 새로운 기능을 노출하는 것을 고려할 때 염두에 두어야 할 사항입니다.

중첩은 이러한 문제를 완화하는 데 도움이 됩니다.

@justinvp

API의 "진입점" 유형은 무엇입니까? 이름이 Hash와 HashCode라면 어떤 것으로 시작하시겠습니까? 그 이름에서 명확하지 않습니다. LinkedList 사용및 LinkedListNode어느 것이 주요 진입점인 LinkedList인지는 매우 분명합니다., 그리고 이것은 도우미입니다.

알겠습니다. 충분한 지적입니다. 중첩 유형이 아닌 Hash 및 HashValue 유형의 이름을 지정하면 어떻게 될까요? 그것은 두 유형 사이의 종속적인 관계를 충분히 의미합니까?

그렇게 하면 팩토리 메소드가 훨씬 간결해집니다. Hash.Combine(field1).Combine(field2) . 또한 구조체 유형 자체를 사용하는 것은 여전히 ​​실용적입니다. 예를 들어 누군가 해시 목록을 수집하고 이를 독자에게 전달하기 위해 List<int> 대신 List<HashValue> 를 사용할 수 있습니다. 중첩 유형을 List<HashCode.HashCodeValue> 로 만든 경우에는 잘 작동하지 않을 수 있습니다( List<Hash.Value> 도 언뜻 보기에는 다소 혼란스럽습니다).

시스템 네임스페이스를 오염시킵니다. (1)만큼 우려할 사항은 아니지만 System 네임스페이스에 새로운 기능을 노출하는 것을 고려할 때 염두에 두어야 할 사항입니다.

동의합니다. 하지만 우리가 관례를 따르고 사용 편의성을 희생하지 않는 것도 중요하다고 생각합니다. 예를 들어 중첩 유형이 있는 곳에서 생각할 수 있는 유일한 BCL API(불변 컬렉션은 포함되지 않으며 엄격하게 프레임워크의 일부가 아님)는 중첩된 유형을 적극적으로 숨기려는 List<T>.Enumerator . 컴파일러 사용을 위한 형식이기 때문입니다. 이 경우에는 그렇게 하고 싶지 않습니다.

Value 속성이 필요하지 않을 수도 있습니다. int로 변환하지 않으려면 GetHashCode()를 통해 Value를 얻을 수 있습니다.

나는 더 일찍 그것에 대해 생각했다. 그러나 사용자는 유형이 GetHashCode 재정의하거나 암시적 연산자가 있다는 것을 어떻게 알 수 있습니까?

제안된 API

public static class Hash
{
    public static HashValue Combine(int hash);
    public static HashValue Combine<T>(T obj);
    public static HashValue Combine<T>(T obj, IEqualityComparer<T> comparer);
}

public struct HashValue : IEquatable<HashValue>
{
    public HashValue Combine(int hash);
    public HashValue Combine<T>(T obj);
    public HashValue Combine<T>(T obj, IEqualityComparer<T> comparer);

    public int Value { get; }

    public static implicit operator int(HashValue hashValue);

    public static bool operator ==(HashValue left, HashValue right);
    public static bool operator !=(HashValue left, HashValue right);

    public override bool Equals(object obj);
    public bool Equals(HashValue other);
    public override int GetHashCode();
}

중첩 유형이 아닌 Hash 및 HashValue 유형의 이름을 지정하면 어떻게 될까요?

Hash 는 나에게 너무 일반적인 이름으로 보입니다. 진입점 API의 이름에 HashCode 가 있어야 한다고 생각합니다. 그 목적은 GetHash() 아니라 GetHashCode() 구현을 돕는 것이기 때문입니다.

누군가 해시 목록을 수집하고 이를 독자에게 전달하기를 원할 수 있습니다.목록 대신 사용됩니다.. 유형을 중첩하면 잘 작동하지 않을 수 있습니다.(심지어 목록언뜻보기에는 다소 혼란 스럽습니다).

이것은 가능성이 희박한 사용 사례처럼 보입니다. 디자인을 최적화해야 하는지 확신이 서지 않습니다.

중첩 유형이 있는 위치를 생각할 수 있는 유일한 BCL API

TimeZoneInfo.AdjustmentRule 및 TimeZoneInfo.TransitionTime 는 의도적으로 중첩 유형으로 추가된 BCL의 예입니다.

@justinvp

진입점 API의 이름에 HashCode가 있어야 한다고 생각합니다. 그 목적은 GetHash()가 아니라 GetHashCode() 구현을 돕는 것이기 때문입니다.

👍 알겠습니다.

좀 더 생각해 봤습니다. 중첩된 구조체를 갖는 것이 합리적으로 보입니다. 당신이 언급했듯이 대부분의 사람들은 실제 유형을 보지 못할 것입니다. 한 가지만: 유형을 HashCodeValue 대신 Seed 라고 해야 한다고 생각합니다. 이름의 컨텍스트는 포함하는 클래스에 이미 암시되어 있습니다.

제안된 API

namespace System
{
    public static class HashCode
    {
        public static Seed Combine(int hash);
        public static Seed Combine<T>(T obj);
        public static Seed Combine<T>(T obj, IEqualityComparer<T> comparer);

        public struct Seed : IEquatable<Seed>
        {
            public Seed Combine(int hash);
            public Seed Combine<T>(T obj);
            public Seed Combine<T>(T obj, IEqualityComparer<T> comparer);

            public int Value { get; }

            public static implicit operator int(Seed seed);

            public static bool operator ==(Seed left, Seed right);
            public static bool operator !=(Seed left, Seed right);

            public bool Equals(Seed other);
            public override bool Equals(object obj);
            public override int GetHashCode();
        }
    }
}

@jamesqo 대신 public readonly int Value 사용하는 것에 대한 이의 또는 구현 문제가 있습니까? Seed 는 기술적으로 첫 번째 결합 후 시드가 아니라는 것입니다.

또한 @justinvp에 동의합니다. Hash 는 해시를 처리하기 위해 예약해야 합니다. 이것은 HashCode 대신 처리하는 것을 단순화하기 위해 도입되었습니다.

@redknightlois 분명히

        public struct Seed : IEquatable<Seed>
        {
            public Seed Combine(int hash);
            public Seed Combine<T>(T obj);
            public Seed Combine<T>(T obj, IEqualityComparer<T> comparer);

            public int Value { get; }

            public static implicit operator int(Seed seed);

            public static bool operator ==(Seed left, Seed right);
            public static bool operator !=(Seed left, Seed right);

            public bool Equals(Seed other);
            public override bool Equals(object obj);
            public override int GetHashCode();
        }

용법:
c# int hashCode = HashCode.Combine(field1).Combine(name, StringComparison.OrdinalIgnoreCase).Value; int hashCode = (int)HashCode.Combine(field1).Combine(field2);

Seed의 문제는 기술적으로 첫 번째 결합 후 종자가 아니라는 것입니다.

그것은 새로운 씨앗을 생산하는 다음 결합의 씨앗입니다.

대신 public readonly int Value를 사용하는 것에 대한 반대 또는 구현 문제가 있습니까?

왜요? int Value { get; } 는 보다 관용적이며 쉽게 인라인될 수 있습니다.

그것은 새로운 씨앗을 생산하는 다음 결합의 씨앗입니다.

묘목이 아니겠습니까? ;)

@jamesqo 내 경험에

편집: 또한 해당 구조체가 실제로 변경 불가능하다는 아이디어도 추진합니다.

내 경험에 따르면 복잡한 코드 속성으로 둘러싸여 있으면 필드보다 더 나쁜 코드를 생성하는 경향이 있습니다(그 중에서 인라인이 아님).

자동 구현 속성이 항상 인라인되지 않는 단일 비 디버그 빌드를 찾으면 이는 JIT 문제이며 확실히 수정해야 합니다.

또한 구조체에 있는 단일 int의 읽기 전용 필드는 레지스터에서 바로 변환됩니다.

읽기 전용이라고 생각할 수 있기 때문에 허용될 수 있는 최적화가 있습니다.

이 구조체의 지원 필드는 읽기 전용입니다. API는 접근자가 될 것입니다.

속성을 사용하면 성능이 저하될 것이라고 생각하지 않습니다.

@jamesqo 찾으면 명심하겠습니다. 성능에 민감한 코드의 경우 그 때문에 더 이상 속성을 사용하지 않습니다(이 시점에서 근육 메모리).

중첩된 구조체를 "Seed"가 아닌 "State"라고 부르는 것을 고려할 수 있습니까?

@ellismg 물론입니다. 제안 감사합니다. 나는 내부 구조체에 대한 좋은 이름을 생각해내기 위해 고군분투했습니다.

@karelz 이 API는 마침내 사용할 수 있다고 생각합니다. 이번에는 모든 것이 컴파일되는지 확인했습니다. 아무도 이의를 제기하지 않는 한 이에 대한 구현 작업을 시작하겠습니다.

@jamesqo @JonHanna 왜 우리는 필요 않은 Combine<T>(T obj) 대신 Combine(object o) ?

콤바인이 필요한 이유Combine(object o) 대신 (T obj)?

인스턴스가 구조체인 경우 후자는 할당합니다.

앗, 설명 감사합니다.

중첩 유형은 디자인을 복잡하게 만들기 때문에 좋아하지 않습니다. 근본적인 문제는 정적 및 비정적 이름을 동일하게 지정할 수 없다는 것입니다. 정적을 제거하거나 이름을 변경하는 두 가지 옵션이 있습니다. Create 이름을 바꾸는 것이 기본 생성자를 사용하는 것과 비교하여 상당히 읽기 쉬운 코드를 생성하므로 가장 의미가 있다고 생각합니다.

강력한 반대가 없는 한 우리가 결정한 디자인은 다음과 같습니다.

```C#
네임스페이스 시스템
{
공개 구조체 해시 코드: IEquatable
{
공개 정적 HashCode Create(int hashCode);
공개 정적 HashCode 만들기(T obj);
공개 정적 HashCode 만들기(T obj, IEqualityComparer비교자);

    public HashCode Combine(int hashCode);
    public HashCode Combine<T>(T obj);
    public HashCode Combine<T>(T obj, IEqualityComparer<T> comparer);

    public int Value { get; }

    public static implicit operator int(HashCode hashCode);

    public static bool operator ==(HashCode left, HashCode right);
    public static bool operator !=(HashCode left, HashCode right);

    public bool Equals(HashCode other);
    public override bool Equals(object obj);
    public override int GetHashCode();
}

}
```

승인된 제안에 대한 강력한 피드백이 있는지 확인하기 위해 추가 피드백이 있을 때까지 며칠을 기다려 보겠습니다. 그러면 우리는 그것을 '잡기 위해' 만들 수 있습니다.

디자인을 복잡하게 만드는 이유는 무엇입니까? 우리가 실제로 코드에서 HashCode.State를 사용해야 한다면(예: 변수 유형 정의) 그것이 얼마나 나쁠지 이해할 수 있지만 종종 그럴 것으로 예상합니까? 대부분의 경우 Value를 완전히 반환하거나 int로 변환하여 저장하게 됩니다.

저는 Create와 Combine의 조합이 더 나쁘다고 생각합니다.

https://github.com/dotnet/corefx/issues/8034#issuecomment -262661653을 참조

@terrajobst

Create로 이름을 바꾸는 것이 기본 생성자를 사용하는 것과 비교하여 상당히 읽기 쉬운 코드를 생성하므로 가장 의미가 있다고 생각합니다.

강력한 반대가 없는 한 우리가 결정한 디자인은 다음과 같습니다.

우리는 단순히 정적 추가 할 수 있습니다 ... 난 당신을 듣고,하지만 난 구현 작업을하는 동안 마지막 순간 생각했다 Zero / Empty 에 속성을 HashCode , 그런 다음 사람들이 거기에서 Combine 전화하도록 합니까? 그러면 별도의 Combine / Create 메서드가 필요하지 않습니다.

namespace System
{
    public struct HashCode : IEquatable<HashCode>
    {
        public static HashCode Empty { get; }

        public HashCode Combine(int hashCode);
        public HashCode Combine<T>(T obj);
        public HashCode Combine<T>(T obj, IEqualityComparer<T> comparer);

        public int Value { get; }

        public static implicit operator int(HashCode hashCode);

        public static bool operator ==(HashCode left, HashCode right);
        public static bool operator !=(HashCode left, HashCode right);

        public bool Equals(HashCode other);
        public override bool Equals(object obj);
        public override int GetHashCode();
    }
}

int GetHashCode()
{
    return HashCode.Empty
        .Combine(_1)
        .Combine(_2);
}

다른 사람이 이것이 좋은 생각이라고 생각합니까? (그동안 PR을 제출하고 사람들이 그렇게 생각하면 PR에서 변경하겠습니다.)

@jamesqo , 저는 Empty/Zero 아이디어를 좋아합니다.

나는 그것으로 괜찮을 것입니다 ( Empty 대 Create 공장 사이에 강한 선호도가 없음) ... @weshaggard @bartonjs @stephentoub @terrajobst 여러분은 어떻게 생각하시나요?

저는 개인적으로 Create()가 더 낫다고 생각합니다. 하지만 같은 HashCode.Empty 보다 new HashCode() .

operator-new가 없는 버전을 허용하고 나중에 Create를 부트스트래퍼로 정말로 원한다는 결정을 배제하지 않기 때문에... ::shrug::.

이것이 내 반발의 전체 범위입니다(별로 많지는 않음).

FWIW Empty / Zero 대신 Create 투표하겠습니다. 모든 것을 Empty / Zero 중단하는 것보다 실제 값으로 시작하고 싶습니다. 기분이 이상하다/이상해 보인다.

그것은 또한 가난한 종자 경향이 있는 0으로 파종하는 사람들을 낙담시킵니다.

나는 비어있는 것보다 만들기를 선호합니다. 그것은 내가 그것에 대해 어떻게 생각하는지 의아해합니다. 해시 코드를 만들고 추가 값을 혼합하고 싶습니다. 중첩 접근 방식도 괜찮습니다.

내가 그것을 Empty라고 부르는 것은 좋은 생각이 아니라고 말하려고 했지만(그리고 이미 말한 바 있음), 세 번째 생각 후에 나는 여전히 그것이 나쁜 해결책이 아니라고 생각합니다. 빌더와 같은 것은 어떻습니까? 여전히 0을 사용할 수는 있지만 단어는 바로 사용하는 것을 권장하지 않습니다.

@JonHanna 명확히 하기 위해: Create 대한 투표를 의미했습니까?

그리고 네 번째는 Create 대신 With에 대해 생각했습니다.

HashCode.With(a).Combine(b). 결합(c)

최신 토론을 기반으로 한 사용 예( Create 가 대체 이름으로 대체될 수 있음):

```c#
공개 재정의 int GetHashCode() =>
HashCode.Create(_field1).Combine(_field2).Combine(_field3);

We went down the path of this chaining approach, but didn't reconsider earlier proposals when the static & instance `Combine` methods didn't pan out...

Are we sure we don't want something like the existing `Path.Combine` pattern, that was proposed previously, with a handful of generic `Combine` overloads? e.g.:

```c#
public override int GetHashCode() =>
    HashCode.Combine(_field1, _field2, _field3);

@justinvp 일관성 없는 코드 + 더 많은 지팅으로 이어질 것입니다. 더 일반적인 조합으로 생각합니다. 그것이 바람직한 것으로 판명되면 우리는 항상 다른 문제에서 이것을 다시 논의할 수 있습니다.

그만한 가치가 있기 때문에 최소한 사용법에서는 원래 제안된 버전을 선호합니다(코드 크기, 지팅 등에 관한 주석은 확실하지 않음). 다른 arity의 몇 가지 오버로드를 사용하여 하나의 메서드로 표현될 수 있는 무언가에 대해 추가 구조와 10개 이상의 다른 멤버를 갖는 것은 과잉처럼 보입니다. 나는 또한 일반적으로 유창한 스타일 API의 팬이 아니므로 아마도 그것이 내 의견에 영향을 미칠 것입니다.

조금 이상하고 아직 내 기분이 어떤지 확신이 서지 않기 때문에 이것을 언급하지 않을 예정입니다. 그러나 여기에 다른 아이디어가 있습니다. 모든 대안이 고려되었는지 확인하기 위한 것입니다...

유사한 Add 메서드를 사용하여 ASP.NET Core의 변경 가능한 HashCodeCombiner "빌더" 라인을 따라 무언가를 수행했지만 컬렉션 이니셜라이저 구문에 대한 지원도 포함했다면?

용법:

```c#
공개 재정의 int GetHashCode() =>
새로운 해시 코드 { _field1, _field2, _field3 };

With a surface area something like:

```c#
namespace System
{
    public struct HashCode : IEquatable<HashCode>, IEnumerable
    {
        public void Add(int hashCode);
        public void Add<T>(T obj);
        public void Add<T>(T obj, IEqualityComparer<T> comparer);

        public int Value { get; }

        public static implicit operator int(HashCode hashCode);

        public static bool operator ==(HashCode left, HashCode right);
        public static bool operator !=(HashCode left, HashCode right);

        public bool Equals(HashCode other);
        public override bool Equals(object obj);
        public override int GetHashCode();

        IEnumerator IEnumerable.GetEnumerator();
    }
}

컬렉션 이니셜라이저 구문을 활성화하려면 최소한 하나의 Add 메서드와 함께 IEnumerable 를 구현해야 합니다. IEnumerable 는 명시적으로 구현하여 Intellisense에서 숨기고 GetEnumerator 는 NotSupportedException 를 던지거나 해시 코드 값을 열거 가능한 단일 결합 항목으로 반환할 수 있습니다. 그것을 사용하십시오 (드문 일입니다).

@justinvp , 흥미로운 아이디어가 있습니다. 그러나 나는 정중하게 동의하지 않습니다. HashCode 는 가변 구조체가 있는 문제를 피하기 위해 불변으로 유지되어야 한다고 생각합니다. 또한 이를 위해 IEnumerable 를 구현해야 하는 것은 다소 인공적이거나 불안정해 보입니다. 누군가 파일에 using System.Linq 지시문이 있는 경우 HashCode 옆에 점을 넣으면 Cast<> 및 OfType<> 가 확장 메서드로 표시됩니다. 나는 우리가 현재 제안에 더 가까이 다가가야 한다고 생각합니다.

@jamesqo , 동의합니다. 따라서 언급하는 것조차 주저합니다. 내가 그것에 대해 좋아하는 유일한 것은 사용법이 체인보다 깨끗할 수 있다는 것입니다. 그러나 컬렉션 이니셜라이저가 샘플 사용법을 보지 않고도 사용할 수 있다는 것이 분명하지 않기 때문에 그 자체가 또 다른 단점입니다.

@MadsTorgersen , @jaredpar , 컬렉션 이니셜라이저에 IEnumerable 구현이 필요한 이유\위의 @justinvp의 세 번째 의견.

@jamesqo , 나는 이것을 불변(IEnumerable이 아닌)으로 유지하는 것이 낫다는 데 동의합니다.

@mellinoe 나는 그것이 간단한 경우를 약간 더 단순하게 만들 것이라고 생각하지만, 그 이상을 더 복잡하게 만들 수도 있습니다.

그것은 포함:

1. 오버로드가 있는 것보다 더 많은 항목
2. 정황
3. 루프
4. 비교자를 사용하여

이 주제에 대해 이전에 게시된 ASP.NET의 코드를 고려하십시오(현재 제안으로 업데이트됨).

```c#
var 해시 코드 = 해시 코드
.Create(IsMainPage)
.Combine(ViewName, StringComparer.Ordinal)
.Combine(컨트롤러 이름, StringComparer.Ordinal)
.Combine(영역 이름, StringComparer.Ordinal);

if (ViewLocationExpanderValues ​​!= null)
{
foreach(ViewLocationExpanderValues의 var 항목)
{
해시코드 = 해시코드
.Combine(item.Key, StringComparer.Ordinal)
.Combine(항목.값, StringComparer.Ordinal);
}
}

반환 해시 코드;

How would this look with the original `Hash.CombineHashCodes`? I think it would be:

```c#
var hashCode = Hash.CombineHashCodes(
    IsMainPage,
    StringComparer.Ordinal.GetHashCode(ViewName),
    StringComparer.Ordinal.GetHashCode(ControllerName),
    StringComparer.Ordinal.GetHashCode(AreaName));

if (ViewLocationExpanderValues != null)
{
    foreach (var item in ViewLocationExpanderValues)
    {
        hashCode = Hash.CombineHashCodes(
            hashCode
            StringComparer.Ordinal.GetHashCode(item.Key),
            StringComparer.Ordinal.GetHashCode(item.Value));
    }
}

return hashCode;

사용자 정의 비교자를 위해 GetHashCode() 호출을 무시하더라도 hashCode 의 이전 값을 첫 번째 매개변수로 전달해야 하는 것은 간단하지 않습니다.

@KrzysztofCwalina @ericlippert에 따르면의 언어 프로그래밍은 C #에서 노트 <sup>1, 그것은</sup> 컬렉션 이니셜 라이저이기 때문에 (당연히)하지 연산에 대한 수집 생성을위한 문법 설탕, (이라는 방법의 다른 일반적인 사용했다 될 운명이다 Add ).

<sup>1</sup> Google 도서의 작동 방식으로 인해 해당 링크가 모든 사람에게 작동하지 않을 수 있습니다.

@KrzysztofCwalina , IEnumerable<T> 가 아닌 일반이 아닌 IEnumerable 가 필요합니다.

@svick , 위의 첫 번째 예에서 사소한 니트: .Combine 대한 첫 번째 호출은 현재 제안에서 .Create 입니다. 중첩 접근 방식을 사용하지 않는 한.

@svic

그것은 또한 그 이상의 것을 더 복잡하게 만들 것입니다(그리고 무엇이 옳은 일인지에 대해 덜 명확해집니다)

두 번째 예제는 전체적으로 첫 번째 예제와 거의 다르지 않으며 더 복잡한 IMO도 아닙니다. 두 번째/원래 접근 방식을 사용하면 많은 해시 코드를 전달하기만 하면 됩니다(첫 번째 매개 변수는 실제로 IsMainPage.GetHashCode() 여야 한다고 생각합니다). 그래서 나에게는 간단해 보입니다. 하지만 제가 소수에 속하는 것 같아서 원래의 방식을 고집하지는 않겠습니다. 나는 강한 의견이 없습니다. 이 두 가지 예는 모두 나에게 충분히 합리적으로 보입니다.

@justinvp 감사합니다. 업데이트되었습니다. (나는 첫 번째 게시물의 첫 번째 제안으로 갔고 그것이 구식이라는 것을 깨닫지 못했습니다. 누군가가 업데이트해야 할 것입니다.)

@mellinoe 문제는 실제로 두 번째가 미묘한 버그를 생성할 수 있다는 것입니다. 이것은 우리 프로젝트 중 하나의 실제 코드입니다.

        [MethodImpl(MethodImplOptions.AggressiveInlining)]
        public int GetHashCode(PageFromScratchBuffer obj)
        {
            int v = Hashing.Combine(obj.NumberOfPages, obj.ScratchFileNumber);
            int w = Hashing.Combine(obj.Size.GetHashCode(), obj.PositionInScratchBuffer.GetHashCode());
            return Hashing.Combine(v, w);            
        }

우리는 그것과 함께 살고 있지만 우리는 매일 매우 낮은 수준의 것들을 다루고 있습니다. 따라서 확실한 평균 개발자는 아닙니다. 그러나 여기에서 v와 w를 결합하는 것이 v와 w보다 ... v와 w 결합 사이에서 동일하지 않습니다. 해시 조합은 교환 가능하지 않으므로 차례로 연결하면 실제로 API 수준에서 전체 오류 집합을 제거할 수 있습니다.

나는 첫 번째 게시물의 첫 번째 제안으로 갔고 그것이 구식이라는 것을 깨닫지 못했습니다. 누군가가 업데이트해야 할 것입니다.

완료.
BTW: 이 제안은 특히 투표를 추적하기가 매우 어렵습니다... 너무 많은 변형(좋은 것 같아요 ;-))

@karelz Create API를 추가하면 Empty 추가할 수 있다고 생각합니다. @bartonjs가 말했듯이 둘 중 하나일 필요는 없습니다. 제안

namespace System
{
    public struct HashCode : IEquatable<HashCode>
    {
        public HashCode();

        public static HashCode Empty { get; }

        public static HashCode Create(int hashCode);
        public static HashCode Create<T>(T value);
        public static HashCode Create<T>(T value, IEqualityComparer<T> comparer);

        public HashCode Combine(int hashCode);
        public HashCode Combine<T>(T value);
        public HashCode Combine<T>(T value, IEqualityComparer<T> comparer);

        public int Value { get; }

        public static implicit operator int(HashCode hashCode);

        public static bool operator ==(HashCode left, HashCode right);
        public static bool operator !=(HashCode left, HashCode right);

        public bool Equals(HashCode other);
        public override bool Equals(object obj);
        public override int GetHashCode();
        public override string ToString();
    }
}

@JonHanna

그것은 또한 가난한 종자 경향이 있는 0으로 파종하는 사람들을 낙담시킵니다.

우리가 선택하는 해싱 알고리즘은 오늘날 HashHelpers 에서 사용되는 것과 동일하며 hash(0, x) == x 효과가 있습니다. HashCode.Empty.Combine(x) 는 HashCode.Create(x) 와 정확히 동일한 결과를 생성하므로 객관적으로 차이가 없습니다.

@jamesqo 마지막 제안에 추가 Zero 를 포함하는 것을 잊었습니다. 그것이 누락이라면 업데이트 할 수 있습니까? 그런 다음 사람들에게 최신 제안에 투표하도록 요청할 수 있습니다. 다른 대안(내가 업데이트한 상위 게시물 참조)은 다음과 같이 많이 얻지 못하는 것 같습니다 ...

@karelz 찾아 주셔서 감사합니다. 수정했습니다.

@KrzysztofCwalina 는 다른 의미가 아니라 컬렉션에 추가한다는 의미에서 "추가"를 의미하는지 확인합니다. 이 제한이 마음에 드셨는지 모르겠지만 당시에는 그렇게 결정했습니다.

public static HashCode Create(int hash);
public HashCode Combine(int hash);

매개 변수를 지정해야합니다 hashCode 대신 hash 부터 전달 된 값 가능성이 호출에서 얻은 해시 코드가 될 것됩니다 GetHashCode() ?

Empty / Zero

이것을 유지하게 된다면 고려해야 할 또 다른 이름은 Default 입니다.

@justinvp

전달된 값이 GetHashCode()를 호출하여 얻을 가능성이 있는 해시 코드가 될 것이기 때문에 매개변수의 이름을 해시 대신 hashCode로 지정해야 합니까?

int 매개변수 hash 및 HashCode 매개변수 hashCode 이름을 지정하고 싶었습니다. 그러나 다시 생각해 보면 hashCode 가 더 좋을 것이라고 생각합니다. 왜냐하면 언급한 대로 hash 가 다소 모호하기 때문입니다. API를 업데이트하겠습니다.

이것을 유지하게 된다면 고려해야 할 또 다른 이름은 Default입니다.

Default 들었을 때 나는 "구조체의 기본값"이 아니라 "어떤 옵션을 선택해야 할지 모를 때 무언가를 하는 일반적인 방법"이라고 생각합니다. 예를 들어 Encoding.Default 와 같은 것은 완전히 다른 의미를 갖습니다.

우리가 선택하는 해싱 알고리즘은 오늘날 HashHelpers에서 사용되는 것과 동일한 것이며, 이는 hash(0, x) == x와 같은 효과를 가집니다. HashCode.Empty.Combine(x)는 HashCode.Create(x)와 정확히 동일한 결과를 생성하므로 객관적으로 차이가 없습니다.

이것의 내부에 대해 잘 모르는 사람으로서 저는 HashCode.Create(x).Combine(...) 의 단순함이 정말 좋습니다. Create 는 다른 많은 곳에서 사용되기 때문에 매우 분명합니다.

Empty / Zero / Default 가 알고리즘 사용을 제공하지 않으면 IMO에 없어야 합니다.

추신: 매우 흥미로운 스레드!! 잘 했어! 👍

@cwe1ss

Empty / Zero / Default가 알고리즘 사용을 제공하지 않으면 IMO에 있어서는 안 됩니다.

Empty 필드가 있으면 알고리즘 사용이 제공됩니다. 해시를 결합할 수 있는 "시작 값"을 나타냅니다. 예를 들어 Create 사용하여 해시 배열을 결합하려는 경우 매우 고통스럽습니다.

int CombineRange(int[] hashes)
{
    if (hashes.Length == 0)
    {
        return 0;
    }

    var result = HashCode.Create(hashes[0]);

    for (int i = 1; i < hashes.Length; i++)
    {
        result = result.Combine(hashes[i]);
    }

    return result;
}

Empty 가 있으면 훨씬 더 자연스러워집니다.

int CombineRange(int[] hashes)
{
    var result = HashCode.Empty;

    for (int i = 0; i < hashes.Length; i++)
    {
        result = result.Combine(hashes[i]);
    }

    return result;
}

// or

int CombineRange(int[] hashes)
{
    return hashes.Aggregate(HashCode.Empty, (hc, next) => hc.Combine(next));
}

@terrajobst 이 유형은 저에게 ImmutableArray<T> 와 매우 유사합니다. 빈 배열은 그 자체로는 그다지 유용하지 않지만 다른 작업의 "시작점"으로 매우 유용합니다. 그래서 우리는 이에 대한 Empty 속성을 가지고 있습니다. HashCode 에도 하나를 갖는 것이 합리적이라고 생각합니다. 우리는 Create 합니다.

@jamesqo 나는 당신이 제안서 https://github.com/dotnet/corefx/issues/8034#issuecomment -262661653에서 당신이 자동으로/실수로 arg name obj 을 value 로 변경했다는 것을 알아차렸습니다. IMO가 얻는 것을 더 잘 캡처하는 obj 다시 전환했습니다. 이름 value 는 이 컨텍스트에서 "int" 해시 값 자체와 더 관련이 있습니다.
필요한 경우 arg 이름에 대해 추가 토론을 할 수 있지만 의도적으로 변경하고 마지막으로 승인된 제안과의 차이점을 추적해 보겠습니다.

상단의 제안을 업데이트했습니다. 나는 또한 제안서의 마지막 승인 버전에 대해 diff를 호출했습니다.

우리가 선택하는 해싱 알고리즘은 오늘날 HashHelpers에서 사용되는 것과 동일합니다.

모든 곳에서 사용해야 하는 알고리즘으로 선택하는 것이 좋은 알고리즘인 이유는 무엇입니까? 결합되는 해시코드에 대해 어떤 가정을 합니까? 모든 곳에서 사용하면 DDoS 공격의 새로운 길을 열 수 있습니까? (과거에 문자열 해싱으로 인해 화상을 입었습니다.)

ASP.NET Core의 변경 가능한 HashCodeCombiner "빌더" 라인을 따라 무언가를 했다면 어떻게 될까요?

사용하기에 적합한 패턴이라고 생각합니다. 좋은 범용 해시코드 결합기는 일반적으로 해시코드 자체에 맞는 것보다 더 많은 상태를 사용할 수 있지만 더 큰 구조체를 전달하는 것은 성능 문제이기 때문에 유창한 패턴이 무너집니다.

모든 곳에서 사용해야 하는 알고리즘으로 선택하는 것이 좋은 알고리즘인 이유는 무엇입니까?

모든 곳에서 사용해서는 안됩니다. https://github.com/dotnet/corefx/issues/8034#issuecomment -260790829에서 내 의견을

결합되는 해시코드에 대해 어떤 가정을 합니까? 모든 곳에서 사용하면 DDoS 공격의 새로운 길을 열 수 있습니까?

현재 해시의 한 가지 문제는 hash(0, x) == x 입니다. 따라서 일련의 null 또는 0이 해시에 입력되면 0으로 유지됩니다. 코드를 참조하십시오. 이것은 null이 계산되지 않는다는 말은 아니지만 초기 null은 계산되지 않습니다. 0에서 0으로 매핑하는 것을 방지하기 위해 마법 상수를 추가하는 here 와 같이 더 강력한(그러나 약간 더 비싼) 것을 사용하는 것을 고려하고 있습니다.

사용하기에 적합한 패턴이라고 생각합니다. 좋은 범용 해시코드 결합기는 일반적으로 해시코드 자체에 맞는 것보다 더 많은 상태를 사용할 수 있지만 더 큰 구조체를 전달하는 것은 성능 문제이기 때문에 유창한 패턴이 무너집니다.

모든 사용 사례에 적합하도록 시도하는 큰 구조체 크기를 가진 범용 결합기가 있어야 한다고 생각하지 않습니다. 대신 모든 int 크기( FnvHashCode 등)이고 모두 고유한 Combine 메서드가 있는 별도의 해시 코드 유형을 구상했습니다. 게다가 이러한 "빌더" 유형은 전달되지 않고 어쨌든 동일한 방법으로 유지됩니다.

모든 사용 사례에 적합하도록 시도하는 큰 구조체 크기를 가진 범용 결합기가 있어야 한다고 생각하지 않습니다.

ASP.NET Core는 현재 상태가 64비트인 자체 해시코드 결합기 를 이것으로 교체할 수 있습니까?

모두 int 크기(FnvHashCode 등)인 별도의 해시 코드 유형을 구상하고 있었습니다.

이것이 결합 폭발로 이어지지 않습니까? 이 API 디자인이 무엇으로 이어지는지 명확히 하기 위해 API 제안의 일부여야 합니다.

@jkotas 토론 초반에 비슷한 반대 의견을 밝혔습니다. 해시 함수를 다루려면 주제 지식이 필요합니다. 그러나 2001년에 프레임워크의 가장 뿌리에 해시 코드를 도입하여 발생한 문제를 수정하는 것을 이해하고 지지하며 해시를 결합하는 방법을 처방하지 않습니다. 이 설계는 99%의 경우(해시의 통계적 속성이 충분하기 때문에 주제 지식을 사용할 수 없거나 필요한 경우)의 문제를 해결하는 것을 목표로 합니다. ASP.Net Core는 https://github.com/dotnet/corefx/issues/13757 에서 논의를 위해 제안된 것과 같은 비시스템 어셈블리의 범용 프레임워크에 이러한 결합기를 사용할 수 있어야 합니다.

99%의 경우에 사용하기 쉬운 해시코드 결합기를 갖는 것이 좋다는 데 동의합니다. 그러나 32비트보다 더 많은 내부 상태를 허용해야 합니다.

BTW: ASP.NET은 원래 해시코드 결합에 유창한 패턴을 사용했지만 버그를 놓치기 쉽기 때문에 중단했습니다. https://github.com/aspnet/Razor/pull/537

해시 플러딩 보안에 관한 @jkotas .
면책 조항: 전문가가 아닙니다(한 사람에게 문의해야 하며 MS는 이 문제에 대해 몇 가지 이상을 갖고 있습니다) .

나는 주변을 둘러보았고 이 문제에 대한 일반적인 합의는 아니지만 요즘 주목을 받고 있는 주장이 있습니다. 해시 코드는 32비트 크기이며, 집합의 크기가 주어진 경우 충돌 확률을 보여주는 그래프 앞에 게시했습니다. 즉, 알고리즘이 아무리 우수하더라도(예를 들어 SipHash 살펴보기) 많은 해시를 생성하고 합리적인 시간(약 1시간 미만)에 충돌을 찾는 것은 꽤 실행 가능합니다. 이러한 문제는 해시를 보유하는 데이터 구조에서 해결해야 하며 해시 함수 수준에서는 해결할 수 없습니다. 기본 데이터 구조를 수정하지 않고 해시 플러딩을 방지하기 위해 비암호화에서 추가 성능을 지불하면 문제가 해결되지 않습니다.

편집: 당신은 내가 쓰는 동안 게시했습니다. 이에 비추어 볼 때 64비트 상태가 얻는 이점은 무엇입니까?

@jkotas 링크하신 문제를 조사했습니다. 그것은 말한다:

aspnet/Common#40에 대한 반응

https://github.com/aspnet/Common/issues/40에 대한 설명:

버그 발견:

public class TagBuilder
{
    private Dictionary<string, string> _attributes;
    private string _tagName;
    private string _innerContent;

    public override int GetHashCode()
    {
        var hash = HashCodeCombiner.Start()
            .Add(_tagName, StringComparer.Ordinal)
            .Add(_innerContent, StringComparer.Ordinal);

        foreach (var kvp in _attributes)
        {
            hash.Add(kvp.Key, StringComparer.Ordinal).Add(kvp.Value, StringComparer.Ordinal);
        }

        return hash.Build();
    }
}

어서 해봐요. 그 인수는 사람들이 Substring 가 새 문자열을 반환한다는 것을 깨닫지 못하기 때문에 string 가 변경 가능해야 한다고 말하는 것과 같습니다. 변경 가능한 구조체는 문제 측면에서 훨씬 더 나쁩니다. 구조체를 불변으로 유지해야 한다고 생각합니다.

해시 플러딩 보안에 대해.

여기에는 두 가지 측면이 있습니다. 올바른 구성 설계(강력한 데이터 구조 등); 및 기존 설계의 문제 완화. 둘 다 중요합니다.

@karelz 매개변수 이름 지정 관련

나는 당신이 자동으로/실수로 당신의 제안 dotnet/corefx#8034(comment)에서 arg name obj를 값으로 변경했다는 것을 알아차렸습니다. IMO가 얻는 것을 더 잘 캡처하는 obj로 다시 전환했습니다. 이 컨텍스트에서 이름 값은 "int" 해시 값 자체와 더 관련이 있습니다.
필요한 경우 arg 이름에 대해 추가 토론을 할 수 있지만 의도적으로 변경하고 마지막으로 승인된 제안과의 차이점을 추적해 보겠습니다.

향후 제안에서 API를 추가하여 값을 일괄적으로 결합하는 것을 고려하고 있습니다. 예: CombineRange(ReadOnlySpan<T>) . 이 이름을 obj 로 지정했다면 거기에 매개변수 이름을 objs 로 지정해야 하므로 매우 어색하게 들립니다. 따라서 이름을 item 합니다. 앞으로는 스팬 매개변수의 이름을 items 지정할 수 있습니다. 제안을 업데이트했습니다.

@jkotas 는 동의하지만 여기서 요점은 결합기 수준에서 어떤 것도 완화하지 않는다는 것입니다...

우리가 할 수 있는 유일한 일은 임의의 시드를 갖는 것입니다. 모든 상태와 목적에 대해 string 에서 코드를 본 것을 기억하며 빌드당 고정됩니다. (오래전 일이기 때문에 틀릴 수 있습니다.) 무작위 시드를 적절하게 구현하는 것이 여기에 적용될 수 있는 유일한 완화 방법입니다.

이것은 도전입니다. 고정된 임의의 시드가 있는 최고의 문자열 및/또는 메모리 해시 함수를 제공하면 충돌만 생성하는 32비트 해시 코드 세트를 구성하겠습니다. 나는 꽤 하기 쉽기 때문에 그런 도전을 하는 것을 두려워하지 않는다. 확률 이론은 내 편이다. 나는 심지어 가서 내기를 할 것이지만 나는 그것을 이길 것이라는 것을 알고 있으므로 본질적으로 더 이상 내기가 아닙니다.

게다가... 더 깊은 분석은 완화가 실행당 내장된 "임의의 시드"를 가질 수 있는 능력이라고 해도 더 복잡한 결합기가 필요하지 않다는 것을 보여줍니다. 본질적으로 소스에서 문제를 완화했기 때문입니다.

M1 및 M2 있고 다른 임의 시드 rs1 및 rs2 ....
M1 는 h1 = hash('a', rs1) 및 h2=hash('b', rs1) 발행합니다.
M2 는 h1' = hash('a', rs2) 및 h2'=hash('b', rs2) 발행합니다.
여기서 요점은 h1 및 h1' 가 1/ (int.MaxInt-1) ( hash 가 충분히 좋은 경우)의 확률로 다르다는 것입니다. 그것이 얻을만큼 좋습니다.
따라서 사용하기로 결정한 c(x,y) 무엇이든(충분한 경우) 소스에 내장된 완화 기능을 이미 고려하고 있습니다.

편집: 코드를 찾았습니다. 현재 각 도메인에서 변경되는 Marvin32를 사용하고 있습니다. 따라서 문자열에 대한 완화는 실행당 임의의 시드를 사용하는 것입니다. 내가 말했듯이 충분히 완화됩니다.

@jkotas

ASP.NET Core는 현재 상태가 64비트인 자체 해시코드 결합기를 이것으로 교체할 수 있습니까?

전적으로; 동일한 해싱 알고리즘을 사용합니다. 방금 이 테스트 앱 을 만들어 충돌 횟수를 측정하고 10번 실행했습니다. 64비트를 사용하는 것과 큰 차이는 없습니다.

모두 int 크기(FnvHashCode 등)인 별도의 해시 코드 유형을 구상하고 있었습니다.

이것이 결합 폭발로 이어지지 않습니까? 이 API 디자인이 무엇으로 이어지는지 명확히 하기 위해 API 제안의 일부여야 합니다.

@jkotas , 그렇지 않습니다. 이 클래스의 디자인은 미래의 해싱 API에 대한 디자인을 확정적으로 설정하지 않습니다. 이는 더 고급 시나리오로 간주되어야 하며 dotnet/corefx#13757과 같은 다른 제안으로 이동해야 하며 다른 설계 논의가 있을 것입니다. GetHashCode 재정의에 어려움을 겪고 있는 초보자를 위해 일반 해싱 알고리즘을 위한 간단한 API를 갖는 것이 훨씬 더 중요하다고 생각합니다.

99%의 경우에 사용하기 쉬운 해시코드 결합기를 갖는 것이 좋다는 데 동의합니다. 그러나 32비트보다 더 많은 내부 상태를 허용해야 합니다.

32비트보다 더 많은 내부 상태가 필요한 경우는 언제입니까? 편집: 사람들이 사용자 정의 해싱 논리를 플러그인할 수 있도록 하려면 고급 시나리오로 간주되어야 하고 dotnet/corefx#13757에서 논의해야 한다고 생각합니다.

현재 각 도메인에서 변경되는 Marvin32를 사용하고 있습니다.

맞습니다. 문자열 해시코드 무작위화 완화는 .NET Core에서 기본적으로 활성화되어 있습니다. 호환성 때문에 전체 .NET Framework의 독립 실행형 앱에는 기본적으로 활성화되어 있지 않습니다. 이는 단점을 통해서만 활성화됩니다(예: 고위험 환경).

.NET Core에 비무작위 해싱을 위한 코드가 여전히 있지만 삭제해도 괜찮습니다. 나는 우리가 그것을 다시 필요로 할 것이라고 기대하지 않습니다. 또한 더 이상 무작위가 아닌 경로를 사용할지 여부를 확인하지 않기 때문에 문자열 해시코드 계산이 조금 더 빨라집니다.

무작위 문자열 해시코드를 계산하는 데 사용되는 Marvin32 알고리즘은 64비트 내부 상태를 갖습니다. MS 과목 전문가들이 뽑았습니다. 나는 그들이 64비트 내부 상태를 사용해야 하는 충분한 이유가 있다고 확신하며, 단지 일을 느리게 하기 위해 사용하지 않았습니다.

범용 해시 결합기는 이 완화를 계속 발전시켜야 합니다. 무작위 시드와 충분히 강력한 해시코드 결합 알고리즘을 사용해야 합니다. 이상적으로는 무작위 문자열 해싱과 동일한 Marvin32를 사용합니다.

무작위 문자열 해시코드를 계산하는 데 사용되는 Marvin32 알고리즘은 64비트 내부 상태를 갖습니다. MS 과목 전문가들이 뽑았습니다. 나는 그들이 64비트 내부 상태를 사용해야 하는 충분한 이유가 있다고 확신하며, 단지 일을 느리게 하기 위해 사용하지 않았습니다.

@jkotas , 연결한 해시 코드 결합기는 Marvin32를 사용하지 않습니다. 그것은 non-randomized string.GetHashCode 사용하는 것과 동일한 순진한 DJBx33x 알고리즘을 사용합니다.

범용 해시 결합기는 이 완화를 계속 발전시켜야 합니다. 무작위 시드와 충분히 강력한 해시코드 결합 알고리즘을 사용해야 합니다. 이상적으로는 무작위 문자열 해싱과 동일한 Marvin32를 사용합니다.

이 유형은 해시 DoS 공격에 취약한 장소에서 사용하기 위한 것이 아닙니다. 이것은 추가/xor를 더 잘 모르는 사람들을 대상으로 하며 https://github.com/dotnet/coreclr/pull/4654 와 같은 것을 방지하는 데 도움이 됩니다

범용 해시 결합기는 이 완화를 계속 발전시켜야 합니다. 무작위 시드와 충분히 강력한 해시코드 결합 알고리즘을 사용해야 합니다. 이상적으로는 무작위 문자열 해싱과 동일한 Marvin32를 사용합니다.

그런 다음 C# 팀과 논의하여 완화된 ValueTuple 해싱 알고리즘을 구현해야 합니다. 그 코드는 고위험 환경에서도 사용될 것이기 때문입니다. 물론 Tuple https://github.com/dotnet/coreclr/blob/master/src/mscorlib/src/System/Tuple.cs#L60 또는 System.Numerics.HashHelpers (모든 장소).

이제 구현 방법을 결정하기 전에 API 방식을 변경하지 않더라도 완전히 무작위화된 해시코드 결합 알고리즘 비용을 지불하는 것이 가치가 있다면(물론 존재하는 경우) 동일한 주제 전문가를 살펴보겠습니다. 둘 중 하나를 설계했습니다(물론 제안된 API에 따라 비용을 지불할 의향이 있다면 512비트 상태를 사용하고 여전히 동일한 공개 API를 사용할 수 있습니다).

이것은 추가/xor를 더 잘 모르는 사람들을 대상으로 합니다.

이것이 바로 견고한 것이 중요한 이유입니다. .NET의 핵심 가치는 잘 모르는 사람들의 문제를 해결한다는 것입니다.

그리고 우리가 그것에 있는 동안 IntPtr https://github.com/dotnet/coreclr/blob/master/src/mscorlib/src/System/IntPtr.cs#L119에 대해 잊지 마세요.
bad 가 dab 와 충돌하기 때문에 xor는 아마도 최악의 것입니다.

완화된 ValueTuple 해싱 알고리즘 구현

좋은 지적. ValueTupup이 배송되었는지 또는 아직 이를 수행할 시간인지 확실하지 않습니다. https://github.com/dotnet/corefx/issues/14046을 열었습니다

IntPtr을 잊지 말자

이것은 과거의 실수입니다 ... 수정의 기준은 훨씬 높습니다.

@jkotas

이것은 과거의 실수입니다 ... 수정의 기준은 훨씬 높습니다.

.Net Core의 요점 중 하나는 그러한 "작은" 변경에 대한 기준이 훨씬 낮아야 한다는 것입니다. 누군가 IntPtr.GetHashCode 구현에 의존하는 경우(실제로 해서는 안 됨) .Net Core 버전을 업그레이드하지 않도록 선택할 수 있습니다.

이와 같은 "작은" 변경 사항에 대한 기준은 훨씬 낮아야 합니다.

예, 전체 .NET Framework와 비교됩니다. 그러나 시스템을 통해 변경 사항을 푸시하려면 여전히 작업을 수행해야 하며 고통받을 가치가 없다는 것을 알게 될 수도 있습니다. 최근의 예는 F#을 깨뜨리기 때문에 되돌려진 Tuple<T> 해싱 알고리즘의 변경입니다. https://github.com/dotnet/coreclr/pull/6767#issuecomment -256896016

@jkotas

HashCode 64비트를 만든다면 32비트 환경에서 변경할 수 없는 디자인이 perf를 죽일 것이라고 생각하십니까? 다른 독자들의 의견에 동의합니다. 빌더 패턴이 훨씬 더 나쁜 것 같습니다.

성능을 죽여라 - 아니. 구문 설탕에 대한 성능 저하 - 예.

구문 설탕에 대한 성능 저하 - 예.

향후 JIT로 최적화할 수 있는 부분인가요?

성능을 죽입니다 - 아니요.
구문 설탕에 대한 성능 저하 - 예.

그것은 구문상의 설탕 이상입니다. HashCode 클래스를 만들 의향이 있다면 구문상의 설탕이 될 것입니다. 그러나 변경 가능한 값 유형은 버그 팜입니다.

이전에서 인용:

이것이 바로 견고한 것이 중요한 이유입니다. .NET의 핵심 가치는 잘 모르는 사람들의 문제를 해결한다는 것입니다.

나는 변경 가능한 값 유형이 더 잘 모르는 대다수의 사람들에게 강력한 API가 아니라고 주장하고 싶습니다.

나는 변경 가능한 값 유형이 더 잘 모르는 대다수의 사람들에게 강력한 API가 아니라고 주장하고 싶습니다.

동의하다. 생각해보면, 가변 구조체 빌더 유형의 경우라는 사실이 안타까운 일이라고 생각합니다. 내가 사용하는 그들에게 모든 시간을 들이 꽉 좋은이다의 때문이다. [MustNotCopy] 주석을

MustNotCopy는 구조체 애호가의 꿈이 실현되는 것입니다. @jaredpar?

MustNotCopy는 스택과 비슷하지만 사용하기가 더 어렵습니다 😄

클래스를 만들지 말고 해시를 결합하는 확장 메서드를 만드는 것이 좋습니다.

static class HashHelpers
{
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static int CombineHash(this int hash1, int hash2);
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static int CombineHash<T>(this int hash, T value);
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static int CombineHash<T>(this int hash, T value, IEqualityComparer<T> comparer);
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static int CombineHash<T>(this int hash, IEnumerable<T> values);
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static int CombineHash<T>(this int hash, IEnumerable<T> values, IEqualityComparer<T> comparer);
}

그게 다야! 빠르고 사용하기 쉽습니다.

@AlexRadch 해시로 의미하는 것이 아니라 모든 정수에 대한 메서드 목록을 오염시키는 것이 마음에 들지 않습니다.

또한 해시 코드 계산 체인을 계속하는 메서드가 있지만 어떻게 시작합니까? 0으로 시작하는 것과 같이 명확하지 않은 작업을 수행해야 합니까? 즉 0.CombineHash(this.FirstName).CombineHash(this.LastName) .

업데이트: dotnet/corefx#14046 의 주석 에 따라 기존 해시 수식이 ValueTuple 대해 유지되기로 결정되었습니다.

@jamesqo 도와주셔서 감사합니다.
@jkotas 및 @VSadov 와의 마지막 토론에서 우리는 무작위화/씨딩을 진행하는 것이 좋지만 더 비싼 해시 함수를 채택하는 것을 보류할 것입니다.
무작위화를 수행하면 향후 필요할 경우 해시 함수를 변경할 수 있습니다.

@jkotas , HashCode 대한 현재 ROL 5 기반 해시를 유지하고 다시 4바이트로 축소할 수 있습니까? 이것은 구조체 복사의 모든 문제를 제거합니다. HashCode.Empty 가 임의의 해시 값을 나타내도록 할 수 있습니다.

@svic
예, 이것은 모든 정수에 대한 메소드를 오염시키지만 분리된 이름 공간에 배치될 수 있으며 해시로 작업하지 않으면 포함하지 않고 볼 수 없습니다.

0.CombineHash(this.FirstName).CombineHash(this.LastName) 는 this.FirstName.GetHash().CombineHash(this.LastName) 로 작성해야 합니다.

시드에서 시작하여 구현하려면 다음 정적 메서드를 가질 수 있습니다.

static class HashHelpers
{
    public static int ClassSeed<T>();
}

class SomeClass
{
    int GetHash()
    {
        return HashHelpers.ClassSeed<SomeClass>().CombineHash(value1).CombineHash(value2);
    }
}

따라서 각 클래스에는 해시를 무작위화하기 위한 다른 시드가 있습니다.

@jkotas , HashCode에 대한 현재 ROL 5 기반 해시를 유지하고 다시 4바이트로 축소할 수 있습니까?

공개 플랫폼 해시코드 구축 도우미가 64비트 상태를 사용해야 견고하다고 생각합니다. 32비트 전용인 경우 특히 더 많은 요소, 배열 또는 컬렉션을 해시하는 데 사용할 때 나쁜 결과를 생성하기 쉽습니다. 사용하는 것이 좋은 경우와 사용하지 않는 경우에 대한 문서는 어떻게 작성합니까? 예, 비트를 혼합하는 데 사용되는 추가 지침이지만 중요하지 않다고 생각합니다. 이러한 종류의 명령은 매우 빠르게 실행됩니다. 내 경험에 따르면 너무 적은 양의 믹싱을 수행하는 것이 너무 많이 하는 것보다 훨씬 더 심각하기 때문에 적은 양보다 많은 양의 믹싱을 수행하는 것이 좋습니다.

또한 제안된 API의 형태에 대해 여전히 우려하고 있습니다. 문제는 해시 코드 결합이 아니라 해시 코드 구축으로 생각해야 한다고 생각합니다. 이를 플랫폼 API로 추가하는 것은 시기상조일 수 있으며, 이에 대해 더 나은 패턴이 나타날지 지켜봐야 합니다. 이것은 누군가가 이 API로 (소스) nuget 패키지를 게시하거나 corefx가 이를 내부 도우미로 사용하는 것을 방지하지 않습니다.

64비트 상태를 가진 @jkotas 는 출력이 적절한 통계적 속성을 가질 것이라고 보장하지 않습니다. 결합 기능 자체는 내부 64비트 상태를 사용하도록 설계되어야 합니다. 또한 결합 기능이 좋다면(통계적으로) 덜 섞는 것 이상은 없습니다. 해싱에 무작위화, 눈사태 및 기타 관심 있는 통계적 속성이 있는 경우 기술적으로 특수하게 조작된 해시 기능을 말하므로 혼합이 설명됩니다.

좋은 해시 함수가 무엇인지 확인하십시오(일부는 xor 같습니다. http://softwareengineering.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and -속도 및 https://research.neustar.biz/2012/02/02/choosing-a-good-hash-function-part-3/

@jamesqo BTW, "시드가 매번 변경되기 때문에 실제로 해시(런타임 해시가 아님)를 결합하고 있습니다."의 경우 결합기가 작동하지 않는다는 것을 깨달았습니다. ... 시드가 있는 공개 생성자?

@jkotas

공개 플랫폼 해시코드 구축 도우미가 64비트 상태를 사용해야 견고하다고 생각합니다. 32비트 전용인 경우 특히 더 많은 요소, 배열 또는 컬렉션을 해시하는 데 사용할 때 나쁜 결과를 생성하기 쉽습니다.

이것이 결국 단일 int 로 압축되는 시점이 중요합니까?

@jamesqo 실제로는 상태 크기가 견고성이 아니라 기능에만 의존합니다. 사실 결합이 그런 식으로 작동하도록 설계되지 않았기 때문에 실제로 해시 함수를 더 악화시킬 수 있으며 강제로 임의성을 얻을 수 없기 때문에 기껏해야 리소스를 낭비하고 있습니다.

결론: 함수가 통계적으로 우수하거나 더 나빠질 것이 거의 보장된다는 점을 추가로 확인하는 것입니다.

이는 항목 간에 상관 관계가 있는지 여부에 따라 다릅니다. 상관 관계가 없으면 32비트 상태와 단순 rotl(또는 xor)이 잘 작동합니다. 상관 관계가 있으면 의존합니다.

누군가가 개별 문자에서 문자열 해시 코드를 빌드하는 데 이것을 사용했는지 고려하십시오. 누군가가 실제로 문자열에 대해 이 작업을 수행할 가능성은 없지만 문제를 보여줍니다.

for (int i = 0; i < str.Length; i++)
   hashCodeBuilder.Add(str[i]);

실제 문자열의 문자는 상관 관계가 있는 경향이 있기 때문에 32비트 상태 및 단순 rotl 문자열에 대해 좋지 않은 결과를 제공합니다. 이것이 사용되는 항목은 얼마나 자주 상관 관계가 있으며 얼마나 나쁜 결과를 줄까요? 말하기는 어렵지만 실생활의 것들은 예상치 못한 방식으로 상관되는 경향이 있습니다.

API 지원 Hash randomization에 다음 메소드를 추가하면 좋을 것입니다.

namespace System
{
    public struct HashCode : IEquatable<HashCode>
    {
       // add this
       public static HashCode CreateRandomized(Type type);
       // or add this
       public static HashCode CreateRandomized<T>();
    }
}

@jkotas 나는 그것을 테스트하지 않았 것이라고 믿습니다 . 그러나 그것은 우리가 사용하려는 기능에 대해 분명히 말하고 있습니다. 안정성을 위해 속도를 교환하려는 경우 최소한 충분하지 않습니다 (아무도 이것으로 어리석은 일을 할 수 없음). 나는 이것이 비-암호화 해싱 함수가 아니라 상관관계가 없는 해시 코드(얻는 만큼 무작위임)를 결합하는 빠른 방법이라는 디자인을 한 번 선호합니다.

우리가 목표로 하는 것이 어리석은 일을 아무도 하지 않는 것이라면 64비트 상태를 사용하는 것은 아무 것도 고칠 수 없고 단지 문제를 숨기고 있을 뿐입니다. 그 상관관계를 이용하는 입력을 생성하는 것은 여전히 ​​가능합니다. 이것은 내가 18일 전에 했던 것과 똑같은 주장으로 우리를 다시금 지적합니다. 참조: https://github.com/dotnet/corefx/issues/8034#issuecomment -261301533

나는 이것이 비-암호화 해싱 함수가 아니라 상관되지 않은 해시 코드를 결합하는 빠른 방법이라는 디자인을 한 번 선호합니다.

상관되지 않은 해시 코드를 결합하는 가장 빠른 방법은 xor...

사실이지만 지난 번에는 잘 작동하지 않았다는 것을 알고 있습니다(IntPtr이 생각납니다). Rotation 및 XOR(현재)도 마찬가지로 빠르며 누군가가 일종의 관련 항목을 넣어도 손실이 없습니다.

public static HashCode CreateRandomized(Type type); 또는 public static HashCode CreateRandomized<T>(); 방법 또는 둘 다를 사용하여 해시 코드 무작위화를 추가합니다.

@jkotas 더 나은 패턴을 찾은 것 같습니다. C# 7 ref 반환을 사용하면 어떻게 될까요? 매번 HashCode 를 반환하는 대신 레지스터에 맞는 ref HashCode 를 반환합니다.

public struct HashCode
{
    private readonly long _value;

    public ref HashCode Combine(int hashCode)
    {
        CombineCore(ref _value, hashCode); // note: modifies the struct in-place
        return ref this;
    }
}

사용법은 이전과 동일하게 유지됩니다.

return HashCode.Combine(1)
    .Combine(2).Combine(3);

유일한 단점은 다시 변경 가능한 구조체로 돌아간다는 것입니다. 하지만 복사와 불변성을 동시에 가질 수 있는 방법은 없다고 생각합니다.

( ref this 는 아직 작동하지 않지만 여기 에서 활성화하기 위해 Roslyn에서 PR을 봅니다

@AlexRadch 유형의 해시 코드를 얻는 데 비용이 많이 들기 때문에 해시를 유형과 더 결합하는 것이 현명하지 않다고 생각합니다.

@jamesqo public static HashCode CreateRandomized<T>(); 유형 해시 코드를 가져오지 않습니다. 이 유형에 대해 임의의 HashCode를 생성합니다.

@jamesqo " ref this 이(가) 아직 작동하지 않습니다". 로슬린의 문제가 해결 되더라도 일단 ref this 잠시 동안 corefx의 REPO (나는 확실히 얼마나 오래, @stephentoub 아마 설정할 수 있습니다 기대하지 않아요)을 사용할 수 없습니다.

디자인 논의는 여기에 수렴되지 않습니다. 게다가 200개의 댓글은 따라가기 매우 어렵습니다.
우리는 다음 주에 @jkotas 를 잡고 다음 화요일에 API 검토에서 제안을 플러시할 계획입니다. 그런 다음 추가 의견을 위해 제안서를 여기에 다시 게시할 것입니다.

옆에서: 나는 긴 토론을 따르는 부담을 줄이기 위해 다음 주에 우리가 그것을 가질 때 이 문제를 닫고 "축복받은 제안"으로 새 문제를 만들 것을 제안합니다. 나쁜 생각이라고 생각되면 알려주십시오.

@jcouv 아직 작동하지 않는 것은 괜찮습니다. 이 디자인이 출시될 때 따라갈 Unsafe 사용하여 일시적으로 이 문제를 해결할 수 있다고 생각합니다.)

@karelz OK :smile: 나중에 시간이 되면 이 제안을 닫고 새 제안을 열겠습니다. 나는 동의한다; 내 브라우저는 200개 이상의 댓글을 잘 처리할 수 없습니다.

@karelz 나는 걸림돌을 쳤다; 문제의 PR이 값 유형이 아닌 참조 유형에 대해 ref this 반환을 활성화하려고 시도한 것으로 나타났습니다. ref this 는 구조체에서 안전하게 반환될 수 없습니다. 이유는 여기 를 참조

어쨌든 이 문제는 닫겠습니다. 여기에서 다른 문제를 열었습니다. https://github.com/dotnet/corefx/issues/14354

C#vNext라고 가정하지만 값 유형 확장 메서드 게시물 https://github.com/dotnet/roslyn/pull/15650 에서 ref "this"를 반환할 수 있어야 합니다.

@benaadams

C#vNext라고 가정하지만 dotnet/roslyn#15650 이후의 값 유형 확장 메서드에서 ref "this"를 반환할 수 있어야 합니다.

옳은. ref this 확장 메서드에서 this 를 반환하는 것이 가능합니다. 그러나 일반 구조체 인스턴스 메서드에서 this 를 반환하는 것은 불가능합니다. 왜 그런지에 대한 피투성이의 평생 세부 사항이 많이 있습니다 :(

@redknightlois

우리가 엄격하게 하고 싶다면 유일한 해시는 uint 이어야 합니다. 프레임워크가 해당 조명 아래에서 int 반환하는 것은 간과로 볼 수 있습니다.

CLS 준수? 부호 없는 정수는 CLS 규격이 아닙니다.