Należy używać uint w C # dla wartości, które nie mogą być ujemne?

Właśnie próbowałem zaimplementować klasę, w której uintzamiast wielu właściwości length / count itp. Są int. Jednak robiąc to zauważyłem, że jest to bolesne, jakby nikt nie chciał tego robić.

Prawie wszystko, co podaje typ całkowy, zwraca an int, dlatego wymaga rzutów w kilku punktach. Chciałem skonstruować StringBufferz długością bufora domyślną dla jednego z pól w tej klasie. Wymaga też obsady.

Zastanawiałem się więc, czy po prostu powrócić do inttego miejsca. Z pewnością i tak nie używam całego zakresu. Pomyślałem tylko, że skoro to, z czym mam do czynienia, po prostu nie może być negatywne (gdyby tak było, byłby to błąd), fajnie byłoby to wykorzystać uint.

PS: Widziałem to pytanie i to przynajmniej wyjaśnia, dlaczego sam framework zawsze używa, intale nawet we własnym kodzie jest tak naprawdę niewygodny do trzymania się, uintco sprawia, że ​​myślę, że najwyraźniej nie jest tak naprawdę potrzebny.

Chociaż ściśle powinieneś używać uintdla zmiennych, które zawierają nieujemną liczbę całkowitą, natknąłeś się na jeden z powodów, dla których nie zawsze jest to wykonalne.

W tym przypadku nie sądzę, aby zmniejszenie czytelności związane z koniecznością wykonywania rzutów było tego warte.

Do innych odpowiedzi dodam również, że używanie uint jako typu pola publicznego, właściwości, metody, parametru itd. Jest naruszeniem zasad Common Language Specification i należy go unikać, gdy jest to możliwe.

Wartość ujemna jest często używana do sygnalizowania stanu błędu, a wywołanie funkcji często zwraca rozmiar operacji; wartość ujemna może zatem sygnalizować błąd bez uciekania się do mechanizmu wyjątków.

Należy również zauważyć, że .NET często opiera się na zwykłych bibliotekach C, dlatego rozsądne jest kontynuowanie tej konwencji. Jeśli potrzebujesz większej przestrzeni indeksów, możesz złamać konwencję dotyczącą innego mechanizmu sygnalizacji błędów.

Osobiście uważam, że prawdopodobnie powinieneś po prostu trzymać się int. Nie warto dodawać rzutowania do prawie każdego dostępu do właściwości tylko po to, aby odzyskać zakres liczbowy, którego .NET i tak prawdopodobnie nie pozwoli Ci użyć.

Używanie int jest również pomocne w wykrywaniu przepełnienia liczb całkowitych w operacjach.

IMO, wadą używania uintjest to, że przesłania błędy. Odpowiedniki poniższego kodu nie są tak ładne:

if (len < 0)
    terminate_program("length attained impossible value.");

Oczywiście twoje programy nie powinny na początku niczego przeliczyć, ale uważam, że powinny być napisane tak, aby szybko wykrywać błędy numeryczne bez propagacji. W przypadku, gdy MaxValue równa 2 ^ 31 jest wystarczająca, mówię, że używaj intwraz z właściwym użyciem System.Diagnostics.Debug.Assert()i odpowiednimi kontrolami błędów, jak pokazano powyżej.

Jeśli uintużywasz go razem z, checkedaby zapobiec niedomiarowi i uzyskać takie same wyniki. Jednak odkryłem, że sprawdzanie jest trochę trudne do zastosowania w istniejącym kodzie, który używa rzutów w jakimś celu.

Nie pływaj pod prąd, jeśli nie musisz. Brak literowania kodu za pomocą rzutowań sprawia, że ​​kod jest bardziej czytelny. Ponadto, jeśli możliwe wartości mieszczą się w int, to użycie int nie stanowi problemu.

Jeśli obawiasz się, że możesz przepełnić int, to zdecydowanie tam ... ale nie optymalizuj przedwcześnie.

Powiedziałbym, że poprawiona czytelność minimalizowania rzutów przeważa nad nieco podwyższonym ryzykiem błędu przy użyciu int.

Jeśli chcesz sprawdzić, czy wartość jest dodatnia, lepszym sposobem jest prawdopodobnie użycie assert (zwróć uwagę, że jest to tylko technika debugowania - powinieneś upewnić się, że nigdy nie wystąpi to w końcowym kodzie).

using System.Diagnostics;
...
Debug.Assert (i > 0);