Apakah bahasa pemrograman C dianggap bahasa tingkat rendah ketika keluar?


151

Saat ini C dianggap sebagai bahasa tingkat rendah , tetapi kembali di tahun 70-an apakah itu dianggap tingkat rendah? Apakah istilah itu bahkan digunakan?

Banyak bahasa tingkat tinggi populer tidak ada sampai pertengahan 80-an dan seterusnya jadi saya ingin tahu apakah dan bagaimana sifat tingkat rendah telah berubah selama bertahun-tahun.


13
Sebagai satu titik data, sekitar tahun 1978 beberapa mentor pemrograman menggambarkan C kepada saya sebagai bahasa assembly yang dimuliakan.
Ben Crowell

7
@BenCrowell Saya tidak yakin apa artinya "dimuliakan" dalam konteks pernyataan Anda, tetapi saya sudah berpengalaman menyebut C sebagai bahasa assembly universal (= platform-independent) .
Melebius

13
Menariknya, ada kasus yang dibuat bahwa C Bukan Bahasa Tingkat Rendah , dan sekarang kurang satu daripada di tahun 70-an, karena mesin abstrak C lebih jauh dihapus dari perangkat keras modern daripada dari PDP-11.
Tom

5
Ketika memikirkan hal ini, Anda mungkin juga ingin memikirkan asal-usulnya - Unix ditulis dalam C, c berjalan pada Unix dan cross-compile unix ke platform lain. Apa pun yang tidak diperlukan untuk mengkompilasi Unix adalah overhead yang tidak perlu, dan tujuan utama C adalah membuatnya mudah untuk menulis / port kompilator mungkin. Untuk tujuan ini, itu adalah tingkat yang BENAR-BENAR tepat, jadi saya tidak menganggap C sebagai tingkat tinggi atau rendah, saya menganggapnya sebagai alat untuk mem-port Unix yang, seperti hampir semua alat Unix, sangat mudah beradaptasi dengan banyak masalah.
Bill K

4
Patut dicatat bahwa pelat diciptakan pada tahun 1958
Perdana

Jawaban:


144

Untuk menjawab aspek historis dari pertanyaan:

Filosofi desain dijelaskan dalam Bahasa Pemrograman C yang ditulis oleh Brian Kernighan dan perancang C Dennis Ritchie, "K&R" yang mungkin pernah Anda dengar. Kata pengantar untuk edisi pertama mengatakan

C bukan bahasa "tingkat sangat tinggi", atau bahasa "besar" ...

dan kata pengantar

C adalah bahasa "tingkat rendah" yang relatif ... C tidak menyediakan operasi untuk menangani langsung objek komposit seperti string karakter, set, daftar, atau array. Tidak ada operasi yang memanipulasi seluruh array atau string ...

Daftar berjalan selama beberapa saat sebelum teks berlanjut:

Meskipun tidak adanya beberapa fitur ini mungkin tampak seperti kekurangan yang parah, ... menjaga bahasa menjadi ukuran sederhana memiliki manfaat nyata.

(Saya hanya memiliki edisi kedua dari tahun 1988, tetapi komentar di bawah ini menunjukkan bahwa teks yang dikutip adalah sama di edisi pertama 1978).

Jadi, ya, istilah "tingkat tinggi" dan "tingkat rendah" sedang digunakan saat itu, tetapi C dirancang untuk jatuh di suatu tempat di spektrum di antaranya. Itu mungkin untuk menulis kode dalam C yang portabel di seluruh platform perangkat keras, dan itu adalah kriteria utama untuk apakah suatu bahasa dianggap tingkat tinggi pada saat itu. Namun, C tidak memiliki beberapa fitur yang menjadi ciri khas bahasa tingkat tinggi, dan ini adalah keputusan desain yang mendukung kesederhanaan.


42
Ini jawaban yang sangat bagus! Bukti historis yang dapat diverifikasi + kesaksian seorang aktor yang paling terinformasi tentang arti level rendah dan tinggi dalam periode yang dirujuk OP. Ngomong-ngomong, saya mengkonfirmasi bahwa kutipan sudah dalam edisi 1978.
Christophe

157

Ini tergantung pada definisi Anda tentang bahasa tingkat tinggi dan tingkat rendah. Ketika C dikembangkan, apa pun yang tingkatnya lebih tinggi daripada perakitan dianggap sebagai bahasa tingkat tinggi. Itu bar rendah untuk dihapus. Kemudian, terminologi ini bergeser ke titik di mana beberapa saat ini akan menganggap Jawa sebagai bahasa tingkat rendah.

Bahkan dalam lanskap bahasa tingkat tinggi tahun 70-an, perlu ditunjukkan bahwa C adalah tingkat yang cukup rendah. Bahasa C pada dasarnya adalah B ditambah sistem tipe sederhana, dan B tidak lebih dari lapisan sintaks prosedural / terstruktur yang nyaman untuk perakitan. Karena sistem tipe adalah retro-fit di atas bahasa B yang tidak diketik, Anda masih dapat meninggalkan anotasi jenis di beberapa tempat dan intakan dianggap.

C secara sadar menghilangkan fitur mahal atau sulit untuk mengimplementasikan yang sudah mapan pada saat itu, seperti

  • manajemen memori otomatis
  • fungsi atau penutupan bersarang
  • OOP dasar atau coroutine
  • sistem tipe yang lebih ekspresif (mis. tipe yang dibatasi rentang, tipe yang ditentukan pengguna seperti tipe rekaman, pengetikan yang kuat, ...)

C memang memiliki beberapa fitur menarik:

  • dukungan untuk rekursi (sebagai konsekuensi dari variabel otomatis berbasis stack, dibandingkan dengan bahasa tempat semua variabel memiliki masa pakai global)
  • pointer fungsi
  • Tipe data yang ditentukan pengguna (struct dan serikat pekerja) diimplementasikan tidak lama setelah rilis awal C.
  • Representasi string C (pointer-to-chars) sebenarnya merupakan peningkatan besar di atas B yang mengkodekan beberapa huruf menjadi satu kata mesin.
  • File header C adalah hack efisiensi untuk menjaga unit kompilasi kecil, tetapi juga memberikan sistem modul yang sederhana.
  • Pointer dan pointer aritmetika tak terbatas gaya perakitan, dibandingkan dengan referensi yang lebih aman. Pointer adalah fitur yang pada dasarnya tidak aman tetapi juga sangat berguna untuk pemrograman tingkat rendah.

Pada saat C dikembangkan, bahasa inovatif lainnya seperti COBOL, Lisp, ALGOL (dalam berbagai dialek), PL / I, SNOBOL, Simula, dan Pascal telah diterbitkan dan / atau digunakan secara luas untuk domain masalah tertentu. Tetapi sebagian besar bahasa yang ada dimaksudkan untuk pemrograman mainframe, atau proyek penelitian akademik. Misalnya ketika ALGOL-60 pertama kali dirancang sebagai bahasa pemrograman universal, teknologi dan ilmu komputer yang diperlukan untuk mengimplementasikannya belum ada. Beberapa di antaranya (beberapa dialek ALGOL, PL / I, Pascal) juga dimaksudkan untuk pemrograman tingkat rendah, tetapi mereka cenderung memiliki kompiler yang lebih kompleks atau terlalu aman (misalnya, tidak ada pointer yang tidak dibatasi). Pascal terutama tidak memiliki dukungan yang baik untuk array panjang variabel.

Dibandingkan dengan bahasa-bahasa itu, C menolak fitur "elegan" dan mahal agar lebih praktis untuk pengembangan tingkat rendah. C tidak pernah terutama proyek penelitian desain bahasa. Alih-alih, itu adalah pengembangan Unix kernel pada minicomputer PDP-11 yang relatif terbatas sumber daya. Untuk niche-nya (bahasa tingkat rendah minimalis untuk menulis Unix dengan kompiler satu-pass yang mudah untuk port) C benar-benar unggul - dan lebih dari 45 tahun kemudian masih merupakan bahasa pemrograman sistem bahasa.


17
Hanya tambahan kecil untuk orang-orang yang tidak mengetahui apa yang diperlukan untuk keluarga ALGOL dan bahasa Pascal yang ada: Bahasa-bahasa tersebut memiliki fungsi bersarang secara leksikal di mana Anda dapat mengakses variabel (lokal) yang dinyatakan dalam fungsi luar. Itu berarti bahwa Anda harus mempertahankan "tampilan" - array pointer ke lingkup leksikal luar - pada setiap pemanggilan fungsi dan kembali (yang mengubah tingkat leksikal) - atau Anda harus menghubungkan cakupan leksikal ke atas tumpukan dan setiap akses variabel tersebut diperlukan beberapa lompatan tidak langsung ke atas tumpukan untuk menemukannya. Mahal! C membuang semua itu. Saya masih merindukannya.
davidbak

12
@davidbak: System V ABI x86-64 (alias konvensi pemanggilan di Linux / OS X) didefinisikan %r10sebagai "penunjuk rantai statis", yang persis seperti yang Anda bicarakan. Untuk C, itu hanyalah register awal yang berantakan, tapi kurasa Pascal akan menggunakannya. (GNU C fungsi bersarang menggunakannya untuk melewatkan pointer ke lingkup luar ketika fungsi seperti itu tidak inline (misalnya jika Anda membuat pointer fungsi ke sana sehingga kompiler membuat trampolin kode mesin pada stack): Acceptability of regular penggunaan r10 dan r11 )
Peter Cordes

2
@PeterCordes Menarik! Pascal masih banyak digunakan ketika Sistem V keluar (meskipun saya tidak tahu kapan SysV ABI formal didefinisikan). Jawaban tertaut Anda sangat informatif.
davidbak

3
C memiliki tipe yang ditentukan pengguna (struct / union). Saya curiga, "fitur" lainnya tidak digunakan karena tidak ada gunanya atau negatif (kecuali jika Anda mengikuti kontes kode yang tidak jelas :-)), karena hal itu mengurangi tujuan menjaga bahasa tetap sederhana dan ekspresif. .
jamesqf

6
@ jamesqf: tetapi sangat awal C tidak memiliki penugasan struct; Saya kira Anda harus memcpy atau menyalin anggota secara individual alih-alih menulis a = b;untuk menyalin seluruh struct seperti yang Anda bisa dalam ISO C89. Jadi pada awal C, tipe yang ditentukan pengguna jelas merupakan kelas dua dan hanya bisa dilewatkan dengan referensi sebagai argumen fungsi. Keengganan C untuk array dan juga Mengapa C ++ mendukung penugasan array di dalam struct, tetapi tidak secara umum?
Peter Cordes

37

Pada awal 1970-an, C menghirup udara segar yang menggunakan konstruksi modern dengan sangat efektif sehingga seluruh sistem UNIX dapat ditulis ulang dari bahasa assembly menjadi C dengan ruang yang dapat diabaikan atau penalti performa. Pada saat itu banyak orang sezaman menyebutnya sebagai bahasa tingkat tinggi.

Para penulis C, terutama Dennis Ritchie, lebih berhati-hati dan dalam artikel Jurnal Sistem Bell mengatakan "C bukan bahasa tingkat yang sangat tinggi." Dengan senyum masam dan ingin menjadi provokatif, Dennis Ritchie akan mengatakan itu adalah bahasa tingkat rendah. Kepala di antara tujuan desainnya untuk C adalah untuk menjaga bahasa tetap dekat dengan mesin namun memberikan portabilitas, yaitu kemandirian mesin.

Untuk info lebih lanjut, baca artikel BSTJ asli:

Dennis terima kasih Semoga Anda beristirahat dengan tenang.


3
Itu pada dasarnya diketik dan pembungkus sintaksis lebih bagus untuk perakitan PDP jika Anda bertanya kepada saya.
einpoklum


2
@einpoklum Saya cenderung setuju dengan itu. Saya belajar C pada sekitar tahun 1980 di universitas, pada PDP-11 / 34a saat itu terjadi, dan dijelaskan oleh salah satu pakar sebagai "Bahasa perakitan portabel." Mungkin karena selain PDP-11, kami memiliki beberapa mesin Superbrain CP / M di lab yang memiliki kompiler C tersedia pada mereka. en.wikipedia.org/wiki/Intertec_Superbrain
dgnuff

2
Juga jawaban yang sangat baik berdasarkan bukti historis yang dapat diverifikasi (wow! Ada versi pra-K&R yang tersedia di luar sana!).
Christophe

7
@einpoklum Bukankah ini agak dibuat-buat? Saya berkesempatan untuk menulis kode sistem dan aplikasi pada assembler pertengahan 80-an (Z80 dan M68K), "assembler portabel" yang disebut M (sintaks PDP11 dengan register 16 bit abstrak dan set instruksi), dan C. Dibandingkan dengan assembler , C jelas merupakan bahasa tingkat tinggi: produktivitas pemrograman C adalah urutan besarnya lebih tinggi daripada di assembler! Tentu saja tidak ada string (SNOBOL), tidak ada dukungan datafile asli (COBOL), tidak ada kode yang menghasilkan sendiri (LISP), tidak ada matematika lanjutan (APL), tidak ada objek (SIMULA), sehingga kami dapat setuju bahwa itu tidak terlalu tinggi
Christophe

21

Seperti yang saya tulis di tempat lain di situs ini ketika seseorang menyebut malloc / pola manajemen memori bebas sebagai "pemrograman tingkat rendah,"

Lucu bagaimana definisi "level rendah" berubah seiring waktu. Ketika saya pertama kali belajar memprogram, bahasa apa pun yang menyediakan model tumpukan standar yang memungkinkan pengalokasian sederhana / pola bebas mungkin dianggap tingkat tinggi memang. Dalam pemrograman tingkat rendah, Anda harus melacak sendiri ingatan, (bukan alokasi, tetapi lokasi ingatan itu sendiri!), Atau menulis pengalokasi tumpukan Anda sendiri jika Anda merasa benar-benar mewah.

Untuk konteks, ini di awal 90-an, jauh setelah C keluar.


Bukankah pustaka standar hanya merupakan hal sejak standardisasi di akhir tahun 80-an (yah, berdasarkan API Unix yang ada)? Juga, pemrograman Kernel (yang merupakan domain masalah awal C) secara alami membutuhkan hal-hal tingkat rendah seperti manajemen memori manual. Pada saat itu C pastilah bahasa pemrograman tingkat tertinggi yang ditulis dengan kernel serius (saya pikir saat ini kernel NT menggunakan C ++ dalam jumlah yang cukup juga).
amon

6
@hyde, saya menggunakan Algol 60, dua dialek FORTRAN yang berbeda, dan beberapa dialek BASIC yang berbeda di tahun 1970-an, dan tidak ada bahasa yang memiliki pointer atau pengalokasi tumpukan.
Solomon Slow

7
Sebenarnya, Anda masih dapat memprogram dengan tidak malloc()dengan langsung menelepon brk(2)atau mmap(2)dan mengelola memori yang dihasilkan sendiri. Ini adalah PITA besar tanpa manfaat yang mungkin (kecuali Anda menerapkan hal seperti malloc), tetapi Anda bisa melakukannya.
Kevin

1
@amon - kecuali untuk mesin berbasis tumpukan Burroughs yang luar biasa yang diprogram dalam ALGOL dari bawah ke atas ... dan jauh lebih awal dari Unix juga. Oh, dan omong-omong, Multics, yang menjadi inspirasi Unix: Ditulis dalam PL / I. Mirip dengan ALGOL, level lebih tinggi dari C.
davidbak

6
Sebenarnya, alasan lebih banyak dari kita tidak menggunakan Multics hari ini mungkin lebih karena fakta bahwa itu hanya berjalan pada mainframe yang sangat mahal - yaitu, biaya mainframe keterlaluan khas hari itu ditambah biaya tambahan setengah kabinet perangkat keras khusus untuk mengimplementasikan memori virtual dengan keamanan. Ketika komputer mini 32-bit seperti VAX-11 keluar semua orang tetapi bank dan pemerintah turun dari IBM dan Tujuh Kurcaci dan membawa pemrosesan skala besar mereka ke komputer "mini".
davidbak

15

Banyak jawaban sudah merujuk ke artikel awal yang mengatakan hal-hal seperti "C bukan bahasa tingkat tinggi".

Saya tidak bisa menahan tiang pancang, namun: banyak, jika tidak sebagian besar atau semua HLL pada saat itu - Algol, Algol-60, PL / 1, Pascal - menyediakan batas array yang disediakan dan deteksi limpahan numerik.

Terakhir saya memeriksa buffer dan integer overflow adalah penyebab utama dari banyak kerentanan keamanan. ... Yap, masih demikian ...

Situasi untuk manajemen memori dinamis lebih rumit, tetapi tetap saja, gaya C malloc / gratis merupakan langkah mundur dalam hal keamanan.

Jadi, jika definisi Anda tentang HLL termasuk "secara otomatis mencegah banyak bug tingkat rendah", well, keadaan cybersecurity yang menyedihkan akan sangat berbeda, mungkin lebih baik, jika C dan UNIX tidak terjadi.


7
Karena saya telah terlibat dalam implementasi Intel MPX dan kompiler penunjuk pointer / batas yang memutar jika itu, saya dapat merujuk Anda ke makalah tentang kinerja mereka: pada dasarnya 5-15%. Banyak dari itu melibatkan analisis kompiler yang hampir tidak mungkin pada tahun 1970-an dan 1980-an - dibandingkan dengan cek naif yang mungkin 50% lebih lambat. Namun, saya pikir wajar untuk mengatakan bahwa C dan UNIX kembali bekerja pada analisis tersebut selama 20 tahun - ketika C menjadi bahasa pemrograman yang paling populer, permintaan akan keamanan semakin berkurang.
Krazy Glew

9
@jamesqf Selain itu, banyak mesin sebelum C memiliki dukungan perangkat keras khusus untuk pemeriksaan batas dan kelebihan bilangan bulat. Karena C tidak menggunakan HW itu, CW akhirnya tidak digunakan lagi dan dihapus.
Krazy Glew

5
@jamesqf Sebagai contoh: MIPS RISC ISA awalnya didasarkan pada tolok ukur Stanford, yang awalnya ditulis dalam Pascal, hanya kemudian dipindahkan ke C. Karena Pascal memeriksa untuk menandatangani integer overflow, maka begitu pula MIPS, dalam instruksi seperti ADD. Sekitar tahun 2010 saya bekerja di MIPS, bos saya ingin menghapus instruksi yang tidak digunakan di MIPSr6, dan penelitian menunjukkan bahwa cek overflow hampir tidak pernah digunakan. Tetapi ternyata Javascript melakukan pemeriksaan seperti itu - tetapi tidak dapat menggunakan instruksi yang murah karena kurangnya dukungan OS.
Krazy Glew

3
@KrazyGlew - Sangat menarik bahwa Anda membicarakan hal ini karena di C / C ++ pertarungan antara pengguna dan penulis kompiler tentang "perilaku tidak terdefinisi" karena bilangan bulat bilangan bulat yang ditandatangani memanas, karena penulis kompiler saat ini telah menggunakan mantra lama "Membuat kesalahan Program yang lebih buruk adalah tidak ada dosa "dan mengubahnya menjadi 11. Banyak posting di stackoverflow dan di tempat lain mencerminkan ini ...
davidbak

2
Jika Rust memiliki SIMD intrinsik seperti C, itu mungkin bahasa rakitan portabel modern yang hampir ideal. C semakin buruk sebagai bahasa rakitan portabel karena optimisasi berbasis UB yang agresif, dan kegagalan untuk mengekspos operasi primitif baru yang didukung oleh CPU modern (seperti popcnt, hitung nol terkemuka / lintasan, bit-reverse, byte-reverse, saturating matematika). Mendapatkan kompiler C untuk membuat asm efisien untuk ini pada CPU dengan dukungan HW sering membutuhkan intrinsik non-portabel. Memiliki kompilator mengemulasi popcnt pada target tanpa itu lebih baik daripada pengakuan idiom popcnt.
Peter Cordes

8

Pertimbangkan bahasa lama dan jauh lebih tinggi yang ada sebelum C (1972):

Fortran - 1957 (level tidak lebih tinggi dari C)

Gangguan - 1958

Cobol - 1959

Fortran IV - 1961 (level tidak lebih tinggi dari C)

PL / 1 - 1964

APL - 1966

Ditambah bahasa tingkat menengah seperti RPG (1959), sebagian besar bahasa pemrograman untuk menggantikan sistem catatan unit berbasis plugboard.

Dari perspektif ini, C tampak seperti bahasa tingkat yang sangat rendah, hanya sedikit di atas assembler makro yang digunakan pada mainframe pada saat itu. Dalam kasus mainframe IBM, macro assembler digunakan untuk akses basis data seperti BDAM (metode akses disk dasar), karena antarmuka basis data belum porting ke Cobol (pada waktu itu) menghasilkan warisan campuran campuran dan Program Cobol masih digunakan sampai sekarang di mainframe IBM.


2
Jika Anda ingin daftar bahasa yang lebih tua, lebih tinggi, jangan lupa LISP .
Deduplicator

@Dupuplikator - Saya menambahkannya ke daftar. Saya berfokus pada apa yang digunakan pada mainframe IBM, dan saya tidak ingat LISP menjadi sepopuler itu, tetapi APL juga merupakan bahasa khusus untuk mainframe IBM (melalui konsol pembagian waktu) dan IBM 1130. Mirip dengan LISP, APL adalah salah satu dari bahasa tingkat tinggi yang lebih unik, misalnya lihat betapa sedikit kode yang diperlukan untuk membuat permainan Conway dengan versi APL: youtube.com/watch?v=a9xAKttWgP4 .
rcgldr

2
Saya tidak akan menganggap RPG atau COBOL sebagai level tinggi, paling tidak sebelum COBOL-85. Ketika Anda menggores permukaan COBOL, Anda melihat bahwa itu pada dasarnya adalah kumpulan macro assembler yang sangat canggih. Pertama-tama, ia tidak memiliki fungsi, prosedur dan rekursi, serta segala jenis pelingkupan. Semua penyimpanan harus dideklarasikan di bagian atas program yang mengarah ke tawaran terlalu lama atau penggunaan kembali variabel yang menyakitkan.
idrougge

Saya memiliki beberapa kenangan buruk dalam menggunakan Fortran IV, saya tidak ingat itu menjadi "level yang lebih tinggi" daripada C.
DaveG

@idrougge - COBOL dan RPG, dan juga set instruksi mainframe termasuk dukungan penuh untuk BCD yang dikemas atau dibongkar, suatu persyaratan untuk perangkat lunak keuangan di negara-negara seperti Amerika Serikat. Saya menganggap operator asli yang terkait seperti "bergerak sesuai" menjadi level tinggi. RPG tidak biasa karena Anda menentukan keterkaitan antara bidang input mentah dan bidang output terformat dan / atau akumulator, tetapi bukan urutan operasi, mirip dengan pemrograman plugboard yang diganti.
rcgldr

6

Jawaban untuk pertanyaan Anda tergantung pada bahasa C yang ditanyakan.

Bahasa yang dijelaskan dalam Manual Referensi C 1974 Dennis Ritchie adalah bahasa tingkat rendah yang menawarkan beberapa kenyamanan pemrograman bahasa tingkat tinggi. Dialek yang berasal dari bahasa itu juga cenderung menjadi bahasa pemrograman tingkat rendah.

Namun, ketika Standar C 1989/1990 diterbitkan, ia tidak menggambarkan bahasa tingkat rendah yang telah menjadi populer untuk pemrograman mesin yang sebenarnya, tetapi sebaliknya menggambarkan bahasa tingkat yang lebih tinggi yang bisa - tetapi tidak diharuskan untuk menjadi- -diimplementasikan dalam istilah tingkat yang lebih rendah.

Seperti yang dicatat oleh penulis Standar C, salah satu hal yang membuat bahasa ini berguna adalah bahwa banyak implementasi dapat diperlakukan sebagai perakit tingkat tinggi. Karena C juga digunakan sebagai alternatif untuk bahasa tingkat tinggi lainnya, dan karena banyak aplikasi tidak memerlukan kemampuan untuk melakukan hal-hal yang tidak bisa dilakukan oleh bahasa tingkat tinggi, para penulis Standar mengizinkan implementasi untuk berperilaku secara sewenang-wenang jika program mencoba menggunakan konstruksi tingkat rendah. Akibatnya, bahasa yang dijelaskan oleh Standar C tidak pernah menjadi bahasa pemrograman tingkat rendah.

Untuk memahami perbedaan ini, pertimbangkan bagaimana Bahasa Ritchie dan C89 akan melihat potongan kode:

struct foo { int x,y; float z; } *p;
...
p[3].y+=1;

pada platform di mana "char" adalah 8 bit, "int" adalah 16 bit big-endian, "float" adalah 32 bit, dan struktur tidak memiliki persyaratan padding atau alignment khusus sehingga ukuran "struct foo" adalah 8 byte.

Pada Bahasa Ritchie, perilaku pernyataan terakhir akan mengambil alamat yang disimpan dalam "p", tambahkan 3 * 8 + 2 [yaitu 26] byte ke dalamnya, dan mengambil nilai 16-bit dari byte pada alamat di alamat itu dan selanjutnya , tambahkan satu ke nilai itu, dan kemudian tulis kembali nilai 16 bit itu ke dua byte yang sama. Perilaku akan didefinisikan sebagai bertindak pada byte 26 dan 27 mengikuti satu di alamat p tanpa memperhatikan jenis objek apa yang disimpan di sana.

Dalam bahasa yang didefinisikan oleh Standar C, jika * p mengidentifikasi elemen "struct foo []" yang diikuti oleh setidaknya tiga elemen lebih lengkap dari tipe itu, pernyataan terakhir akan menambahkan satu ke anggota y dari elemen ketiga setelah * p. Perilaku tidak akan didefinisikan oleh Standar dalam keadaan lain apa pun.

Bahasa Ritchie adalah bahasa pemrograman tingkat rendah karena, sementara itu memungkinkan seorang programmer untuk menggunakan abstraksi seperti array dan struktur ketika nyaman, itu mendefinisikan perilaku dalam hal tata letak objek di dalam memori yang mendasarinya. Sebaliknya, bahasa yang dijelaskan oleh C89 dan standar yang lebih baru mendefinisikan hal-hal dalam hal abstraksi tingkat yang lebih tinggi, dan hanya mendefinisikan perilaku kode yang konsisten dengan itu. Implementasi kualitas yang sesuai untuk pemrograman tingkat rendah akan berperilaku bermanfaat dalam lebih banyak kasus daripada yang diamanatkan oleh Standar, tetapi tidak ada dokumen "resmi" yang menentukan apa yang harus dilakukan suatu implementasi agar sesuai untuk tujuan tersebut.

Bahasa C yang ditemukan oleh Dennis Ritchie dengan demikian adalah bahasa tingkat rendah, dan diakui demikian. Bahasa yang ditemukan oleh Komite Standar C, bagaimanapun, tidak pernah menjadi bahasa tingkat rendah dengan tidak adanya jaminan yang diberikan implementasi yang melampaui mandat Standar.

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.