Tại sao mọi người sẽ sử dụng C trên C ++? [đóng cửa]

Mặc dù mọi người dường như muốn phàn nàn về C ++, tôi không thể tìm thấy nhiều bằng chứng về lý do tại sao bạn muốn chọn C hơn C ++. C dường như không nhận được nhiều flak và nếu C ++ có tất cả những vấn đề này thì tại sao bạn không thể tự giới hạn mình trong tập hợp con C? Suy nghĩ / kinh nghiệm của bạn là gì?

Câu trả lời của Joel là tốt vì lý do bạn có thể phải sử dụng C, mặc dù có một vài người khác:

• Bạn phải đáp ứng các hướng dẫn của ngành, dễ chứng minh và kiểm tra trong C.
• Bạn có các công cụ để làm việc với C, nhưng không phải C ++ (nghĩ không chỉ về trình biên dịch, mà tất cả các công cụ hỗ trợ, bảo hiểm, phân tích, v.v.)
• Nhà phát triển mục tiêu của bạn là C gurus
• Bạn đang viết trình điều khiển, hạt nhân hoặc mã cấp thấp khác
• Bạn biết trình biên dịch C ++ không tốt trong việc tối ưu hóa loại mã bạn cần viết
• Ứng dụng của bạn không chỉ không cho vay theo hướng đối tượng mà còn khó viết hơn ở dạng đó

Tuy nhiên, trong một số trường hợp, bạn có thể muốn sử dụng C thay vì C ++:

• Bạn muốn hiệu năng của trình biên dịch mà không gặp sự cố mã hóa trong trình biên dịch chương trình (C ++, về mặt lý thuyết, có khả năng thực hiện 'hoàn hảo', nhưng các trình biên dịch không thể thấy tối ưu hóa mà một lập trình viên C giỏi sẽ thấy)
• Phần mềm bạn đang viết là tầm thường, hoặc gần như vậy - xóa sạch trình biên dịch C nhỏ, viết một vài dòng mã, biên dịch và bạn đã sẵn sàng - không cần phải mở một trình soạn thảo lớn với người trợ giúp, không cần phải viết thực tế các lớp trống và vô dụng, xử lý các không gian tên, v.v. Bạn có thể làm gần như tương tự với trình biên dịch C ++ và chỉ cần sử dụng tập hợp con C, nhưng trình biên dịch C ++ chậm hơn, ngay cả đối với các chương trình nhỏ.
• Bạn cần hiệu năng cực cao hoặc kích thước mã nhỏ và biết trình biên dịch C ++ thực sự sẽ khiến việc thực hiện khó khăn hơn do kích thước và hiệu suất của các thư viện

Bạn cho rằng bạn chỉ có thể sử dụng tập hợp con C và biên dịch với trình biên dịch C ++, nhưng bạn sẽ thấy rằng nếu bạn làm điều đó bạn sẽ nhận được kết quả hơi khác nhau tùy thuộc vào trình biên dịch.

Bất kể, nếu bạn đang làm điều đó, bạn đang sử dụng C. Câu hỏi của bạn có thực sự là "Tại sao các lập trình viên C không sử dụng trình biên dịch C ++?" Nếu đúng như vậy, thì bạn không hiểu sự khác biệt về ngôn ngữ hoặc bạn không hiểu lý thuyết trình biên dịch.

Tôi thích sự tối giản & đơn giản.

• Vì họ đã biết C
• Bởi vì họ đang xây dựng một ứng dụng nhúng cho một nền tảng chỉ có trình biên dịch C
• Bởi vì họ đang duy trì phần mềm kế thừa được viết bằng C
• Bạn đang viết một cái gì đó ở cấp độ của một hệ điều hành, một công cụ cơ sở dữ liệu quan hệ hoặc một công cụ trò chơi video 3D bán lẻ.

Những lo ngại về hiệu suất hoặc sự phình to không phải là lý do chính đáng để từ bỏ C ++. Mọi ngôn ngữ đều có những cạm bẫy tiềm tàng và sự đánh đổi - các lập trình viên giỏi tìm hiểu về những điều này và khi cần phát triển các chiến lược đối phó, các lập trình viên nghèo sẽ phạm lỗi và đổ lỗi cho ngôn ngữ.

Python được giải thích theo nhiều cách được coi là ngôn ngữ "chậm", nhưng đối với các tác vụ không tầm thường, lập trình viên Python có kỹ năng có thể dễ dàng tạo mã thực thi nhanh hơn so với nhà phát triển C thiếu kinh nghiệm.

Trong ngành công nghiệp của tôi, trò chơi video, chúng tôi viết mã hiệu suất cao trong C ++ bằng cách tránh những thứ như RTTI, ngoại lệ hoặc hàm ảo trong các vòng lặp bên trong. Đây có thể là cực kỳ hữu ích nhưng có vấn đề hiệu suất hoặc phình to mà nó muốn tránh. Nếu chúng ta tiến thêm một bước và chuyển hoàn toàn sang C, chúng ta sẽ thu được rất ít và mất đi các cấu trúc hữu ích nhất của C ++.

Lý do thực tế lớn nhất để thích C là sự hỗ trợ rộng rãi hơn C ++. Có nhiều nền tảng, đặc biệt là các nền tảng được nhúng, thậm chí không có trình biên dịch C ++.

Ngoài ra còn có vấn đề tương thích cho các nhà cung cấp. Trong khi C có ABI (Giao diện nhị phân ứng dụng) ổn định và được xác định rõ thì C ++ không có. ABI trong C ++ phức tạp hơn do những thứ như vtables và construcurs / phá hủy do đó được triển khai khác nhau với mọi nhà cung cấp và thậm chí các phiên bản của chuỗi công cụ của nhà cung cấp.

Trong thực tế, điều này có nghĩa là bạn không thể lấy một thư viện được tạo bởi một trình biên dịch và liên kết nó với mã hoặc thư viện từ một trình biên dịch khác tạo ra cơn ác mộng cho các dự án phân tán hoặc nhà cung cấp phần mềm trung gian của thư viện nhị phân.

Tôi chọn viết bằng C vì tôi thích làm việc với một ngôn ngữ nhỏ, chặt chẽ. Tôi thích có quyền truy cập vào một tiêu chuẩn có thể được đọc trong một khoảng thời gian hợp lý (đối với tôi - tôi là một người đọc rất chậm). Hơn nữa, tôi sử dụng nó để viết phần mềm cho các hệ thống nhúng mà ít trình biên dịch C ++ mong muốn tồn tại (như một số bộ điều khiển vi PIC).

Tôi có quan điểm khác: tại sao sử dụng C ++ thay vì C?

Cuốn sách Ngôn ngữ lập trình C (hay còn gọi là: K & R) cho bạn biết rõ cách thực hiện mọi thứ mà ngôn ngữ có thể làm trong dưới 300 trang. Đó là một kiệt tác của chủ nghĩa tối giản. Không có cuốn sách C ++ nào đến gần.

Phản biện rõ ràng là hầu hết đều có thể nói giống nhau, nếu không nói là tất cả, các ngôn ngữ hiện đại - chúng cũng không thể cho bạn biết cách làm mọi thứ chỉ trong vài trăm trang. Thật. Vậy tại sao nên sử dụng C ++ thay thế? Tính năng phong phú? Quyền lực? Nếu bạn cần một cái gì đó nhiều tính năng phong phú hoặc mạnh mẽ hơn thì hãy đi với C #, Objective C, Java hoặc một cái gì đó tương tự. Tại sao gánh nặng cho bản thân với sự phức tạp của C ++? Nếu bạn cần mức độ kiểm soát cấp C ++ thì tôi lập luận sử dụng C. C có thể làm bất cứ điều gì và có thể làm tốt.

Ngoài một số điểm khác đã được đề cập:

Ít bất ngờ

có nghĩa là, nó là dễ dàng hơn nhiều để xem những gì một đoạn mã sẽ làm làm chính xác . Trong C ++, bạn cần tiếp cận cấp độ guru để có thể biết chính xác trình biên dịch tạo ra mã nào (thử kết hợp các mẫu, nhiều kế thừa, hàm tạo tự động, hàm ảo và trộn một chút ma thuật không gian tên và tra cứu phụ thuộc đối số).

Trong nhiều trường hợp, phép thuật này rất hay, nhưng ví dụ trong các hệ thống thời gian thực, nó thực sự có thể làm hỏng ngày của bạn.

Câu trả lời của Linus cho câu hỏi của bạn là "Bởi vì C ++ là một ngôn ngữ khủng khiếp"

Bằng chứng của anh ấy là giai thoại tốt nhất, nhưng anh ấy có một điểm ..

Là ngôn ngữ cấp thấp hơn, bạn thích ngôn ngữ này hơn C ++. C ++ là C có thêm thư viện và trình biên dịch hỗ trợ cho các tính năng bổ sung ( cả hai ngôn ngữ đều có tính năng mà ngôn ngữ khác không có và triển khai mọi thứ khác nhau ), nhưng nếu bạn có thời gian và kinh nghiệm với C, bạn có thể hưởng lợi từ các quyền hạn liên quan ở cấp độ thấp thêm ... [Đã chỉnh sửa] (vì bạn đã quen với việc thực hiện nhiều công việc thủ công hơn là hưởng lợi từ một số quyền hạn đến từ chính ngôn ngữ / trình biên dịch)

Thêm liên kết:

Tại sao C ++ cho nhúng

Tại sao bạn vẫn sử dụng C? PDF

Tôi sẽ google cho điều này .. bởi vì có rất nhiều bình luận trên web

Bởi vì họ đang viết một plugin và C ++ không có ABI tiêu chuẩn.

Thời gian biên dịch dài có thể gây phiền nhiễu. Với C ++, bạn có thể có thời gian biên dịch rất dài (tất nhiên, điều đó có nghĩa là có nhiều thời gian hơn cho Stack Overflow!).

Tôi đã từng sử dụng C ++ cho các dự án của mình. Sau đó, tôi đã nhận được một công việc trong đó đơn giản C được sử dụng (một cơ sở mã phát triển 20 năm của một phần mềm AV có tài liệu kém ...).

3 điều tôi thích ở C là:

• Không có gì là ẩn: bạn thấy chính xác những gì chương trình của bạn làm hoặc không làm. Điều này làm cho việc gỡ lỗi dễ dàng hơn.

• Việc thiếu không gian tên và quá tải có thể là một lợi thế: nếu bạn muốn biết một hàm được gọi ở đâu, chỉ cần grep qua thư mục mã nguồn và nó sẽ cho bạn biết. Không có công cụ đặc biệt khác cần thiết.

• Tôi đã khám phá lại sức mạnh của các con trỏ hàm. Về cơ bản, chúng cho phép bạn thực hiện tất cả các công cụ đa hình mà bạn làm trong C ++, nhưng chúng thậm chí còn linh hoạt hơn.

Tôi ngạc nhiên không có thư viện đề cập đến. Rất nhiều ngôn ngữ có thể liên kết với C libs và gọi các hàm C (bao gồm C ++ với "C" bên ngoài). C ++ gần như là thứ duy nhất có thể sử dụng lib C ++ (được định nghĩa là lib một lib sử dụng các tính năng trong C ++ không có trong C [như các hàm bị quá tải, các phương thức ảo, toán tử quá tải, ...] và không xuất mọi thứ thông qua các giao diện tương thích C thông qua "C" 'bên ngoài.

Nếu bạn muốn mã của bạn được hiểu bởi hầu như bất kỳ lập trình viên nào viết bằng C.

Bởi vì họ muốn sử dụng các tính năng trong C99 không có tương đương trong C ++.

Tuy nhiên, không có nhiều tính năng C99 hữu ích cho C ++ như mọi người nghĩ ngay từ cái nhìn đầu tiên. Mảng có độ dài thay đổi? C ++ có std :: vectơ. Hỗ trợ cho số phức / tưởng tượng? C ++ có kiểu phức tạp templated. Hàm toán tổng quát loại? C ++ đã quá tải các hàm toán học tiêu chuẩn, gây ra kết quả tương tự.

Đặt tên khởi tạo? Không phải trong C ++, nhưng có một cách giải quyết:

struct My_class_params {
    int i;
    long j;
    std::string name;

    My_class_params& set_i(int ii)
    {
        i = ii;
        return *this;
    }

    My_class_params& set_j(long jj)
    {
        j = jj;
        return *this;
    }


    template <typename STRING>
    My_class_params& set_name(STRING&& n)
    {
        name = std::forward<STRING>(n);
        return *this;
    }

    My_class_params()
    {
        // set defaults
    }
};

class My_class {
    My_class_params params;
  public:
    My_class(const My_class_params& p) : params(p) { }
    ...
};

Điều này cho phép bạn viết những thứ như:

My_class mc(My_class_params().set_i(5).set_name("Me"));

Bởi vì đối với nhiều tác vụ lập trình, C đơn giản hơn và đủ tốt. Khi tôi đang lập trình các tiện ích nhẹ đặc biệt, tôi có thể cảm thấy như C ++ muốn tôi xây dựng một cấu trúc siêu thanh lịch cho mục đích riêng của mình, thay vì chỉ đơn giản là viết mã.

OTOH, đối với các dự án phức tạp hơn, sự thanh lịch cung cấp sự chặt chẽ về cấu trúc vững chắc tốt hơn so với việc chảy ra khỏi bàn phím của tôi một cách tự nhiên.

Hầu hết các tính năng quan trọng của c ++ bằng cách nào đó liên quan đến các lớp hoặc mẫu. Đây là những tính năng tuyệt vời ngoại trừ cách trình biên dịch biến chúng thành mã đối tượng. Hầu hết các trình biên dịch sử dụng xáo trộn tên và những trình biên dịch không làm gì đó ít nhất là lộn xộn.

Nếu hệ thống của bạn tự hoạt động, như trường hợp của nhiều ứng dụng, thì C ++ là một lựa chọn tốt.

Nếu hệ thống của bạn cần tương tác với phần mềm không được viết bằng C ++ (thường xuyên nhất là trong trình biên dịch chương trình, hoặc Thư viện Fortran) thì bạn đang ở trong tình trạng khó khăn. Để tương tác với các loại trường hợp đó, bạn sẽ cần phải tắt chức năng xáo trộn tên cho các biểu tượng đó. điều này thường được thực hiện bằng cách khai báo các đối tượng đóextern "C" , nhưng sau đó chúng không thể là các mẫu, các hàm quá tải hoặc các lớp. Nếu đó có thể là API ứng dụng của bạn, thì bạn sẽ phải bọc chúng bằng các hàm trợ giúp và giữ cho các chức năng đó đồng bộ với các triển khai thực tế.

Và trong thực tế, ngôn ngữ C ++ cung cấp một cú pháp tiêu chuẩn cho các tính năng có thể dễ dàng thực hiện trong C.

Nói tóm lại, chi phí hoạt động của C ++ có thể tương tác là quá cao đối với hầu hết mọi người để biện minh.

Điều này khá nông cạn nhưng là một sinh viên bận rộn, tôi đã chọn C vì tôi nghĩ C ++ sẽ mất quá nhiều thời gian để học. Nhiều giáo sư tại trường đại học của tôi sẽ không chấp nhận các bài tập trong Python và tôi cần phải nhanh chóng nhận được một cái gì đó.

Một nhận xét về "chỉ sử dụng tập hợp con của C ++ mà bạn muốn sử dụng": vấn đề với ý tưởng này là nó có chi phí để thực thi rằng mọi người trong dự án đều sử dụng cùng một tập hợp con. Ý kiến ​​riêng của tôi là những chi phí đó khá cao cho các dự án được ghép lỏng lẻo (ví dụ như các dự án nguồn mở) và C ++ hoàn toàn thất bại trong việc trở thành một C tốt hơn, theo nghĩa là bạn không thể sử dụng C ++ ở bất cứ nơi nào bạn sử dụng C.

Ôi trời, C vs C ++, một cách tuyệt vời để bắt đầu một cuộc chiến rực lửa. :)

Tôi nghĩ rằng C là tốt hơn cho trình điều khiển và mã nhúng.

C ++ có một số tính năng tuyệt vời mà C không có, nhưng nhiều tính năng hướng đối tượng của C ++ có thể gây ra sự lộn xộn mã hóa hoành tráng khi mọi người viết mã với các tác dụng phụ không rõ ràng xảy ra đằng sau hậu trường. Mã điên có thể được ẩn trong các hàm tạo, hàm hủy, hàm ảo, ... Vẻ đẹp của mã C là ngôn ngữ không có gì không rõ ràng đằng sau lưng của bạn, do đó bạn có thể đọc mã và không phải tìm kiếm mọi hàm tạo và hàm hủy và như thế. Rất nhiều vấn đề là thực hành mã hóa xấu bởi MỘT SỐ người.

Ngôn ngữ hoàn hảo của tôi sẽ là sự kết hợp của C99 cộng với một tập hợp con tối thiểu các khả năng C ++ an toàn hơn, bổ sung thêm trình biên dịch ZERO (hoặc gần 0) cho đầu ra nhị phân. Bổ sung hoàn hảo sẽ là đóng gói lớp và đặt tên các khái niệm về dữ liệu và hàm.

Tôi chưa thể tìm thấy nhiều bằng chứng về lý do tại sao bạn muốn chọn C hơn C ++.

Bạn khó có thể gọi những gì tôi sắp nói bằng chứng; đó chỉ là ý kiến ​​của tôi

Mọi người thích C vì nó phù hợp độc đáo trong tâm trí của người lập trình.

Có nhiều quy tắc phức tạp của C ++ [khi nào bạn cần các hàm hủy ảo, khi nào bạn có thể gọi các phương thức ảo trong một hàm tạo, làm thế nào để quá tải và ghi đè tương tác, ...] và để làm chủ tất cả chúng phải mất rất nhiều nỗ lực. Ngoài ra, giữa các tham chiếu, nạp chồng toán tử và nạp chồng hàm, hiểu một đoạn mã có thể yêu cầu bạn hiểu mã khác có thể dễ hoặc không tìm thấy.

Một câu hỏi khác nhau tại sao các tổ chức sẽ thích C hơn C ++. Tôi không biết rằng, tôi chỉ là một người ;-)

Để bảo vệ C ++, nó mang lại các tính năng có giá trị cho bảng; Mặc dù vậy, cái tôi đánh giá cao nhất có lẽ là đa hình tham số ('ish): các hoạt động và loại lấy một hoặc nhiều loại làm đối số.

Tôi có thể nói rằng C cung cấp cho bạn quyền kiểm soát tối ưu hóa và hiệu quả tốt hơn C ++ và do đó sẽ hữu ích trong các tình huống mà bộ nhớ và các tài nguyên khác bị hạn chế và mọi tối ưu hóa đều giúp ích. Nó cũng có một dấu chân nhỏ hơn tất nhiên.

Ngoài ra còn có cách tiếp cận mà một số cửa hàng sử dụng một số tính năng của C ++ theo cách giống như C, nhưng tránh những thứ bị phản đối. Ví dụ, sử dụng các lớp và phương thức lớp và nạp chồng hàm (thường dễ dàng đối với các bế tắc C để đối phó), nhưng không phải là STL, toán tử luồng và Boost (khó học hơn và có thể có các đặc điểm bộ nhớ xấu).

Bởi vì bạn đang viết cho một hệ thống có tài nguyên chặt chẽ (chẳng hạn như hệ thống nhúng hoặc một loại mã kim loại trần thực sự nào đó như hạt nhân) và bạn muốn có càng ít chi phí càng tốt.

Có một lý do tại sao hầu hết các hệ thống nhúng không có trình biên dịch C ++ - không phải mọi người không muốn, đó là việc nhồi nhét mã C ++ vào một không gian nhỏ đó là nhiệm vụ không thể tiếp cận.

Những gì C cần là một tiền xử lý tốt hơn. cfront là một và do đó sinh ra c ++

Tôi sẽ sử dụng C, trong đó 'c ++ là tiền xử lý' sẽ không ổn.

Tôi khá chắc chắn, ở dưới cùng của bất kỳ thư viện / khung / bộ công cụ c ++ nào được viết tốt, bạn sẽ tìm thấy bẩn-old-c (hoặc phôi tĩnh, giống nhau)

• Cho đến vài năm trước, các trình biên dịch C ++ hiện tại đã thiếu các tính năng quan trọng hoặc khả năng hỗ trợ kém và các tính năng được hỗ trợ rất khác nhau giữa chúng và vì vậy rất khó để viết các ứng dụng di động.
• Do không có cách đặt tên biểu tượng chuẩn nên các ngôn ngữ / ứng dụng khác khó có thể hỗ trợ trực tiếp các lớp C ++.