Là C ++ hiện đại ngày càng trở nên thịnh hành? [đóng cửa]

Khi tôi mới học C ++ 6-7 năm trước, những gì tôi học được về cơ bản là "C với các lớp học". std::vectorchắc chắn là một chủ đề nâng cao, một cái gì đó bạn có thể tìm hiểu nếu bạn thực sự muốn. Và chắc chắn không có ai nói với tôi rằng các tàu khu trục có thể được khai thác để giúp quản lý bộ nhớ. Ngày nay, ở mọi nơi tôi nhìn thấy tôi đều thấy RAII và SFINAE và STL và Boost và, tốt, Modern C ++. Ngay cả những người mới bắt đầu với ngôn ngữ dường như được dạy những khái niệm này gần như từ ngày 1.

Câu hỏi của tôi là, điều này đơn giản là vì tôi chỉ thấy "tốt nhất", nghĩa là các câu hỏi ở đây trên SO và trên các trang lập trình khác có xu hướng thu hút người mới bắt đầu (gamedev.net), hoặc đây thực sự là đại diện của Cộng đồng C ++ nói chung?

C ++ hiện đại có thực sự trở thành mặc định? Thay vì là một điều thú vị mà các chuyên gia viết về, liệu nó có trở thành "cách thức của C ++" không? Hay tôi chỉ không thể thấy hàng ngàn người vẫn học "C với các lớp" và viết các mảng động của riêng họ thay vì sử dụng std::vectorvà quản lý bộ nhớ bằng cách gọi thủ công mới / xóa từ mã cấp cao nhất của họ?

Nhiều như tôi muốn tin, có vẻ khó tin nếu cộng đồng C ++ nói chung đã phát triển rất nhiều trong một vài năm về cơ bản. Kinh nghiệm và ấn tượng của bạn là gì?

(từ chối trách nhiệm: Một người không quen thuộc với C ++ có thể hiểu sai tiêu đề khi hỏi liệu C ++ có được phổ biến so với các ngôn ngữ khác hay không. Đó không phải là câu hỏi của tôi. Thiết kế C ++ hiện đại: Các mẫu thiết kế và lập trình chung được áp dụng "và tôi chỉ quan tâm đến điều này so với" C ++ cũ ". Vì vậy, không cần phải nói với tôi rằng thời gian của C ++ đã qua và tất cả chúng ta nên sử dụng Python;))

Đây là cách tôi nghĩ rằng mọi thứ đã phát triển.

Thế hệ lập trình viên C ++ đầu tiên là lập trình viên C, trên thực tế họ sử dụng C ++ như C với các lớp. Thêm vào đó, STL chưa được đặt ra, vì vậy đó chính là C ++.

Khi STL ra đời, những thứ tiên tiến đó, nhưng hầu hết mọi người viết sách, tập hợp các chương trình giảng dạy và các lớp giảng dạy đã học C trước, sau đó là công cụ C ++ bổ sung, vì vậy thế hệ thứ hai đã học từ quan điểm đó. Như một câu trả lời khác đã lưu ý, nếu bạn thoải mái viết thường xuyên cho các vòng lặp, việc thay đổi sử dụng std::for_eachsẽ không mua cho bạn nhiều ngoại trừ cảm giác mờ nhạt ấm áp rằng bạn đang làm mọi thứ theo cách "hiện đại".

Bây giờ, chúng tôi có những người hướng dẫn và người viết sách đã sử dụng toàn bộ C ++ và nhận hướng dẫn của họ từ quan điểm đó, chẳng hạn như sách tăng tốc C ++ của Koenig & Moo và sách giáo khoa mới của Stroustrup. Vì vậy, chúng ta không học char*sau đó std::strings.

Đó là một bài học thú vị về việc phải mất bao lâu để thay thế các phương pháp "di sản", đặc biệt là khi chúng có hồ sơ theo dõi hiệu quả.

Hoàn toàn đồng ý. Đối với tôi nếu bạn không lập trình C ++ theo kiểu "Modern C ++" như bạn thuật ngữ, thì không có điểm nào sử dụng C ++! Bạn cũng có thể chỉ sử dụng C. "Modern C ++" nên là cách duy nhất C ++ được lập trình theo ý kiến ​​của tôi và tôi hy vọng rằng tất cả những ai sử dụng C ++ và đã lập trình theo kiểu "Hiện đại" này sẽ đồng ý với tôi. Trên thực tế, tôi luôn bị sốc hoàn toàn khi nghe về một lập trình viên C ++, người không biết gì về những thứ như auto_ptr hoặc ptr_vector. Theo như tôi quan tâm, những ý tưởng đó là cơ bản và cơ bản cho C ++, và vì vậy tôi không thể tưởng tượng nó theo bất kỳ cách nào khác.

Trong thời của Windows 3.1, C là tiêu chuẩn. Khi C ++ tấn công thị trường nhà phát triển và sau đó trở thành tiêu chuẩn ANSI, đó là độ hot mới. Nó phổ biến từ viết tắt OOP và một số mẫu thiết kế cơ bản sử dụng đa hình.

Giờ đây, với sự chấp nhận lớn hơn đối với các nền tảng được quản lý theo rào cản thấp, như C # /. NET, có ít lý do hơn để sử dụng C ++. Rất nhiều cơ sở của nhà phát triển sẽ có một sự lựa chọn và hãy trung thực: C ++ là một con gấu để học hỏi cho người mới. Với C #, bạn có thể chạy với nó.

Điều đó thực sự chỉ còn lại các nền tảng CẦN C ++ và các nhà truyền giáo C ++ khó tính tiếp tục thực hành nghệ thuật. Đây là cộng đồng cần và muốn tất cả các lớp trừu tượng được coi là "Modern C ++".

Vì vậy, có, tôi tin rằng "Modern C ++", như bạn nói, đang trở nên phổ biến hơn. Mặc dù, nó phổ biến với một đối tượng khác hơn là đã sử dụng nó trong quá khứ.

Tôi là một trong số những người đã học cách làm việc với STL và nghe nhiều về RAII và thực hành lập trình C ++ tốt từ ngày 1. Có vẻ như một số cuốn sách được khuyên dùng nhất để học C ++ ngày nay (như Gia tốc C ++ và sê-ri C ++ hiệu quả ) tập trung vào việc sử dụng các công cụ STL thay vì triển khai công cụ của riêng bạn và cũng đưa ra nhiều "quy tắc" để lập trình hiệu quả (hoặc "hiện đại").

Nhưng nói chuyện với bạn bè tôi cũng lưu ý rằng một số công ty vẫn làm việc với "C with Classes" chứ không phải "Modern C ++". Có thể văn hóa được đề xuất bởi các tác giả và người dùng của "Modern C ++" sẽ thắng thế một ngày nào đó :)

Tôi nghĩ rằng bạn vừa có một trải nghiệm tồi tệ bắt đầu.

Bạn cần có cho mình những cuốn sách C ++ hiệu quả của Scott Meyers . Tôi bắt đầu sử dụng C ++ trong cơn giận dữ vào năm 1999, trưởng nhóm của tôi đã cho tôi ngồi và đọc C ++ hiệu quả và C ++ hiệu quả hơn trước khi tôi được phép kiểm tra BẤT K code mã nào.

Hầu hết lời khuyên của anh ấy là về dòng chữ "Đừng sử dụng tính năng này , nhưng nếu bạn phải, hãy ghi nhớ điều này "

Nếu bạn làm theo lời khuyên của anh ấy, bạn sẽ viết C ++ tốt hoặc "Hiện đại".

Anh ấy cũng có một cuốn sách về STL, nhưng tôi chưa đọc.

Trong các công việc C ++ của mình, tôi đã tìm thấy các tính năng hiện đại ngày càng được sử dụng và nhiều người hỏi tôi về chúng trong các cuộc phỏng vấn và phỏng vấn qua điện thoại. Theo như tôi có thể nói, họ đang bắt kịp.

Tôi đã học C ++ ban đầu giống như C với Classes; mặc dù ngôn ngữ đã tiến xa hơn thế, những cuốn sách tôi đọc và những người tôi làm việc cùng đã bị mắc kẹt trong "C ++ cũ". RAII một cái gì đó mọi người sẽ nghĩ về, thay vì tự động làm, và tôi nhớ đọc một số bài viết đầu tiên về các vấn đề an toàn ngoại lệ.

Như đã chỉ ra, bây giờ có sách mới. Nhiều trong số những cái cũ vẫn còn có liên quan, nhưng dường như chúng ngày càng đầy lý giải tại sao rõ ràng ý tưởng xấu là xấu. (Tương tự như vậy, thật khó để độc giả hiện đại hiểu được những ý tưởng của Freud mang tính cách mạng về tâm trí vô thức như thế nào, vì giờ đây nó là trí tuệ thông thường.)

Stroustrup vừa ra mắt với một cuốn sách giáo khoa, Lập trình: Nguyên tắc và Thực hành Sử dụng C ++ . Tôi đã mua nó bởi vì tôi chưa học được những thứ hay từ một cuốn sách của Stroustrup, nhưng đã không vượt qua được vài chương đầu tiên. Cho đến nay, tất cả những gì tôi có thể nói là tôi tán thành cách anh ấy bắt đầu, và ít nhất đó là một giới thiệu tốt về cách sử dụng C ++.

Trong khi thực hiện dự án mà tôi hiện đang tham gia, có rất nhiều mã C ++ đã phát triển trong một khoảng thời gian đáng kể (hơn 10 năm nay). Sự tiến hóa mà bạn nói đến có thể thấy rõ ở đó: mã cũ hơn thường là "C với các lớp" - các con trỏ thô, (bao gồm các thông số tùy chỉnh để quản lý các điều khiển, v.v.), các hàm lớp và các mẫu lớp được khái quát hóa, v.v. Hầu hết các kỹ thuật mã hóa "C với các lớp" truyền thống, chẳng hạn như các con trỏ chưa đóng gói thô với quản lý trọn đời thủ công, rất được tán thành trong các đánh giá mã ngày nay. Đánh giá bằng cách này, có vẻ như quan sát của bạn là chính xác.char* chuỗi và sử dụng các hàm C liên quan, mảng, v.v. mã mới hơn sử dụng con trỏ thông minh ATL và như vậy để quản lý tài nguyên, nhưng vẫn dính vào các vòng lặp được mã hóa bằng tay hầu hết thời gian và iterator là một cảnh hiếm thấy; và cái mới nhất chứa đầy các thùng chứa STL, thuật toán,shared_ptr

Sự phát triển gần đây nhất dường như là một mốt nhất thời cho C ++ 0x lambdas - có một mặt tích cực ở chỗ nó cũng nghiêng sự cân bằng trong việc sử dụng các thuật toán tiêu chuẩn trên các vòng lặp được mã hóa bằng tay, vì bây giờ bạn có thể có tất cả mã của mình với thuật toán là tốt.

Tôi sẽ không nói rằng std :: vector đủ điều kiện là "hiện đại" ngày nay. Nó thực sự là cơ bản.

Nói chung, ấn tượng của tôi là mọi người đã đạt được một số kinh nghiệm với phong cách C ++ hiện đại và tỉnh táo lên một chút. Chỉ cần lấy một ví dụ đơn giản, STL for_each rất thú vị nhưng trong thực tế, nó không thêm nhiều giá trị khủng khiếp vào một vòng lặp C đơn giản. Khó gỡ lỗi hơn và đôi khi không cung cấp hiệu suất tốt nhất. Ngoài ra, các cấu trúc để lập trình chức năng trong STL hiện tại nhìn chung rất cồng kềnh, đặc biệt nếu bạn có kinh nghiệm từ một ngôn ngữ chức năng thực sự như ML.

Theo kinh nghiệm của tôi (Đại học Tây Ban Nha), thật không may, tiêu chuẩn là không xem xét ngôn ngữ trong chính nó. Họ sử dụng các ngôn ngữ dễ nhất để dạy lập trình (ví dụ Java), vì nó được cho là dễ dàng cho giáo viên và học sinh, và sau đó họ sử dụng C cho các lớp OS và như vậy.

C ++ được giới thiệu rất nhẹ (ở mọi mức độ tại bất kỳ khóa học nào), chỉ để cung cấp C với các lớp. Họ không được tăng hoặc thậm chí STL. Tôi nghĩ rằng theo kịp tất cả các đặc điểm và cách suy nghĩ của C ++ là tốn kém cho cả giáo viên và học sinh. Có bao nhiêu lập trình viên C ++ ở đây biết đủ tất cả các thư viện Boost để sử dụng chúng để đưa ra giải pháp tốt hơn hoặc thiết kế nó? Người ta phải có hứng thú với việc theo kịp tất cả các thư viện và thành ngữ mới.

Tuy nhiên, như tôi đã nói, dường như việc lập trình nói chung (và ngôn ngữ lập trình nói riêng) không quá nghiêm trọng, vì dường như đó là một sự phân công tạm thời khi họ bắt đầu một công việc, sau đó quên cách lập trình khi họ đi lên cây doanh nghiệp. Nhiều doanh nghiệp ở đây, và chính Đại học, có cảm giác rằng lập trình có thể được thực hiện bởi bất kỳ ai.

Nếu bạn theo triết lý này, thì đối với hầu hết mọi người tôi biết, C ++ sẽ luôn là "C với các lớp".

Trân trọng,

Theo kinh nghiệm của tôi, nó phụ thuộc rất nhiều vào độ tuổi của sản phẩm / dự án phần mềm. Hầu hết các dự án mới mà tôi biết đều sử dụng C ++ hiện đại (RAII, STL, Boost). Tuy nhiên, có nhiều dự án C ++ đã hơn 10 năm tuổi và bạn không thấy C ++ hiện đại ở đó.

Ngoài ra, hãy nhớ rằng một số triển khai STL phổ biến nhất đã bị phá vỡ khá nhiều cho đến khoảng 5 năm trước (MSVC <7.0 và GNU <3.00)

Tôi nghĩ rào cản lớn nhất tôi gặp phải là hỗ trợ toolchain, đặc biệt là các dự án đa nền tảng. Cho đến một vài năm trước, người ta thường thấy các ghi chú xây dựng nói rằng "nền tảng x cần STLport để hoạt động vì trình biên dịch của họ đã bị hỏng". Ngay cả bây giờ, tôi thấy các vấn đề với những người đang cố gắng sử dụng nhiều phụ thuộc của bên thứ ba gắn liền với các phiên bản BOOST khác nhau. Điều này làm cho việc liên kết là không thể, có nghĩa là bạn phải quay lại và xây dựng lại deps của bạn từ đầu.

Bây giờ mọi người đã ngừng sử dụng MSVC ++ 6, mớ hỗn độn STLport đang ở phía sau chúng ta. Nhưng ngay khi TR1 ra khỏi cửa, chúng tôi sẽ quay lại "phiên bản nào của môi trường hỗ trợ và làm cho đúng" và một lần nữa điều này sẽ làm chậm việc áp dụng.

Tôi làm việc trong một dự án bắt đầu từ C (không phải C ++) vào năm 1992. Triển khai các thực tiễn hiện đại trên cơ sở mã di sản là không thể. Tương tự như vậy, tôi làm việc trên một dự án khác gần với ngôn ngữ C ++ hơn.

Nhiều đội tôi đã tham gia và nghe nói về việc xem xét vấn đề lớn "chúng ta có đang sử dụng ngoại lệ không?" câu hỏi Đây là mã cho "chúng ta có đang sử dụng C ++ hiện đại không?"

Khi bạn không sử dụng ngoại lệ, bạn không được sử dụng toàn bộ sức mạnh của ngôn ngữ và thư viện của ngôn ngữ đó.

Nhưng nhiều cơ sở mã cũ không có ngoại lệ và được cho là rất khó để ngoại lệ cho một cơ sở mã không mong đợi chúng hoặc vào một nhóm không biết cách sử dụng chúng, vì vậy câu trả lời trong những trường hợp như vậy là thường là 'không.'

Theo kinh nghiệm của tôi, C ++ hiện đại cần một người đam mê nó trong nhóm, người không thể chịu được bất cứ điều gì ít hơn, để thúc đẩy nó. Nó cũng cần phải vượt qua sự phản đối của những người muốn nó giống như mã kế thừa.

Mặc dù tôi không nghĩ rằng các cơ sở mã C ++ cũ sẽ biến mất rất nhanh, tôi tin rằng có nhiều người đam mê trên thế giới hơn so với năm năm trước. Họ phải đối mặt với trận chiến khó khăn tương tự mà họ phải đối mặt năm năm trước, nhưng họ có nhiều khả năng tìm thấy những linh hồn tốt bụng.

Trước khi trả lời một câu hỏi như vậy, bạn phải đồng ý về "Hiện đại" là gì. Điều này không có khả năng xảy ra, vì "Hiện đại" là một từ được định nghĩa kém và có nghĩa là những thứ khác nhau cho những người khác nhau. Tiêu đề của cuốn sách của Alexandrescu (Thiết kế C ++ hiện đại) cũng không thực sự hữu ích, vì phần lớn nó là một cuốn sách về Siêu dữ liệu mẫu, là một lĩnh vực cụ thể của C ++ nhưng không có nghĩa là duy nhất.

Đối với tôi, "Modern C ++"! = "Lập trình siêu mẫu". Tôi có thể nói các tính năng của C ++ trên đầu C sẽ thuộc các loại sau:

• Các lớp học (Người xây dựng, Người phá hủy, RAII, Đúc động và RTTI)
• Ngoại lệ
• Người giới thiệu
• Cấu trúc dữ liệu và thuật toán trong thư viện chuẩn (STL)
• iostreams
• Các lớp đơn giản và các mẫu hàm
• Lập trình siêu mẫu

Không ai trong số này đặc biệt hiện đại, vì tất cả chúng đã có khoảng gần 10 năm trở lên. Hầu hết các tính năng này đều hữu ích và sẽ cho phép bạn có năng suất cao hơn C thẳng cho nhiều trường hợp sử dụng. Một lập trình viên giỏi nên và sẽ sử dụng tất cả chúng trong một dự án có quy mô khá, nhưng một trong những điều này không giống như những điều khác:

Siêu lập trình mẫu.

Câu trả lời ngắn cho siêu lập trình mẫu chỉ là nói không. Thật không may cho một số người, nó đồng nghĩa với "Lập trình C ++ hiện đại", do cuốn sách, nhưng cuối cùng nó tạo ra nhiều vấn đề hơn nó giải quyết. Trừ khi C ++ phát triển các cơ chế lập trình chung tốt hơn như phản chiếu, nó sẽ không phù hợp với lập trình chung và các ngôn ngữ cấp cao hơn như Python sẽ phù hợp hơn cho các trường hợp sử dụng đó. Vì lý do đó và nhiều lý do khác, hãy xem C ++ FQA

Cuốn sách tốt nhất để học C ++. "Gia tốc C ++" của Koenig & Moo, dạy những gì bạn mô tả là C ++ hiện đại, vì vậy tôi đoán hầu hết mọi người ngày nay đang sử dụng nó. Đối với những người trong chúng ta đã sử dụng C ++ trong một thời gian dài (kể từ giữa những năm 80 trong trường hợp của tôi), C ++ hiện đại là một cứu cánh tuyệt vời từ các nhiệm vụ tẻ nhạt của việc viết các mảng, chuỗi, bảng băm của riêng chúng tôi (lặp lại quảng cáo).

Tôi đã xem C ++ Jobs trên thực tế và các thư viện "hiện đại" ngày càng được sử dụng nhiều hơn trong các mô tả công việc, MFC là một thư viện c ++ "kiểu cũ" ít được sử dụng.

Việc chuẩn hóa ngôn ngữ vào cuối những năm 1990 là bước đầu tiên, nó cho phép các nhà sản xuất trình biên dịch tập trung vào bộ tính năng "tiêu chuẩn", cũng cho phép ngôn ngữ sửa một số cạnh thô, xuất hiện quá trình chuẩn hóa.

Điều này đến lượt nó cho phép phát triển các khung dựa trên các tính năng tiêu chuẩn của ngôn ngữ và không dựa trên các tính năng được cung cấp bởi một trình biên dịch cụ thể. Thư viện Boost đáng chú ý về vấn đề này. Ngoài ra, điều này cho phép phát triển mới dựa trên công việc trước đó, do đó đưa ra các giải pháp khả thi cho các vấn đề phức tạp hơn.

Một thay đổi đáng chú ý ở đây là cách các khung công tác trước đây dựa trên khái niệm các lớp cơ sở và các lớp dẫn xuất (một tính năng thời gian chạy). Nhưng hiện nay, hầu hết các tính năng nâng cao thường dựa rất nhiều vào các mẫu "đệ quy" (tính năng biên dịch thời gian).

STL có những ưu và nhược điểm nhưng nó vẫn vượt qua thử thách của thời gian, nếu bạn muốn thứ gì đó hoạt động và đơn giản thì STL chắc chắn có thứ gì đó giúp bạn bắt đầu. Không có điểm nào trong việc phát minh lại bánh xe (trừ khi vì lý do mô phạm).

Phần cứng máy tính cũng đã có những bước nhảy vọt từ những năm 1990, sau đó bộ nhớ và CPU không còn là một hạn chế đối với trình biên dịch. Vì vậy, hầu hết các tối ưu hóa lý thuyết từ sách là có thể.

Các bước tiếp theo của ngôn ngữ là sự hỗ trợ của lập trình đa lõi, là một phần của nỗ lực tiêu chuẩn 0x.

Có và không. Chắc chắn đối với các dự án mới, nó ngày càng phổ biến. Tuy nhiên, vẫn còn những rào cản đối với việc áp dụng là thiết thực, không mang tính chính trị, mà những người khác chưa đề cập. Có rất nhiều thư viện C ++ thương mại sử dụng ABI từ các trình biên dịch cổ xưa không hỗ trợ đúng các tính năng được thấy trong Modern C ++ và rất nhiều công ty dựa vào các thư viện này. Sun Studio trên Solaris chẳng hạn không thể hoạt động với Boost mà không sử dụng STLport, nhưng bất kỳ thư viện thương mại bên thứ 3 nào bạn muốn sử dụng đều yêu cầu phiên bản STL của Sun. Câu chuyện tương tự với GCC 2.95 và Redhat Enterprise Linux.

Thật đáng tiếc khi có ít nỗ lực để làm cho c ++ ổn định hơn. Hệ thống cảnh báo được đưa ra, nhưng nó không phát triển nhiều. Thậm chí còn dễ dàng tự bắn vào chân mình hơn so với 10 năm trước. Không biết tại sao, nhưng c ++ vẫn là ngôn ngữ yêu thích của tôi. :)