Zgodnie z moją wiedzą, nie istnieje równoważnik do biblioteki libc odpowiadający getline(), który działa z deskryptorem pliku zamiast pracować z FILE *.getline() z deskryptorem pliku zamiast wskaźnika pliku
Czy istnieje (techniczny) powód?
Możesz utworzyć strumień FILE z pliku opisu pliku przy pomocy fdopen.
Aby ogólnie uzyskać linię z deskryptora pliku, należy spytać system operacyjny o jedną znak na raz, co jest bardzo nieefektywne. (Wbudowane w POSIX powłoki read działają w ten sposób - linie odczytują bardzo nieefektywnie, pobierając bajt na raz).
Strumienie PLIKÓW proszą o dane z systemu operacyjnego w partiach, co poprawia wydajność, jednak deskryptor pliku może nie być plikiem do przewinięcia - może to być gniazdo lub potok, a jeśli poprosisz o 100 znaków, a trzeci znak z tej 100 partii będzie znakiem nowej linii, to nie będzie sposobu, aby ogólnie cofnąć odczyt 97 znaków po nim.
Nie trzeba pytać systemu operacyjnego o jeden znak za jednym razem, prosta implementacja jest możliwa przy użyciu statycznego bufora, aby pobrać tyle bajtów naraz jak chcesz z systemu operacyjnego. To było rzeczywiście ćwiczenie kodowania w szkole, w której uczyłem się, Epitech, zwanej get_next_line. Jestem pewien, że możesz znaleźć wiele projektów studenckich o tej nazwie na GitHub. Należy zauważyć, że jeśli chcesz użyć jednego z nich, powinieneś dostać taki, który utrzymuje deskryptory plików w tablicy, aby móc obsługiwać kilka plików jednocześnie. – deb0ch
@ deb0ch Pewnie. Ale wtedy będziesz czytać więcej niż tylko jedną linię, co oznacza, że twój kolejny dostęp do pliku będzie wyłączony, chyba że: a) będziesz dalej używał swojej buforującej warstwy b) przewinąć. I b) nie zawsze jest możliwe, ponieważ nie wszystkie pliki można przewijać. – PSkocik
Tak, właśnie dlatego mówiłem o statycznym buforze, aby ponownie użyć go w kolejnych połączeniach i skonsumować linie już obecne w buforze przed pobraniem nowych danych. Może potrzebna byłaby pewna praca, aby była niezawodna między close() i open(), dając ten sam plik fd dla innego pliku, ale moim celem jest to, że * jest * technicznie możliwe. – deb0ch
'getline' nie pochodzi ze standardu C, przypuszczam, że masz na myśli funkcję POSIX? –
Deskryptor plików terminów jest tak subiektywny, że może to być dowolna rzecz od IOFile do gniazda. więc linia odczytu może nie być poprawną metodą implementacji, chyba że jest bardzo związana z plikami –