lập trình chung, mức độ thường xuyên được sử dụng trong công nghiệp


11

Tôi làm lập trình trong một môi trường học thuật vào lúc này, vì vậy tôi có thể sử dụng bất cứ thứ gì tôi muốn. Tôi đang sử dụng thư viện biểu đồ boost cho một số thứ và tôi tự hỏi liệu nỗ lực đầu tư vào việc hiểu GP sâu hơn có đáng hay không.

Tôi tò mò - lập trình chung (GP) được sử dụng nhiều trong công nghiệp? Tôi đoán là hầu hết các lập trình viên đều thoải mái hơn với OOP hoặc đang sử dụng các ngôn ngữ không nhấn mạnh hoặc hỗ trợ GP, do đó, ngoài việc gọi các cấu trúc / chức năng dữ liệu STL trong C ++, ấn tượng của tôi là GP không được sử dụng thường xuyên trong thực tế. Nhưng, ở ngoài ngành công nghiệp vào lúc này, thật tuyệt khi nghe các học viên về điều này.

(khi tôi viết bài này, tôi thấy rằng lập trình chung thậm chí không phải là một thẻ hợp lệ!)


Phân phối thẻ trên StackOverflow có lẽ hữu ích hơn nhiều khi là bằng chứng thống kê so với bằng chứng ở đây. Xem stackoverflow.com/questions/tagged/generic-programming , stackoverflow.com/questions/tagged/generics
Péter Török

Câu trả lời:


7

Tôi tò mò - lập trình chung (GP) được sử dụng nhiều trong công nghiệp?

Nó thực sự phụ thuộc rộng rãi vào bối cảnh của nhóm và dự án.

Ví dụ, trong các trò chơi video, thường thì mã là "đơn giản nhất" có thể (và thậm chí đôi khi quá đơn giản) nhưng trong các kiến ​​trúc lớn. Đó là bởi vì các nhà phát triển trò chơi có rất nhiều vấn đề cần khắc phục và không muốn bận tâm đến lập trình meta (đó là một ngôn ngữ rất trừu tượng và khó nắm bắt trong C ++).

Đồng thời, việc sử dụng cơ bản các mẫu là phổ biến ngay cả trong các cửa hàng đó và bạn có thể thấy một số tối ưu hóa dựa trên mẫu trong một số chức năng rất cụ thể của một số công cụ.

Nhưng trong trò chơi dev, hầu hết mọi người sẽ tránh mọi chương trình siêu hình.

Bây giờ, ở một khía cạnh cực đoan khác, một số ứng dụng xử lý thực sự phức tạp hoặc nặng, không phổ biến, đòi hỏi một số loại siêu lập trình nặng vì yêu cầu về hiệu năng và tính linh hoạt (tại thời gian biên dịch) không phổ biến. Tôi đang làm việc trong một ngay bây giờ.

Nó không phổ biến nhưng nó tồn tại và một số miền thích hợp (trong một số bối cảnh nhúng khoa học hoặc số giòn) không yêu cầu mọi người biết nhiều về siêu lập trình hoặc muốn tìm hiểu.

Ở giữa, hầu hết mọi người sẽ chỉ sử dụng siêu lập trình như là "khách hàng", chứ không phải là "nhà thiết kế". Hầu hết các mã lập trình meta được gói trong các thư viện vì các thư viện là công cụ cho mã và điều gì tốt hơn một thư viện có thể thích ứng với các loại tùy chỉnh mà bạn đã làm việc cho đến bây giờ?

Boost (http://boost.org) là một tập hợp các thư viện, một số được tạo ra bằng ma thuật đen siêu lập trình nặng và được sử dụng trong rất nhiều cửa hàng C ++ dưới dạng "STL ++", một phần mở rộng của STL (và nó là). Không phải mọi cửa hàng đều sử dụng nó vì một số lý do, như khả năng tương thích trình biên dịch (một số thư viện tăng cường có thể khiến trình biên dịch của bạn xin lỗi mỗi khi anh ta làm tổn thương cảm giác của bạn ...) và thường xuyên hơn vì một số nhà phát triển không thể hiểu được làm thế nào một công cụ hoạt động bên trong (cố gắng hiểu Boost.Sprite ...)

Bất kể công ty nào bạn sẽ làm việc, một số sẽ sử dụng mô hình này, một số sẽ ít hoặc không hoàn toàn hoặc thậm chí cấm họ.

Không có sự đồng thuận vì không ai có cùng nhu cầu, bối cảnh hoặc nhóm.

Nhưng rõ ràng, nó được sử dụng. Có thể hỏi ai sử dụng boost trong danh sách gửi thư của họ để có nhiều ví dụ thực tế hơn?


1
+1 cho khách hàng so với nhà thiết kế. Theo kinh nghiệm của tôi, ít nhà phát triển đủ hiểu việc triển khai của họ rằng việc tạo mã chung mới trong một ứng dụng trừ khi nó tạo ra sự cải thiện lớn về khả năng bảo trì. Các thư viện được thiết kế để tái sử dụng rộng rãi nằm trong điều kiện đó thường xuyên hơn nhiều so với các ứng dụng riêng lẻ.
Karl Bielefeldt

Cảm ơn các câu trả lời chi tiết. Tôi là một fan hâm mộ của Boost và xem xét liệu có nên đào sâu vào BGL hay không, đòi hỏi kiến ​​thức GP nhiều hơn so với các thư viện Boost khác là điều khiến tôi phải hỏi điều này. Nhận xét của bạn về thế giới phát triển trò chơi khá hấp dẫn. Tôi ngạc nhiên trước những kỳ công phát triển của các trò chơi hiện đại và thật thú vị khi biết rằng có lẽ chúng được cách ly khỏi các phương pháp lập trình mới hơn là đi đầu trong chúng.
bd1

Vâng, các nhà phát triển trò chơi đang quản lý mức độ phức tạp cao chỉ bằng cách phải kiến ​​trúc các khái niệm trò chơi. Thêm các hướng dẫn meta chỉ làm phức tạp mọi thứ để nó phải thực sự hợp lý. Một điều khác là rất nhiều nhà phát triển trò chơi hoạt động trên các hệ máy console có phần cứng rất cụ thể với các trình biên dịch rất cụ thể không cho phép mọi thứ tăng cường cố gắng làm (ví dụ: không có ngoại lệ hoặc không có nhiều kế thừa hoặc không hoạt động chính xác từ tài liệu của trình biên dịch (câu chuyện có thật)). Vì vậy, có những lý do tốt.
Klaim

5

Tôi tò mò - lập trình chung (GP) được sử dụng nhiều trong công nghiệp?

Lập trình chung, về mặt học thuật gọi là đa hình tham số , thường được sử dụng trong các lĩnh vực. Tại công ty của tôi, chúng tôi sử dụng nó chủ yếu để xây dựng các trình soạn thảo độc lập cho dữ liệu, bất kể loại nào. Bạn không cần nó thường xuyên như các tính năng khác, nhưng đó chắc chắn là một tính năng tôi không muốn bỏ lỡ. Bạn sử dụng nó khi một hành vi phù hợp với một số lượng lớn các loại. Đó là một dấu hiệu rõ ràng rằng bạn cần thuốc generic khi bạn thấy mình viết cùng một mã nhiều lần cho các loại khác nhau.

Tôi đoán là hầu hết các lập trình viên đều thoải mái hơn với OOP hoặc đang sử dụng các ngôn ngữ không nhấn mạnh hoặc hỗ trợ GP, do đó, ngoài việc gọi các cấu trúc / chức năng dữ liệu STL trong C ++, ấn tượng của tôi là GP không được sử dụng thường xuyên trong thực tế.

Ít nhất theo kinh nghiệm của tôi, quan điểm của bạn là sai. OOP và lập trình chung không loại trừ lẫn nhau. Trong thực tế, bạn nên sử dụng các hiệu ứng tổng hợp của việc kết hợp chúng. Giống như tôi đã nói trước đây, lý do bạn không thấy nó xuất hiện thường xuyên như các kỹ thuật khác là vì bạn không cần nó thường xuyên. Nhưng đó là một tính năng mạnh mẽ cần có và giúp bạn giữ mã DRY của mình rất nhiều . Những ngôn ngữ nào không thực sự nhấn mạnh sự hỗ trợ của GP trong lập trình cấp cao? 3 trong 5 ngôn ngữ của 5 mẫu chung / mẫu hỗ trợ của Tiobe . Và PHP được gõ động nên nó không thực sự cần chúng. Vậy thì sao?


quan điểm, tôi không có ý ám chỉ rằng OOP và GP là một hoặc / hoặc sự lựa chọn. Tuy nhiên, nhiều dự án tôi từng thấy dường như hoàn toàn OOP trong Java. Tôi nghĩ rằng các phiên bản gần đây hơn của Java hỗ trợ GP, nhưng phần nào các lập trình viên Java thực sự sử dụng chức năng đó? Như tôi đã nói, tôi không làm việc trong ngành công nghiệp và quan điểm của tôi có thể bị sai lệch, đó là lý do tại sao tôi đặt câu hỏi.
bd1

@ bd1: Các ứng dụng cũ hơn được viết trước Java chung chung hoặc trước một bộ công cụ cụ thể hỗ trợ phiên bản Java đó sẽ không có chung chung và các nhà phát triển có thể tiếp tục tránh các khái quát về dự án cụ thể đó, để giữ cho mã phù hợp. Tôi đã thấy điều đó, và nó thay đổi theo dự án và bởi các nhà phát triển. Bất kỳ dự án nào tôi thấy đã được bắt đầu sau khi hỗ trợ cho các tổng quát Java đều có xu hướng sử dụng chúng thường xuyên, khi thích hợp.
Thất vọngWithFormsDesigner

@FrustratedWithFormsDesigner: Generics trong Java hoàn toàn khác với các mẫu C ++. Java generic là đường cú pháp tinh khiết 100% và không hỗ trợ lập trình meta.
kevin cline

"OOP và lập trình chung không loại trừ lẫn nhau.": Thật vậy, cả hai đều là dạng đa hình, tương ứng ad-hoc và đa hình tham số. Vì vậy, chúng là hai công cụ khác nhau cho các loại đa hình khác nhau.
Giorgio

4

Các mẫu C ++ được sử dụng rộng rãi cho các công cụ khác với các thùng chứa - ít nhất là trong miền vấn đề của tôi (tài chính định lượng). Tôi thậm chí còn mạo hiểm nói rằng đôi khi nó được sử dụng quá thường xuyên, cho các mục đích mà các hàm ảo cũ đơn giản là đủ (và sẽ không làm tăng thời gian biên dịch quá nhiều).

Mọi người sử dụng nó để tránh sao chép mã và để đạt được đa hình thời gian biên dịch (không có công văn ảo).

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.