W dniu poniedziałek, 11 lutego 2019 14:27:54 UTC+1 użytkownik Mateusz Viste napisał:
Wiem, że rozmawiamy trochę z przymrużeniem oka, więc miałem kiedyś przygodę, kiedy utrzymywana przeze mnie paczka (co gorsza, w Pythonie) przestała się budować. Tam był kod w C który był generowany automatycznie, a narzędzia do współpracy Python - C na pewnym etapie przestawiły flagi kompilatora z domyślnego "ANSI C z typowymi bajerami" na "brak wstępu dla młodzieży, wyrzucaj error przy czymkolwiek czego nie można według C89". Wszystko dzięki temu, że generowany kod miał "int i;" przed forem a nie na początku funkcji. Wtedy się dowiedziałem, że tego nie było w standardzie bo wszystkie kompilatory C jakich w życiu używałem nie miały co do tego obiekcji;)
Ja patrzę z punktu widzenia kogoś, kto czasem napisze coś na "normalny" komputer i chyba nigdy nie udało mi się napisać programu w C, który używa poza jakimiś niekrytycznymi pętlami po 100 elementach któregokolwiek z typów danych z C89. Standard C w tym zakresie jest spuścizną po czasach Unixa, kiedy starano się zrobić jeden przenośny język oprogramowania i system operacyjny obejmujący miriadę komputerów. Efekt jest taki, że w kontekście zwykłego x86-64 windowsowy long ma 32 bity, a uniksowy 64 i obydwa podejścia są zupełnie koszerne pod względem standardu. Long long rzeczywiście jest sposobem na wymuszenie zmiennej, która będzie miała te >= 64 bity ;)
Pozdrawiam,