.net에서 OrderedDictionary의 일반적인 구현이없는 이유는 무엇입니까?

Microsoft가 OrderedDictionary의 일반적인 구현을 제공하지 않은 이유는 무엇입니까?

내가 본 몇 가지 사용자 정의 구현이 있습니다. http://www.codeproject.com/KB/recipes/GenericOrderedDictionary.aspx

그러나 왜 Microsoft가 기본 .net 라이브러리에 포함시키지 않았습니까? 분명히 그들은 제네릭을 만들지 않은 이유가 있었지만 ... 무엇입니까?

이 메시지를 게시하기 전에 https://stackoverflow.com/questions/2629027/no-generic-implementation-of-orderdictionary를 보았습니다.

그러나 그것은 존재하지 않는다는 것을 확인합니다. 아니 왜 이 존재하지 않습니다.

감사

c# .net

— nonot1
소스

항상 존재 SortedDictionary<TKey, TValue>: msdn.microsoft.com/en-us/library/f7fta44c.aspx

— Travis Gockel

SortedDict 문서를 오해하지 않는 한, 그것은 내가 원하는 것이 아닙니다. 정렬을 원하지 않습니다. 키로 액세스 할 수있는 배열을 원합니다. 어쨌든 MS가 왜 이것을 건너 뛰었는지 궁금합니다. (미묘한 문제 등)

— nonot1

정렬 된 사전의 일반적인 사용 사례는 무엇입니까? 나는 내 머리 꼭대기에서 하나를 생각하기 위해 고심하고 있습니다.

— Carson63000

@Carson 언제든지 빠른 임의 액세스가 필요한 데이터 항목 배열이 있습니다. 단순히 Dict에 저장하려면 주문 정보가 손실되고 배열을 사용하려면 자체 색인을 유지해야합니다.

— nonot1

Eric Lippert에게 질문을 읽고 답변하도록 요청하십시오. 그는 일반적으로 이러한 유형의 질문을 돕는 데 매우 동의합니다. 나는 당신이 그의 블로그를 통해 그에게 연락 할 수 있다고 생각합니다 : blogs.msdn.com/b/ericlippert

— devuxer

답변:

에서 C # 4.0에서 간단히 말해서 나는이 읽기 :

이 OrderedDictionary의 조합 HashTable및ArrayList
일반이 없습니다 ArrayList
"비 제네릭 ArrayList클래스는 주로 Framework 1.x와의 호환성을 위해 사용됩니다 ..."
" ArrayList기능적으로 유사하다 List<object>"
"비 제네릭 ArrayList을 사용하면 List<object>"

결론?

어떤 일반 OrderedDictionary이 기본 있기 때문에 구조에는 일반 버전 자체가없는 (비공식적으로) 감가 상각 클래스입니다.

— 레이더 밥
소스

이것은 실제로 질문에 대답하지 않습니다. 제네릭 OrderedDictionary는 제네릭 사전과 제네릭 목록에 구축 될 수 있습니다.

— JacquesB

클래스 사용의 한 가지 교훈은 구현에 관심이있는 사람이 UI를 변경하지 않는 경우입니다. 언어 설계 / 컴파일러 팀 은 제네릭이 아닌 제네릭을 상속하는 제네릭을 선호 할 수 있습니다 . 내 욕심이 흔들린다. 우선 : 다른 (즉시) 조상들이 공분산과 대조 분산 의 진화 경로에있는 지뢰 인가OrderedDictionary ?

— radarbob

OrderedDictionary과부하 인덱싱 작업 때문에 정수와 인덱싱 N위치에 항목을 얻을 것이다 N,으로 인덱싱하는 동안 Object해당 개체에 풀어서 항목을 검색합니다. OrderedDictionary<int, string>호출 된 을 만들고 myDict항목 (1, "George") 및 (0, "Fred")를 순서대로 추가하려면 myDict[0]"George"또는 "Fred"를 반환 해야 합니까?

이러한 문제는 키 유형에 클래스 제약 조건을 적용하여 해결할 수 있습니다. 반면에 일반 컬렉션의 유용성은 가치 유형을 효율적으로 처리 할 수있는 능력에서 비롯됩니다. 키 유형에 클래스 제약 조건을 적용하면 약간 추한 것처럼 보입니다.

클래스가 CLS를 준수하지 않아도 vb.net과 함께 작동해야한다면 명명 된 인덱스 속성을 사용하는 것이 합리적이었습니다. 따라서 위의 예에서 myDict.ByKey[0]"Fred"를 myDict.BySequence[0]산출하고 "George"를 산출했을 것입니다. 불행히도 C #과 같은 언어는 명명 된 인덱스 속성을 지원하지 않습니다. 하나는 심지어 속성없이 위 구문의 사용을 허용하는 kludged 뭔가를 할 수 있지만, 불행한 결정은 같은 구조의 필드를 포장하는 Point과 Rectangle에 대한 것을 수단을 myDict.ByKey[0] = "Wally"하려면 myDict.ByKey새로운 클래스의 객체를 반환해야합니다. 구조체는 더 효율적이지만 컴파일러는 읽기 전용 구조에 대한 쓰기처럼 보이는 것을 거부합니다 (속성이 속성이 반환 한 구조체를 수정하지는 않더라도)ByKey참조가있는 컬렉션을 수정하십시오.

개인적으로, 나는 삽입 순서를 추적하도록 지정된 사전 같은 객체가 좋은 것이라고 생각합니다. 또한 특정 키와 관련된 키를 쉽게 반환 할 수있는 사전 -ish 객체를 갖고 싶습니다 (예 : 대소 문자를 구분하지 않는 사전이 있고 키가 "GEORGE"인 레코드를 추가 한 경우 KeyValuePair열거에 반환 된 모든 객체 를 검색하지 않고도 사전에 "George"와 관련된 키를 요청할 수 있습니다.

— 슈퍼 캣
소스

순서를 유지하면 추가 / 제거 성능이 떨어지고 메모리 사용량이 증가하는 두 컬렉션 (주문 용, 검색 용)을 래핑하지 않는 한 IDictionary가 암시하는 O (1) 조회를 방지 할 수 있습니다. 또는 메모리 사용량을 줄이기 위해 검색 속도가 느려질 수 있습니다.

내 생각 엔 여기에는 '더 나은'선택이 없었기 때문에 표준 라이브러리로 들어 가지 않았습니다. 특히 2.0 부근에서 C #은 여전히 Java의 실수로부터 배우고있었습니다. 표준 라이브러리의 컬렉션에 대한 Java의 '모든 것 및 부엌 싱크대'접근 방식도 피해야 할 것으로 보아도 놀라지 않을 것입니다.

— 텔라 스틴
소스

메모리를 적게 사용하면서 조회 속도를 느리게하면 효과적으로 OrderedDictionarya가 List됩니다. 합법적 인 유스 케이스가있는 사람 OrderedDictionary은 O (1) 조회가 있지만 삽입 순서를 기억하기 때문에 추가 메모리를 사용하는 것이 불가피하고 수용 가능하기 때문에 특별히 사용하고 있다고 생각합니다.

— Abion47