Mengapa Embedded Strictly C / C ++ [ditutup]


15

Saya tidak menyukai pertanyaan ini karena tidak dapat dijawab dengan mudah, tetapi mungkin saya dapat menguraikan kembali: "Apa yang membuat Embedded dari perubahan bahasa?"

Sebagai contoh, kita cukup banyak melihat C / C ++ untuk disematkan (saya pikir saya juga pernah mendengar ADA yang disebutkan sebelumnya? Koreksi saya jika saya salah)

Tapi apa sebenarnya yang membuat dunia Embedded dari perubahan bahasa? Apakah hanya karena C terlalu mudah digunakan atau sebenarnya tidak ada "kebutuhan" untuk perubahan karena C melakukan semuanya dengan baik?

Ini selalu agak membingungkan saya, bukankah saya mengeluh. Karena menyimpannya dalam beberapa bahasa membuat hal-hal menjadi standar. Namun pertanyaannya tetap.

Saya menyadari ini adalah semacam pertanyaan Subyektif, namun Pertanyaan utama saya adalah "Mengapa" dan bukan "JIKA / KAPAN"


2
Apakah ada bahasa tingkat tinggi tertentu yang ingin Anda lihat pada sistem embedded? EDIT: atau lebih tepatnya, fitur bahasa apa yang Anda minati yang tidak disediakan oleh C?
Jon L

1
@ Jon - Ada banyak fitur tingkat rendah yang saya harap C miliki. EG manipulasi bit / nibble / byte / word yang lebih baik di dalam int besar. Dukungan keamanan yang lebih baik, misalnya jenis fitur yang dimiliki Ada.
Rocketmagnet

3
Tertanam tidak sepenuhnya C. Berikut adalah sekelompok bahasa tingkat tinggi untuk sistem tertanam: electronics.stackexchange.com/questions/3423/…
Kellenjb

1
"Tertanam" memiliki arti yang berbeda. Mikrokontroler 4-bit yang menjalankan pemanggang berbeda dengan ECU atau Set Top Box. Spektrum ini membuat pertanyaan Anda sulit dijawab.
Toby Jaffey

1
Dan, seperti yang diharapkan, ini sudah ditutup. Pertanyaan ini saya harap akan menerima jawaban berkualitas tinggi dan orang-orang akan bekerja untuk menjaganya sebagai pertanyaan yang bagus, bukan ini masalahnya. Alih-alih kami mendapatkan banyak jawaban yang merupakan satu kalimat yang menerima banyak upvote, kami memiliki jawaban yang prosa yang memiliki perang downvote di atasnya dengan bendera berlimpah, dan jawaban lainnya menghasilkan lebih banyak bendera dalam 1 hari kemudian seluruh situs digabungkan . Masalahnya adalah bahwa bagi banyak orang ada banyak jawaban benar yang berbeda tentang mengapa mereka tidak berubah.
Kortuk

Jawaban:


18

Pertama-tama: lupakan "tertanam" karena itu bukan perbedaan yang berguna. Properti yang sangat penting adalah "terbatas sumber daya". Sumber daya yang paling penting adalah waktu, dalam hal ini kita berbicara tentang sistem waktu nyata, tetapi juga bisa berupa memori atau daya.

  • Adopsi bahasa baru sulit dan jarang. Ini membutuhkan pelatihan ulang, alat baru, dan menemukan cara yang baik untuk bekerja dengan bahasa baru. Ini mahal, terutama untuk pengguna awal. Ini juga merupakan masalah ayam-dan-telur: tanpa basis pengguna yang besar tidak akan ada alat dan libarari berkualitas baik, tetapi tanpa itu tidak akan ada basis pengguna yang besar. Oleh karena itu bahasa baru harus memiliki keunggulan besar dibandingkan yang ada, jika tidak maka tidak akan ada peluang.

  • Kebanyakan perkembangan baru "baru" dalam bahasa telah mengisi kesenjangan antara daya CPU yang tersedia dan apa yang dibutuhkan pengguna. Dengan kata lain: mereka bisa tidak efisien dalam kecepatan, tetapi mengimbangi dengan menjadi lebih mudah pada programmer. Pikirkan munculnya bahasa-bahasa seperti Java, Python, Perl, Tcl yang pada dasarnya dijalankan oleh seorang juru bahasa (mungkin setelah beberapa kompilasi) dan menggunakan manajemen memori dinamis. Tetapi ini tidak cocok dengan dunia dengan keterbatasan sumber daya, di mana kami ingin mendapatkan a) hasil maksimal dari sumber daya yang tersedia, bahkan dengan mengorbankan lebih banyak upaya pemrograman, dan b) penggunaan sumber daya yang dapat diprediksi.

  • C dan C ++ (atau himpunan bagian yang sesuai) masih merupakan bahasa tingkat tertinggi yang umum digunakan (cukup alat yang bagus, programmer yang cukup terlatih, dan perpustakaan lengkap semuanya tersedia) yang dapat memenuhi persyaratan ruang dan waktu yang dapat diprediksi yang tidak jauh. dari apa yang mungkin pada perangkat keras saat ini. Satu-satunya pesaing adalah saya pikir Ada, tetapi telah menderita dari awal yang buruk: implementasi pertama (dianggap?) Terlalu lambat dan tidak efisien, dan sekarang (meskipun implementasi yang baik tersedia) bahasa telah tertinggal sedikit di belakang di fitur (dibandingkan dengan C ++). Secara pribadi saya pikir ini sangat disayangkan, hal-hal lain dianggap sama. Saya lebih suka terbang di pesawat yang diprogram dalam Ada daripada yang telah dilakukan di C atau C ++.


+1 - jawaban yang bagus. Ada sepertinya bahasa yang menarik, apakah ada kompiler Ada untuk micros kecil di sekitar?
Oli Glaser

Ada GNAT, kompiler GCC Ada. Tetapi AFAIK belum banyak digunakan pada micros, sehingga Anda akan kesulitan menemukan sesuatu yang bisa dibaca untuk dijalankan.
Wouter van Ooijen

Yeh saya melihat GNAT disebutkan di halaman Wiki. Anda benar, tidak banyak untuk micros kecil, tetapi tampaknya ada sedikit dukungan (seperti yang Anda harapkan) untuk hal-hal penting misi pada 68k, x86, MIPS, dll (mis. DDCI )
Oli Glaser

Saya melihat ada SPARK Ada juga, seperti yang disebutkan oleh Deek di bawah ini. Saya harus memeriksanya ketika saya memiliki beberapa hal yang sulit dipahami yang mereka sebut waktu ...
Oli Glaser

2
Ada, dalam bentuk Agas, bekerja dengan baik pada mikroprosesor AVR, seperti yang terlihat di Arduino. Eksekusi Agas terkecil yang saya buat adalah 65 byte. Diakui semua itu berkedip LED, meskipun sketsa Arduino setara lebih dari 1K. Pada saat executable saya mencapai 600 byte, ia mengendarai 2 motor stepper secara independen ... Anda tidak perlu SPARK - kecuali Anda ingin membuktikan bahwa tanda bahayanya LED Anda benar secara formal!
Brian Drummond

9

Dengan sistem embedded berbasis mikrokontroler 8 dan 16-bit, semakin mudah untuk mengembangkan perangkat lunak yang dapat masuk ke dalam sumber daya terbatas keterbatasan penyimpanan yang sangat sederhana ini (mungkin beberapa 100 byte RAM untuk mikrokontroler 8-bit low-end) , dengan 2-8 KiB ROM atau EPROM / Flash untuk penyimpanan kode).

Dalam kasus tersebut bahasa kecil seperti C atau assembly cenderung menjadi bahasa pengembangan yang paling umum digunakan. Sebagai perbandingan relatif yang sangat kasar, assembler lengkap dan kompiler C99 dapat masuk ke dalam floppy disk tunggal, sementara Anda memerlukan beberapa MiB untuk sistem pengembangan C ++ modern (dengan STL, dll.).

Ketika Anda melihat micros high-end (high-end 16-bit, dan sebagian besar 32-bit, dengan 64-bit yang cukup langka) dan DSP di lingkungan yang disematkan maka batasannya melemah, dan pengembangan perangkat lunak mungkin merupakan bagian terbesar dari pengembangan upaya, jadi masuk akal untuk menggunakan alat pengembangan paling produktif, termasuk bahasa yang lebih maju dengan fitur-fitur seperti Object-Oriented Programming (OOP) bahasa seperti C ++, dan bahasa yang lebih baru (Java, Perl, Ruby, Python).

Dimungkinkan dalam perakitan dan C untuk memprediksi berapa banyak memori yang digunakan, sehingga desain ruang terbatas layak, tetapi fitur-fitur canggih seperti templat, penanganan pengecualian, dan pengikatan run-time membuatnya tidak mungkin untuk mengetahui dengan tepat jejak memori yang diperlukan. untuk program C ++ standar sebelumnya. Saya tidak cukup tahu tentang MISRA C ++ , yang merupakan subset dari C ++, untuk mengomentarinya.

Bahasa yang didasarkan pada mesin virtual yang menjalankan byte-code (Java, Perl, Python) kurang matang dalam pengalaman pengembang yang disematkan, dan karena bahasa ini dirancang untuk mengisolasi programmer dari perangkat keras tertentu, itu juga membuatnya lebih sulit untuk menjadi hati nurani. pembatasan dan pembatasan sistem perangkat keras tertanam tersebut. Ini kurang masalah dengan prosesor 32-bit cepat (misalnya ARMv7) dengan MiB jika tidak GiB RAM.

Semua implementasi BASIC yang saya sadari cukup sederhana dalam fitur bahasa, sebagian besar tetap berlaku untuk warisan Dartmouth BASIC dari tahun 1960-an. Ini berarti bahwa bahasa tersebut tidak memiliki pustaka run-time yang kompleks atau penanganan perkecualian, dan juru bahasa atau kompiler cukup mudah untuk menulis dan juga kecil dalam ukuran file. Sebagian besar mikrokontroler memiliki setidaknya satu kompiler BASIC tersedia untuk itu.

Saya berharap bahwa menguraikan dalam stroke luas alasan Anda akan menemukan C dan perakitan terutama digunakan pada sistem embedded yang lebih kecil atau lebih tua, dan dengan keterbatasan sistem embedded menengah ke atas hanya berbeda sedikit dari komputer pribadi desktop tradisional.


5

Sebagian besar jawaban sudah menyatakan alasan historis (terkenal, semua orang menggunakannya, tidak akan mudah mengubah kebiasaan, dll). Sementara saya setuju dengan mereka, kita harus ingat bahwa ada alasan penting lainnya.

Ini bukan bahwa "C adalah pilihan yang buruk atau usang tetapi kita masih menggunakannya keluar dari kebiasaan" (seperti keyboard QWERTY).

C sendiri merupakan pilihan yang sangat baik untuk pengembangan yang disematkan, terutama dalam aplikasi yang kritis terhadap waktu. Mengapa?

  • itu level yang cukup rendah sehingga mudah digunakan untuk mengimplementasikan program waktu nyata. Jika Anda perlu mengukur waktu dalam nanodetik, harus menangkap interupsi setiap 5 mikrodetik, atau harus menggunakan tepat 64 byte total RAM, maka dengan bahasa tingkat yang sangat tinggi itu akan paling sering mustahil atau sangat sulit untuk menyelesaikannya . C memberi Anda kontrol yang lebih baik terhadap perangkat keras daripada bahasa tingkat yang lebih tinggi, ini adalah salah satu perbedaan paling penting antara pengembangan untuk embedded vs PC.

  • itu tingkat yang cukup tinggi untuk menjadi cepat dan mudah untuk kode, dibandingkan dengan Majelis.

Jadi, C adalah kompromi terbaik (atau salah satu yang terbaik) antara kecepatan dan akses perangkat keras langsung dari Assembly, dan bacaan yang mudah dan pemahaman bahasa tingkat tinggi.


1
Saya pikir aspek utama dalam mendukung C adalah memungkinkannya untuk mengoptimalkan kode untuk platform tertentu sambil memungkinkan kode tersebut untuk dijalankan (mungkin tidak seefisien) pada yang lain. Pada sesuatu seperti PIC, banyak instruksi C akan diterjemahkan secara terprediksi menjadi instruksi mesin; loop seperti unsigned char i=63,j=128; do {something;} while(--j); while(--i);tidak akan bisa dibaca unsigned int i=16000; do {something;} while(--i);, tetapi akan berjalan lebih cepat dan lebih efisien pada PIC. Jika kode dipindahkan ke ARM, pendekatan kedua akan lebih efisien, tetapi yang pertama masih bekerja.
supercat

4

Itu persis alasan yang sama mengapa dalam pemrograman reguler bahasa (paling banyak digunakan) tidak (benar-benar) berubah:

  1. Sejumlah besar kode yang ada (perpustakaan / implementasi yang ada)
  2. Kumpulan alat besar yang dapat bekerja dengan bahasa-bahasa ini (IDE, simulator, ...)

4

Di dunia tertanam, mungkin jauh lebih sulit (atau tidak mungkin) untuk menyediakan pembaruan perangkat lunak, dan karenanya sangat penting untuk menjamin kebenaran. Sayangnya C memberikan sedikit bantuan dalam hal ini, dan memungkinkan programmer untuk bermain cepat dan longgar.

Sangat menyakitkan saya untuk menggunakan C untuk embedded system, dan berharap saya setidaknya bisa naik ke C ++ untuk banyak manfaat yang diberikannya dalam bentuk kendala seperti const, referensi, stringer typing, dll.

Saya kira jawabannya hanyalah kita terjebak dengan C karena perubahan tidak layak secara komersial. Semua orang tahu C, ada banyak kompiler untuk itu, perpustakaan untuk itu dan alat untuk menghasilkannya. Dengan bahasa baru, kami akan mulai dari awal.

Saya kira itu sebabnya orang masih menggunakan PHP .

PHP double claw hammer


Jika Anda ingin mendiskusikan pertanyaan, gunakan komentar atau meta, jika Anda ingin menepuk punggung pengguna untuk pertanyaan yang bagus, upvote atau komentar.
Kortuk

Anda selalu dapat menggunakan Pascal - sepertinya memiliki batasan tambahan yang Anda cari :-). Atau semacam Super-Lint.
Russell McMahon

2
Salah satu alasan yang mungkin sangat signifikan untuk C adalah bahwa CARA itu lebih mudah untuk menulis kompiler C dasar daripada kompiler C ++. Saya mengerjakan satu untuk sementara waktu sebelum tugas yang lebih penting menarik saya. Hal menyenangkan! Menulis kompiler C ++? Ugh. Saya lebih suka C ++ sebagai pengguna.
darron

1
@RussellMcMahon - Saya tidak bisa menggunakan Pascal, karena tidak ada kompilator Pascal untuk MCU yang saya gunakan.
Rocketmagnet

@dronon - Itu poin yang sangat bagus. Namun, ada kompiler C ++ open source yang sangat bagus, seperti gpp. Mereka hanya perlu menulis bagian belakang untuk itu.
Rocketmagnet

4

Belum ada yang mendengar SPARK Ada di sini?

Ini adalah versi "kecil" dari bahasa Ada dan alat pengembangan terkait untuk sistem tertanam, misalnya avionik dan aplikasi penting lainnya seperti peralatan medis.

Studi menunjukkan hanya 5-10% kehilangan dalam kecepatan pemrosesan dibandingkan dengan C / C ++ dengan pengkodean SPARK yang lebih andal.

Saya berpikir bahwa proliferasi C dalam sistem embedded adalah karena alasan ekonomi:

  • Itu sudah ada dan biasanya bisa diterapkan untuk sebagian besar aplikasi - dan sebagian besar aplikasi berdasarkan volume tidak kritis, tidak ada yang akan mati jika mesin cuci overruns - jadi mengapa berubah?

  • Toolset SPARK akan menjadi biaya tambahan sendiri dan bagi staf pelatihan untuk menggunakannya.

  • Manfaat tambahan dari SPARK (atau bahasa non-C lainnya) untuk sistem kontrol / manajemen tertanam mungkin tidak cukup untuk membenarkan premi yang diperlukan dalam harga produk di mata konsumen - terutama ketika mereka melihat merek pesaing yang tampaknya "baik" menjual untuk harga yang lebih rendah.

  • Perusahaan AdaCore berhati-hati untuk tidak masuk terlalu jauh ke dalam aplikasi pasar massal karena ini pasti akan menuntut peningkatan besar dalam staf dukungan teknis untuk menangani masalah-masalah non-inti. AdaCore adalah perusahaan keahlian tingkat tinggi, bangga akan hal itu dan meluncurkan produk dan layanannya di perusahaan teknologi tinggi. Tidak biasa bagi bahasa untuk menembus pasar baru kecuali jika pemangku kepentingan utamanya benar-benar menginginkannya.

Jadi, @ Wouter, Anda tidak perlu khawatir mati di langit karena kekurangan kode yang disematkan!

Sudah dalam sistem pesawat selama bertahun-tahun. Demikian juga untuk alat pacu jantung Anda.

Tetapi untuk mesin pencuci piring, sistem kontrol layanan bangunan, pengontrol tungku laboratorium dan arena lain yang tidak diatur secara ketat - apakah layak secara ekonomis untuk bekerja lebih keras?


Menarik, terima kasih - Saya belum pernah mendengar SPARK, akan memeriksanya.
Oli Glaser

Beberapa studi menunjukkan kecepatan relatif terhadap aplikasi yang ada di C - lihat server DNS "Ironsides" ...
Brian Drummond

3

Saya kira alasan utama popularitas C adalah yang pertama: C populer dan banyak orang mengetahuinya dan kedua: Tidak ada bahasa populer baru seperti Java, C # dan bahkan banyak aspek C ++ yang cocok untuk pekerjaan yang disematkan. Pada dasarnya 3 bahasa lain yang saya sebutkan banyak bergantung pada memori dinamis, yang membawa eksekusi non-deterministik program dengan itu, objek, yang membawa memori dinamis dengan mereka, persyaratan memori besar (karena salah satu sisi OO yang lebih penting adalah penggunaan semakin banyak kelas), semakin populernya kompilasi tepat waktu (dan banyak platform tertanam bahkan tidak dapat mengkompilasi kode C mereka sendiri) ...

Ada juga fakta bahwa banyak perpustakaan yang mengirimkan dengan mengatakan Java atau C # tidak berguna untuk sejumlah besar proyek tertanam.

Di sisi lain, kami memiliki bahasa yang lebih lama seperti Pascal atau Basic. Dari sudut pandang saya, mereka tidak sepopuler C menjadikan dirinya bahasa "standar industri" dan sejumlah besar programmer dan insinyur mempelajari C hari ini. Di beberapa sekolah Pascal atau Basic bahkan tidak dipelajari. Ada juga fakta bahwa banyak bahasa populer saat ini memiliki sintaksis mirip-C dan menggunakan Pascal akan terasa aneh bagi seorang programmer C.

Adapun FORTRAN, saya kira itu masuk ke bidang niche dan sebagian besar digunakan oleh insinyur dan ilmuwan yang bekerja di daerah di mana ada ekosistem yang cocok untuk penggunaannya. Saya tidak melihat alasan tertentu (selain yang saya sebutkan untuk Pascal dan Basic) itu tidak digunakan pada sistem embedded.

Perhatikan bahwa dalam jawaban ini saya berfokus terutama pada sistem yang lebih kecil. Ada juga banyak perangkat embedded yang menggunakan sistem operasi yang lebih kompleks seperti GNU / Linux atau beberapa turunan Unix lainnya dan untuk pemrograman mereka, lebih atau kurang bahasa popualr dapat digunakan.


1
C populer karena C populer? :-)
stevenvh

2
@stevenvh Ya, itu benar. Ini semacam umpan balik positif. Semakin populer, semakin populer.
AndrejaKo

3

C adalah bahasa yang sangat sederhana, dan telah lebih dari satu kali disebut sebagai bahasa rakitan mewah . Ini hampir merupakan jumlah minimum abstraksi yang dapat Anda berikan di atas kode rakitan, karena C membuat peta secara langsung ke konstruksi tingkat mesin.

Untuk alasan ini dan beberapa alasan lainnya, sangat mudah untuk mengimplementasikan kompiler C pada chip baru. Sebagian besar pekerjaan sudah dilakukan, hanya ada sedikit kompleksitas atau kesalahan, dan kontrol tingkat rendah memungkinkan Anda untuk dengan mudah menangani kebiasaan apa pun yang dimiliki oleh perangkat keras Anda.

C ++ dapat (sebenarnya aslinya) diimplementasikan sebagai lapisan terjemahan kode sumber di atas C, yang berarti Anda mendapatkan C ++ (atau setidaknya beberapa versi) secara gratis dengan kompiler C Anda.

Dengan C dan C ++, Anda bootstrap hampir semua yang Anda butuhkan untuk chip baru Anda, menjadikannya tempat yang logis untuk memulai.


3

Beberapa alasan yang lain belum disebutkan:

  • Ruang masalah: C cocok untuk sistem kecil dan sederhana. Jika semua yang Anda lakukan adalah bereaksi terhadap sinyal eksternal dan mendorong beberapa angka di sekitar C bekerja dengan baik (tidak ada struktur data yang kompleks, tidak ada malloc, tidak ada penanganan kesalahan yang kompleks).

  • Volume produksi: Jika Anda memiliki produksi besar berjalan maka secara ekonomis masuk akal untuk menghemat setiap unit perangkat keras dan menghabiskan lebih banyak pada programmer, karena pemrograman adalah biaya satu kali.


2

Saya pikir itu karena C / C ++ adalah level terendah, bahasa level tinggi.


1

Bahkan, untuk sistem embedded kecil C jauh lebih populer daripada C ++. Dan alasannya sama karena tidak menggunakan bahasa lain. C ++ membutuhkan runtime, kecuali Anda memberikan sebagian besar fitur yang membuatnya berbeda dari C.

Selain perakitan, C adalah satu-satunya bahasa yang saya tahu yang mengkompilasi ke kode asli dan yang memiliki runtime adalah opsional. Jadi dijamin menjadi jejak terkecil dan waktu eksekusi tercepat di lingkungan terbatas (kecuali jika Anda menggunakan perakitan).

Di sisi lain, dalam sistem tertanam menengah dan besar (yang saya maksud lebih banyak memori dan jam, ukuran kata lebih besar) Saya tidak akan mengatakan C (atau C ++) begitu lazim. Saya telah melihat sistem yang mendukung Python, Keempat ... bahkan Java.

Tapi tentu saja Anda hampir selalu memiliki opsi untuk menggunakan C / C ++, jelas, untuk alasan yang sama yang saya sebutkan di atas. Dan memiliki pilihan, dan menjadi Anda seseorang yang sudah merasa nyaman dengan C untuk embedded-kecil, mengapa Anda memilih bahasa lain?


4
C ++ dapat menghasilkan banyak overhead tetapi kompiler C ++ yang sepenuhnya sesuai yang saya gunakan untuk MSP430 tidak memerlukan runtime, C ++ memang mengkompilasi ke kode asli. Saya minta maaf, mengatakan kepada orang lain itu merugikan dan saya telah menurunkan Anda. Anda dapat menghapus downvote dengan memberikan referensi yang meyakinkan saya bahwa saya salah (yang akan sulit, saya telah membaca daftar perakitan C ++ yang dikompilasi untuk proyek saya, bagian untuk memastikannya mengkompilasi secara efisien) atau Anda dapat menghapus jawaban Anda yang akan menghapus pengaruhnya pada reputasi Anda (meskipun pada saat ini Anda menerima +8 net rep)
Kortuk

3
Saya sepenuhnya setuju dengan Kortuk. Beberapa bagian dari C ++ memerlukan dukungan run-time yang luas, tetapi bagian yang tidak C masih jauh lebih baik (dan sepenuhnya OO). Pembatasan pada subset ini mudah ditegakkan oleh beberapa saklar kompilator dan penghubung. Di beberapa bagian (printf yang ditakuti misalnya) C ++ memiliki setidaknya potensi bahasa untuk memerlukan dukungan runtime yang jauh lebih sedikit (jika hanya std :: cout diimplementasikan dengan sistem kecil dalam pikiran ...)
Wouter van Ooijen

1
@ Kortuk, maaf karena tidak jelas di sana, tetapi ketika saya mengatakan bahwa "C adalah satu-satunya bahasa yang ..." tidak berarti C ++ tidak memiliki kedua hal itu, maksud saya C memiliki kombinasi keduanya. dan C ++ memiliki salah satunya. Penekanan saya adalah pada bagian runtime. Saya juga tidak mengatakan bahwa itu benar-benar mustahil untuk menggunakan C ++ tanpa runtime, tapi itu sangat tidak biasa. Saya tidak bisa melihat bagaimana Anda dapat memiliki hal-hal seperti penanganan pengecualian dan RTTI tanpa runtime, misalnya, dan itu adalah fitur yang cukup penting. Tapi saya minta maaf jika cara saya mengungkapkan ini menyebabkan kemungkinan kesalahpahaman.
fceconel

@ fceconel, saya tidak pernah menggunakan C ++ dengan lingkungan runtime, dan kami sedang membahas embedded system di sini, saya tidak pernah menggunakan run-time pada mikrokontroler saya. Pertanyaan ini sedikit berbeda maka Anda mungkin telah membacanya, ia bertanya mengapa C / C ++ adalah satu-satunya pilihan umum, bukan mengapa C bukan C ++. Saya akui, menggunakan sesuatu yang sesederhana cout tidak akan pernah terjadi di mikro saya, saya punya beberapa pin gratis, bukan layar.
Kortuk
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.