Có thực tế khi từ bỏ STL trong phát triển C ++ không? [đóng cửa]

Tôi biết trong một số lĩnh vực (ví dụ như ngành công nghiệp trò chơi), STL không được khuyến khích. Vì vậy, câu hỏi của tôi là: nó thực sự là một thực hành tốt không sử dụng STL trong một số trường hợp? Nếu vậy, lý do lớn nhất của việc không sử dụng STL của C ++ hiện đại là gì?

• Tôi chỉ có thể nghĩ về một lý do hợp lệ và nó thực sự hiếm: Thời gian thực khó khăn. Nhiều thứ trong thư viện chuẩn phân bổ bộ nhớ trong và điều đó không đủ tính xác định cho các ứng dụng thời gian thực cứng, vì vậy chúng phải được tránh. Các ứng dụng này thường khá đơn giản, mặc dù chúng mất thời gian không tương xứng để phát triển do việc xem xét và kiểm tra rất nghiêm ngặt.

• Tôi có thể nghĩ về một lý do không hợp lệ, nhưng rất phổ biến: Các nhà phát triển không hiểu độ phức tạp tính toán, lạm dụng STL và sau đó đổ lỗi cho thư viện.

  STL thường nhanh hơn trong thời gian chạy so với các giải pháp kiểu C với các con trỏ gọi lại hoặc các giải pháp dựa trên đa hình với các phương thức ảo ( xem thêm bài phát biểu của Bjarne Stroustrup này ). Tuy nhiên, khi nhà phát triển không hiểu các thông số kỹ thuật phức tạp được đưa ra và sử dụng sai thư viện bằng cách tạo ra thứ gì đó như vectơ của một số đối tượng phức tạp (trong C ++ 11, nó không còn là vấn đề nữa!), Gây ra vấn đề về hiệu năng và hơn là tự bảo vệ với "bạn thấy đấy, các vectơ khá chậm", nó có thể gây ra nhận thức rằng thư viện chuẩn bị chậm. Và một khi các nhà quản lý có được nhận thức như vậy, nó có thể sống rất lâu trong tổ chức.

• Rõ ràng bạn không thể sử dụng bất cứ thứ gì mà nền tảng bạn đang nhắm mục tiêu không hỗ trợ. Tuy nhiên, chúng tôi hiện đang nhắm mục tiêu bốn nền tảng di động phổ biến nhất (Android, iOS, Bada và WinCE cũ) và sử dụng thư viện tiêu chuẩn và một số phần của Boost trên tất cả chúng.

  Phần lớn thư viện tiêu chuẩn từng được Microsoft không hỗ trợ sớm trong WinCE (IIRC iostreams chỉ xuất hiện với Visual Studio 2005), nhưng thay vào đó, có thể sử dụng STLport từ lâu. Và bạn thường có thể có được điều đó để biên dịch cho bất cứ điều gì. Vì vậy, tôi sẽ gọi lý do này là không hợp lệ là tốt.

  Bên cạnh đó, trong một thời gian khá dài, nó không phải là "STL", mà là Thư viện tiêu chuẩn ANSI C ++. Nó được định nghĩa bởi cùng một tài liệu tiêu chuẩn xác định chính ngôn ngữ đó. Bất cứ điều gì không hỗ trợ, nó không thực sự xứng đáng được gọi là C ++.

Tôi đang sử dụng STL và tăng trong nhiều năm. Nếu tôi muốn từ bỏ nó và sử dụng các công cụ tùy chỉnh của mình, động lực sẽ là:

1. Biên dịch giảm thời gian (75%). Chỉ cần bao gồm các iostream có thể thêm 1 triệu dòng mã vào mô-đun của bạn. Có các tiêu đề được biên dịch trước giúp ích rất nhiều, nhưng nó vẫn làm chậm quá trình biên dịch rất nhiều trong các dự án lớn. Về lâu dài, nó lãng phí rất nhiều thời gian của bất cứ ai làm việc trên nó.
2. Hiệu suất. (25%) STL được viết để hoạt động nói chung, nhưng bạn có thể tối ưu hóa các cấu trúc của mình để hoạt động chính xác như bạn muốn. Ví dụ: bạn có thể có cấu trúc dữ liệu với hàng triệu chuỗi ngắn. Có thể nhanh hơn nhiều khi sử dụng lớp chuỗi tùy chỉnh dựa trên hiệu trưởng của boost :: small_vector (vectơ dữ liệu cục bộ tĩnh nhỏ, chỉ phân bổ động cho các chuỗi lớn hơn), những thay đổi này có thể làm cho các phần mã quan trọng hoạt động nhanh hơn nhiều lần.

Có một lý do hợp lệ lớn để không sử dụng thư viện mẫu tiêu chuẩn C ++: Một trong những nền tảng mục tiêu của bạn không có triển khai tuân thủ hoàn toàn (hoặc không thực hiện gì cả) và bạn biết rằng nó sẽ không nhận được một trong những năm tiếp theo

Tôi không biết về độ phức tạp (hiệu quả thực hiện) nhưng tôi đang sử dụng các bộ chứa và chuỗi Qt rộng rãi thay vì các tiêu chuẩn và chúng hoạt động tốt. Tôi cũng thấy việc thực hiện Qt của các bộ và danh sách dễ sử dụng hơn.

Vì vậy, việc từ bỏ STL là điều thiết thực nếu bạn có thể sử dụng một thư viện khác phù hợp với nhu cầu của mình.

Patrick đã đề cập đến lý do không sử dụng toàn bộ STL, cụ thể là (các) nền tảng của bạn không có.

Tất cả trong tất cả tôi nghĩ rằng câu hỏi đang thiếu điểm. Đó không phải là một quyết định tất cả hoặc không có gì, mà là một trong những lựa chọn và lựa chọn. Bạn cũng có thể quyết định sử dụng các thùng chứa và thuật toán, nhưng quyết định sử dụng một cái gì đó bên ngoài Std Lib cho chuỗi và i / o.

Nó không thực tế, trừ khi có một lý do nặng nề để làm như vậy. Một số lý do như vậy mà tôi có thể nghĩ đến chỉ bao gồm triển khai STL một phần hoặc thiếu (hoặc bất kỳ phần nào khác của thư viện chuẩn) hoặc giới hạn tài nguyên (bộ nhớ, tốc độ CPU, lưu trữ, ...) mà bạn phải khắc phục lăn các công cụ của riêng bạn mà tuân thủ những gì bạn cần phải hoàn thành.

Trong ngành công nghiệp trò chơi, hầu hết các studio (thậm chí nhỏ hơn ở một mức độ nào đó) đều có thư viện nội bộ và triển khai nhiều phần thư viện tiêu chuẩn được thiết kế riêng cho nền tảng đích và trong một số trường hợp nhắm mục tiêu engnie hoặc thậm chí là chính trò chơi. Nói một cách đơn giản khi phát triển một trò chơi dành cho bảng điều khiển, phần cứng rất hạn chế bởi các tiêu chuẩn ngày nay. Có hàng ngàn và hàng ngàn dây chuyền lắp ráp thủ công vì một lý do. Điều rất quan trọng là giảm thiểu tất cả các loại dấu chân tài nguyên trong mã của bạn để trò chơi chạy nhanh hơn, cho phép nhiều nội dung hơn trong thế giới trò chơi (ví dụ như một thế giới lớn hơn) hy vọng sẽ mang lại một sản phẩm tốt hơn.

"Mỗi trò chơi thành công bắt đầu bằng cách triển khai thực hiện danh sách liên kết của riêng bạn."