Tại sao C ++ có 'hành vi không xác định' (UB) và các ngôn ngữ khác như C # hoặc Java thì không?

Bài đăng Stack Overflow này liệt kê một danh sách khá đầy đủ các tình huống trong đó đặc tả ngôn ngữ C / C ++ tuyên bố là 'hành vi không xác định'. Tuy nhiên, tôi muốn hiểu tại sao các ngôn ngữ hiện đại khác, như C # hoặc Java, không có khái niệm 'hành vi không xác định'. Điều đó có nghĩa là, trình thiết kế trình biên dịch có thể kiểm soát tất cả các kịch bản có thể (C # và Java) hay không (C và C ++)?

Hành vi không xác định là một trong những điều được công nhận là một ý tưởng rất xấu chỉ khi nhìn lại.

Các trình biên dịch đầu tiên là những thành tựu to lớn và tưng bừng hoan nghênh những cải tiến so với giải pháp thay thế - ngôn ngữ máy hoặc lập trình ngôn ngữ lắp ráp. Các vấn đề với điều đó đã được biết đến và các ngôn ngữ cấp cao được phát minh đặc biệt để giải quyết những vấn đề đã biết. .

Mãi đến sau này chúng tôi mới nhận ra những vấn đề mới hơn xảy ra với cách tiếp cận mới hơn. Nằm cách xa máy thực tế mà mã chạy trên có nghĩa là có nhiều khả năng mọi thứ âm thầm không làm những gì chúng ta mong đợi chúng làm. Chẳng hạn, việc phân bổ một biến thường sẽ không xác định giá trị ban đầu; đây không được coi là một vấn đề, bởi vì bạn sẽ không phân bổ một biến nếu bạn không muốn giữ một giá trị trong đó, phải không? Chắc chắn sẽ không quá nhiều để mong đợi rằng các lập trình viên chuyên nghiệp sẽ không quên gán giá trị ban đầu, phải không?

Hóa ra, với các cơ sở mã lớn hơn và các cấu trúc phức tạp hơn có thể có với các hệ thống lập trình mạnh hơn, vâng, nhiều lập trình viên thực sự sẽ có những lần giám sát như vậy theo thời gian và hành vi không xác định đã trở thành một vấn đề lớn. Thậm chí ngày nay, phần lớn các rò rỉ bảo mật từ nhỏ đến khủng khiếp là kết quả của hành vi không xác định ở dạng này hay dạng khác. (Lý do là thông thường, trên thực tế, hành vi không xác định được xác định rất nhiều bởi những thứ ở cấp độ thấp hơn tiếp theo về điện toán và những kẻ tấn công hiểu rằng cấp độ đó có thể sử dụng phòng ngọ nguậy đó để tạo ra một chương trình không chỉ là những thứ ngoài ý muốn, mà chính xác là những thứ họ dự định.)

Vì chúng tôi đã nhận ra điều này, đã có một nỗ lực chung để loại bỏ hành vi không xác định khỏi các ngôn ngữ cấp cao và Java đặc biệt kỹ lưỡng về điều này (điều này tương đối dễ dàng vì dù sao nó cũng được thiết kế để chạy trên máy ảo được thiết kế riêng của nó). Các ngôn ngữ cũ hơn như C không thể dễ dàng được trang bị thêm như thế mà không mất khả năng tương thích với số lượng lớn mã hiện có.

Chỉnh sửa: Như đã chỉ ra, hiệu quả là một lý do khác. Hành vi không xác định có nghĩa là người viết trình biên dịch có rất nhiều thời gian để khai thác kiến ​​trúc đích để mỗi lần thực hiện được thực hiện với việc thực hiện nhanh nhất có thể của từng tính năng. Điều này quan trọng hơn đối với các máy thiếu năng lực của ngày hôm qua so với ngày nay, khi lương lập trình viên thường là nút thắt cho phát triển phần mềm.

Về cơ bản vì các nhà thiết kế Java và các ngôn ngữ tương tự không muốn hành vi không xác định trong ngôn ngữ của họ. Đây là một sự đánh đổi - cho phép hành vi không xác định có khả năng cải thiện hiệu suất, nhưng các nhà thiết kế ngôn ngữ ưu tiên an toàn và dự đoán cao hơn.

Ví dụ: nếu bạn phân bổ một mảng trong C, dữ liệu không được xác định. Trong Java, tất cả các byte phải được khởi tạo thành 0 (hoặc một số giá trị được chỉ định khác). Điều này có nghĩa là thời gian chạy phải vượt qua mảng (một hoạt động O (n)), trong khi C có thể thực hiện phân bổ ngay lập tức. Vì vậy, C sẽ luôn luôn nhanh hơn cho các hoạt động như vậy.

Nếu mã sử dụng mảng sẽ cư trú bằng cách nào trước khi đọc, thì về cơ bản, điều này đã lãng phí công sức cho Java. Nhưng trong trường hợp mã được đọc trước, bạn sẽ nhận được kết quả có thể dự đoán được trong Java nhưng kết quả không thể đoán trước được trong C.

Hành vi không xác định cho phép tối ưu hóa đáng kể, bằng cách cho vĩ độ trình biên dịch thực hiện điều gì đó kỳ lạ hoặc bất ngờ (hoặc thậm chí bình thường) ở ranh giới nhất định hoặc các điều kiện khác.

Xem http://blog.llvm.org/2011/05/what-every-c-programmer-should-ledge.html

Sử dụng một biến chưa được khởi tạo: Đây thường được gọi là nguồn của các vấn đề trong các chương trình C và có nhiều công cụ để nắm bắt những điều này: từ cảnh báo của trình biên dịch đến các máy phân tích tĩnh và động. Điều này cải thiện hiệu suất bằng cách không yêu cầu tất cả các biến được khởi tạo bằng 0 khi chúng đi vào phạm vi (như Java thực hiện). Đối với hầu hết các biến vô hướng, điều này sẽ gây ra ít chi phí, nhưng các mảng ngăn xếp và bộ nhớ malloc'd sẽ phải chịu một bộ nhớ lưu trữ, điều này có thể khá tốn kém, đặc biệt là vì bộ lưu trữ thường bị ghi đè hoàn toàn.

Tràn số nguyên đã ký: Nếu số học trên loại 'int' (ví dụ) tràn, kết quả không được xác định. Một ví dụ là "INT_MAX + 1" không được bảo đảm là INT_MIN. Hành vi này cho phép một số lớp tối ưu hóa quan trọng đối với một số mã. Ví dụ: biết rằng INT_MAX + 1 không xác định cho phép tối ưu hóa "X + 1> X" thành "true". Biết phép nhân tràn "không thể" (vì làm như vậy sẽ không được xác định) cho phép tối ưu hóa "X * 2/2" thành "X". Mặc dù những thứ này có vẻ tầm thường, nhưng những thứ này thường được phơi bày bằng cách mở rộng nội tuyến và vĩ mô. Một tối ưu hóa quan trọng hơn mà điều này cho phép là cho các vòng lặp "<=" như thế này:

for (i = 0; i <= N; ++i) { ... }

Trong vòng lặp này, trình biên dịch có thể giả định rằng vòng lặp sẽ lặp lại chính xác N + 1 lần nếu "i" không được xác định khi tràn, điều này cho phép một phạm vi tối ưu hóa vòng lặp rộng để khởi động. Mặt khác, nếu biến được xác định là quấn quanh tràn, sau đó trình biên dịch phải giả sử rằng vòng lặp có thể là vô hạn (xảy ra nếu N là INT_MAX) - sau đó vô hiệu hóa các tối ưu hóa vòng lặp quan trọng này. Điều này đặc biệt ảnh hưởng đến các nền tảng 64 bit vì rất nhiều mã sử dụng "int" làm biến cảm ứng.

Trong những ngày đầu của C, có rất nhiều hỗn loạn. Trình biên dịch khác nhau đối xử với ngôn ngữ khác nhau. Khi có hứng thú viết một đặc tả cho ngôn ngữ, đặc tả đó sẽ cần tương thích ngược với C mà các lập trình viên đang dựa vào trình biên dịch của họ. Nhưng một số trong những chi tiết đó là không thể mang theo và nói chung không có ý nghĩa, ví dụ như giả sử một bố cục cụ thể hoặc bố cục dữ liệu. Do đó, tiêu chuẩn C bảo lưu rất nhiều chi tiết dưới dạng hành vi không xác định hoặc được chỉ định thực hiện, điều này để lại rất nhiều tính linh hoạt cho người viết trình biên dịch. C ++ xây dựng dựa trên C và cũng có các hành vi không xác định.

Java đã cố gắng trở thành một ngôn ngữ an toàn và đơn giản hơn nhiều so với C ++. Java định nghĩa ngữ nghĩa ngôn ngữ theo nghĩa của một máy ảo kỹ lưỡng. Điều này để lại không gian nhỏ cho hành vi không xác định, mặt khác, nó tạo ra các yêu cầu có thể khó thực hiện Java (ví dụ: các phép gán tham chiếu phải là nguyên tử hoặc cách các số nguyên hoạt động). Trong đó Java hỗ trợ các hoạt động không an toàn tiềm tàng, chúng thường được máy ảo kiểm tra khi chạy (ví dụ: một số phôi).

Các ngôn ngữ JVM và .NET có thể dễ dàng:

1. Họ không phải làm việc trực tiếp với phần cứng.
2. Họ chỉ phải làm việc với các hệ thống máy tính để bàn và máy chủ hiện đại hoặc các thiết bị tương tự hợp lý hoặc ít nhất là các thiết bị được thiết kế cho chúng.
3. Họ có thể áp đặt bộ sưu tập rác cho tất cả bộ nhớ và bắt buộc khởi tạo, do đó có được sự an toàn của con trỏ.
4. Họ được chỉ định bởi một diễn viên duy nhất cũng cung cấp việc thực hiện dứt khoát duy nhất.
5. Họ được chọn để an toàn hơn hiệu suất.

Có những điểm tốt cho các lựa chọn mặc dù:

1. Lập trình hệ thống là một trò chơi hoàn toàn khác, và tối ưu hóa hoàn toàn cho lập trình ứng dụng thay vào đó là hợp lý.
2. Phải thừa nhận rằng, có phần cứng kỳ lạ hơn mọi lúc, nhưng các hệ thống nhúng nhỏ vẫn ở đây.
3. GC không phù hợp với tài nguyên không bị nấm và giao dịch nhiều không gian hơn để có hiệu suất tốt. Và hầu hết (nhưng không phải gần như tất cả) các khởi tạo bắt buộc có thể được tối ưu hóa đi.
4. Có lợi thế để cạnh tranh nhiều hơn, nhưng các ủy ban có nghĩa là thỏa hiệp.
5. Tất cả những giới hạn-kiểm tra làm thêm lên, mặc dù hầu hết có thể được tối ưu hóa đi. Kiểm tra con trỏ Null hầu hết có thể được thực hiện bằng cách bẫy truy cập với chi phí không nhờ vào không gian địa chỉ ảo, mặc dù tối ưu hóa vẫn bị ức chế.

Khi các cửa thoát hiểm được cung cấp, những người mời hành vi không xác định đầy đủ trở lại. Nhưng ít nhất chúng thường chỉ được sử dụng trong một số đoạn rất ngắn, do đó dễ xác minh thủ công hơn.

Java và C # được đặc trưng bởi một nhà cung cấp vượt trội, ít nhất là trong giai đoạn đầu phát triển. (Sun và Microsoft tương ứng). C và C ++ là khác nhau; họ đã có nhiều triển khai cạnh tranh từ sớm. C đặc biệt chạy trên nền tảng phần cứng kỳ lạ, quá. Kết quả là, có sự khác biệt giữa các triển khai. Các ủy ban ISO đã chuẩn hóa C và C ++ có thể đồng ý về mẫu số chung lớn, nhưng ở các cạnh mà việc triển khai khác nhau, các tiêu chuẩn còn lại để thực hiện.

Điều này cũng là bởi vì việc chọn một hành vi có thể tốn kém đối với các kiến ​​trúc phần cứng thiên về một lựa chọn khác - endian là sự lựa chọn rõ ràng.

Lý do thực sự dẫn đến một sự khác biệt cơ bản về ý định giữa C và C ++ trên một mặt và Java và C # (chỉ cho một vài ví dụ) mặt khác. Vì lý do lịch sử, phần lớn các cuộc thảo luận ở đây nói về C thay vì C ++, nhưng (như bạn có thể đã biết) C ++ là hậu duệ khá trực tiếp của C, vì vậy những gì nó nói về C cũng áp dụng tương tự cho C ++.

Mặc dù chúng hầu như bị lãng quên (và sự tồn tại của chúng đôi khi thậm chí bị từ chối), các phiên bản đầu tiên của UNIX được viết bằng ngôn ngữ lắp ráp. Phần lớn (nếu không chỉ) mục đích ban đầu của C là chuyển UNIX từ ngôn ngữ lắp ráp sang ngôn ngữ cấp cao hơn. Một phần của ý định là viết càng nhiều hệ điều hành càng tốt bằng ngôn ngữ cấp cao hơn - hoặc nhìn nó từ hướng khác, để giảm thiểu số lượng phải viết bằng ngôn ngữ lắp ráp.

Để thực hiện điều đó, C cần cung cấp gần như cùng mức truy cập vào phần cứng như ngôn ngữ lắp ráp đã làm. PDP-11 (ví dụ) lấy các thanh ghi I / O ánh xạ tới các địa chỉ cụ thể. Ví dụ: bạn sẽ đọc một vị trí bộ nhớ để kiểm tra xem phím đã được nhấn trên bảng điều khiển hệ thống chưa. Một bit được đặt ở vị trí đó khi có dữ liệu đang chờ để đọc. Sau đó, bạn sẽ đọc một byte từ một vị trí được chỉ định khác để lấy mã ASCII của khóa đã được nhấn.

Tương tự, nếu bạn muốn in một số dữ liệu, bạn sẽ kiểm tra một vị trí được chỉ định khác và khi thiết bị đầu ra đã sẵn sàng, bạn sẽ ghi dữ liệu của mình vào một vị trí được chỉ định khác.

Để hỗ trợ trình điều khiển ghi cho các thiết bị như vậy, C cho phép bạn chỉ định một vị trí tùy ý bằng cách sử dụng một số loại số nguyên, chuyển đổi nó thành một con trỏ và đọc hoặc ghi vị trí đó trong bộ nhớ.

Tất nhiên, điều này có một vấn đề khá nghiêm trọng: không phải mọi cỗ máy trên trái đất đều có bộ nhớ được đặt giống hệt với PDP-11 từ đầu những năm 1970. Vì vậy, khi bạn lấy số nguyên đó, chuyển đổi nó thành một con trỏ, sau đó đọc hoặc viết thông qua con trỏ đó, không ai có thể cung cấp bất kỳ đảm bảo hợp lý nào về những gì bạn sẽ nhận được. Chỉ cần một ví dụ rõ ràng, đọc và viết có thể ánh xạ tới các thanh ghi riêng biệt trong phần cứng, do đó bạn (trái với bộ nhớ thông thường) nếu bạn viết một cái gì đó, sau đó cố gắng đọc lại, những gì bạn đọc có thể không khớp với những gì bạn đã viết.

Tôi có thể thấy một vài khả năng để lại:

1. Xác định giao diện cho tất cả các phần cứng có thể - chỉ định địa chỉ tuyệt đối của tất cả các vị trí bạn có thể muốn đọc hoặc ghi để tương tác với phần cứng theo bất kỳ cách nào.
2. Cấm mức độ truy cập đó và quy định rằng bất kỳ ai muốn làm những việc đó đều cần sử dụng ngôn ngữ lắp ráp.
3. Cho phép mọi người làm điều đó, nhưng để họ đọc (ví dụ) hướng dẫn sử dụng cho phần cứng họ đang nhắm mục tiêu và viết mã để phù hợp với phần cứng họ đang sử dụng.

Trong số này, 1 dường như đủ kích thích mà hầu như không đáng để thảo luận thêm. 2 về cơ bản là vứt bỏ ý định cơ bản của ngôn ngữ. Điều đó khiến cho lựa chọn thứ ba về cơ bản là lựa chọn duy nhất họ có thể cân nhắc hợp lý.

Một điểm khác xuất hiện khá thường xuyên là kích thước của các loại số nguyên. C lấy "vị trí" intphải là kích thước tự nhiên được đề xuất bởi kiến ​​trúc. Vì vậy, nếu tôi đang lập trình VAX 32 bit, intcó thể là 32 bit, nhưng nếu tôi đang lập trình Univac 36 bit, intcó lẽ nên là 36 bit (v.v.). Có lẽ không hợp lý (và thậm chí có thể không khả thi) để viết một hệ điều hành cho máy tính 36 bit chỉ sử dụng các loại được đảm bảo là bội số của 8 bit. Có lẽ tôi chỉ hời hợt, nhưng dường như với tôi rằng nếu tôi đang viết một hệ điều hành cho máy 36 bit, có lẽ tôi muốn sử dụng ngôn ngữ hỗ trợ loại 36 bit.

Từ quan điểm ngôn ngữ, điều này dẫn đến vẫn còn nhiều hành vi không xác định. Nếu tôi lấy giá trị lớn nhất phù hợp với 32 bit, điều gì sẽ xảy ra khi tôi thêm 1? Trên phần cứng 32 bit thông thường, nó sẽ bị trục trặc (hoặc có thể gây ra một số lỗi phần cứng). Mặt khác, nếu nó chạy trên phần cứng 36 bit, nó sẽ chỉ ... thêm một. Nếu ngôn ngữ sẽ hỗ trợ viết hệ điều hành, bạn không thể đảm bảo một trong hai hành vi - bạn chỉ cần cho phép cả kích cỡ của loại và hành vi tràn thay đổi từ loại này sang loại khác.

Java và C # có thể bỏ qua tất cả điều đó. Họ không có ý định hỗ trợ viết hệ điều hành. Với họ, bạn có một vài lựa chọn. Một là làm cho phần cứng hỗ trợ những gì họ yêu cầu - vì họ yêu cầu các loại 8, 16, 32 và 64 bit, chỉ cần xây dựng phần cứng hỗ trợ các kích thước đó. Khả năng rõ ràng khác là ngôn ngữ chỉ chạy trên phần mềm khác cung cấp môi trường họ muốn, bất kể phần cứng cơ bản có thể muốn gì.

Trong hầu hết các trường hợp, đây không thực sự là một hoặc / hoặc sự lựa chọn. Thay vào đó, nhiều triển khai làm một chút của cả hai. Bạn thường chạy Java trên JVM chạy trên hệ điều hành. Thường xuyên hơn không, HĐH được viết bằng C và JVM bằng C ++. Nếu JVM đang chạy trên CPU ARM, rất có thể CPU sẽ bao gồm các phần mở rộng Jazelle của ARM, để điều chỉnh phần cứng chặt chẽ hơn với nhu cầu của Java, do đó, cần phải thực hiện ít hơn trong phần mềm và mã Java chạy nhanh hơn (hoặc ít hơn từ từ, dù sao đi nữa).

Tóm lược

C và C ++ có hành vi không xác định, bởi vì không ai xác định một giải pháp thay thế chấp nhận được cho phép họ thực hiện những gì họ dự định làm. C # và Java có một cách tiếp cận khác, nhưng cách tiếp cận đó không phù hợp (nếu có) với các mục tiêu của C và C ++. Cụ thể, dường như không cung cấp một cách hợp lý để viết phần mềm hệ thống (như hệ điều hành) trên hầu hết các phần cứng được lựa chọn tùy ý. Cả hai thường phụ thuộc vào các cơ sở được cung cấp bởi phần mềm hệ thống hiện có (thường được viết bằng C hoặc C ++) để thực hiện công việc của họ.

Các tác giả của Tiêu chuẩn C mong muốn độc giả của họ nhận ra điều gì đó mà họ cho là hiển nhiên và được ám chỉ trong Cơ sở lý luận đã xuất bản của họ, nhưng không nói thẳng: Ủy ban không cần phải ra lệnh cho các nhà văn biên dịch đáp ứng nhu cầu của khách hàng, vì khách hàng nên biết rõ hơn Ủy ban về nhu cầu của họ. Nếu rõ ràng là các trình biên dịch cho một số loại plaform dự kiến ​​sẽ xử lý một cấu trúc theo một cách nhất định, thì không ai quan tâm liệu Standard có nói rằng cấu trúc đó gọi ra Hành vi không xác định hay không. Tiêu chuẩn không bắt buộc các trình biên dịch tuân thủ xử lý một đoạn mã một cách hữu ích theo cách không ngụ ý rằng các lập trình viên nên sẵn sàng mua các trình biên dịch không.

Cách tiếp cận này để thiết kế ngôn ngữ hoạt động rất tốt trong một thế giới nơi các nhà văn biên dịch cần bán sản phẩm của họ cho khách hàng trả tiền. Nó hoàn toàn sụp đổ trong một thế giới nơi các nhà văn biên dịch bị cô lập khỏi các tác động của thị trường. Người ta nghi ngờ rằng các điều kiện thị trường thích hợp sẽ tồn tại để điều khiển một ngôn ngữ theo cách mà họ đã điều khiển ngôn ngữ trở nên phổ biến vào những năm 1990, và càng nghi ngờ hơn nữa là bất kỳ nhà thiết kế ngôn ngữ lành mạnh nào cũng muốn dựa vào các điều kiện thị trường như vậy.

Cả C ++ và c đều có các tiêu chuẩn mô tả (dù sao cũng là phiên bản ISO).

Mà chỉ tồn tại để giải thích làm thế nào các ngôn ngữ hoạt động, và để cung cấp một tài liệu tham khảo duy nhất về ngôn ngữ là gì. Thông thường, các nhà cung cấp trình biên dịch và các nhà văn thư viện, dẫn đường và một số đề xuất được đưa vào tiêu chuẩn ISO chính.

Java và C # (hoặc Visual C #, mà tôi giả sử bạn muốn nói) có các tiêu chuẩn quy định . Họ cho bạn biết những gì trong ngôn ngữ dứt khoát trước thời hạn, cách thức hoạt động và những gì được coi là hành vi được phép.

Quan trọng hơn thế, Java thực sự có "triển khai tham chiếu" trong Open-JDK. (Tôi nghĩ Roslyn được coi là triển khai tham chiếu Visual C #, nhưng không thể tìm thấy nguồn cho việc đó.)

Trong trường hợp của Java, nếu có bất kỳ sự mơ hồ nào trong tiêu chuẩn và Open-JDK thì đó là một cách nhất định. Cách Open-JDK thực hiện nó là tiêu chuẩn.

Hành vi không xác định cho phép trình biên dịch tạo mã rất hiệu quả trên nhiều kiến ​​trúc sư. Câu trả lời của Erik đề cập đến tối ưu hóa, nhưng nó vượt xa hơn thế.

Ví dụ, tràn tràn đã ký là hành vi không xác định trong C. Trong thực tế, trình biên dịch dự kiến ​​sẽ tạo ra một mã bổ sung được ký đơn giản để CPU thực thi và hành vi sẽ là bất cứ điều gì mà CPU cụ thể đã làm.

Điều đó cho phép C thực hiện rất tốt và tạo ra mã rất nhỏ gọn trên hầu hết các kiến ​​trúc. Nếu tiêu chuẩn đã chỉ định rằng các số nguyên đã ký phải tràn theo một cách nhất định thì các CPU hoạt động khác nhau sẽ cần nhiều mã hơn để tạo ra một bổ sung được ký đơn giản.

Đó là lý do cho phần lớn hành vi không xác định trong C và tại sao những thứ như kích thước intkhác nhau giữa các hệ thống. Intphụ thuộc vào kiến ​​trúc và thường được chọn là loại dữ liệu nhanh nhất, hiệu quả nhất lớn hơn a char.

Trở lại khi C mới, những cân nhắc này rất quan trọng. Máy tính ít mạnh hơn, thường có tốc độ xử lý và bộ nhớ hạn chế. C đã được sử dụng khi hiệu suất thực sự quan trọng và các nhà phát triển dự kiến ​​sẽ hiểu làm thế nào máy tính hoạt động đủ tốt để biết những hành vi không xác định này thực sự sẽ là gì trên các hệ thống cụ thể của họ.

Các ngôn ngữ sau này như Java và C # ưa thích loại bỏ hành vi không xác định so với hiệu suất thô.

Theo một nghĩa nào đó, Java cũng có nó. Giả sử, bạn đã đưa ra bộ so sánh không chính xác với Arrays.sort. Nó có thể ném ngoại lệ của nó phát hiện ra nó. Nếu không, nó sẽ sắp xếp một mảng theo một cách nào đó không được đảm bảo là bất kỳ cụ thể.

Tương tự như vậy nếu bạn sửa đổi biến từ một số chủ đề kết quả cũng không thể đoán trước.

C ++ chỉ đi xa hơn để tạo ra nhiều tình huống không xác định (hay đúng hơn là java đã quyết định xác định thêm các hoạt động) và để đặt tên cho nó.