Khấu hao coi có hại? [đóng cửa]

Tôi vừa mới biên dịch một số mã của riêng mình với -std=c++0xcờ trong GCC, vì tôi muốn mơ hồ theo kịp những gì tất cả những người trẻ đang làm (miễn là họ ở lại bãi cỏ của tôi), và tôi đã kết thúc với một loạt các cảnh báo về việc auto_ptrbị phản đối Tất nhiên, tôi biết rằng auto_ptrđã bị phản đối trong C ++ 0x, nhưng ...

Không phải là mất giá một thời gian và nỗ lực? Các lý do không phản đối (với ví dụ auto_ptr):

• có một đại dương mã ngoài kia vẫn cần được hỗ trợ, tạo ra hàng triệu cảnh báo sẽ chỉ cám dỗ mọi người tắt cảnh báo.

• auto_ptr là một chút naff, nhưng nó thực sự làm những gì nó nói trên tin.

• nếu chúng ta thực sự muốn phản đối mọi thứ, tôi đề cử printf(). Nhưng chỉ cần tưởng tượng những tiếng kêu sẽ xảy ra. auto_ptrkhông có quá nhiều bạn bè, nhưng ít nhất trong mã C ++ của tôi, nó được sử dụng nhiều hơn printf, hoàn toàn không được sử dụng.

• ủy ban có một hồ sơ tồi về việc nhận quyền này - họ không tán thành tĩnh ở phạm vi không gian tên, và bây giờ dường như nó không được đánh giá cao - tôi sẽ không ngạc nhiên nếu auto_ptrthực hiện một sự trở lại tương tự

• cuối cùng, bất kể ủy ban nói gì, những người triển khai trình biên dịch đều bỏ qua chúng - đơn giản là họ không thể mạo hiểm phá vỡ mã khách hàng của mình, tất cả những gì họ có thể làm là đưa ra các cảnh báo khó chịu.

Vì vậy, câu hỏi của tôi - bạn có xem xét sự phản đối (của bất cứ điều gì, không chỉ auto_ptrs, và không chỉ trong C ++) là một ý tưởng tốt, và nếu vậy, tại sao?

Lý do phản đối (nói chung):

• Nó rõ ràng cho mọi người thấy rằng một cái gì đó là thực hành xấu (và hy vọng gợi ý một sự thay thế).
• Thời gian khấu hao cung cấp cho mọi người một cơ hội để thay đổi mã của họ trước khi trình biên dịch loại bỏ nó hoàn toàn.

Tôi cũng không đồng ý về điểm cuối cùng. Trình biên dịch không bỏ qua ủy ban và cuối cùng họ sẽ loại bỏ những thứ không được chấp nhận (ví dụ >?=và <?=trong GCC - chúng không được chấp nhận sau đó bị xóa *).

Tôi nghĩ rằng điểm quan trọng là: một số thứ nên được loại bỏ, vì nhiều lý do và tôi nghĩ rằng sự phản đối là cách duy nhất để làm điều đó. Trong trường hợp cụ thể này, auto_ptrnên được loại bỏ vì nó đã được thay thế bởi unique_ptr. Thay đổi là đủ dễ dàng và mọi người sẽ có nhiều thời gian để làm điều đó.

(*) Có Tôi biết chúng là các tiện ích mở rộng và không phải là tiêu chuẩn, nhưng vấn đề là các nhà cung cấp trình biên dịch cuối cùng sẽ loại bỏ mọi thứ một khi chúng không được dùng nữa, cho dù mã có còn dựa vào chúng hay không.

Bất kỳ API đủ phức tạp nào cũng có thể có các lỗ hổng không được phát hiện cho đến khi chúng được sử dụng một thời gian. Lựa chọn của chúng tôi:

• Để lại mọi thứ như chúng là. Điều này có nghĩa là API sẽ tiếp tục thu thập ngày càng nhiều hơn khi nó phát triển theo thời gian. Ngay cả khi các phiên bản mới và cải tiến được thêm vào, những phiên bản cũ cũng sẽ cần được duy trì.
• Hủy bỏ nó mà không có cảnh báo. Điều này có khả năng phá vỡ rất nhiều mã.
• Khấu hao nó và loại bỏ nó trong một phiên bản sau. Điều này cho thời gian để sửa mã hiện có, trong khi đảm bảo rằng số lượng hành trình vẫn bị giới hạn.

Khấu hao là sanest của các lựa chọn thay thế.

Không Khấu hao có thể là một điều thực sự tốt. Nó giữ cho công nghệ khỏi bị mắc kẹt với hành lý cũ vô dụng.

Chỉ trong lĩnh vực C ++, tôi nhớ "tính năng" của Microsoft về việc không hỗ trợ chính xác khai báo biến trong một câu lệnh for. Điều đó đã diễn ra trong khoảng một thập kỷ và tạo ra rất nhiều mã không thể di động. Đó là một "tính năng" tôi vui mừng đã bị phản đối.

Tổng quát hơn, Apple đã có thói quen kể từ những năm 80 đánh dấu các API cũ rườm rà là "không dùng nữa" trong 5 - 7 năm trước khi đánh cắp chúng. Tôi vừa nói chuyện với một kỹ sư của Apple tại WWDC về việc không tán thành một số API cổ điển của C và tôi thực sự vui mừng khi biết họ đang làm điều đó, bởi vì việc tiếp tục hỗ trợ cho một mô hình được phát triển vào khoảng năm 1990 hoàn toàn cản trở những gì người ta mong đợi để làm trên CPU đa lõi 64 bit hiện đại.

Trong thực tế, sẽ mất nhiều thời gian để người viết trình biên dịch kết xuất auto_ptr và họ có thể sẽ hỗ trợ một số chế độ tương thích ngược trong một hoặc hai thập kỷ, nhưng đó là một điều tốt.

nếu chúng ta thực sự muốn phản đối mọi thứ, tôi chỉ định printf ()

printflà một chức năng hữu ích. Nó cho phép định dạng mọi thứ ngắn hơn iostreams. Và đó là chức năng C. Lý do C ++ tồn tại và được sử dụng là vì nó tương thích với C. Vì vậy, việc phản đối printfcó vẻ ít hữu ích hơn.

Vì vậy, bất cứ ai khác lên cho một cuộc thập tự chinh chống mất giá?

Ủy ban nhận thức được một số vấn đề về ý nghĩa của sự phản đối hiện tại. Xem ý nghĩa của sự phản đối .

Ngôn ngữ và API phải tiến lên phía trước. Mặc dù có thể có rất nhiều mã tùy thuộc vào một số tính năng cũ, nhưng có thể có một cách mới và tốt hơn để làm một cái gì đó và chi phí hỗ trợ tính năng cũ là quá nhiều.

Sự phản đối cũng đưa ra cảnh báo rằng trong tương lai, tính năng này sẽ bị xóa. Điều này cho phép các nhà phát triển có thời gian cập nhật mã của họ nếu họ theo kịp API mới. Điều này là tốt hơn nhiều so với giải pháp thay thế: loại bỏ hoàn toàn. Hãy nhớ rằng khấu hao là một cảnh báo, không phải là một lỗi.

Và nếu đây là một chương trình cũ mà bạn không muốn cập nhật, thì không có gì ngăn bạn sử dụng API cũ (hoặc trong trường hợp này là trình biên dịch).

Khi nó đứng, khấu hao có ít nhất hai ý nghĩa.

• Nó sẽ bị xóa trong một phiên bản trong tương lai
• Chúng tôi đã tạo ra các lựa chọn thay thế tốt hơn và bây giờ tính năng này là dư thừa (nhưng không hoàn toàn vô dụng). Những người mới đến sẽ tốt hơn bỏ qua điều này trong khi học ngôn ngữ; tuy nhiên, nó sẽ không bị xóa bất cứ lúc nào sớm.

Tôi nghĩ tĩnh rơi vào loại thứ hai, nhưng chỉ có thời gian mới biết auto_ptr có thực sự đáng bị loại bỏ hay tốt hơn là giữ nó trong ngôn ngữ.

Khấu hao không có hại nếu chuyển sang một giải pháp thay thế có thể được thực hiện trong 1 ngày làm việc: vd. tìm kiếm đơn giản / thay thế chức năng cũ bằng lớp mới hoặc lớp tương thích dễ dàng thiết lập.

Nếu bạn cần viết lại các phần lớn của phần mềm vì không dùng nữa, thì nó có hại.

Một ví dụ điển hình có thể là API mysql của PHP, về cơ bản, bạn chỉ cần thay thế tất cả mysql_ * bằng mysqli_ * và cung cấp id liên kết cho chúng và đã xong.

Một ví dụ tồi là sự phản đối và loại bỏ glBegin, glEnd và tất cả các công cụ tính toán ma trận từ OpenGL, nếu bạn muốn mã của mình hoạt động trên OpenGL3 trở lên, bạn sẽ cần phải viết lại toàn bộ mã kết xuất để sử dụng bộ đệm đỉnh.

Tôi nghĩ rằng đó là một cách tốt để cho mọi người biết rằng có một cách tốt hơn. Tôi rất thích một sự phản đối tốt đẹp hơn là một chức năng chỉ biến mất.