2013-01-24 7 views
17

Obecnie do reprezentowania nowej linii w programach go używam \n. Na przykład:Jaki jest najbardziej przenośny/międzyplatformowy sposób reprezentowania nowej linii w go/golang?

package main 

import "fmt" 


func main() { 
    fmt.Printf("%d is %s \n", 'U', string(85)) 
} 

... spowoduje wydanie 85 is U, po którym nastąpi znak nowej linii.

Jednak nie wydaje się to takie wieloplatformowe. Patrząc na inne języki, PHP reprezentuje to ze stałą globalną (PHP_EOL). Czy \n jest właściwym sposobem reprezentowania nowych linii w specyficzny dla platformy sposób w go/golang?

Odpowiedz

15

Zaciekawiło mnie to, więc postanowiłem sprawdzić, co dokładnie robi fmt.Println. http://golang.org/src/pkg/fmt/print.go

Jeśli przewiniesz na sam dół, zobaczysz if addnewline, gdzie zawsze używana jest \n. Nie mogę ledwie mówić, jeśli jest to najbardziej "cross-platformowy" sposób, aby to zrobić, i początkowo był związany z Linuksem, ale to jest miejsce dla std lib.

Pierwotnie zamierzałem zasugerować użycie tylko fmt.Fprintln i może to być nadal aktualne, ponieważ obecna funkcjonalność nie jest odpowiednia, błąd może zostać zgłoszony, a następnie kod musiałby być po prostu skompilowany z najnowszym toolchainem Go.

+0

Jest OK, aby mieć „\ n” mają być drukowane bezpośrednio do jakiegoś wyjścia strumień z powodu tłumaczenia wiersza nowego, które jest włączone, gdy ten strumień wyjściowy nie jest binarny. Jest to właściwość biblioteki uruchomieniowej C, na której opiera się Go: automatycznie konwertuje zakończenia linii na te używane przez platformę, więc można bezpiecznie używać tylko "\ n" w kodzie programu. Działa to jednak tylko w przypadku strumieni innych niż binarne i nie będzie łatwo uzyskać separator linii platformy (na przykład jako ciąg znaków) przy użyciu tylko środowiska wykonawczego C. –

+4

@ VladimirMatveev, czy na pewno Go opiera się na środowisku wykonawczym C? Wygląda na to, że jego standardowe kompilatory nie zależą od środowiska wykonawczego C i nie produkują statycznych plików binarnych, które również nie są zależne od niczego. – kostix

+1

@kostix, wygląda na to, że masz rację. Przeglądanie wewnętrznych mechanizmów Go I/O sugeruje, że używają POSIX 'open()' syscall w systemach uniksowych i 'CreateFile' w systemach Windows do otwierania plików. Bufor dostarczony do 'os.File # Write' wydaje się być wysyłany w niezmienionej postaci bezpośrednio do funkcji API Windows' WriteFile'. Funkcje interfejsu Windows API nie wykonują konwersji kończących linię, więc wynik będzie zawierał tylko LF w przypadku, gdy w źródle istnieje tylko LF. –

10

Posiadanie systemu operacyjnego decyduje o tym, co dzieje się w znakach nowej linii w wielu kontekstach. To, co naprawdę chcesz wiedzieć, to "separator", a Go zakłada, że ​​ty, jako programista, musisz to wiedzieć.

Nawet jeśli plik binarny działa w systemie Windows, może pobierać plik z systemu operacyjnego Unix.

końca linii są określane przez co źródło pliku lub dokumentu powiedział była linia nie kończąc OS binarna jest uruchomiony.

Powiązane problemy