Sử dụng C ++ nhưng không sử dụng các tính năng cụ thể của ngôn ngữ, có nên chuyển sang C?

Tôi đang phát triển trình giả lập NES như một sở thích, trong thời gian rảnh. Tôi sử dụng C ++ vì đây là ngôn ngữ tôi sử dụng chủ yếu, biết hầu hết và thích phần lớn.

Nhưng bây giờ khi tôi thực hiện một số tiến bộ trong dự án, tôi nhận ra rằng tôi không sử dụng hầu hết các tính năng cụ thể của C ++ và có thể đã thực hiện nó trong C đơn giản và nhận được kết quả tương tự. Tôi không sử dụng các mẫu, quá tải toán tử, đa hình, kế thừa. Vậy bạn sẽ nói gì? Tôi nên ở lại C ++ hay viết lại bằng C?

Tôi sẽ không làm điều này để đạt được hiệu suất, nó có thể là một tác dụng phụ, nhưng ý tưởng là tại sao tôi nên sử dụng C ++ nếu tôi không cần nó?

Các tính năng duy nhất của C ++ tôi đang sử dụng là các lớp để đóng gói dữ liệu và phương thức, nhưng điều đó cũng có thể được thực hiện với các cấu trúc và chức năng, tôi đang sử dụng mới và xóa, nhưng cũng có thể sử dụng malloc và miễn phí, và tôi sử dụng tính kế thừa chỉ cho các cuộc gọi lại, có thể đạt được với các con trỏ tới các hàm.

Hãy nhớ rằng, đó là một dự án sở thích, tôi không có thời hạn, vì vậy thời gian và công việc đòi hỏi phải viết lại không phải là một vấn đề, cũng có thể rất vui. Vậy, câu hỏi là C hay C ++?

Bạn không sử dụng nó bây giờ, nhưng lần sau khi bạn bị rò rỉ bộ nhớ hoặc có được một đôi xóa, bạn sẽ được xin trở lại std::vector<T>, std::unique_ptr<T, Del>và std::shared_ptr<T>, có thể giải quyết những vấn đề easily- gần trivially. Cuối cùng, đó là những gì xảy ra với tất cả những người sử dụng C trên C ++ và những người thông minh hơn chỉ chờ đợi các lỗi xuất hiện trước khi chuyển qua.

Mã sử ​​dụng newvà deletetrực tiếp không thực sự thuộc về C ++, nó thuộc loại nửa nhà mà chúng ta gọi là "C với các lớp". Đó là nơi ngôn ngữ được sử dụng vào khoảng năm 1985. Nó không đặc biệt giống với C ++, vào khoảng năm 2011. Trong mọi khả năng, bất cứ nơi nào bạn học C ++ chỉ đơn giản là không dạy nó rất tốt - một điều không may là khá phổ biến - và với một nền giáo dục tốt hơn, bạn sẽ tìm sử dụng các tính năng này.

Cụ thể, như tôi đã liệt kê ở trên, các cấu trúc dữ liệu chung của C ++ và các lớp quản lý tài nguyên đơn giản là vượt trội về cơ bản so với bất cứ thứ gì C cung cấp. Nếu bạn muốn một mảng được phân bổ động, sau đó sử dụng std::vector<T>. Đó là một trường hợp sử dụng khá phổ biến. Nếu bạn không sử dụng chúng, thì mã của bạn có nguy cơ lỗi rất lớn không cần thiết - đặc biệt là liên quan đến quản lý tài nguyên. C ++ có thể đảm bảo an toàn và sử dụng lại mã theo cách mà C không bao giờ có thể chạm vào.

Tuy nhiên, tôi nghĩ rằng bạn cũng có thể mong đợi quá nhiều. Viết mẫu và quá tải toán tử không phổ biến đối với người tiêu dùng thư viện. Nếu mã của bạn sử dụng std::vector<T>, bạn không cần phải viết một mẫu để thực hiện điều đó. Nếu mã của bạn sử dụng std::string, không ai buộc bạn phải quá tải toán tử. Bạn chỉ phải làm những điều đó để viết std::vector<T> và std::string- nhưng bạn vẫn có thể tận dụng tối đa chúng.

Đa hình / kế thừa cũng chỉ có một trường hợp sử dụng cụ thể. Nếu mã của bạn xảy ra không yêu cầu bạn viết bất kỳ mẫu nào hoặc sử dụng các hàm ảo, thì nó không có, và có các chương trình hoặc phân đoạn chương trình mà bạn không cần phải viết mẫu của riêng mình.

Ngoài ra, không có hiệu suất trong C so với C ++.

Ngay cả khi bạn không sử dụng các tính năng cụ thể của C ++, trình biên dịch C ++ sẽ gặp nhiều vấn đề hơn so với C do hệ thống loại C ++ chặt chẽ hơn.

Tôi sẽ nhìn nó từ hướng khác. Bạn sẽ đạt được bất cứ điều gì bằng cách viết lại mã trong C? Ngay cả trong một dự án hoàn toàn sở thích, có một chi phí liên quan đến việc viết lại như thế. Nếu không có gì khác, thứ mà tôi cho là sẽ được gọi là chi phí cơ hội - tức là, những thứ khác bạn có thể đã làm trong thời gian đó nếu bạn không lãng phí thời gian để viết lại nó trong C.

Điểm mấu chốt: trừ khi bạn nghĩ rằng mã thực sự có khả năng được sử dụng trong một số môi trường nơi quyền truy cập vào C ++ thực sự bị hạn chế (hoặc không tồn tại), thì sẽ rất lãng phí thời gian vô ích. Ít nhất là theo kinh nghiệm của tôi, nó thường vượt xa rất nhanh - nghĩ lại về mã tôi đã viết bằng C ++ phải chuyển đổi thành C, tôi có thể nhớ khá rõ rằng ngay cả trong một vài trường hợp có vẻ như thật là tầm thường, tôi đã sử dụng rất nhiều tính năng dành riêng cho C ++ so với lúc đầu tôi nhận ra. Để có nhiều hy vọng hữu ích, bạn sẽ phải nhắm mục tiêu C89 / 90, trong trường hợp đó, bạn sẽ nhanh chóng được nhắc nhở về những việc như phải xác định tất cả các biến ở đầu một khối thay vì thực sự chúng là gì đã sử dụng.

Nói tóm lại, trừ khi bạn khá chắc chắn viết lại bằng C sẽ mang lại lợi ích thực sự, gần như chắc chắn sẽ có rất nhiều điều tốt hơn để làm.

Như một câu trả lời tổng quát hơn:

Đừng chuyển sang C ++ chỉ vì bạn đang sử dụng một số tính năng độc đáo hơn. Một ngày nào đó bạn có thể cần những tính năng đó, và sẽ chỉ đập đầu vì bạn đang sử dụng C.

Để phát triển sở thích, tôi sẽ xem xét chuyển trở lại ngôn ngữ C. C và C đơn giản có nhiều khả năng được hỗ trợ trên các mô-đun phát triển sở thích nhỏ.

Nhiều câu trả lời ở đây có thể là từ các loại phần mềm chuyên nghiệp. Là người có sở thích, bạn sẽ không được mã hóa liên tục hoặc toàn thời gian. Vì vậy, hãy xem xét ngôn ngữ nào bạn có khả năng nhớ hoặc quên những điều kỳ quặc bên trong, nếu bạn đặt dự án của mình trong một năm và sau đó quay lại và cố gắng đọc mã của bạn sau khi bạn đã bị mã hóa. C ++, có bộ tính năng phong phú hơn, có thể mất nhiều thời gian hơn để có được lại, tùy thuộc vào phong cách mã hóa của bạn.

Thật không dễ để trả lời câu hỏi của bạn, vì chúng tôi không biết liệu bạn đang làm việc trong dự án để cải thiện các kỹ năng cụ thể về ngôn ngữ của bạn (C vs C ++) hay để cải thiện các kỹ năng lập trình khác (thiết kế, giải quyết vấn đề, v.v.).

"Các tính năng duy nhất của C ++ tôi đang sử dụng là các lớp để đóng gói dữ liệu và phương thức, nhưng điều đó có thể được thực hiện tốt với các cấu trúc và chức năng,". Đây không phải là sự thật. structstrong C không hỗ trợ đóng gói và không thể chứa hàm (phương thức) - ít nhất là không sử dụng các kỹ thuật như con trỏ tới hàm. Ngoài ra, các chức năng trong C yếu hơn vì chúng không thể bị quá tải.

"Tôi đang sử dụng mới và xóa, nhưng cũng có thể sử dụng malloc và miễn phí, và tôi đang sử dụng tính kế thừa chỉ cho các cuộc gọi lại, điều này có thể đạt được với các con trỏ tới các chức năng." Như deadmg đã đề cập, sử dụng trực tiếp newvà deletetrong C ++ không được khuyến khích. Ngoài ra, kế thừa IMHO (và GoF) trong OOP chỉ nên được ưu tiên hơn thành phần khi cần đa hình. Và tôi không nghĩ rằng việc đạt được tính đa hình (liên kết muộn) trong C là không quan trọng bằng cách sử dụng các con trỏ tới các hàm.

Ngoài ra, tôi sẽ không thuyết phục bạn rằng C ++ "tốt" hơn C vì đó là vấn đề ưu tiên và nó luôn phụ thuộc vào vấn đề mà bạn đang cố gắng giải quyết (sử dụng các tính năng OOP để phát triển trình giả lập NES của bạn một ý tưởng tốt).

Tôi là một người mới bắt đầu, vì vậy đây là 2 bit của tôi.

Tôi đang học C và C ++ tại Wibit.net với một số băng video cơ bản đẹp, có lẽ chúng có thể giúp bạn rất nhiều để có cái nhìn tổng quan về "tình huống" (không phải quảng cáo!)

Tôi khuyên bạn nên đổi sang C, chỉ để học, vì bạn là người có sở thích, đây sẽ là một niềm vui chứ không phải là vấn đề.

Tôi tư vấn thêm. Làm điều đó bằng cả hai ngôn ngữ. So sánh cách và giải pháp bạn sẽ tìm và sử dụng. Tôi chắc chắn rằng nó sẽ không "dễ dàng" như bạn mong đợi ... nhưng chắc chắn bạn sẽ học được rất nhiều!

Dưới đây là ưu và nhược điểm của C ++ so với C:

1. Di chuyển đến C sẽ giúp dễ dàng hơn trong tập hợp con C ++ đã chọn, bởi vì trình biên dịch sẽ báo lỗi khi bạn đi ra ngoài nó. Nếu vấn đề chính là ở lại trong tập hợp con quyết định, nên chọn phương án này. (tại sao chúng tôi không có hỗ trợ trình biên dịch cho việc này?)
2. Một khi bạn có thể ở trong tập hợp tính năng c ++ đã chọn, thì điều tiếp theo là cố gắng thay đổi tập hợp con để loại bỏ các quy ước xấu phá vỡ mã. Điều này đòi hỏi phải sử dụng toàn bộ c ++.
3. Khi bạn có cả "nằm trong tập hợp con" và "đó là tập hợp con tốt", sau đó di chuyển ra ngoài các tính năng của c ++ và bắt đầu suy nghĩ về các yêu cầu.