Witam.
Czy ktoś mógłby mi wyjaśnić jak uzyskano obsługę wejścia i wyjścia w C skoro sam C tego nie potrafi?
To oznacza, że np. stdio i funkcja printf lub scanf została napisana w asemblerze?
Ja wywołuję w swoim programie funkcję z biblioteki standardowej i już, ale jak ta funkcja została zaimplementowana, opisana?
Zależy gdzie. Na Windowsie/Linuksie to po prostu wrappery na API systemowe, a np. pod DOS-m to zapewne wrappery wokół odpowiednich przerwań. Co do implementacji w asm, wątpię.
Na takim Linuksie istnieje nagłówek unistd.h, a w nim funkcje ssize_t read(int fd, void *buf, size_t count); oraz ssize_t write(int fd, const void *buf, size_t count);. Najpewniej za ich pomocą napisano printf i scanf. One same są z kolei prostymi wrapperami na wywołania systemowe (to jest termin, który możesz zgooglować).
Z tego co się orientuję w Linuxie to kernel obsługuje podstawowe operacje typu read/write i udostępnia je user space'owi. W user space działa biblioteka libc, która udostępnia userowi zarówno funkcje podstawowe typu read/write jak i fread/fwrite. Jeśli więc piszesz program (aplikcję) w user space to korzystasz z funckji bibliotecznych libc, który później przetwarza i przekazuje parametry kernelowi. Funkcji printf/scanf szukaj w źródłach libc-a, nie ma powodu żeby kernel zajmował się parsowaniem stringów.
A co do stdin/stdout/stderr to nie jestem pewien - ale albo te deskryptory tworzy kernel albo libc. Ale tu nie mam pewności. Kernel udostępnia samą generyczną obsługę deskryptorów plików a glibc może tworzyć stdin/out/err na podstawie tych deskryptorów.
Czy to znaczy, że nawet w miarę sprawny programista C nie do końca wie, czy interesuje się tym co siedzi w tych funkcjach? Nie ma sensu zgłębiać tematu na początku tylko przyjąć, że printf to obsługa standardowego wyjścia a scanf wejścia i nie ważne w jaki sposób dzieje się to co się dzieje?
Bo rozumiem, że w zależności od platformy sprzętowe/systemowej rozwiązywane jest to w inny sposób. Inaczej na komputerze z Linuxem a inaczej w jakimś systemie wbudowanym z mikrokontrolerem i wyświetlaczem LCD?
andijaw napisał(a):
Czy to znaczy, że nawet w miarę sprawny programista C nie do końca wie, czy interesuje się tym co siedzi w tych funkcjach?
Zasada jest prosta i nie dotyczy tylko C. Jeśli biblioteka działa to w większości przypadków wiedza jak jest zbudowana jest niepotrzebna. Wystarczy wiedza jak używać. Wiedza o wnętrzności biblioteki zaczyna być przydatna dopiero jak biblioteka ma bugi lub zaczynamy mieć inne problemy np. wydajnościowe
Bo rozumiem, że w zależności od platformy sprzętowe/systemowej rozwiązywane jest to w inny sposób.
Istnieje nawet wiele różnych implementacji biblioteki standardowej C
Many other implementations exist, provided with both various operating systems and C compilers. Some of the popular implementations are the following:
BSD libc, implementations distributed under BSD operating systems
GNU C Library (glibc), used in GNU Hurd, GNU/kFreeBSD and Linux
Microsoft C run-time library, part of Microsoft Visual C++
dietlibc, an alternative small implementation of the C standard library (MMU-less)
μClibc, a C standard library for embedded μClinux systems (MMU-less)
Newlib, a C standard library for embedded systems (MMU-less)[5]
klibc, primarily for booting Linux systems
musl, another lightweight C standard library implementation for Linux systems[6]
Bionic, originally developed by Google for the Android embedded system operating system, derived from BSD libc
za wikipedią
Tak, po to systemy budowane są warstwowo, żeby nie trzeba było się znać na tym co poniżej. Nie każdy programista C będzie wiedział jak wysłać coś np. na konsolę szeregową czy na LCD w danym systemie i nie każdego to interesuje - dlatego zapewnia się takiemu programiście bibliotekę C, która ma przekierowanie stdout na seriala albo LCD.
No i to chciałem wiedzieć bo już myślałem, że się pogrążam czym bardziej chcę coś zgłębić. Nawet w książce K&R ANSI C (którą wyrwałem na dniach wydrukowaną w 2020 r. bo już nie było dostępnych egz. za 35 zł w promo) nie zgłębiają tematu a na niej i książce Marka Tłuczka się opieram aktualnie. Tam jest dokładnie jak używać funkcji ale nie ma jak to się dzieje, że daje ona pożądany wynik.
Upraszczając, taki printf po prostu formatuje stringa z tymi wszystkimi znacznikami i przesyła go dalej - do funkcji która już w stringu nie miesza ale zajmuje się wypluciem tego na standardowe wyjście.
Jeśli tym wyjściem jest okno konsoli na ekranie w trybie graficznym, po iluś tam pośrednich warstwach znajdziemy się w bibliotece która składa piksele tekstu korzystając z jakiegoś fonta, a potem w sterowniku karty graficznej który gada bezpośrednio ze sprzętem - przy czym to wcale nie musi się wszystko dziać w ramach naszego printfa, tylko w zupełnie osobnym wątku, osobnym procesie.
Wygląda to znacznie prościej jeśli to jest „prawdziwa” konsola w trybie tekstowym (czyli np. Linux bez żadnych X-ów, choć i pod Linuxem tryb tekstowy jest teraz zwykle emulowany).