🚀 go-pugleaf

W dniu niedziela, 15 grudnia 2019 20:08:41 UTC+1 użytkownik Borneq napisał:
> signed char utrudnia porównywanie, bo #128 <#0
> zwykle lubię działać na bajtach, czyli unsigned char a to wymaga 
> rzutowania. Co stało za wyborem by char używać ze znakiem?

Zdaje się, że standard pozostawia implementacji to, czy char będzie domyślnie signed, czy unsigned. 

Zdefiniuj sobie

typedef unsigned char byte;

albo używaj uint8_t z <stdint.h> i po kłopocie.

Borneq <borneq@antyspam.hidden.pl> wrote:

> signed char utrudnia porównywanie, bo #128 <#0
> zwykle lubię działać na bajtach, czyli unsigned char a to wymaga 
> rzutowania. Co stało za wyborem by char używać ze znakiem?

Podejrzewam, że chęć zachowania konsekwencji. Taki int np. jest już 
signed.

gcc ma flagę -funsigned-char. Możesz użyć.

-- 
https://www.youtube.com/watch?v=9lSzL1DqQn0

No to albo działasz na bajtach, albo znakach. Typ uint8_t ma dokładnie 8 bitów i jest bez znaku. W C++17 jest std::byte, ale nie miałem jeszcze okazji używać.

w.

W dniu 2019-12-16 o 18:41, Queequeg pisze:

>> signed char utrudnia porównywanie, bo #128 <#0
>> zwykle lubię działać na bajtach, czyli unsigned char a to wymaga
>> rzutowania. Co stało za wyborem by char używać ze znakiem?
> 
> Podejrzewam, że chęć zachowania konsekwencji. Taki int np. jest już
> signed.

Nie rozumiem.
Brzmi tak jakby char nie było signed, ale int już tak.
A przecież char też jest signed.
P.G.

On Sunday, December 15, 2019 at 9:04:13 PM UTC+1, Maciek Godek wrote:
> W dniu niedziela, 15 grudnia 2019 20:08:41 UTC+1 użytkownik Borneq napisał:
> > signed char utrudnia porównywanie, bo #128 <#0
> > zwykle lubię działać na bajtach, czyli unsigned char a to wymaga 
> > rzutowania. Co stało za wyborem by char używać ze znakiem?
> 
> Zdaje się, że standard pozostawia implementacji to, czy char będzie domyślnie signed, czy unsigned. 
> 
> Zdefiniuj sobie
> 
> typedef unsigned char byte;
> 
> albo używaj uint8_t z <stdint.h> i po kłopocie.

Zależy po jakim kłopocie :) np. std::cout nie traktuje tego jako
inta:

uint8_t x = 33;
std::cout << x << std::endl;

U mnie wyświetla wykrzyknik.

W dniu 2019-12-17 o 16:34, Piotr Gałka pisze:
> W dniu 2019-12-16 o 18:41, Queequeg pisze:
> 
>>> signed char utrudnia porównywanie, bo #128 <#0
>>> zwykle lubię działać na bajtach, czyli unsigned char a to wymaga
>>> rzutowania. Co stało za wyborem by char używać ze znakiem?
>>
>> Podejrzewam, że chęć zachowania konsekwencji. Taki int np. jest już
>> signed.
> 
> Nie rozumiem.
> Brzmi tak jakby char nie było signed, ale int już tak.
> A przecież char też jest signed.

char domyślnie może być signed jak i unsigned - zazwyczaj zależy od 
ustawień kompilatora.

-- 
http://kaczus.ppa.pl

Piotr Gałka <piotr.galka@cutthismicromade.pl> wrote:

>> Podejrzewam, że chęć zachowania konsekwencji. Taki int np. jest już
>> signed.
> 
> Nie rozumiem.
> Brzmi tak jakby char nie było signed, ale int już tak.
> A przecież char też jest signed.

int domyślnie jest signed, bo tego wymaga standard. char może być signed 
lub unsigned, bo standard tego nie określa, ale w gcc domyślnie jest 
signed -- domyślam się, że przez chęć zachowania konwencji, zgodnie z 
którą większe typy są signed (bo tego wymaga standard).

-- 
https://www.youtube.com/watch?v=9lSzL1DqQn0

W dniu 2019-12-18 o 08:10, Tomasz Kaczanowski pisze:
> 
> char domyślnie może być signed jak i unsigned - zazwyczaj zależy od 
> ustawień kompilatora.
> 

Człowiek uczy się całe życie. Dla mnie 'od zawsze' char było signed.
Może kiedyś (lata temu) widziałem flagę kompilatora zmieniającą to, ale 
musiałem o tym zapomnieć.
P.G.

2019-12-19 o 10:39 +0100, Piotr Gałka napisał:
> W dniu 2019-12-18 o 08:10, Tomasz Kaczanowski pisze:
> > 
> > char domyślnie może być signed jak i unsigned - zazwyczaj zależy od 
> > ustawień kompilatora.
> >   
> 
> Człowiek uczy się całe życie. Dla mnie 'od zawsze' char było signed.
> Może kiedyś (lata temu) widziałem flagę kompilatora zmieniającą to,
> ale musiałem o tym zapomnieć.

Już w 1987 Turbo C miało do tego celu "-K". Dzisiejsze gcc i clang też
mają stosowny switch.

Mateusz

W dniu 2019-12-19 o 11:05, Mateusz Viste pisze:

>> Człowiek uczy się całe życie. Dla mnie 'od zawsze' char było signed.
>> Może kiedyś (lata temu) widziałem flagę kompilatora zmieniającą to,
>> ale musiałem o tym zapomnieć.
> 
> Już w 1987 Turbo C miało do tego celu "-K". Dzisiejsze gcc i clang też
> mają stosowny switch.
> 

Wtedy jeszcze interesowałem się flagami kompilacji, bo człowiek się na 
przykład zastanawiał jaki model pamięci (zaczynając od tiny) dla każdego 
programu itp.
Podejrzewam, że ostatnio przejrzałem flagi w okolicy 2000 i wtedy 
ustawiony zestaw (cały czas używam C++ Builder 5) się po prostu kopiuje 
jak kopiuję programik (nie piszę nic poważnego) aby na jego bazie zrobić 
kolejny.
Zupełnie mi wyszło z głowy, że coś tam zależy od flag - ja mam zawsze 
tak samo i u mnie char jest signed.
Myślałem, że wszyscy tak mają :)
P.G.

On Thursday, December 19, 2019 at 11:05:59 AM UTC+1, Mateusz Viste wrote:
> 2019-12-19 o 10:39 +0100, Piotr Gałka napisał:
> > W dniu 2019-12-18 o 08:10, Tomasz Kaczanowski pisze:
> > > 
> > > char domyślnie może być signed jak i unsigned - zazwyczaj zależy od 
> > > ustawień kompilatora.
> > >   
> > 
> > Człowiek uczy się całe życie. Dla mnie 'od zawsze' char było signed.
> > Może kiedyś (lata temu) widziałem flagę kompilatora zmieniającą to,
> > ale musiałem o tym zapomnieć.
> 
> Już w 1987 Turbo C miało do tego celu "-K". Dzisiejsze gcc i clang też
> mają stosowny switch.
> 
> Mateusz

Stare dobre czasy, był sobie DOS i turbo pascal lub turbo C.

On 2019-12-20 03:10, M.M. wrote:
[...]
> Stare dobre czasy, był sobie DOS i turbo pascal lub turbo C.
> 
Hyhy, to tak jakbym słyszał moją matkę, emerytkę, która czasami mówi, że
za komuny było dobrze. Ja jej wtedy przypominam, gdy jako szczawia,
jeszcze przed wojną, wysyłała mnie do pobliskiego spożywczaka, abym
stanął w kolejce po ĆWIERĆ kostki masła. :-)

Ja od siebie bym dodał, że były też MCS-51, MCS-48, 8080, Z-80 i
oczywiście nieśmiertelny 8086, a nie to co teraz, Panie, jakieś tam
AMY-y, MIPS-y i i7. :-)

W dniu 2019-12-22 o 16:35, JDX pisze:

> Ja od siebie bym dodał, że były też MCS-51, MCS-48, 8080, Z-80

I program się ładowało do EPROMu :)
P.G.