Mengapa tanda persen (%) dipilih sebagai penentu format untuk keluarga fungsi printf?


27

Semua orang tahu, setidaknya dalam C, Anda menggunakan printfkumpulan fungsi untuk mencetak string yang diformat. Dan fungsi-fungsi ini menggunakan tanda persen ( %) untuk menunjukkan awal penentu format. Misalnya, %dberarti untuk mencetak int, dan %uberarti untuk mencetak unsigned int. Jika Anda tidak terbiasa dengan cara printffungsi dan format placeholder bekerja, atau hanya perlu penyegaran, artikel Wikipedia adalah tempat yang baik untuk memulai.

Pertanyaan saya adalah, apakah ada alasan kuat mengapa ini awalnya atau harus dipilih di masa depan sebagai penentu format?

Jelas keputusan itu dibuat sejak lama (sangat mungkin untuk pendahulu bahkan bahasa C), dan itu sudah lebih atau kurang "standar" sejak saat itu (tidak hanya dalam bahasa C, tetapi juga dalam berbagai bahasa lain yang telah mengadopsi sintaksnya ke berbagai derajat), jadi sudah terlambat untuk berubah. Tapi saya masih penasaran apakah ada yang punya wawasan tentang mengapa pilihan ini mungkin telah dibuat di tempat pertama, dan apakah masih masuk akal sebagai pilihan jika seseorang merancang bahasa baru dengan fungsi yang sama.

Sebagai contoh, dengan C # (dan keluarga lain dari bahasa .NET), Microsoft membuat keputusan yang sedikit berbeda mengenai pengoperasian fungsi pemformatan string. Meskipun beberapa tingkat keamanan jenis dapat ditegakkan di sana (tidak seperti penerapan printfdi C), dan oleh karena itu tidak perlu menyertakan indikasi jenis parameter yang sesuai, mereka memutuskan untuk menggunakan pasangan kurung kurawal yang tidak diindekskan ( {}) sebagai penentu format, seperti:

string output = String.Format("In {0}, the temperature is {1} degrees Celsius.",
                              "Texas", 37);
Console.WriteLine(output);

// Output:
//     In Texas, the temperature is 37 degrees Celsius.

Dokumentasi untuk String.Formatmetode ini berisi lebih banyak informasi, seperti halnya artikel ini tentang pemformatan komposit secara umum , tetapi detail yang tepat agak tidak penting. Intinya adalah bahwa mereka meninggalkan praktik lama menggunakan %untuk menunjukkan awal penentu format. Bahasa C bisa saja dengan mudah digunakan {d}dan {u}, tetapi tidak. Adakah yang memiliki pemikiran tentang mengapa, apakah keputusan ini masuk akal jika ditinjau kembali, dan apakah implementasi baru harus mengikutinya?

Jelas tidak ada karakter yang bisa dipilih yang tidak harus bisa diloloskan sehingga bisa dimasukkan ke dalam string itu sendiri, tetapi masalah itu sudah diselesaikan dengan cukup baik dengan hanya menggunakan dua dari mereka. Pertimbangan lain apa yang relevan?


5
Masalah melarikan diri tidak diselesaikan dengan menggunakan dua karakter. Itu hanya berarti Anda memiliki satu karakter lagi untuk melarikan diri.
JJJ

2
Saya penasaran. Tentu saja, itu mungkin untuk digunakan {u}daripada %utetapi apakah itu memiliki keuntungan yang signifikan? Sepertinya pilihan yang sebagian besar sewenang-wenang.
CB Bailey

12
@JarrodRoberson jadi Anda mengatakan mereka sengaja memilih {}sintaks sehingga orang yang belajar C # tidak akan mulai belajar hal lain? Saya merasa sangat sulit untuk percaya bahwa itu adalah bagian utama, jika ada, keputusan desain mereka. Bisakah Anda membuat cadangan pernyataan Anda entah bagaimana?
stijn

6
Menariknya, Python meninggalkan (bentuk yang jauh lebih unggul) %memformat dalam mendukung sesuatu yang mirip dengan {}format .NET karena yang terakhir menawarkan lebih banyak fleksibilitas.
Konrad Rudolph

3
Mengapa langit biru, dan mengapa kata "biru" dinamai biru? Mereka harus memilih sesuatu.

Jawaban:


12

Seperti yang dicatat oleh @Secure, printffungsi C terinspirasi oleh writeffungsi BCPL . Dan jika Anda melihat halaman wikipedia untuk BCPL , ia memiliki contoh yang menunjukkan bahwa BCPL writefjuga digunakan %untuk memperkenalkan penentu format.

Jadi kita dapat menyimpulkan bahwa C digunakan %karena BCPL melakukannya, atau untuk alasan yang sama seperti BCPL. Perasaan saya adalah bahwa itu hanyalah %salah satu karakter ASCII yang paling jarang digunakan ... atau begitulah menurut penulis. Kemungkinan juga mereka tidak menghabiskan banyak waktu untuk menimbang berbagai alternatif. Pada saat itu, baik BCPL dan C adalah bahasa yang tidak jelas, dan penulis kemungkinan besar memiliki hal-hal yang lebih penting untuk ditangani.

Namun, ada kunci pas kecil dalam karya. Meskipun C terinspirasi oleh BCPL, tidak sepenuhnya jelas apakah C meminjam perpustakaan BCPL I / O atau sebaliknya. Saya samar-samar ingat bahwa perpustakaan I / O BCPL mengalami proses evolusi tentang waktu ketika operator pengindeksan byte infiks ditambahkan ke bahasa. (Sebenarnya, saya pikir saya tahu siapa yang akan tahu tentang itu.)


3
"Sebenarnya, kurasa aku tahu siapa yang akan tahu tentang itu" ... dan? ... dan? .. Jangan hanya meninggalkan kita dengan gantungan tebing ...
Mawg

2
@Mawg - Brian Knight mungkin akan melakukannya. Ian Wilson mungkin akan melakukannya. Martin Richards pasti akan melakukannya. HTH.
Stephen C

6

Entri Wikipedia tidak mengandung banyak informasi historis, tidak khusus untuk printf, tetapi untuk melarikan diri karakter secara umum.

http://en.wikipedia.org/wiki/Escape_character

Referensi awal untuk istilah "karakter pelarian" ditemukan dalam publikasi teknis IBM Bob Bemer. Rupanya, dialah yang menemukan mekanisme ini, selama karyanya pada set karakter ASCII.

Dugaan saya adalah: Backslash sudah digunakan untuk string literal dan karakter lain diperlukan untuk format string. Kemungkinan besar mereka memilih karakter dengan frekuensi penggunaan dan kejadian normal yang dianggap paling rendah.

BTW, artikel terkait lainnya terhubung di sana dengan istilah yang belum pernah saya dengar sebelumnya:

http://en.wikipedia.org/wiki/Leaning_toothpick_syndrome

Artikel untuk printfmemiliki beberapa cuplikan informasi lebih lanjut, tetapi bukan tentang alasannya.

http://en.wikipedia.org/wiki/Printf

Printf variad C berawal pada fungsi writef BCPL.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.