Tại sao các nhà phát triển trò chơi C ++ không sử dụng thư viện boost? [đóng cửa]

Vì vậy, nếu bạn dành thời gian xem / trả lời các câu hỏi trên Stack Overflow dưới thẻ C ++, bạn sẽ nhanh chóng nhận thấy rằng mọi người đều sử dụng thư viện boost ; một số người thậm chí còn nói rằng nếu bạn không sử dụng nó, bạn sẽ không viết "C ++" thực sự (tôi không đồng ý, nhưng đó không phải là vấn đề).

Nhưng sau đó là ngành công nghiệp game, vốn nổi tiếng với việc sử dụng C ++ và không sử dụng boost. Tôi không thể không tự hỏi tại sao lại như vậy. Tôi không quan tâm đến việc sử dụng boost vì tôi viết game (bây giờ) như một sở thích và một phần của sở thích đó là thực hiện những gì tôi cần khi tôi có thể và sử dụng các thư viện ngoài lề khi tôi không thể. Nhưng đó là tôi.

Tại sao các nhà phát triển trò chơi, nói chung, sử dụng thư viện boost? Đó là hiệu suất hoặc mối quan tâm bộ nhớ? Phong cách? Thứ gì khác?

Tôi đã định hỏi điều này về stack overflow, nhưng tôi đoán rằng câu hỏi được hỏi tốt hơn ở đây.

BIÊN TẬP :

Tôi nhận ra tôi không thể nói cho tất cả các lập trình viên trò chơi và tôi chưa thấy tất cả các dự án trò chơi, vì vậy tôi không thể nói các nhà phát triển trò chơi không bao giờ sử dụng boost; đây đơn giản là kinh nghiệm của tôi

Cho phép tôi chỉnh sửa câu hỏi của mình để hỏi, nếu bạn sử dụng boost, tại sao bạn lại chọn sử dụng nó?

Một số nhà phát triển làm, một số nhà phát triển không (trong trò chơi và các nơi khác). Nó phụ thuộc vào nhu cầu / yêu cầu của những nhà phát triển đó là gì và công nghệ hiện có mà họ phải tận dụng.

Thư viện tiêu chuẩn của C ++ thường được xử lý giống nhau và mọi người cũng thường tự hỏi điều tương tự mà bạn đang tự hỏi về nó . Hầu hết các lý do là tương tự nhau, ví dụ:

• Nhà phát triển có thể đã có thư viện chức năng nội bộ cung cấp các dịch vụ giống như thư viện tiêu chuẩn hoặc Boost cung cấp. Các thư viện nội bộ như vậy thường được viết từ lâu, khi hỗ trợ triển khai cho thư viện chuẩn còn yếu và Boost về cơ bản là không tồn tại, do đó chúng ít nhiều phải được viết. Trong kịch bản này, thường không thực sự đáng để chuyển khỏi chức năng nội bộ - đó sẽ là một nỗ lực chuyển mạng lớn sẽ làm mất ổn định rất nhiều mã và hầu như không mang lại lợi ích gì.

• Một nhà phát triển có thể đang làm việc trên các nền tảng nơi trình biên dịch hỗ trợ cho các kỹ thuật C ++ nâng cao được Boost sử dụng không được hỗ trợ tốt, do đó mã Boost hoàn toàn không biên dịch hoặc hoạt động khá kém. Điều này cũng áp dụng cho thư viện tiêu chuẩn, mặc dù ngày nay ít hơn rất nhiều.

• Boost và thư viện tiêu chuẩn của ngôn ngữ là mục đích chung, và mặc dù điều đó tốt và tốt cho hầu hết các ứng dụng, đôi khi một nhà phát triển có các nhu cầu cụ thể có thể được giải quyết tốt hơn bằng các container chuyên dụng hơn.

Tôi nghĩ ở trên là hai lý do hợp lý, mặc dù chắc chắn có những lý do khác. Mặc dù vậy, bạn phải cẩn thận vì nhiều lý do để tránh Boost, các thư viện tiêu chuẩn hoặc bất cứ điều gì làm sôi lên hội chứng "không được phát minh ở đây", đây có thể là một dấu hiệu cho thấy lý do không thực sự có căn cứ thực tế.

Cũng nên nhớ rằng nhu cầu của một studio lớn thường rất khác với nhu cầu của một nhà phát triển cá nhân. Ví dụ: một nhà phát triển cá nhân có thể có ít mã kế thừa trôi nổi để duy trì và do đó, có lẽ việc chuyển từ phiên bản Boost hoặc chức năng thư viện tiêu chuẩn sẽ không lớn như vậy và sẽ tiết kiệm cho nhà phát triển đó khỏi phải duy trì mã đó được mở rộng trong tương lai - do đó làm mất hiệu lực điểm đầu tiên của tôi.

Cuối cùng, tất cả là về việc đánh giá các yêu cầu và đầu tư thời gian của bạn so với mục tiêu mong muốn của bạn và xác định tùy chọn nào đáp ứng nhu cầu của bạn tốt nhất. Các nhà phát triển không sử dụng Boost hoặc thư viện chuẩn thường đã làm như vậy và đạt được kết luận đó - có lẽ bạn cũng sẽ như vậy, và có lẽ là không.

Chỉnh sửa Trở lại câu hỏi này sau một vài năm
Tiếp tục sử dụng ngày càng nhiều thư viện boost, tôi nghĩ rằng tôi nên cập nhật câu hỏi này để đưa ra một trường hợp chắc chắn về lý do tại sao bạn nên sử dụng boost khi mô tả sản phẩm phù hợp với chức năng mong muốn của bạn. Điều này sẽ thuyết phục ngay cả những người nói nay. Tải về openSSL, thử tạo ứng dụng khách và máy chủ với nó. Bây giờ hãy thử và làm cho nó hoạt động trên mọi nền tảng. Sau đó, tải xuống và sử dụng boost :: asio :: ssl để tạo cùng một ứng dụng. Nếu bạn không tin rằng boost là nơi thích hợp để tìm kiếm mã sạch, được tối ưu hóa tốt, được đánh giá ngang hàng, mã đa nền tảng, bài tập đơn giản này sẽ chuyển đổi bạn.

Phiên bản Tl; dr:

Theo tôi, bạn không thấy hàng tấn công ty phát triển quy mô nhỏ hoặc vừa sử dụng boost vì đó là một con thú hoang to lớn và mạnh mẽ không dễ thuần hóa và về cơ bản bạn sẽ tự mình cố gắng học cách để dùng nó. Tài liệu này thiếu một vài cách (xem phiên bản dài) và "cộng đồng" xung quanh dự án dường như bị thiếu, phân tán hoặc không hoạt động (so với các dự án khác).

Phiên bản rất dài:

Tôi nhận ra rằng đã có một câu trả lời được chấp nhận nhưng vì một người thực sự sử dụng boost trong gần như mọi dự án tôi làm, tôi nghĩ tôi sẽ đăng câu trả lời.

Tôi nhớ khi lần đầu tiên tôi được chọc ngoáy và thật lòng tôi không có ý tưởng gì về những gì đang xảy ra. Boost không phải là tài liệu rất tốt ở tất cả. Mọi người có thể không đồng ý với tôi về điều đó tôi chắc chắn bởi vì có rất nhiều đoạn mã ví dụ và một nhận xét, nhưng tất cả đều rất lạnh lùng và mơ hồ cũng như khó điều hướng.

Ngoài ra, có vẻ khó tìm thấy bất kỳ nơi nào bạn cảm thấy như bạn đã tìm thấy "cộng đồng" xung quanh dự án. Trong thực tế, cộng đồng dường như không tồn tại, hoặc du mục. Thật không may, ngay cả danh sách gửi thư của họ đã bị troll bởi rất nhiều trang web đỉa mà bạn có thể đi xuống lỗ thỏ này luôn luôn quay trở lại nơi bạn bắt đầu.

Hai yếu tố này làm cho việc học cách sử dụng các thư viện boost là một nhiệm vụ khá khó khăn. Ngay cả khi các kỹ thuật sử dụng boost không quá phức tạp, thì đó là một bộ thư viện đồ sộ và nhìn chằm chằm xuống khi tất cả những gì bạn được trang bị là một vài đoạn mã và các phần rải rác của danh sách gửi thư từ các góc tối nhất của internet ... Chà, bạn hiểu ý rồi đó.

Tôi đã tìm hiểu về việc tăng cường xung quanh phiên bản 1.45 và giờ chỉ có ở phiên bản 1.52 / 1.53 mà tôi cảm thấy đủ thoải mái để sử dụng nó trong sản xuất. Có rất nhiều thứ để làm quen và ghi nhớ, ngay cả những điều đơn giản như cách bạn định cấu hình tăng và ghi nhớ cấu hình đó, bởi vì cách các thư viện được xây dựng và chức năng có thể thay đổi tùy theo sở thích của bạn vào thời gian biên dịch do cách mọi thứ có thể tùy chỉnh là

Tuy nhiên , đừng nhầm lẫn , một khi bạn có thể tăng sức mạnh, bạn đã có được một vũ khí mạnh mẽ để nhanh chóng xây dựng các chương trình đa nền tảng vững chắc. Chỉ lấy boost::asioví dụ. Bạn có thể viết một máy chủ web không đồng bộ đa nền tảng vững chắc, có khả năng mở rộng và mạnh mẽ chỉ trong vài trăm dòng. Tôi đã viết nhiều máy khách, máy chủ, proxy, v.v.

Như những người khác đã chỉ ra, các công ty lớn hơn thường bị mắc kẹt với những thứ di sản hoặc muốn tự lăn lộn mà tôi hoàn toàn hiểu được. Ngoài ra còn có điều thực sự ngớ ngẩn mà tôi đã nghe nói và gặp phải khi các nhà phát triển và quản lý dự án cấm sử dụng boost vì nó "quá lớn". Tôi đoán là họ tin rằng boost là 1 thư viện duy nhất hoặc họ chưa bao giờ nghe nói về BCP .

Vì sao tôi chọn sử dụng boost

Tôi muốn nói rằng tôi sử dụng nó bởi vì như bạn ngụ ý trong câu hỏi của bạn, đó là "thư viện" C ++. Boost được xem trong thế giới C ++ như con dao quân đội của những thứ mà cuối cùng bạn sẽ cần sử dụng. Vì vậy, ý tưởng là nếu có nhu cầu, cần có một phiên bản có hiệu suất cao và khả năng di động của nó. Các công ty lớn góp phần thúc đẩy , những người có học thức cao với sơ yếu lý lịch ấn tượng đóng góp và duy trì nó , và khi một tiêu chuẩn mới của C ++ đang được phát triển, mọi người thường tìm cách thúc đẩy để xem những phần nào của nó sẽ trở thành tiêu chuẩn C ++.

Vì vậy, nếu tôi cần thêm một số chức năng có thể có thư viện hiện có, thì nơi đầu tiên tôi sẽ tìm thấy là vì tôi khá an toàn khi cá cược rằng nó được tối ưu hóa tốt, di động, nó sẽ được hỗ trợ và duy trì cho một thời gian rất dài và các lỗi sẽ được tìm thấy và xử lý. Trong thế giới nguồn mở, những phẩm chất đó có thể rất khó trở thành hiện thực.

Chúng tôi đã sử dụng một chút Boost trở lại tại nơi làm việc cũ của chúng tôi. Những lý do chính để tránh nó và hạn chế sử dụng là:

• thời gian biên dịch - một số trong số đó rất chậm để biên dịch và cuối cùng bạn không muốn có # # loại trừ trong bất kỳ tiêu đề nào của bạn
• độ phức tạp - hầu hết các nhà phát triển trò chơi không được biết đến nhiều và do đó làm cho mã không thể đọc được
• hiệu suất - một số khái niệm thực hiện chậm theo mặc định, ví dụ. đã chia sẻ

Điều tương tự là (đã?) Được nói cho STL "chuẩn hơn". Bài viết này nói về EASTL, một bản viết lại (một phần) STL của Electronic Arts để đáp ứng nhu cầu phát triển trò chơi khác hẳn so với phát triển ứng dụng "chung chung" hơn.

Vì vậy, có lẽ, một người nào đó ở đâu đó đang viết lại (một phần) thúc đẩy để đáp ứng nhu cầu của họ trong phát triển trò chơi!

Ai nói họ không sử dụng boost? Tôi đã biết một hoặc hai công cụ C ++ đã sử dụng boost. Tôi chưa bao giờ trực tiếp làm việc với họ; nhưng, điều đó chủ yếu là vì kinh nghiệm của tôi nằm ở Unreal.

Vì những lý do tôi gặp phải vì không sử dụng boost, và những điều này là chủ quan:

• Chúng tôi thích cuộn các cấu trúc dữ liệu của riêng mình cho các nền tảng mà chúng tôi đang triển khai
• Chúng tôi muốn giới hạn số lượng mã không được phát triển nội bộ mà chúng tôi phải sử dụng trong các dự án của mình, đặc biệt khi mã bên ngoài đó phụ thuộc vào các thư viện được phát triển bên ngoài khác.

Về cơ bản, nó hiểu rõ: một giải pháp chung không phải lúc nào cũng là "phù hợp".

Tôi chắc rằng ai đó thực sự làm việc với thư viện có thể bình luận tốt hơn.

Tôi đi chơi ở StackOverflow và không sử dụng boost. Tôi sẽ thêm lý do của tôi, bởi vì nó chưa được đề cập.

Boost có nhiều ý tưởng tuyệt vời, thực sự. Tôi thích nhìn vào những gì họ đã làm và thử những điều và ý tưởng mới. Chúng rất tuyệt, vì nó là nơi sinh sản của nhiều cải tiến C ++.

Nhưng sự gia tăng là một con thú rất khó sử dụng vì nhiều lý do. Một trong những lý do là họ cần (muốn) tương thích trên hầu hết mọi trình biên dịch với bất kỳ quirks nào. Kết quả là họ cần sử dụng nhiều thủ thuật, chẳng hạn như MPL để thực hiện. Ví dụ (một thời gian dài trước đây) tôi muốn sử dụng shared_ptr của họ, để nó chạy có nghĩa là tôi cần các nguồn và thư viện với mức tăng 90%. Tôi đã kết thúc việc viết của riêng tôi; 50 dòng mã có thể đọc được. (Yêu cầu của tôi khi nghiêm ngặt hơn, như không có yếu tố an toàn hoặc luồng yếu.)

Thường thì bạn cần một tập hợp tăng thực sự nhỏ, nhưng việc tích hợp toàn bộ tăng chỉ là không đáng để gặp rắc rối.

Chỉnh sửa :

Chỉ cần làm cho rõ ràng, vì nó dường như không đi qua rõ ràng (tức là downvote). Tôi sử dụng làm sử dụng thư viện bên thứ ba. Nhưng trong hầu hết các trường hợp, tất cả mọi thứ đều bình đẳng, tích hợp thư viện bên thứ ba hoặc tăng cường, thư viện bên thứ ba khác nhanh hơn và sạch hơn. Phần còn lại được thực hiện trong bài tập ngón tay "2h". Tôi có một cái nhìn rất khó khăn trong việc xây dựng nó hoặc mua câu hỏi.

Trong trường hợp của chúng tôi (không phải trò chơi), chúng tôi có một lý do tuyệt vời cho việc không sử dụng boost (cũng không phải std): Chúng tôi có rất nhiều mã có từ một thập kỷ. Theo các tiền bối, std và boost là không đầy đủ, đầy lỗi hoặc chỉ quá chậm đối với những thứ hiệu suất cao mà chúng tôi yêu cầu. Vì vậy, một số lớp cơ sở đã được triển khai, sử dụng các khái niệm tương tự (như các trình vòng lặp) và thường được tối ưu hóa cho các thuật toán của chúng tôi. Ngày nay, cả ba thư viện (của chúng tôi, std và boost) đều rất giống nhau.

Nhưng chúng tôi có muốn chuyển qua tất cả các mã của chúng tôi? Không hẳn vậy. Tôi cho rằng nhiều công ty khác phải đối mặt với tình trạng khó xử tương tự. Hoặc viết lại rất nhiều mã đã được thử nghiệm và làm việc hoặc không sử dụng std / boost.

Cá nhân tôi không sử dụng boost hoặc bất kỳ mã mục đích chung nào khác khi tạo trò chơi, vì trò chơi không phải là mục đích chung. Loại mã bạn có thể cần để thực hiện một trò chơi thường dành riêng cho phát triển trò chơi, không phải lúc nào cũng giống như 98% (con số ngẫu nhiên) của thời gian. Bạn có thể giải quyết một vài đoạn mã cuối cùng từ boost hoặc một số lib khác, nhưng có lẽ tốt hơn là chỉ viết ra những phần nhỏ bạn cần ở đây và ở đó.

Bên cạnh đó, tôi nghĩ rằng thật thú vị khi viết mã của riêng bạn trong c ++, đó là lý do tại sao tôi chưa bao giờ sử dụng boost hoặc bất cứ thứ gì tương tự.

di sản trong các thư viện nội bộ không phải là một yếu tố ... lý do chính tại sao mọi người không nên sử dụng thư viện mục đích chung khác là vì chúng không được tối ưu hóa tốc độ và bộ nhớ, tôi phải đề cập đến việc Cryengine sử dụng STL nhưng họ biên dịch đó là phiên bản nguồn mở có tên STLPort, vì vậy đừng ngại sử dụng STL, chỉ cần thực hiện các cấp phát tùy chỉnh của bạn và bạn sẽ ổn. không sử dụng boost tho.