Cześć :) Czy wiadomo komuś, czy zmienna char w zależności od komputera może mieć inny zakreś? Np. na jednym komputerze od -128 do 127, a w innym od 0 do 255. Dzięks za pomoc z góry ;)

- Rejestracja:około 6 lat
- Ostatnio:prawie 3 lata
- Lokalizacja:Warszawa 🐪
- Postów:1719
Standard C++ nie przewiduje ilości danych jakie mają być przeznaczone na zmienną o type char. W praktyce na procesorach opartych na x86 (x86 i x64) jest to jeden bajt. Podana przez ciebie różnica w zakresie wynika z czegoś innego. Binarnie bajt może być ten sam, ale reprezentacja inna. Jako zmienna nieoznaczona będzie mieć zakres 0-255. Jako zmienna oznaczona przyjmie wartości od -128 do 127. Czemu? Temu, że jako oznaczona musi gdzieś przechować znak, najczęściej jest to najbardziej znaczący bit. Skoro zabieramy jeden bit z wartości, to nie może być już 255 tylko 127.

- Rejestracja:ponad 12 lat
- Ostatnio:22 dni
- Lokalizacja:Kraków
- Postów:1055
"The character types are large enough to represent any UTF-8 eight-bit code unit (since C++14). The signedness of char depends on the compiler and the target platform: the defaults for ARM and PowerPC are typically unsigned, the defaults for x86 and x64 are typically signed."
https://en.cppreference.com/w/cpp/language/types

- Rejestracja:ponad 10 lat
- Ostatnio:ponad 3 lata
- Postów:146
PerlMonk napisał(a):
Standard C++ nie przewiduje ilości danych jakie mają być przeznaczone na zmienną o type char. W praktyce na procesorach opartych na x86 (x86 i x64) jest to jeden bajt. Podana przez ciebie różnica w zakresie wynika z czegoś innego. Binarnie bajt może być ten sam, ale reprezentacja inna. Jako zmienna nieoznaczona będzie mieć zakres 0-255. Jako zmienna oznaczona przyjmie wartości od -128 do 127. Czemu? Temu, że jako oznaczona musi gdzieś przechować znak, najczęściej jest to najbardziej znaczący bit. Skoro zabieramy jeden bit z wartości, to nie może być już 255 tylko 127.
Kłamstwo.
Besides the minimal bit counts, the C++ Standard guarantees that
1 == sizeof(char)

- Rejestracja:około 6 lat
- Ostatnio:prawie 3 lata
- Lokalizacja:Warszawa 🐪
- Postów:1719
Craith napisał(a):
PerlMonk napisał(a):
Standard C++ nie przewiduje ilości danych jakie mają być przeznaczone na zmienną o type char. W praktyce na procesorach opartych na x86 (x86 i x64) jest to jeden bajt. Podana przez ciebie różnica w zakresie wynika z czegoś innego. Binarnie bajt może być ten sam, ale reprezentacja inna. Jako zmienna nieoznaczona będzie mieć zakres 0-255. Jako zmienna oznaczona przyjmie wartości od -128 do 127. Czemu? Temu, że jako oznaczona musi gdzieś przechować znak, najczęściej jest to najbardziej znaczący bit. Skoro zabieramy jeden bit z wartości, to nie może być już 255 tylko 127.
Kłamstwo.
Besides the minimal bit counts, the C++ Standard guarantees that
1 == sizeof(char)
Nie do końca. Cytat, który podałeś, nie niesie informacji czy w procesorze PowerPC i IA64 zmienna char zajmuje dokładnie tyle samo miejsca.

- Rejestracja:ponad 10 lat
- Ostatnio:prawie 2 lata
- Postów:2500
char
zawsze zajmuje 1 bajt, natomiast 1 bajt nie zawsze oznacza 8 bitów.
https://en.cppreference.com/w/cpp/language/sizeof

- Rejestracja:około 17 lat
- Ostatnio:4 minuty
Poza jałowym sporem o wielkość char
autor przypuszczalnie powinien się zapoznać z kodowaniem znaków.
Czyli wszystkie możliwe kombinacje od ASCII przez Windows-1252 Utf-8 aż po UCS-4 (UTF-32). Jestem prawie pewien, że tak naprawdę z tym ma problem, ale jeszcze sobie z tego sprawy nie zdaje.
- Rejestracja:ponad 5 lat
- Ostatnio:ponad 5 lat
- Postów:3
Dzięki za szybką odpowiedź!
@MarekR22 Możliwe, że masz rację nie za bardzo się znam na kodowaniu znaków. Nie wiem jednak, jak dokładnie jest to powiązane z problemem. Wiem, że w internecie na pewno mogę znaleźć dużo poradników na temat kodowania, ale czy Ty możesz mi jakiś polecić, najlepiej taki, który odpowiadałby do mojego problemu? Z góry dzięki
Reszcie dziękuje za zaangażowanie w temacie ale jako początujący trochę nie ogarniam, więc byłoby dobrze, jeśli skupilibyście się dokładnie na problemie zamiast wspomnianych przez @MarekR22 off-topów.

- Rejestracja:około 6 lat
- Ostatnio:prawie 3 lata
- Lokalizacja:Warszawa 🐪
- Postów:1719
JanuszB napisał(a):
Dzięki za szybką odpowiedź!
@MarekR22 Możliwe, że masz rację nie za bardzo się znam na kodowaniu znaków. Nie wiem jednak, jak dokładnie jest to powiązane z problemem. Wiem, że w internecie na pewno mogę znaleźć dużo poradników na temat kodowania, ale czy Ty możesz mi jakiś polecić, najlepiej taki, który odpowiadałby do mojego problemu? Z góry dziękiReszcie dziękuje za zaangażowanie w temacie ale jako początujący trochę nie ogarniam, więc byłoby dobrze, jeśli skupilibyście się dokładnie na problemie zamiast wspomnianych przez @MarekR22 off-topów.
A jaki dokładnie masz problem? Chcesz przetłumaczyć apkę na kilka języków i mieć pewność, że char będzie odpowiadać?

- Rejestracja:ponad 21 lat
- Ostatnio:około 3 godziny
twonek napisał(a):
char
zawsze zajmuje 1 bajt, natomiast 1 bajt nie zawsze oznacza 8 bitów.
Potrafisz wymienić architekturę, na której char nie ma 8 bitów? Ale taką z którą można się jeszcze gdziekolwiek spotkać, nawet wliczając starocia? ;-)
Bo to jest taka teoria akademicka, tak samo jak arytmetyka całkowita inna niż U2...

- Rejestracja:prawie 6 lat
- Ostatnio:około 6 godzin
- Postów:289
@Azarien:
Według tego co tu napisali: https://stackoverflow.com/questions/2098149/what-platforms-have-something-other-than-8-bit-char
Atmel - kompilator podobno pozwala wybrać
Procesory DSP Texas Instruments - C62xx - char ma 16-bitów
C64xx może mieć 8/16/32/40
Co do arytmetyki U2 - z tego co pamiętam były procesory w których można było wybrać tryb pracy ALU. Pamięć już szwankuje, ale jestem prawie pewien że MOS650x - ciągle do spotkania w 8-bitowych Atari i Commodore i nadal produkowany przez WDC - pozwalał przestawić ALU w tryb BCD.
Zdaje się, że którys z ARM-ow też miał możliwość wyboru (ale być może tu było tylko pomiędzy Little/Big Endian).
- Rejestracja:ponad 5 lat
- Ostatnio:ponad 5 lat
- Postów:3
@PerlMonk Nie, nic z tych rzeczy :) Jestem jeszcze wczesno-początkującym programistą i postanowiłem zacząć swoją przygodę od C++. Uczę się z książki Bjarne Stroustrup'a dla początkujących. Znalazłem tam wpis, że zakres chara zależy od komputera, ale że książka jest dość stara chciałem się zapytać bardziej doświadczonych osób jak to wygląda w praniu i od czego właściwie to zależy. Poszukałem na ten temat, ale nie udało mi się znaleźć odpowiednich informacji. Wyżej powiedziano, że powinienem zająć się kodowaniem znaków, ale nie do końca wiem, co autor miał na myśli, dlatego byłbym wdzięczny za podanie sprostowania lub adresu do strony, gdzie mógłbym dowiedzieć się, jak sprawa wygląda.
Tak btw. straszny offtop leci w temacie, nie wiem czy to przypadek, ale przeszkadza w zorientowaniu się o co chodzi, gdy widzę pełno niezrozumiałych dla mnie nazw xd.


- Rejestracja:ponad 11 lat
- Ostatnio:12 miesięcy
- Postów:215
0-255
https://www.ascii-code.com/
Zależy to od tego by każdy znak dało się zapisać w postaci dziesiętnej.
Chińczycy używają dwóch bajtów do reprezentacji znaku bo mają w alfabecie więcej dziabongów

- Rejestracja:ponad 11 lat
- Ostatnio:ponad rok
- Postów:1340
JanuszB napisał(a):
Np. na jednym komputerze od -128 do 127, a w innym od 0 do 255.
Na 8 bitach możesz zapisać 256 wartości. A czy zinterpretujesz je jako liczba ze znakiem czy bez to już Twój wybór.
Równie dobrze możesz napisać sobie klasę, która np. inaczej będzie traktowała pierwsze trzy bity a inaczej pozostałe pięć.
Jeśli chcesz operować dokładnie na ośmiobitowych wartościach to użyj typu std::uint8_t
/std::int8_t
.
Do zmiany "zakresu" możesz użyć static_cast
std::uint8_t liczbaNaturalna = 150;
std::int8_t liczbaCalkowita = static_cast<std::int8_t>(liczbaNaturalna); // = -106

- Rejestracja:około 17 lat
- Ostatnio:16 dni
au7h napisał(a):
0-255
https://www.ascii-code.com/Zależy to od tego by każdy znak dało się zapisać w postaci dziesiętnej.
Chińczycy używają dwóch bajtów do reprezentacji znaku bo mają w alfabecie więcej dziabongów
Witamy w XXI wieku drogi hibernatusie. Dziś wszyscy używają Unicode, w większości w kodowaniu UTF-8.
CHAR_BITS
o wartości minimum 8.