Tại sao các hệ điều hành làm công cụ cấp thấp trong C và C ++? Tại sao không chỉ là C ++?

20

Trên trang Wikipedia cho Windows , nó nói rằng Windows được viết bằng hội đồng cho trình tải khởi động và trình chuyển đổi tác vụ, và C và C ++ cho các thường trình kernel.

IIRC, bạn có thể gọi các hàm C ++ từ một extern "C"khối 'd. Tôi có thể sử dụng C cho các hàm kernel để các ứng dụng C thuần túy có thể sử dụng chúng (như printfvà như vậy), nhưng nếu chúng chỉ có thể được gói trong một extern "C "khối, thì tại sao lại mã trong C?

c++ c language-choice kernel

— Cole Johnson
nguồn

10

Bạn đã thấy nhiều câu "Tại sao sử dụng C khi có C ++?" câu hỏi ở đây? Đây không nhất thiết là một bản sao của bất kỳ trong số họ, nhưng chúng có liên quan.

1

"bạn có thể gọi các hàm C ++ từ một khối" C "bên ngoài là C ++" Bạn có nghĩa là bạn có thể gọi các hàm C ...?

— Code-Guru

@ Code-Guru no, bởi vì sự khác biệt duy nhất giữa các hàm C và C ++ được xuất là trang trí tên và trong C ++, việc thêm thisbiến

— Cole Johnson

2

Ném một ngoại lệ vào ISR và xem điều gì sẽ xảy ra

— James

Một câu hỏi C so với C ++ khác.

— Machado

31

Nó chủ yếu là vì lý do lịch sử. Một số phần của kernel windows ban đầu được viết bằng C, bởi vì năm 1983, hơn ba thập kỷ trước, khi Windows 1.0 được phát hành , C ++ hầu như không được phát hành. Giờ đây, các thư viện C này sẽ tồn tại ở đó "mãi mãi", bởi vì Microsoft đã biến khả năng tương thích ngược trở thành điểm bán hàng và viết lại phiên bản tương thích lỗi của các bộ phận C trong C ++ đòi hỏi rất nhiều nỗ lực để không có lợi ích hiệu quả.

— back2dos
nguồn

+1, tôi đoán đó là câu trả lời thực tế nhất (bên cạnh thực tế là có thể có một số nhà phát triển nhân Windows không thích C ++ hoặc không tin tưởng trình biên dịch C ++ cho công cụ cấp thấp đó). Ví dụ, hãy xem tại đây stackoverflow.com/questions/520068/ , tại sao nhân Linux được viết bằng C.

— Doc Brown

@ back2dos - Mặc dù mã C của họ sẽ không bị loại bỏ, điều đó không có nghĩa là nó sẽ được sử dụng hoặc không được cập nhật. Tôi đảm bảo với bạn rằng có ít nhất một phương thức thực hiện một cái gì đó ban đầu được viết và chứa trong thư viện C đã được chuyển sang thư viện C ++ trong Windows 8

— Ramhound

8

Tôi có một thời gian khó tin rằng có bất kỳ mã Windows 1.0 nào trong bất kỳ bản phát hành Windows nào gần đây. Windows ME là bản phát hành Windows cuối cùng không dựa trên cơ sở mã Windows NT. Và thậm chí điều đó đã được thay thế phần lớn bởi hạt nhân RT mới (mà theo tôi hiểu, nó không hứa hẹn nhiều về khả năng tương thích ngược).

— TMN

@TMN: lập luận là có lẽ hầu hết đúng một trong hai - Tôi khá chắc chắn trên đường từ Win 1.0 đến bây giờ có được rất nhiều thư viện viết bằng C mà vẫn là một phần của cơ sở mã Win8 hiện tại, và không có ai ở MS thấy bất kỳ lợi ích để viết lại chúng trong C ++.

— Doc Brown

1

Hầu như không có mã nào nói chuyện với kernel Windows. Về cơ bản, chỉ có trình điều khiển làm. Các ứng dụng thường nói chuyện với API Win32 hoặc có thể là API POSIX.

— MSalters

24

Như hầu hết mọi người đã chỉ ra, lý do là từ lịch sử, nhưng có một điều khác không ai nhắc đến và tôi tin đó là lý do mọi người vẫn viết mã C cho cấp thấp.

C là một ngôn ngữ nhỏ theo nghĩa là thông số kỹ thuật (tương đối) ngắn. C ++ rất lớn và đó là một cách đánh giá thấp. Điều này có thể không quan trọng đối với lập trình viên (mặc dù tôi nghĩ vậy), nhưng nó cực kỳ quan trọng nếu bạn muốn xác minh chính thức . Hơn nữa, có các công cụ được thiết lập để phân tích mã C, có thể giúp ngăn ngừa lỗi, v.v.

Và điều này rất quan trọng trong phần mềm nhúng, trong đó chi phí cho một lỗi được triển khai là rất cao, so với phần còn lại của ngành (so sánh Web, nơi bạn có thể áp dụng bản vá ngay lập tức cho tất cả người dùng). Không đề cập đến phần mềm nhiệm vụ quan trọng và các công cụ y tế.

Đã có những nỗ lực thay thế C từ vị trí thống lĩnh của nó trong lập trình cấp thấp với các ngôn ngữ thậm chí còn tốt hơn như BitC, nhưng cho đến nay chúng vẫn chưa thành công.

— K.Steff
nguồn

4

+1 Để đề cập đến phần mềm quan trọng cho nhiệm vụ trong C thuần túy (ví dụ: phần mềm hàng không). Tuy nhiên, trong phần mềm y tế C ++ cũng được sử dụng (thử nghiệm rộng rãi được sử dụng thay vì xác minh chính thức, điều này sẽ cực kỳ khó khăn trong C ++).

— Giorgio

1

Ngoài ra, C có một tập hợp con an toàn khá thành công MISRA-C. Có tương đương với C ++, nhưng chúng không phải là tiêu chuẩn thực tế của ngành (chưa). Xu hướng trong lập trình quan trọng về an toàn là các thư viện và trình biên dịch cũng sẽ buộc phải sử dụng một tập hợp con an toàn như MISRA. Để viết lại một phiên bản tương thích MISRA-C ++ của toàn bộ thư viện chuẩn C ++ rất có thể sẽ là một cơn ác mộng.

2

@Lundin Hướng dẫn MISRA không phải là một tập hợp con an toàn - bạn vẫn có các con trỏ thô và hầu hết các tính năng khác làm cho C không an toàn - chúng chủ yếu tập trung vào việc không sử dụng hoặc ghi lại hành vi cụ thể thực hiện.

— Pete Kirkham

@PeteKirkham MISRA-C sẽ bắt tất cả các lỗi con trỏ cổ điển nhất và thực thi phân tích tĩnh. Các tiêu chuẩn an toàn trong ngành (IEC 61508 et al) rõ ràng chấp thuận MISRA-C là một tập hợp con an toàn của C. Không có nhiều lựa chọn thay thế hữu ích khác cho phần mềm quan trọng, trừ khi bạn chọn SPARK Ada, một ngôn ngữ mà ít người biết, với công cụ hạn chế ủng hộ.

2

Điều này nên được chọn là câu trả lời tốt nhất vì nó đúng. Những người khác đề nghị C chỉ được sử dụng vì lý do lịch sử là bản thân cuồng loạn.

— Rob

15

Thời gian chạy C nhỏ hơn nhiều.
Việc dịch C ++ sang các cấu trúc cấp thấp hơn kém minh bạch hơn so với C. (Xem tài liệu tham khảo và vtables, để biết hai ví dụ nhanh)
C thường có ABI ổn định. C ++ thường không. Điều này có nghĩa là ở mức tối thiểu, giao diện cuộc gọi hệ thống phải là kiểu C. Ngoài ra, nếu bạn muốn bất kỳ loại mô-đun động nào, có ABI nhất quán sẽ giúp ích rất nhiều.

— khao khát
nguồn

+1 cho (2) và (3). Tôi không bị thuyết phục với (1).

— Thomas Eding

7

@Thomas Eding: Thời gian chạy C ++ bao gồm thời gian chạy C, cộng với các tính năng C ++ như ngoại lệ, RTTI và cấp phát bộ nhớ khác. YMMV cho dù đó là lớn hơn nhiều . (Và sau đó có các thư viện chuẩn ...)

— wnoise

Ah, tôi quên mất các trường hợp ngoại lệ và nhóm mới / xóa. RTTI Tôi không bao giờ sử dụng mặc dù: D

— Thomas Eding

11

Những lý do không phải là kỹ thuật. Một chút lắp ráp là không thể tránh khỏi, nhưng họ không bị buộc phải sử dụng C thường xuyên, họ muốn . Công ty của tôi sử dụng kernel độc quyền của riêng mình, được viết gần như hoàn toàn bằng C ++, nhưng chúng tôi không cần hỗ trợ giao diện C cho kernel như hầu hết mọi người khác, bởi vì kernel nhúng của chúng tôi được biên dịch nguyên khối với các ứng dụng C ++ của chúng tôi. Khi bạn có giao diện C, việc viết mã giao diện bằng C thường dễ dàng hơn, mặc dù điều đó là có thể sử dụngextern "C" để viết nó trong C ++.

Thậm chí chúng tôi có một ít tệp C, phần lớn là do mã của bên thứ ba. Mã cấp thấp của bên thứ ba hầu như luôn được cung cấp trong C, bởi vì việc kết hợp mã C vào ứng dụng C ++ dễ dàng hơn nhiều so với cách khác.

— Karl Bielefeldt
nguồn

6

Các nhà phát triển hạt nhân thường là loại người, những người cảm thấy hạnh phúc hơn, khi nó rõ ràng ngay lập tức từ nguồn, những gì mã thực sự làm.

C ++ có nhiều tính năng hơn, trong đó ẩn những gì mã làm nhiều hơn mã C đơn giản ẩn nó: quá tải, phương thức ảo, mẫu, tham chiếu, ném ... C ++ cũng có nhiều cú pháp hơn bạn phải nắm vững để thậm chí hiểu được C ++ mã sử dụng nó.

Tôi nghĩ rằng sức mạnh của C ++ là các công cụ rất mạnh để tạo ra các thư viện và khung công tác, sau đó làm cho việc phát triển ứng dụng trở nên nhanh chóng. Rất thường xuyên, nhà phát triển ứng dụng C ++ sẽ hoàn toàn bị mất trong các bộ phận chứa đầy mẫu của thư viện, ngay cả khi anh ta rất thành thạo trong việc tạo các ứng dụng sử dụng thư viện đó. Và viết đúng thư viện C ++ là một nhiệm vụ lập trình rất khó khăn và chỉ được thực hiện để cung cấp một khuôn khổ tuyệt vời cho lợi ích của nhà phát triển ứng dụng. Các thư viện C ++ không đơn giản trong nội bộ, chúng (hoặc có thể ...) chỉ mạnh mẽ nhưng đơn giản theo quan điểm của các lập trình viên ứng dụng.

Nhưng API kernel không thể là API C ++, nó phải là API không biết ngôn ngữ, vì vậy hầu hết những thứ hay ho trong C ++ sẽ không thể sử dụng trực tiếp trên giao diện đó. Hơn nữa, kernel không thực sự được chia thành các phần "thư viện" và "ứng dụng" được phát triển độc lập, với nhiều nỗ lực hơn để đi đến một thư viện, để tạo ra một khối ứng dụng dễ dàng.

Ngoài ra, bảo mật và tính ổn định là quan trọng hơn trong hạt nhân và các phương thức ảo năng động hơn nhiều và do đó khó phân tách và xác minh hơn nhiều so với các cuộc gọi lại đơn giản hoặc các cơ chế giống C khác.

Nói tóm lại, trong khi bạn tất nhiên có thể viết bất kỳ chương trình C nào bao gồm kernel là C ++, phần lớn sức mạnh của C ++ không được sử dụng tốt trong kernel. Và nhiều người sẽ tranh luận rằng các công cụ lập trình sẽ ngăn bạn làm những việc bạn không nên làm. C ++ thì không.

— hyde
nguồn

+1. Là một nhà phát triển nhân, "quy tắc ngón tay cái" của tôi là nếu bạn không thể ước tính "các dòng bộ đệm được chạm" dễ dàng thì ngôn ngữ bạn đang sử dụng sẽ gây hại nhiều hơn là tốt.

— Brendan

Làm rõ: Đối với các hạt nhân, bạn phải giả sử rằng CPU dành phần lớn thời gian của nó trong không gian người dùng và mã hạt nhân được sử dụng một cách rời rạc (ví dụ: khi không gian người dùng gọi API hạt nhân hoặc xảy ra gián đoạn); có nghĩa là bạn phải giả sử "bộ đệm lạnh". Đối với các CPU hiện đại (trong đó RAM chậm so với tốc độ CPU) và bộ nhớ TLB rất tốn kém, do đó (kết hợp với kỳ vọng "bộ đệm lạnh"), số liệu "các dòng bộ đệm được chạm" trở thành một chỉ số cực kỳ quan trọng về hiệu suất và / hoặc khả năng mở rộng.

— Brendan

5

Bjarne Stroustrup, trong một cuộc phỏng vấn vào tháng 7 năm 1999 :

Không có ngôn ngữ nào trong số này là hoàn toàn khác biệt hoặc tốt hơn đáng kể so với các ngôn ngữ đương đại khác. Tuy nhiên, họ đủ tốt và là người hưởng lợi từ sự may mắn và các yếu tố xã hội

— yêu
nguồn

2

Chào mừng David. Khi trích dẫn hoặc trích dẫn, bạn nên cung cấp tài liệu tham khảo (đã thêm!)

— Andrew

3

C là một ngôn ngữ cấp thấp, bởi thiết kế của nó. Đó là một bước đi từ nhà lắp ráp; biết chipset bạn đang nhắm mục tiêu, bạn có thể, với một chút kiến thức, tự "biên dịch" C thành ASM. Loại ngôn ngữ "gần với kim loại" này là chìa khóa cho mức độ tối ưu hóa cao (cho hiệu suất, hiệu quả bộ nhớ, v.v.). Tuy nhiên, vì nó gần với kim loại này, bạn không nhận được nhiều miễn phí với ngôn ngữ này; nó là một ngôn ngữ thủ tục, không hướng đối tượng và do đó để làm việc với các cấu trúc như vậy bao gồm rất nhiều mã soạn sẵn để tạo và sử dụng các cấu trúc đa giá trị trong bộ nhớ.

C ++ là "C one better", bổ sung một số tính năng dễ sử dụng như cấp phát bộ nhớ động, sắp xếp cấu trúc tích hợp, một thư viện mã lớn được xác định trước, v.v., với chi phí cho một số tổn thất hiệu quả (vẫn tốt hơn nhiều hơn môi trường quản lý thời gian chạy). Đối với các lập trình viên trung bình, các ưu điểm vượt xa các nhược điểm trong các khu vực của cơ sở mã không cần kiểm soát hậu môn trong việc phân bổ bộ nhớ, v.v.

Sự kết hợp của cả hai là một truyền thống khá; bạn sử dụng C để viết các vùng mã hóa hiệu năng, hiệu năng bộ nhớ cao nhất của codebase, sau đó bạn có thể làm việc theo kiểu trừu tượng hơn thông qua các cuộc gọi phương thức từ mã C ++, có thể được tổ chức và thiết kế thanh lịch hơn so với trình diễn uber , mã C được tối ưu hóa uber-oogly.

— Keith
nguồn

2

Về hiệu quả, tôi sẽ nhắc lại: (1) Mọi người trong C ++ sẽ nói với bạn điều đó thật nhảm nhí. (2) Tôi đang nói rằng tôi thấy không có lý do gì phải xảy ra như vậy, và muốn có những ví dụ cụ thể. Không phải các ví dụ về cách dễ dàng viết mã kém hiệu quả, nhưng các ví dụ về cách hiệu quả như C đòi hỏi sự xấu xí không đáng có.

3

Xác định "xấu xí"; Tôi viết mã bằng C # để kiếm sống và bất cứ khi nào tôi thấy các ví dụ về mã C ++ trong StackOverflow, tôi sẽ thấy mức độ hành trình được coi là bình thường trong việc sử dụng ngôn ngữ hàng ngày. Khi tôi mã hóa theo cách C ++ trở lại khi, tôi thường thấy mã C và co rúm lại; các loại cấu trúc đóng gói bằng tay, tính toán con trỏ thực thi cho các bước nhảy thủ công, ASM nhúng ... yuck. Một số người than phiền về việc mất kiến thức cấp thấp trong số các lập trình viên Java / .NET; Tôi coi đó là một lợi ích to lớn cho năng suất.

— KeithS

1

Bạn đã không trả lời câu hỏi của tôi;) Bởi "xấu xí" Tôi có nghĩa là "xấu xí theo tiêu chuẩn của các bậc thầy về C ++". Nói cách khác, các ví dụ trong đó người ta không thể sử dụng "C ++ hiện đại" và hiệu quả như C.

2

Điều đó có thể đúng (tôi thực sự không biết). Để phát triển kernel (và một vài lĩnh vực khác), chúng tôi không nói về các lập trình viên trung bình.

3

Mọi người quên rằng C -> C ++ là một sự liên tục. Quá thường xuyên, các đối số này đang so sánh C ++ hiện đại, tốt với C. Bạn có thể lấy một chương trình C và biên dịch nó với trình biên dịch C ++ trong một thời gian tương đối ngắn và nó sẽ chạy chính xác nhanh như vậy. Nếu một tính năng C ++ hiện đại là "quá chậm", đừng sử dụng nó. Điều đó thậm chí có thể bao gồm những thứ như iostream. "Quá chậm" không bao giờ là một cái cớ tốt để sử dụng C trên C ++.

— Gort Robot

1

Có thể là với C, bạn dành phần lớn thời gian để suy nghĩ về vấn đề hiện tại và cách viết mã giải pháp. Trong C ++, bạn sẽ nghĩ về C ++ và vô số các tính năng, chức năng và cú pháp tối nghĩa của nó.

Ngoài ra, trong nhiều cửa hàng C ++, mã của bạn bị theo dõi bởi "cảnh sát thời trang", người bị mê hoặc bởi các mẫu thiết kế mới nhất, hoặc, những phát âm khó hiểu mới nhất của vị thần vĩ đại Stroustrup. Mã đẹp trở nên có giá trị hơn mã làm việc, việc tìm kiếm sử dụng cho bộ mẫu Boost mới nhất được ngưỡng mộ hơn là tìm giải pháp làm việc cho doanh nghiệp.

Kinh nghiệm của tôi là đối với tất cả các tính năng thông minh và độ tinh khiết OO của C ++, mã hóa trong đồng bằng C giúp công việc được thực hiện nhanh hơn và hiệu quả hơn.

— James Anderson
nguồn

0

Có thể các phần C không thể di chuyển độc đáo vào trình biên dịch C ++ được sử dụng cho các phần C ++. Có thể mã C rất thân với trình biên dịch C theo cách phá vỡ trình biên dịch C ++.

Nếu bạn có một trình biên dịch C ++ chất lượng, gần như không có lý do gì để trộn C và C ++ trong một dự án. Hầu hết.

Một lý do là dự án của bạn chia sẻ mã C với các dự án khác, mã không được biên dịch thành C ++ và bạn không muốn duy trì một ngã ba C ++ của mã đó.

— Kaz
nguồn

-1

Tôi nghĩ rằng bạn có nó ngược - extern "C"khối đảm bảo rằng các quy ước gọi C được sử dụng cho tất cả các chức năng trong khối. Vì vậy, bạn có thể gọi các hàm C thuần từ C ++, không phải các hàm C ++ từ C. Bất kể, tôi tưởng tượng rằng lý do mọi người sử dụng cả C và C ++ là vì rất nhiều thư viện cấp thấp được viết bằng C và sử dụng thứ gì đó dễ dàng hơn đã tồn tại (và có lẽ được gỡ lỗi và tối ưu hóa) hơn là viết của riêng bạn. OTOH, C ++ cung cấp rất nhiều tính năng cấp cao đẹp mà mọi người muốn làm việc cùng, vì vậy họ sử dụng nó cho phần còn lại.

— TMN
nguồn

-2

Có nhiều cấp độ nền tảng nhúng khác nhau sử dụng C làm ngôn ngữ lập trình (tất nhiên bạn có thể tự do sử dụng ngôn ngữ lắp ráp bất cứ lúc nào)

Đối với 'Cấp độ' Tôi đang nói về mức tài nguyên ROM và SRAM nội bộ cho một hệ thống.

Các nền tảng này đôi khi bị hạn chế về tài nguyên (ví dụ: một số nền tảng 8051 chỉ có 128 byte SRAM người dùng).

Thật vô nghĩa khi hỗ trợ cấp phát bộ nhớ động với một lượng nhỏ như vậy cho RAM. (mới / xóa) hoặc thậm chí malloc trong C.

Một trong những cải tiến chính từ C đến C ++ là mô hình hướng đối tượng. C ++ phù hợp trong phần mềm có dung lượng bộ nhớ lớn hơn

nhưng không phải trong phần mềm nhúng có giới hạn kích thước lên tới 32KB. (ví dụ: trong bản đồ MCU 16 bit)

Không cần phải có trình biên dịch C ++ thường phức tạp hơn trình biên dịch C. (ít nhất các nhà cung cấp SDK sẽ không bận tâm để làm điều này).

Trong thực tế, tôi khó có thể tìm thấy trình biên dịch C ++ trên nền tảng ARM7 32 bit.

Nó không đáng để phức tạp

Trong một số 8051 (8 bit): ROM 1 MB, RAM 128B

TI MSP430 (16 bit): ROM 32KB, RAM 4KB

ST Vi điện tử CPU ARM 32-bit Cortex ™ -M3 CPU (STM32F103T4): Bộ nhớ flash 16 hoặc 32 Kbyte 6 hoặc 10 Kbyte SRAM

— ansonchau
nguồn

2

Điều này không có gì mới đối với các câu trả lời khác đã được đăng ở đây.

— Martijn Pieters

Trình biên dịch C ++ 32 bit cho ARM? Nếu bạn muốn, bạn có thể tự biên dịch LLVM từ nguồn sau một vài sửa đổi để có được trình biên dịch C ++ cho iOS.

— Cole Johnson

-4

Tôi thấy một vài lý do có thể:

C hiệu quả hơn một chút nếu so với C ++.
Một số thư viện họ sử dụng được viết bằng C.
Họ sử dụng một số phần của nhân Linux, được viết bằng C.

Chỉnh sửa: Hóa ra, đối số thứ ba là không đúng sự thật (xem bình luận).

— Pijusn
nguồn

5

(1) Mọi người C ++ sẽ cầu xin khác biệt. Và khách quan tôi thấy không có lý do này nên là trường hợp. (2) C ++ có thể gọi mã C tốt (đó là toàn bộ điểm tương thích ngược và extern "C").

1

Nếu MS sử dụng một số phần của nhân Linux và nhân Linux là GPL, điều đó có nghĩa là Windows cũng sẽ phải là GPL?

— TomJ

1

@TomJ thực sự là lý do tại sao họ buộc phải tặng một vài ngàn dòng cho Linux. + Tại sao bạn nghĩ rằng họ hỗ trợ phát triển Linux?

— Pijusn

2

@Pius Quan điểm của anh ấy là (và anh ấy đúng AFAIK), nếu có mã GPL được liên kết với kernel Windows, toàn bộ kernel sẽ phải là GPL'd (miễn là không có thỏa thuận riêng với chủ bản quyền).

@delnan, không chắc về chi tiết. Tôi không phải là luật sư nên tôi không thể bình luận về điều đó. Nhưng có một vụ bê bối nhỏ vài năm trước về điều này. Không chắc chắn nhưng tôi nghĩ rằng tôi có thể là mô-đun mạng tất cả những thứ điên rồ là về.

— Pijusn

-4

Bởi vì C được cho là một ngôn ngữ tốt hơn C ++. Và bởi vì một số mã được viết trước khi C ++ trở nên phổ biến và mọi người không có lý do để thay thế nó.

Và bởi vì C ++ có rất nhiều tính năng có thể phá vỡ mã của bạn nếu bạn không cẩn thận khi sử dụng nó trong kernel.

— Minthos
nguồn

C ++ mong đợi các thư viện động? Và bộ nhớ động là gì?

4

-1 cho [stuff] that C++ expects. Tại sao C ++ sử dụng nhiều heap hơn C? Tại sao C ++ yêu cầu nhiều dll hơn C? Đơn giản là KHÔNG ĐÚNG

— Thomas Eding

1

Sửa chữa: Bạn mất các thư viện được viết bằng C ++. Vì vậy, nó trở lại hình vuông 1 nếu bạn đang sử dụng C ++ hoặc C. Tại sao lại giới hạn chức năng của C nếu bạn có thể sử dụng các mẫu, lớp, hàm hủy, const và tất cả các loại tính tốt khác.

— Thomas Eding

6

Gì? Các mẫu, ngoại lệ, đối tượng (bao gồm cả hàm tạo, hàm hủy, toán tử quá tải, hiện đang di chuyển xây dựng và - thực tế? - mọi thứ khác), v.v ... hoạt động tốt bất kể bộ nhớ từ đâu (ngăn xếp, bộ nhớ tĩnh, nhóm tùy chỉnh của bạn hoặc bất cứ thứ gì) . Các thùng chứa tiêu chuẩn sử dụng phân bổ heap theo mặc định, nhưng các cấp phát của chúng có thể được tùy chỉnh và các nhân kernel viết bộ sưu tập và quản lý bộ nhớ của riêng họ. -1

2

FYI: Tôi đã loại bỏ downvote của mình bởi vì tôi không nghĩ rằng câu trả lời của bạn hiện đang gây hại tích cực, nhưng tôi cũng không cho rằng nó đặc biệt hữu ích hoặc sâu sắc.