Sự sợ hãi của C++ giữa các nhà phát triển được nhúng phần lớn là một điều trong quá khứ, khi trình biên dịch C++ không tốt bằng trình biên dịch C (tối ưu hóa và chất lượng mã khôn ngoan).
Điều này áp dụng đặc biệt cho nền tảng hiện đại với kiến trúc 32 bit. Nhưng, C chắc chắn vẫn là sự lựa chọn ưa thích cho các môi trường hạn chế hơn (như là lắp ráp cho 8 bit hoặc 4 bit mục tiêu). Vì vậy, nó thực sự thích hợp với các tài nguyên mà nền tảng đích của bạn cung cấp, và bao nhiêu tài nguyên mà bạn có khả năng thực sự yêu cầu, nghĩa là nếu bạn có thể đủ khả năng phát triển nhúng trong C++ (hoặc thậm chí là Java). cho rằng vấn đề), bởi vì bạn biết rằng bạn sẽ khó có bất kỳ vấn đề liên quan đến bộ nhớ hoặc CPU khó khăn. Ngày nay, nhiều nền tảng nhúng hiện đại (nghĩ game console, điện thoại di động, PDA, vv), đã thực sự trở thành mục tiêu rất có khả năng, với kiến trúc RISC, vài MB RAM và tăng tốc phần cứng 3D. Nó sẽ là một quyết định tồi tệ, để lập trình nền tảng như vậy bằng cách sử dụng chỉ C hoặc thậm chí lắp ráp các cân nhắc về hiệu năng không được cải thiện, mặt khác lập trình PIC 16 bit trong C++ cũng có thể là một quyết định gây tranh cãi. Vì vậy, nó thực sự là vấn đề tự hỏi mình có bao nhiêu quyền lực, bạn sẽ thực sự cần và bao nhiêu bạn có thể đủ khả năng để hy sinh, để cải thiện kinh nghiệm phát triển (ngôn ngữ cấp cao, phát triển nhanh hơn, ít tẻ nhạt/nhiệm vụ dự phòng).
Tôi nên thêm rằng cuộc thảo luận này được dựa một phần khi các nhà quản lý của chúng tôi miễn cưỡng áp dụng C++ trong hầu hết các thư viện của chúng tôi. Chúng tôi làm "nhúng" làm việc, chỉ có nó sống trên một robot hầu hết thời gian. 99% thời gian, chúng tôi không sử dụng RTOS hoặc bất kỳ hệ thống nào có bộ nhớ rất hạn chế. – jdt141
Câu hỏi liên quan: http://stackoverflow.com/questions/812717/ –
Xem thêm http://stackoverflow.com/questions/649789/why-artificially-limit-your-code-to-c – Suma