Błędy przy użyciu THashSet z biblioteki kolekcji DeHL

Question

Jestem całkiem nowy dla Delphi i próbuję użyć biblioteki Kolekcje DEHL. (zobacz http://code.google.com/p/delphi-coll/) Mam trochę problemów z nim z perspektywy IDE. Kompiluje się i działa poprawnie, ale Delphi XE pokazuje błędy wszędzie, gdzie używam biblioteki HashSet. Największą skargą jest to, że nie mogę używać kodu.

Pierwsze miejsce pojawia się błąd w deklaracji obiektu:

uses 
    SysUtils, Windows, Collections.Base, Collections.Sets, Collections.Lists, 
    adscnnct, adstable, 
    uOtherClass; 

type 
    OneClass = class(OtherClass) 
    private 
     _bad: THashSet<string>; // THashSet underlined 
     _good: TList<string>;  // No problems 
    end; 

państw o ​​błędach: „argumenty typu nie pasuje do ograniczenia”

Nie sądzę, że to konfiguracja, jak mogę używaj TLista w porządku, ale oto jak to skonfigurowałem: skopiowałem bibliotekę do Projects/Libs/DeHLCollections/Library i skompilowałem bibliotekę do Projects/Libs/bin. Włączyłem katalog bin w mojej ścieżce biblioteki globalnej, która dostarczyła go do kompilacji i uruchomienia. Próbowałem dodać do niego wszystko (/ libs,/DeHLCollections,/Library), mając nadzieję, że IDE pomoże mi, ale wydaje się, że to nie pomaga.

W każdym razie, aby to naprawić, czy po prostu muszę sobie z tym poradzić?

Korzystanie DeHL kolekcjach wersji 1.1.1.119

Answer 1

Witamy kłopotów z użyciem leków generycznych kod Ladena. DeHL i generics działają dużo lepiej w Delphi XE niż w jakiejkolwiek poprzedniej wersji Delphi, ale to nie to samo, co "brak problemów". Problemy, których doświadczam, są dokładnie takie same jak twoje.

Moja opinia jest taka, że ​​DeHL pokazuje każdy znak, że został napisany przez programistę delphi, i że jest to rzecz piękna, pod pewnymi względami. To także źródło wielkiego bólu, bez żadnej winy.

Delphi nie zawiera jednego lub dwóch, ale co najmniej trzech (może czterech?) Oddzielnych analizatorów składni, włączając pełny analizator składni i kilka parserów IDE używanych do takich rzeczy jak Error Insight (błędy, które widzisz nawet przed kompilacją) i parser danych zakończenia kodu. Każda z nich ma inne ograniczenia dotyczące obsługi języka w odniesieniu do leków generycznych. Być może możliwe jest napisanie DeHL, aby uniknąć problemów z parserem ze wszystkimi różnymi parserami Delphi. Nie widziałem nigdy napisanego przewodnika, który pokazuje ograniczenia, ale nie zdziwiłbym się, gdyby złożone deklaracje typu w postaci TSomething<TSomething<ISomethingElse>,TBar<IFoo>> dzieliły więcej niż kilka z tych parserów.

Jeśli zamierzasz używać generics bardzo mocno, możesz równie dobrze wyłączyć Code Completion i Error Insight. Możesz również często oszczędzać i być przygotowanym na wiele problemów z kompilatorem. I nie próbuj kompilować kodu generycznego generycznego i umieszczaj go w pakietach. Doświadczyłem wielu URW i AV (wewnętrzne błędy kompilatora) podczas pisania kodu opartego na generycznych. Uważam, że zespół kompilatorów Delphi jest świetny w naprawianiu tego, co zostało zgłoszone, ale Generics są dla mnie najbardziej stabilne, gdy ograniczam się do korzystania z Generics.Collections, które pochodzą z Delphi, i nie używając innych generycznych kodów. Wydaje się, że można pisać rzeczy za pomocą funkcji generycznych, że IDE i narzędzia dwukierunkowe oraz uzupełnianie kodu nie jest jeszcze w pełni gotowe do obsłużenia. Oznacza to, że fenomenalne kosmiczne moce generyczne są kosztem klasycznych cech wydajności RAD IDE.

Zgodnie z tym, latest DeHL sources from Subversion działa dobrze dla mnie i budować i uruchomić bez błędów, ale najnowszy kod źródłowy ZIP całej kolekcji DeHL miał problemy dla mnie.

Spodziewam się, że w ciągu następnych kilku wydań Delphi, jakiekolwiek problemy zostały znalezione (i DeHL wydaje się być doskonałym miejscem do przekraczania granic, i to jest jeden z powodów, dla których jestem ich wielkim fanem) być naprawione i nie będziesz się zastanawiał, dlaczego ciężkie generics łamią twoje funkcje IDE, ponieważ wszystkie będą znowu działać.