Câu hỏi liên quan

0 Phiếu
2 Câu trả lời
+1 Phiếu
3 Câu trả lời

Tại sao các C++ allocators tránh reallocation tại chỗ


0 Phiếu
Đã hỏi 25/5/2016 bởi magedYoho (970 điểm)
Sự hiểu biết của tôi về realloc là rằng, nếu bộ nhớ có sẵn tiếp vượt quá điểm phân bổ, nó có thể cố gắng để mở rộng việc phân bổ hiện tại mà không sao chép. Trong khi đọc này https://github.com/facebook/folly/blob/master/folly/docs/FBVector.md tôi đến để biết rằng hầu hết allocators tránh inplace reallocation
. Nhiều bộ nhớ allocators không hỗ trợ tại chỗ reallocation, mặc dù hầu hết trong số họ có thể. Điều này xuất phát từ thiết kế bây giờ khét tiếng của realloc() opaquely thực hiện tại chỗ reallocation hoặc một chu kỳ allocate-memcpy-deallocate. Như vậy thiếu control sau đó đã buộc tất cả các mẫu thiết kế dựa trên clib cấp phát để tránh ở nơi reallocation, và bao gồm C ++ 's mới và std:allocator.
như đã trả lời bằng một câu hỏi ( lý do tại sao có không có chức năng reallocation trong C++ allocators? ) về việc thiếu reallocators trong C++ nơi câu trả lời chấp nhận đề cập rằng như vậy cấp phát một sẽ có Cấm realloc sử dụng form C library nhưng không trả lời tại sao không cố gắng để làm cho realloc mở rộng bộ nhớ hiện tại nếu có thể?

4 Câu trả lời

0 Phiếu
Đã trả lời 04/6/2016 bởi learnInterv (1,190 điểm)
được bình chọn là câu trả lời hay nhất 06/6/2016 bởi Raya9235
 
Câu trả lời hay nhất
Đó là thực sự rất ít lợi thế để cố gắng thực hiện "tại chỗ reallocation", bởi vì case phổ biến là để có được không có phòng để mở rộng bộ nhớ được phân bổ một chặn tại chỗ. Bất kỳ cấp phát tốt sẽ nhằm mục đích để tránh phân mảnh như là một ưu tiên hàng đầu của nó - không làm như vậy có thể dẫn đến thảm họa vụ nổ của yêu cầu bộ nhớ và nhanh chóng dẫn đến thất bại phân bổ, hầu hết các chương trình được trang bị kém để xử lý, đặc biệt là trong một không gian address 32-bit. Và để tránh sự phân mảnh, cấp phát một nhu cầu để thực hiện theo một chiến lược phù hợp nhất. Vì vậy, cho một tốt thực thế giới cấp phát, chính case mở rộng ở nơi đâu có thể là khi không trước đó đã giải phóng khối có sẵn, và phân phối diễn ra tại "đầu heap". Cho chương trình rất đơn giản, mà chỉ là một phân bổ đơn đang được thay đổi kích cỡ với không có phân bổ khác diễn ra ở giữa những resizings, đó là một lợi thế hiệu suất nghiêm trọng có khả năng để có được từ sự mở rộng tại chỗ. Điều này là chính đáng trong single-ren chương trình viết trong C, nhưng không quá nhiều cho chương trình C++ nơi có thể phân bổ dynamic xảy ra trong gần như tất cả mọi thứ bạn làm.
Đã bình luận 06/6/2016 bởi orgcheck (270 điểm)
có thể trùng lặp của [lý do tại sao có không có chức năng reallocation trong C++ allocators không?] (http://stackoverflow.com/questions/ 3105001 /why-is-there-no-reallocation-functionality-in-c-allocators)
Đã bình luận 06/6/2016 bởi semon (140 điểm)
Nếu bạn có một bình luận về câu trả lời được chấp nhận từ một câu hỏi, gửi nó như là một bình luận cho rằng câu trả lời. Tôi không thấy làm thế nào câu hỏi này là đáng kể khác nhau cho câu hỏi được liên kết.
+1 Phiếu
Đã trả lời 29/5/2016 bởi dhn_Reed (160 điểm)
Đã bình luận 31/5/2016 bởi Cayce9707 (240 điểm)
Có lẽ bởi vì nó là rất nhiều toàn bộ công việc không có nhiều lợi ích, và nó làm cho mọi thứ thêm rắc rối, đặc biệt là khi bạn có nhà thầu và destructors trong hỗn hợp (ví dụ, bạn sẽ nhận được hai hành vi khác nhau tùy thuộc vào việc nó reallocated hay không, vì theo một kịch bản một loạt các bản sao nhà thầu và destructors sẽ được kích hoạt, trong khi khác họ không).
0 Phiếu
Đã trả lời 04/6/2016 bởi Workingprier (140 điểm)
Vấn đề với mở rộng bộ nhớ khối hiện tại là cấp phát nhu cầu để biết trạng thái của các khối liền kề bộ nhớ. Nghĩa vụ quản lý cấp phát khối của một kích thước cố định. Hãy nói rằng tất cả các khối được quản lý là quyền lực của 2. Trong trường hợp đó, việc cấp phát sẽ mở rộng một khối để điện gần nhất của hai. Bất cứ điều gì khác sẽ yêu cầu sao chép. Nghĩa vụ cấp phát quản lý variable có kích thước khối bằng cách sử dụng hàng đợi? Sau đó nó sẽ là rất khó khăn để tìm thấy khối liền kề. Như chỉ ra ở trên, reallocs không cần thiết mà thường xuyên. Đó là nói chung hiệu quả hơn chỉ để lấy một khối mới và sao chép.
–1 Phiếu
Đã trả lời 04/6/2016 bởi FubDoing (600 điểm)
Đó là thực sự rất ít lợi thế để cố gắng thực hiện "tại chỗ reallocation", bởi vì case phổ biến là để có được không có phòng để mở rộng bộ nhớ được phân bổ một chặn tại chỗ. Bất kỳ cấp phát tốt sẽ nhằm mục đích để tránh phân mảnh như là một ưu tiên hàng đầu của nó - không làm như vậy có thể dẫn đến thảm họa vụ nổ của yêu cầu bộ nhớ và nhanh chóng dẫn đến thất bại phân bổ, hầu hết các chương trình được trang bị kém để xử lý, đặc biệt là trong một không gian address 32-bit. Và để tránh sự phân mảnh, cấp phát một nhu cầu để thực hiện theo một chiến lược phù hợp nhất. Vì vậy, cho một tốt thực thế giới cấp phát, chính case mở rộng ở nơi đâu có thể là khi không trước đó đã giải phóng khối có sẵn, và phân phối diễn ra tại "đầu heap". Cho chương trình rất đơn giản, mà chỉ là một phân bổ đơn đang được thay đổi kích cỡ với không có phân bổ khác diễn ra ở giữa những resizings, đó là một lợi thế hiệu suất nghiêm trọng có khả năng để có được từ sự mở rộng tại chỗ. Điều này là chính đáng trong single-ren chương trình viết trong C, nhưng không quá nhiều cho chương trình C++ nơi có thể phân bổ dynamic xảy ra trong gần như tất cả mọi thứ bạn làm.
Đã bình luận 06/6/2016 bởi Bs_3620_Out (420 điểm)
@ MichaelAaronSafyan vì vậy một thực tế rằng realloc function library C mà không đảm bảo rằng destructors sẽ được gọi là nếu data là hoàn toàn được sao chép vào một số khác đặt lý do rằng để thay đổi kích thước chúng tôi làm điều gì đó giống như cuộc gọi malloc cho thích hợp các dữ liệu có kích thước, sao chép các đối tượng và gọi destructors vào việc phân bổ trước đây?
Đã bình luận 06/6/2016 bởi A_Vigo (720 điểm)
Tôi không biết lý do đứt đằng sau lý do tại sao những điều đã thiết kế theo cách họ đã. Tôi chỉ là suy đoán về nó và một số khó khăn rõ ràng / trở ngại mà có thể đã ngăn chặn nó.
Đã bình luận 06/6/2016 bởi Biley207 (150 điểm)
@ MichaelAaronSafyan: nếu chỉ có tôi đã có một xu cho mỗi khi ai đó trả lời một "Tại sao không X làm Y?" với một đầu gối-jerk "bởi vì nó là rất nhiều công việc cho không có lợi ích"...

ToughDev Q&A là gì?

Trang web hỏi đáp cho các bạn đam mê lập trình, phát triển phần mềm và các vấn đề kỹ thuật khác. Với sự giúp đỡ của bạn, chúng tôi hy vọng sẽ xây dựng thành công một thư viện đầy đủ các câu hỏi và trả lời về tất cả các vấn đề có liên quan đến lập trình!







...