Tôi có nên ngừng sử dụng thuật ngữ C / C ++ không?

Tôi hiểu C và C ++ là các ngôn ngữ khác nhau nhưng khi tôi học C ++, tôi luôn được thông báo rằng C là tập con của C ++ hoặc C ++ là C với các lớp. Và điều đó hoàn toàn đúng cho đến khi xuất hiện C ++ x0, C ++ 11 (hay C ++ 11/14/17 hiện đại nói chung). Trong thực tế (đặc biệt là khi làm việc trên các hệ thống nhúng) rất có thể tìm thấy mã được viết bằng C ++ nhưng với rất nhiều phần được viết hoàn toàn bằng ngôn ngữ C thuần túy. Ở đây tôi có một số câu hỏi:

1. Tôi có nên ngừng sử dụng thuật ngữ C / C ++ không?
2. Nếu câu trả lời cho # 1 là có, làm thế nào tôi có thể gọi một chương trình sử dụng kết hợp C và C ++?
3. Cho rằng cả hai ngôn ngữ 'khác nhau', có khả năng tại một số điểm, trình biên dịch C ++ ngừng hỗ trợ mã được viết bằng ngôn ngữ C (vì c ++ hiện đại đang chuyển hướng khỏi tâm lý C cho các công cụ cơ bản như con trỏ, xử lý bộ nhớ động, v.v.)
4. Hiện tại có bất kỳ sự hợp tác nào giữa những người tạo ra các tiêu chuẩn của C / C ++ để giữ tính tương thích
5. Nếu số 4 là có, sự hợp tác như vậy có thể kết thúc trong tương lai gần với sự xuất hiện của c ++ hiện đại (14/11/17)

Tôi biết rằng đã có những câu hỏi tương tự, nhưng tôi chắc chắn rằng nhiều người chia sẻ những câu hỏi này vì vậy tôi rất quan tâm để có câu trả lời tốt, đặc biệt là những điểm liên quan đến xu hướng C ++ trong tương lai gần.

C chưa bao giờ là tập con của C ++. Ví dụ rõ ràng nhất về điều này là int new;. Điều này đã đúng từ C89 và C ++ 98, và các ngôn ngữ chỉ phát triển hơn nữa khi các tiêu chuẩn mới được đưa ra.

Tôi có nên ngừng sử dụng thuật ngữ C / C ++

Đúng

Nếu câu trả lời cho # 1 là có, làm thế nào tôi có thể gọi một chương trình sử dụng kết hợp C và C ++?

Một tập tin nguồn được viết bằng ngôn ngữ này hay ngôn ngữ khác. Một chương trình có thể bao gồm mã từ nhiều ngôn ngữ làm việc cùng nhau hoặc một tệp thực thi được tạo bằng cách liên kết các đối tượng được biên dịch khác nhau. Bạn sẽ nói chương trình được viết bằng C và C ++, "C / C ++" không phải là ngôn ngữ.

Cho rằng cả hai ngôn ngữ 'khác nhau', có khả năng tại một số điểm, trình biên dịch C ++ ngừng hỗ trợ mã được viết bằng ngôn ngữ C

3) Họ không bao giờ làm. char *a = malloc(10);. C và C ++ chưa bao giờ tương thích hoàn toàn ít nhất là miễn là chúng có các tiêu chuẩn ISO (Tôi không biết tất cả các chi tiết về những ngày được chuẩn hóa trước). nhấp vào liên kết hoặc xem bên dưới để biết tệp phù hợp với C89 trở lên, nhưng không hợp lệ theo bất kỳ tiêu chuẩn C ++ nào.

4) afaik không, các nhóm làm việc nhận thức được nhau nhưng các tiêu chuẩn đưa ra quyết định tốt nhất cho chính họ.

/* A bunch of code that compiles and runs under C89 but fails under any C++ */

/* type aliases and struct names occupy separate namespaces in C, not in C++ */
struct S { int i; };
typedef int S;


struct Outer { struct Inner { int i; } in; };
/* struct Inner will be Outer::Inner in C++ due to name scope */
struct Inner inner;


/* default return type of int in C, C++ functions need explicit return types */
g() {
    return 0;
}


/* C sees this as two declarations of the same integer,
 * C++ sees it as redefinition */
int n;
int n;


/* K&R style argument type declarations */
void h(i) int i; { }


/* struct type declaration in return type */
struct S2{int a;} j(void) { struct S2 s = {1}; return s; }


/* struct type declaration in argument, stupid and useless, but valid */
/*void dumb(struct S3{int a;} s) { } */


/* enum/int assignment */
enum E{A, B};
enum E e = 1;


void k() {
    goto label; /* C allows jumping past an initialization */
    {
        int x = 0;
label:
        x = 1;
    }
}


/* () in declaration means unspecified number of arguments in C, the definition
 * can take any number of arguments,
 * but means the same as (void) in C++  (definition below main) */
void f();

int main(void) {
    f(1); /* doesn't match declaration in C++ */
    {
        /* new is a keyword in C++ */
        int new = 0;
    }

    /* no stdio.h include results in implicit definiton in C.  However,
     * as long as a matching function is found at link-time, it's fine.
     * C++ requires a declaration for all called functions */
    puts("C is not C++");
    {
        int *ip;
        void *vp = 0;
        ip = vp; /* cast required in C++, not in C */
    }
    return 0;
}

/* matches declaration in C, not in C++ */
void f(int i) { }

Tôi luôn cảm thấy đáng nói khi C là tập con của Objective-C.

Phải có một lý do tại sao các điều khoản này đến với nhau thường xuyên như vậy. Mặc dù bạn không nên nói với giáo viên C của mình rằng ngôn ngữ của anh ta là một tập hợp con của C ++, có một số sự thật ở đây. Những người khác đã bộc lộ quan điểm của giáo viên của bạn. Điều này là rất tốt đẹp (và minh họa bằng các ví dụ, vv). Nhưng chúng ta không sống trong một tòa tháp ngà hay một cuốn sách.

Sếp lớn của bạn không thể không quan tâm đến ngôn ngữ chính xác mà bạn đã sử dụng. Nếu anh ta biết một chút về lập trình, chỉ cần nói với anh ta rằng bạn đã sử dụng C / C ++ và nó sẽ nghe như "Tôi đã sử dụng một ngôn ngữ cần được biên dịch thành mã máy, với DLL và tất cả những thứ phức tạp". Đây là phần "giao tiếp bên ngoài".

Nếu bạn tạo một thư viện có thể được giao tiếp bởi cả C và C ++, bạn chắc chắn muốn gọi nó là thư viện C / C ++. Tất nhiên, ai đó sẽ giơ tay và hỏi tại sao bạn không gọi đây là thư viện C tình cờ có trình bao bọc C ++ và dù sao C ++ cũng có thể liên kết với thư viện C nên bạn không cần đề cập đến nó. Chỉ cần trả lời: "Vâng, bạn đã đúng, đây là thư viện C / C ++". Đây là phần "truyền thông nội bộ".

Nếu bạn tạo một bộ phân tích từ vựng cho C ++, bạn sẽ ngạc nhiên khi nó hoạt động tốt như thế nào với C. Bạn thậm chí có thể không cần phải sửa đổi tất cả. Đây là "nếu nó trông giống như một con vịt, v.v." phần.

Vân vân.

Phần lớn các chương trình C tôi từng thấy biên dịch (và hoạt động) mà không sửa đổi như mã C ++. Đừng để một vài trường hợp ngoại lệ hoặc lập trình viên giáo điều (tuy có ảnh hưởng) đánh lừa trực giác của bạn. C và C ++ rất gần nhau, và thường tương thích, và thường được trộn lẫn và khớp với nhau, nên thuật ngữ C / C ++ được sử dụng. Nó được sử dụng vì rất hữu ích khi mô tả các loại tình huống trong đó không thực sự quan trọng cho dù bạn đang xem xét C hay C ++, miễn là nó không phải là Java hay PHP . Chúng tôi biết đó là "sai", nhưng chúng tôi không quan tâm, nó hữu ích hơn sai.

Nó có thể bị lạm dụng, nó có thể là ngu ngốc, nhưng tôi vẫn không chắc bạn sẽ nhận được lợi ích gì khi trở nên tầm thường hơn mức cần thiết và từ chối giao tiếp theo cách mà người khác hiểu. Nếu bạn cảm thấy không thoải mái trong một số tình huống cụ thể, thì đơn giản là không sử dụng thuật ngữ chung C / C ++, nhưng thuật ngữ có liên quan đến vụ án (C hoặc C ++).

Đừng sợ tương lai. Các hệ điều hành của chúng tôi được viết bằng C. Khá nhiều sản phẩm phần mềm hiện tại của C / C ++ xảy ra trong C ++. Cặp vợ chồng này ở đây để ở khá lâu. Không ai có hứng thú với việc một người trở nên không tương thích với người kia (thực ra hoàn toàn khác).

Để được cụ thể về điểm của bạn:

1) Nó phụ thuộc. Có khi nó có thể dẫn đến một sự nhầm lẫn, khi bạn cảm thấy không thoải mái, hoặc khi nó đơn giản là sai hoặc ra khỏi bối cảnh. Không khi bạn nghĩ rằng nó đầy đủ.

2) Không có

3) Tôi nghĩ là không, nhưng tôi không có quả cầu pha lê.

4) không có ý tưởng

5) Tôi không nghĩ như vậy vì không có gì thúc đẩy theo hướng này

Đi ngược lại dòng chảy tôi sẽ nói nó phụ thuộc vào bối cảnh .

Thuật ngữ "C / C ++" thường không phù hợp khi nói điều gì đó như "đây là chương trình C / C ++", nhưng điều này đã được khám phá sâu hơn trong các câu trả lời khác.

Tuy nhiên, có thể có bối cảnh trong đó C / C ++ có thể phù hợp.

• Có nhiều thư viện khác nhau thường có cả API C và C ++. Tôi đoán nó không xa sự thật nếu bạn gọi một thứ như vậy là thư viện C / C ++. Con người chúng ta thích nén thông tin, vì vậy nói "opencv là thư viện C / C ++" ngắn gọn, rõ ràng và dễ hiểu, so sánh nó với "opencv là một thư viện, được gửi với các tiêu đề cho cả C và C ++".
• Bạn có thể nói về thiết kế ngôn ngữ và cú pháp. Từ quan điểm của cú pháp ngôn ngữ, bạn có thể nói rằng một ngôn ngữ có cú pháp giống C / C ++.
• Bạn tổ chức một cuộc thi mã hóa và bạn chấp nhận cả hai giải pháp được viết bằng C và bằng C ++
• Bạn đang thuê một lập trình viên mới và hầu hết các nhiệm vụ sẽ là C hoặc C ++, vì vậy lập trình viên dự kiến ​​sẽ biết cả hai ngôn ngữ. Nó phổ biến trong phát triển nhúng, trong đó C phù hợp hơn với một số vi điều khiển (thường là rất nhỏ) và C ++ cho các loại khác. Trong trường hợp này, bạn có thể nói rằng bạn đang tìm kiếm một lập trình viên C / C ++.

Nói chung, người dùng SO hỏi người đang đặt câu hỏi để chọn ngôn ngữ: C hoặc C ++. Tại sao?

Có nhiều sự khác biệt tinh tế giữa C và C ++. Ví dụ, trong C ++, một constbiến ở phạm vi toàn cầu có liên kết bên trong trừ khi được khai báo extern, nhưng trong C, nó có liên kết ngoài trừ khi được khai báo static. Bằng cách nói "C / C ++", OP đang khẳng định kiến ​​thức rằng câu trả lời cho câu hỏi của họ là giống nhau ở cả C và C ++, khi đó rất có thể là không. Điều này không cần thiết làm cho mọi thứ khó hơn cho những người trả lời.

• Đôi khi chúng ta có thể phát hiện ra rằng mã không hợp lệ trong một ngôn ngữ này hoặc ngôn ngữ khác (ví dụ: chuyển đổi ngầm định từ void*con trỏ sang đối tượng không hợp lệ trong C ++). Điều này thật khó chịu. Tại sao bạn lại nói "C / C ++" khi bạn có một đoạn mã hợp lệ trong C mà không phải là C ++? Bạn có ý định C, hay đây chỉ là một lỗi trong mã dự định là C ++?

• Đôi khi câu trả lời sẽ khác nhau tùy thuộc vào ngôn ngữ (ví dụ: mảng có độ dài thay đổi tồn tại trong C99 nhưng không có trong C ++). Nếu chúng tôi không biết bạn đang nói về ngôn ngữ nào, chúng tôi phải đoán hoặc viết câu trả lời cho cả hai khi chỉ một ngôn ngữ sẽ thực sự hữu ích, bởi vì bạn biết bạn đang sử dụng ngôn ngữ nào; bạn chỉ không nói với chúng tôi!

• Đôi khi câu trả lời thực sự giống nhau cho cả hai ngôn ngữ, nhưng thật khó để chắc chắn. Ví dụ, tôi nghĩ C và C ++ có cùng quy tắc chuyển đổi số nguyên, nhưng để thực sự, thực sự chắc chắn, tôi phải đọc kỹ cả hai tiêu chuẩn. Một lần nữa, điều này khiến tôi làm gấp đôi công việc cần thiết khi bạn có thể chỉ quan tâm đến một trong những ngôn ngữ.

Dù sao, để trả lời các câu hỏi khác của bạn:

1. Đúng.

2. Nếu bạn đang liên kết mã C và C ++ với nhau, có thể chấp nhận sử dụng cả hai thẻ, nhưng vui lòng chỉ định ngôn ngữ của mỗi tệp.

3. Đôi khi có những thay đổi đột phá, nhưng chúng rất hiếm và thường bị hạn chế về tác động (nếu không chúng không được chấp thuận). Ví dụ, autotrong C ++ 11.

4. Tôi không nghĩ rằng họ trực tiếp hợp tác, nhưng họ chú ý đến sự phát triển trong ngôn ngữ khác và cố gắng tránh đưa ra những thay đổi sẽ làm cho việc tương thích trở nên khó khăn hơn.

Và nếu bạn thực sự muốn biết về cả hai ngôn ngữ, điều đó tốt, và bạn có thể nói điều đó trong câu hỏi của mình. Khi bạn nói "C / C ++", tôi thực sự không chắc ý của bạn là gì và có vẻ như bạn đang đưa ra một giả định về hai ngôn ngữ.

Tôi luôn được thông báo rằng C là tập con của C ++ hoặc C ++ là C với các lớp. Và đó là sự thật thầm lặng cho đến khi xuất hiện C ++ x0, C ++ 11 (hay C ++ 11/14/17 hiện đại nói chung).

C chưa bao giờ là tập con của C ++. Ví dụ C89 không phải là tập con của C ++ 98.

Một vài ví dụ:

• biểu mẫu danh sách định danh C89 để khai báo tham số chức năng không được hỗ trợ trong C ++
• C89 và C ++ 98 có các loại khác nhau cho các hằng ký tự
• C89 và C ++ 98 có các loại khác nhau cho chuỗi ký tự
• toán tử logic mang lại các loại khác nhau trong C89 và C ++ 98 ( intvs. bool)

1. Tôi có nên ngừng sử dụng thuật ngữ C / C ++ không?

Đúng.

2. Nếu câu trả lời cho # 1 là có, làm thế nào tôi có thể gọi một chương trình sử dụng kết hợp C và C ++?

Một chương trình là C hoặc C ++ (nếu thậm chí một số chương trình rất cơ bản có thể được biên dịch bằng trình biên dịch C hoặc C ++). Trình biên dịch nào bạn đang sử dụng để biên dịch nó? Nó sẽ trả lời câu hỏi của bạn. Harbison & Steele đưa ra thuật ngữ Clean C để chỉ định một tập hợp con chung của C và C ++ nhưng tôi nghĩ đó là một ý tưởng tồi.

EDIT : Tuy nhiên, tôi thừa nhận rằng về mặt kỹ thuật, bạn có thể liên kết các tệp đối tượng C và C ++ trong một chương trình nhưng OTH có nhiều ngôn ngữ được phép trộn lẫn trong một chương trình, ví dụ Java và C ++. Tôi nghĩ rằng việc sử dụng thuật ngữ chương trình C / C ++ chỉ làm tăng thêm sự nhầm lẫn rằng nó được viết bằng một ngôn ngữ duy nhất gọi là C / C ++.

3. Cho rằng cả hai ngôn ngữ 'khác nhau', có khả năng tại một số điểm, trình biên dịch C ++ ngừng hỗ trợ mã được viết bằng ngôn ngữ C (vì c ++ hiện đại đang chuyển hướng khỏi tâm lý C cho các công cụ cơ bản như con trỏ, xử lý bộ nhớ động, v.v.)

Có nhiều tính năng (ví dụ: mảng có chiều dài thay đổi, thành viên mảng linh hoạt _Generic, ...) của C99 hoặc C11 không được hỗ trợ bởi bất kỳ phiên bản C ++ nào.

Một số chương trình được viết bằng hỗn hợp C và C ++

Đây chỉ là một thực tế của cuộc sống. Bạn có thể biên dịch các tệp đối tượng từ C và C ++ và liên kết chúng lại với nhau. Kết quả hoàn toàn có thể được gọi là "chương trình C / C ++".

Nhưng đó chỉ là toàn bộ chương trình. Còn các đơn vị biên dịch riêng lẻ thì sao?

Có một tập hợp con của C cũng là tập con của C ++

Một chương trình (hoặc đơn vị biên dịch) được viết trong tập hợp con đó sẽ biên dịch và hoạt động giống nhau theo trình biên dịch C và C ++ tuân thủ. Một chương trình hoặc tệp như vậy có thể được gọi đúng là "chương trình C / C ++" hoặc "tệp C / C ++".

Một chương trình một phần như tệp tiêu đề cũng có thể được sử dụng trong cả chương trình C và C ++. Các tệp tiêu đề như vậy có thể được gọi đúng là các tiêu đề C / C ++.

Trích dẫn giáo sư Bjarne Stroustrup:

C có phải là tập con của C ++ không?

Theo nghĩa toán học nghiêm ngặt, C không phải là tập con của C ++. Có những chương trình là C hợp lệ nhưng không hợp lệ C ++ và thậm chí một vài cách viết mã có ý nghĩa khác trong C và C ++. Tuy nhiên, C ++ hỗ trợ mọi kỹ thuật lập trình được C. hỗ trợ. Mọi chương trình C có thể được viết về cơ bản giống như trong C ++ với cùng thời gian chạy và hiệu quả không gian. Không có gì lạ khi có thể chuyển đổi hàng chục ngàn dòng ANSI C sang C ++ kiểu C trong vài giờ. Do đó, C ++ là một siêu bộ của ANSI C cũng như ANSI C là một siêu bộ của K & R C và nhiều như ISO C ++ là một siêu bộ của C ++ như nó đã tồn tại vào năm 1985.

C cũng được viết có xu hướng hợp pháp C ++. Ví dụ: mọi ví dụ trong Kernighan & Ritchie: "Ngôn ngữ lập trình C (Phiên bản 2)" cũng là một chương trình C ++.

• http://www.stroustrup.com/bs_faq.html#C-is-subset

Vì vậy, có một thứ như C / C ++. Đó là bất cứ thứ gì có cả C hợp lệ và C ++ hợp lệ.

Bộ xử lý trước C là một phần của ngôn ngữ C. Bộ xử lý trước C ++ là một phần của ngôn ngữ C ++

Bạn có thể viết một đơn vị biên dịch sẽ biên dịch theo C hoặc C ++ và khác nhau . Ví dụ, nó có thể có chức năng cơ bản được biên dịch trong C nhưng tận dụng thư viện C ++ nếu được biên dịch trong C ++.

Nếu chương trình cơ bản là giống nhau, nhưng với các tính năng bổ sung, nó không chính xác sai để nói nó là cùng một chương trình. Nó giống nhau, nhưng cũng khác nhau.

Hầu hết các lập trình viên C có thể làm ít nhất một chút C ++ và ngược lại

Không phải vô lý khi gọi một người như vậy là lập trình viên C / C ++. Vâng, họ có thể chuyên về một, nhưng có ai là lập trình viên C hoặc C ++ có năng lực, người thực sự không thể làm bất kỳ ngôn ngữ nào khác không? Theo một cách nào đó, không phải tất cả họ đều là lập trình viên C / C ++ sao?

Không có gì sai khi nói "C / C ++". Vấn đề đang được hiểu

Ngôn ngữ tiếng Anh không phải là một công cụ để thể hiện tam đoạn luận . Bạn có thể sử dụng tiếng Anh cho logic, nhưng chỉ, và với nỗ lực rất lớn.

Điều này là do các từ không tự nhiên có ý nghĩa chính xác, mà là một đám mây mơ hồ của các ký hiệu và ý nghĩa. Điều quan trọng là nếu mọi người hiểu những gì bạn đang nói.

1. Tôi có nên ngừng sử dụng thuật ngữ C / C ++ không?

Chắc chắn rồi. Không rõ cấu trúc này được dùng để thể hiện điều gì ngoại trừ, có lẽ, sự nhầm lẫn về những gì C và C ++ thay mặt cho người sử dụng thuật ngữ này.

Vì sự nhầm lẫn này là một nguồn thất vọng phổ biến như vậy, nhiều người đã trở nên khá xúc động về nó và sự xuất hiện của thuật ngữ đó sẽ là lý do đủ để họ trở nên tiêu cực về sự đóng góp của bạn. Điều này có vẻ ngớ ngẩn nhưng nó dường như là những gì chúng ta có.

Tôi khuyên bạn thay vì nói về chuyện C / C ++, bạn nên sử dụng một thuật ngữ thực sự làm rõ ý của bạn.

• Nếu bạn đang nói về một cái gì đó trong C mà có thể hoặc có thể không còn đúng cho C ++, chỉ cần nói C .

  Ví dụ: Làm thế nào nên mainchức năng được khai báo trong C?

  Lúc đầu, có vẻ như câu trả lời cho C ++ là giống nhau: int main()hoặc int main(int, char**). Nhưng khi cuộc thảo luận diễn ra, có thể có liên quan để chỉ ra rằng trong C ++, hàm phải được khai báo ở phạm vi toàn cầu, điều này không có ý nghĩa gì trong C, vì nó không có namespaces. Mặt khác, C cho phép gọi mainđệ quy trong khi C ++ thì không. Trong C ++, có một ẩn ý return 0;nếu bạn bỏ rơi ra mainnhưng trong C thì returncâu lệnh được yêu cầu trên bất kỳ đường dẫn nào. Danh sách này tiếp tục và nó làm cho cuộc thảo luận đơn giản hơn nhiều nếu bạn làm cho nó rõ ràng về ngôn ngữ sẽ được thảo luận.

• Nếu bạn đang nói về điều gì đó trong C ++ có thể đúng hoặc có thể không đúng với C, chỉ cần nói C ++ .

  Ví dụ: Một malloc()mảng ed của ints ban đầu có phải là số không trong C ++ không?

  Câu trả lời ngắn gọn cho C xảy ra giống nhau: không. Nhưng khi câu trả lời tiếp tục, có thể đáng để chỉ ra rằng trong C, callocsẽ là một lựa chọn tốt trong khi ở C ++, sử dụng một từ std::vector<int>có thể là lựa chọn tốt hơn ngay từ đầu.

• Nếu bạn muốn chỉ ra sự tương đồng giữa C và C ++, hãy nói C và C ++ .

  Ví dụ: Trong C và C ++, sizeofan intđược triển khai được xác định và có thể khác nhau giữa các trình biên dịch và kiến ​​trúc.

  Ở đây, chúng tôi muốn chỉ ra rằng C và C ++ hành xử giống nhau. Chúng tôi đang nói rõ ràng về cả hai ngôn ngữ.

Tôi thực sự khuyên bạn nên cụ thể hơn nữa và không chỉ nói về C C hay hay C ++, mà còn là phiên bản chính xác. Cả hai ngôn ngữ đang phát triển và một tuyên bố thẳng thừng như

C ++ hỗ trợ /* … */và // …bình luận trong khi C chỉ hỗ trợ /* … */kiểu.

không đúng cũng không sai.

2. Nếu câu trả lời cho # 1 là có, làm thế nào tôi có thể gọi một chương trình sử dụng kết hợp C và C ++?

Vì các ngôn ngữ có sự trùng lặp, mọi chương trình C sẽ chứa các phần có thể trông giống C ++ và ngược lại. Tuy nhiên, các tác giả có thể đã quyết định sử dụng trình biên dịch C hoặc C ++. Vì vậy, nói rằng chương trình được viết bằng CÊ nếu nó được biên dịch bằng trình biên dịch C và chương trình được viết bằng C ++, nếu họ sử dụng trình biên dịch C ++, ngay cả khi họ có thể từ chối sử dụng bất kỳ tính năng C ++ hiện đại nào. Một số người đề cập đến như C ++ mã như C-style C ++ . Không có quá tải, ngoại lệ, đa hình, mẫu và luồng I / O một đặc điểm chung của mã đó.

Thay vào đó, nếu một số tệp được viết bằng C và được biên dịch bằng trình biên dịch C và một số tệp khác được viết bằng C ++ và được biên dịch bằng trình biên dịch C ++, sau đó các tệp đối tượng được liên kết với nhau, tôi sẽ nói rằng chương trình được viết bằng một kết hợp giữa C và C ++ , như trên thực tế, bạn đã làm.

Tuy nhiên, nếu, thay vào đó, các tác giả đã hết sức cẩn thận để viết từng tệp theo cách có thể được biên dịch bằng trình biên dịch C hoặc C ++ và chương trình kết quả sẽ làm điều tương tự, bạn có thể nói rằng chương trình đó được viết trong một tập hợp con phổ biến của C và C ++ .

Cái sau thường là trường hợp cho các tệp tiêu đề nên được chia sẻ giữa mã C và C ++. Nhân tiện, viết mã như vậy không dễ. Nếu bạn muốn tiếp tục nhấn mạnh rằng chỉ có cấu trúc như vậy đã được sử dụng đó là hợp lệ trong C và C ++ và được hỗ trợ rộng rãi bởi các nhà cung cấp trình biên dịch khác nhau, thuật ngữ một xách tay tập hợp con chung của C và C ++ có thể được sử dụng để nhấn mạnh điều này.

3. Cho rằng cả hai ngôn ngữ này đều khác nhau, có khả năng các trình biên dịch C ++ dừng hỗ trợ mã được viết bằng ngôn ngữ C (vì C ++ hiện đại đang chuyển hướng khỏi tâm lý C cho các công cụ cơ bản như con trỏ, xử lý bộ nhớ động, v.v.)?

Tôi không chắc là tôi hiểu câu hỏi này. Vì C và C ++ là các ngôn ngữ khác nhau, bạn không thể mong đợi trình biên dịch cho một trong số chúng chấp nhận một chương trình được viết cho ngôn ngữ kia. Tuy nhiên, trình biên dịch thường được thiết kế theo cách mô-đun và nếu một trình biên dịch có C ++ front-end , rất có thể là tốt nó cũng sẽ có một C front-end. (Sau đó, bạn sẽ chọn ngôn ngữ nào bạn muốn thông qua một công tắc dòng lệnh hoặc phương tiện tương tự.) Miễn là cả hai ngôn ngữ sẽ được sử dụng rộng rãi, có vẻ như điều này sẽ không thay đổi. Quan điểm của bạn về hiện đại của C ++, tôi nghĩ về cơ bản là vấn đề về tiêu chuẩn mã hóa tốt và thư viện chuẩn. Từ quan điểm của nhà soạn nhạc , sự phát triển của cả hai ngôn ngữ khá hội tụ hơn là chuyển hướng.

4. Hiện tại có sự hợp tác nào giữa những người tạo ra các tiêu chuẩn của C / C ++ để giữ tính tương thích không?

Đúng. Mô hình bộ nhớ và thư viện hoạt động nguyên tử được giới thiệu trong C ++ 11 và C11 là một ví dụ điển hình. Dường như các nhà thiết kế của cả hai ngôn ngữ nhận ra rằng khả năng tương thích là quan trọng và đang nỗ lực cải thiện nó. Cá nhân, tôi muốn rằng sự hợp tác sẽ mạnh mẽ hơn và hai nhóm làm việc ISO thậm chí có thể tham gia nhưng mong muốn của tôi không quan trọng.

Bjarne Stroustrup nói về sự khác biệt và tương đồng giữa các phiên bản khác nhau của C và C ++ trong § 44.3 của phiên bản thứ 4 của Ngôn ngữ lập trình C ++ , trớ trêu thay, có tựa đề là Tương thích C / C ++. Sử dụng thuật ngữ có thể thực sự phù hợp trong trường hợp này vì nó rõ ràng có nghĩa là gì.

5. Nếu số 4 là có, sự hợp tác như vậy có thể kết thúc trong tương lai gần với sự xuất hiện của C ++ hiện đại (14/11/17)

Như đã thảo luận ở trên, nó đã xảy ra trong C ++ 11 và được mong đợi / hy vọng / cần thiết để xảy ra lần nữa.

C / C ++ là giao điểm của C và C ++.

int new;không phải là C / C ++, và cũng không vector<int> foo;.

Tương tự, C89 / C99 là giao điểm của hai ngôn ngữ này, nơi không enum bool { false, true };hoặc không for(int i = 0;;)được phép.

Và C ++ 11 / C ++ 14, v.v.

Có thể viết mã biên dịch (và chạy chính xác) theo C ++ 11 và C ++ 14, mặc dù việc biên dịch theo cái này không có nghĩa là nó biên dịch theo cái khác. Trong thực tế, rất nhiều người làm điều này.

Và rất nhiều người viết mã hoạt động trong C và C ++.

Rõ ràng, sự chồng chéo càng lớn, nó càng có ý nghĩa; Tôi không mong đợi thấy bất kỳ câu hỏi nào về mã C / C ++ / Java.

Mặc dù thật "có ý nghĩa" khi nói về một tập hợp con phổ biến của các ngôn ngữ này, nhiều câu hỏi sẽ không có câu trả lời trong tập hợp con này, ví dụ main () nên trả về gì trong C và C ++?

Nhưng bạn có thể nói về mã hoạt động cho nhiều thông số kỹ thuật ngôn ngữ, cho dù các thông số kỹ thuật đó được phân biệt bởi "phiên bản" hay "tên ngôn ngữ" hay nói cách khác.

Đây là một câu trả lời cho các vị trí rằng "đây là mã dành cho các lập trình viên làm việc gần với kim loại và ổn trong bối cảnh quản lý" được thấy trong một số câu trả lời và nhận xét khác.

Tôi tranh luận rằng ngay cả việc giải thích cũng nên được thực hiện cẩn thận.

Bắt đầu từ ít nhất là giữa thập niên 90 nếu bạn muốn lập trình viên C ++ và ai đó tự mô tả là lập trình viên C đã áp dụng, bạn phải hỏi họ biết bao nhiêu về thiết kế hướng đối tượng, họ có bao nhiêu kinh nghiệm khi gỡ lỗi trong một đối tượng bối cảnh định hướng và về khả năng sử dụng các thư viện mẫu. Bạn muốn thăm dò chính xác những vấn đề đó trong quá trình phỏng vấn và tuyển dụng.

Mặt khác, đã hơn một thập kỷ kể từ khi các bậc thầy về C ++ bắt đầu đẩy "C ++ hiện đại" có nghĩa là nhấn mạnh vào việc chuyển từ các con trỏ trần sang các đối tượng con trỏ an toàn hơn và các thành ngữ dựa trên trình lặp. Với sự xuất hiện của C ++ 11, giờ đây đã có sự hỗ trợ rõ ràng cho lập trình đa mô hình và việc đẩy mã không thể hiện con trỏ trần là rất mạnh. Điều đó có nghĩa là nếu tôi phỏng vấn một lập trình viên C ++ cho vị trí C ngày hôm nay tôi sẽ rất quan tâm đến việc kiểm tra mức độ quen thuộc của người này với các con trỏ hỗ trợ chụp chân thực tế.

Tôi không làm việc trong những ngày này (thậm chí ở mức độ khi tôi còn ở trạng thái Stack Overflow), vì vậy tôi sẽ không đoán được mức độ thường xuyên người được phỏng vấn tưởng tượng sẽ không có kỹ năng giao thoa, nhưng Tôi nghĩ rằng như thường được áp dụng, các ngôn ngữ bây giờ thực sự rất khác nhau.

Tóm lại, "C / C ++" nên được loại bỏ không chỉ trong bối cảnh kỹ thuật mà còn trong hầu hết các bối cảnh kinh doanh.

Câu trả lời đơn giản nhất cho câu hỏi này là bạn không bao giờ nên sử dụng thuật ngữ đó. Đó là một thuật ngữ không nên tồn tại. Nó không có ý nghĩa. Mỗi chương trình là C hoặc C ++.

Và đó là sự thật thầm lặng cho đến khi xuất hiện C ++ x0, C ++ 11 (hay C ++ 11/14/17 hiện đại nói chung).

C ++ 98 và 03 thậm chí không có C từ xa. Bất cứ ai dạy bạn điều này không biết shit và bạn có thể quên chúng. Điều này không bao giờ đúng.

Về mặt khái niệm, không có khó khăn đặc biệt nào khi thiết kế các tệp nguồn C để chúng cũng có thể được biên dịch giống như với C ++. Thực sự có thể có một số lợi thế đáng kể để làm điều này. Ví dụ, khi viết mã cho một hệ thống nhúng, đôi khi rất hữu ích để có thể kiểm tra mã trên môi trường PC được lưu trữ. Nếu mã biên dịch rõ ràng là C ++, thì có thể có một câu lệnh như "MOTOR_ENABLE = 1;" ghi vào bit I / O dễ bay hơi trên hệ thống nhúng (được biên dịch là C), nhưng kích hoạt logic mô phỏng trên PC (biên dịch thành C ++). Có lẽ cũng có thể thiết kế một loại C ++ trên PC, nó sẽ hoạt động theo cách một uint16_t hoạt động trên các hệ thống nhúng nhỏ hơn (vì vậy, ví dụ như đã cho u16 x=65533;, một trình biên dịch sẽ phải xem xét giá trị củax*xnhư chín, thay vì có quyền tự do làm bất cứ điều gì nó muốn), mặc dù chưa có trình giả lập nào của tôi đưa vào điều đó [một phần vì các trình biên dịch C ++ mà tôi đã sử dụng chưa làm bất cứ điều gì kỳ quặc trong những trường hợp như vậy].

Thật không may, các lập trình viên C và lập trình viên C ++ có đủ ác cảm với nhau mà các ngôn ngữ, trong nhiều năm qua, đã phát triển theo những cách tương thích. Trong khi C89 cố gắng điều chỉnh một số tính năng hữu ích hơn của C ++ (như nguyên mẫu hàm), một thái độ dường như đã xuất hiện rằng các lập trình viên muốn bất kỳ tính năng nào của C ++ nên sử dụng C ++, bỏ qua thực tế là có nhiều tình huống sẽ xảy ra Rất hữu ích để có thể sử dụng một số tính năng của C ++ (ví dụ: khả năng quá tải các chức năng với liên kết nội tuyến tĩnh hoặc tĩnh mà không phải chấp nhận chi phí liên quan đến các tính năng khác mà người ta không cần (ví dụ: xáo trộn tên liên quan đến xuất khẩu chức năng quá tải).

Trong khi giao điểm của C89 và C ++ 98 là ngôn ngữ hoàn toàn khả thi, siêu ngôn ngữ có thể sử dụng được của các phiên bản C sau này có thể bị thu hẹp thay vì phát triển (nhờ những thứ như Quy tắc bí danh nghiêm ngặt) và xu hướng ủng hộ gia tăng vết nứt.