Dlaczego tablice w .Net mają długość, a inne typy kolekcji mają liczbę? [Zamknięte]


23

Na przykład w języku C # tablice mają właściwość Length. Ale inne typy kolekcji, takie jak listy itp., Mają właściwość Count. Czy istnieje powód, dla którego te dwa są różne? Jeśli tak, chciałbym wiedzieć.


4
Nie mogę znaleźć mojego gwizdka Lipperta, więc nie sądzę, że dzisiaj otrzymamy dobrą odpowiedź :(
MetaFight

4
Po prostu zgadnij, ponieważ nie mam wewnętrznej wiedzy o tym, jak zaprojektowano CLR: szczegóły dotyczące działania tablic zostały określone przed typami kolekcji. Wywołanie właściwości Długość jest najbardziej naturalną nazwą dla niej, a ponieważ nie istniał wcześniej istniejący standard do spełnienia, więc właśnie tego użył projektant tablic. Następnie kolekcje zostały określone później, ale Długość nie jest odpowiednia dla niektórych kolekcji (implikuje liniowość, więc w przypadku kolekcji nieuporządkowanych nie jest to rozsądna nazwa), więc Count został wybrany jako bardziej logicznie spójny.
Jules

4
Wydaje mi się, że ten poprzedni post z przepływem stosów ma właściwą odpowiedź.
Doc Brown

6
@MetaFight: Niedawno nagrałem serię filmów edukacyjnych i w pewnym momencie wspominam, że nie mam pojęcia, dlaczego projektanci używali zarówno długości, jak i liczby. Zawsze wydawało mi się to dziwne. Komentarz Jules powyżej wydaje się wiarygodny.
Eric Lippert,

3
Notatka meta - rzuciłem VTC, ponieważ nie wierzę, że na to pytanie można ostatecznie odpowiedzieć. Istniejąca odpowiedź jest solidna i wiarygodna, ale nie jest poparta dowodami. Podobnie, komentarz Lipperta prowadzi mnie do wniosku, że nikt nie zna odpowiedzi, ponieważ mogła to wynikać z przeoczenia, a nie świadomej decyzji.

Odpowiedzi:


30

Są one nazywane inaczej, ponieważ są semantycznie różne:

Liczba kolekcji jest liczbą przechowywanych w niej przedmiotów i może z czasem ulec zmianie.

Długość tablicy to maksymalna liczba przedmiotów, które może pomieścić (będzie miała długość 10, nawet jeśli nie zgromadziłeś w niej tylu przedmiotów) i jest niezmienna.

Przykład:

Jeśli mam wiadro, w którym zmieści się maksymalnie 100 piłek, ma ono długość 100. Jeśli włożę do niego 50 piłek, wówczas będzie miało liczbę 50.

Jeśli dodam jeszcze 10 kulek, liczba będzie wynosić 60, ale długość będzie nadal wynosić 100. Aby zmienić długość, muszę zdobyć inne wiadro.

Tablica prawdopodobnie używa słowa Długość, ponieważ pod maską przydziela ciągły blok (długość) pamięci na podstawie pojemności pomnożonej przez rozmiar elementu. Chociaż fakt, że klasa List używa „Pojemność” do podobnej (choć zmiennej) koncepcji, sugeruje, że tablica może używać słowa „Długość” ze względów historycznych.


12
A T[]o długości N zawsze przechowuje dokładnie N wartości typu T. Semantycznie nie wszystkie z tych wartości mogą mieć znaczenie (mogą być nullna przykład), ale istnieją. Różni się to od zwykłego znaczenia pojemności (używanego List<T>na przykład przez). Masz rację, że Countmożesz się zmienić, a Lengthnie możesz. Z drugiej strony nic nie nakazuje, Countaby faktycznie się zmieniło. Jest również używany do niezmiennych kolekcji.

@ delnan oh kochanie. nie zdawałem sobie sprawy, że słowo Pojemność zostało już użyte w języku C # w ten sposób. Przypadkowo go przeciążyłem. Dzięki za zwrócenie na to uwagi. Zaktualizuję moją odpowiedź, aby wyjaśnić.
kombinatoryka

Różnica między pojemnością a długością jest - pojemność może się zmieniać w trakcie cyklu życia obiektu, podczas gdy długość zawsze pozostaje taka sama. Jeśli widzę właściwość Length na obiekcie, zakładam, że jest to „twarda” maksymalna liczba (lub obramowanie / indeks), a jeśli widzę właściwość Capacity, zakładam, że jest to „miękka” maksymalna liczba, którą powinienem tylko sprawdzić przeciw, jeśli martwię się wydajnością.
StupidOne

@StupidOne: Jeśli wybierzesz tę trasę, każda tablica powinna również mieć countwłaściwość -property.
Deduplicator

1
Cholerny StringBuilder ... w bardziej rygorystycznych językach takich jak Wigilia klasa StringBuilder zostałaby odpowiednio ukarana za zerwanie konwencji github.com/munificent/vigil
Falco
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.