Może wydajność? Uważam, że używanie liczb całkowitych niezwiązanych z rzeczywistością powoduje, że programy są bardziej skomplikowane i podatne na błędy podczas przenoszenia do innej architektury.Czy istnieje jakaś zaleta używania liczb całkowitych niepodzielnych (int, long) zamiast stałych o stałej wielkości (int64_t, int32_t)?
są dostarczane . A zatem portowanie kodu, który z nich korzysta, może się nie udać.
Wolałbym std::intfastN_t do ogólnego użytku, ponieważ ma on mniejsze ograniczenia i powinien być szybszy lub szybszy niż int.
Ponadto, większość kodu C++ używa int wszędzie więc może napotkasz promocyjnej tajemniczości kiedy przechodząc std::int32_t do funkcji przyjmującej int, zwłaszcza jeśli sizeof(int) jest tylko 16 bitów.
Wiele interfejsów API akceptuje lub zwraca wartości nieokreślonych typów. Na przykład deskryptory plików są typu int, przesunięcia plików lub rozmiary są typu off_t i strtol() zwraca long. Ślepa konwersja takich wartości z lub na typy o stałym rozmiarze prawdopodobnie spowoduje przepełnienie na niektórych komputerach.
Typy gwarantowanej szerokości (intN_t) są po prostu typedefs dla odpowiednich "standardowych" typów całkowitych. Jeśli platforma nie ma odpowiedniego typu (na przykład używa liczb całkowitych 36-bitowych), to nie może i nie może podawać gwarantowanej szerokości. Oznacza to, że wydajność nie może być argumentem.
Ogólna wytyczna dotycząca maksymalnej możliwości przenoszenia (w tym względzie) polega na domyślnym użyciu "standardowych" typów całkowitych i gwarantowanych szerokości tylko wtedy, gdy algorytm wymaga dokładnej liczby bitów. Należy przyjąć, że "standardowe" typy całkowite są tylko tak szerokie, jak gwarantowane przez odpowiednie standardy (jeśli spojrzymy tylko na standard C++, będą to: 8-bitowe char, 16-bitowe int, 32-bitowe long oraz , jeśli twój kompilator ją obsługuje, 64-bitowe long long).
Jeśli masz dane, w których rozmiar twojego typu ma kluczowe znaczenie dla jego funkcjonalności, powinieneś używać typów o zdefiniowanych rozmiarach. Jednak na przykład fragment kodu, który znajduje się w granicach [czego możesz rozsądnie oczekiwać] w swoim zasięgu (powiedzmy na przykład licznik pętli 1 ... 1000), nie ma powodu, aby używać int_32t tylko dlatego, że chcesz zdefiniować swoją zmienną . Będzie działał bez problemu z 16, 32, 64, 36, 18 lub 49-bitową liczbą całkowitą, wszystko to samo. Niech kompilator wybierze najlepszy rozmiar.
Istnieje możliwość, że kompilator wygeneruje gorszy kod dla stałych liczb całkowitych, które nie są "najlepszym wyborem" dla architektury.
Oczywiście wszelkie dane prezentowane w sieci lub w pliku muszą mieć stały rozmiar. Podobnie, jeśli masz interfejsy, które wymagają zgodności binarnej na granicy interfejsu, użycie typów zdefiniowanych rozmiarów jest bardzo użyteczne, aby uniknąć problemu z rozmiarem.
Uważam, że dokładny rozmiar bardzo rzadko ma znaczenie w moim kodzie - w takich przypadkach użycie liczb całkowitych o stałej wielkości po prostu dodaje rufę i zmniejsza przenośność. Co robisz, co wymaga znajomości rozmiaru bitowego? – delnan
Myślę, że sprowadza się to do założeń, które chcesz zrobić. Czy chcesz założyć, że konkretna wartość zawsze będzie zawierała dokładną liczbę bitów w dowolnej architekturze? Jeśli tak, poprawna wielkość całkowita może być właściwym wyborem. Jeśli nie, to możesz po prostu użyć typu, który gwarantuje pewną minimalną liczbę bitów. –