Các thực hành tốt nhất liên quan đến ints không dấu là gì?

Tôi sử dụng số nguyên không dấu ở khắp mọi nơi và tôi không chắc mình có nên không. Điều này có thể từ các cột id khóa chính của cơ sở dữ liệu đến các bộ đếm, v.v ... Nếu một số không bao giờ âm, thì tôi sẽ luôn sử dụng một số nguyên không dấu.

Tuy nhiên tôi nhận thấy từ mã của người khác rằng dường như không ai khác làm điều này. Có điều gì quan trọng mà tôi đang xem không?

Chỉnh sửa: Vì câu hỏi này tôi cũng nhận thấy rằng trong C, việc trả về các giá trị âm cho lỗi là phổ biến thay vì đưa ra các ngoại lệ như trong C ++.

Có điều gì quan trọng mà tôi đang xem không?

Khi các tính toán liên quan đến cả loại đã ký và loại không dấu cũng như các kích thước khác nhau, các quy tắc cho quảng cáo loại có thể phức tạp và dẫn đến hành vi không mong muốn .

Tôi tin rằng đây là lý do chính tại sao Java bỏ qua các kiểu int không dấu.

Tôi nghĩ rằng Michael có một điểm hợp lệ, nhưng IMO lý do tại sao mọi người sử dụng int mọi lúc (đặc biệt là for (int i = 0; i < max, i++) là chúng tôi đã học được theo cách đó. Khi mỗi ví dụ đơn lẻ trong một cuốn sách ' làm thế nào để học lập trình ' sử dụng inttrong một forvòng lặp, rất ít người sẽ đặt câu hỏi cho việc thực hành đó.

Lý do khác là nó intngắn hơn 25% uintvà tất cả chúng ta đều lười biếng ... ;-)

Mã hóa thông tin phạm vi thành các loại là Một điều tốt. Nó thực thi sử dụng số hợp lý tại thời gian biên dịch.

Nhiều kiến ​​trúc dường như có các hướng dẫn chuyên biệt để xử lý int-> floatchuyển đổi. Việc chuyển đổi từ unsignedcó thể chậm hơn (một chút xíu) .

Trộn các loại có chữ ký và không dấu có thể đưa bạn vào một thế giới đau khổ. Và bạn không thể sử dụng tất cả các loại không dấu vì bạn sẽ gặp những thứ có phạm vi hợp lệ bao gồm số âm hoặc cần một giá trị để chỉ ra lỗi và -1 là tự nhiên nhất. Vì vậy, kết quả cuối cùng là nhiều lập trình viên sử dụng tất cả các loại số nguyên đã ký.

Đối với tôi các loại là nhiều về giao tiếp. Bằng cách sử dụng một cách rõ ràng một int unsign bạn nói với tôi rằng các giá trị đã ký không phải là giá trị hợp lệ. Điều này cho phép tôi thêm một số thông tin khi đọc mã của bạn ngoài tên biến. Lý tưởng nhất là một loại không ẩn danh sẽ cho tôi biết nhiều hơn, nhưng nó cung cấp cho tôi nhiều thông tin hơn nếu bạn đã sử dụng ints ở mọi nơi.

Thật không may, không phải ai cũng rất ý thức về những gì mã của họ truyền đạt, và đó có lẽ là lý do bạn thấy ints ở khắp mọi nơi mặc dù các giá trị ít nhất là không dấu.

Tôi sử dụng unsigned inttrong C ++ cho các chỉ số mảng, chủ yếu và cho bất kỳ bộ đếm nào bắt đầu từ 0. Tôi nghĩ rằng thật tốt khi nói rõ ràng "biến này không thể âm".

Bạn nên quan tâm đến điều này khi bạn đang xử lý một số nguyên thực sự có thể tiếp cận hoặc vượt quá giới hạn của một số nguyên đã ký. Vì mức tối đa dương của số nguyên 32 bit là 2.147.483.647, nên bạn nên sử dụng số nguyên không dấu nếu bạn biết nó sẽ không bao giờ âm và b) có thể đạt 2.147.483.648. Trong hầu hết các trường hợp, bao gồm các khóa và bộ đếm cơ sở dữ liệu, tôi thậm chí sẽ không bao giờ tiếp cận các loại số này vì vậy tôi không bận tâm đến việc lo lắng liệu bit dấu được sử dụng cho một giá trị số hay để chỉ ra dấu hiệu.

Tôi sẽ nói: sử dụng int trừ khi bạn biết bạn cần một số nguyên không dấu.

Đó là sự đánh đổi giữa sự đơn giản và độ tin cậy. Càng nhiều lỗi có thể bị bắt tại thời điểm biên dịch, phần mềm càng đáng tin cậy. Những người và tổ chức khác nhau ở những điểm khác nhau dọc theo quang phổ đó.

Nếu bạn từng thực hiện bất kỳ chương trình có độ tin cậy cao nào trong Ada, bạn thậm chí sử dụng các loại khác nhau cho các biến như khoảng cách tính bằng feet so với khoảng cách tính bằng mét và trình biên dịch gắn cờ nó nếu bạn vô tình gán cái này cho cái kia. Điều đó hoàn hảo để lập trình một tên lửa dẫn đường, nhưng quá mức cần thiết (ý định chơi chữ) nếu bạn xác nhận một biểu mẫu web. Không nhất thiết có bất cứ điều gì sai với bất kỳ cách nào miễn là phù hợp với yêu cầu.

Tôi có khuynh hướng đồng ý với lý luận của Joel Etherton, nhưng đi đến kết luận ngược lại. Theo cách tôi nhìn thấy, ngay cả khi bạn biết rằng các con số không bao giờ đạt đến giới hạn của loại đã ký, nếu bạn biết rằng số âm sẽ không xảy ra, thì có rất ít lý do để sử dụng biến thể đã ký của loại.

Vì lý do tương tự tại sao tôi có, trong một vài trường hợp chọn, được sử dụng BIGINT(số nguyên 64 bit) thay vì INTEGER(số nguyên 32 bit) trong các bảng SQL Server. Xác suất dữ liệu sẽ đạt đến giới hạn 32 bit trong bất kỳ khoảng thời gian hợp lý nào là rất nhỏ, nhưng nếu nó xảy ra, hậu quả trong một số tình huống có thể rất nghiêm trọng. Chỉ cần chắc chắn ánh xạ các loại giữa các ngôn ngữ một cách chính xác, hoặc bạn sẽ kết thúc với sự kỳ lạ thú vị thực sự ở phía xa ...

Điều đó nói rằng, đối với một số thứ, chẳng hạn như các giá trị khóa chính của cơ sở dữ liệu, đã ký hoặc không dấu thực sự không thành vấn đề, bởi vì trừ khi bạn đang tự sửa chữa dữ liệu bị hỏng hoặc một cái gì đó dọc theo các dòng đó, bạn sẽ không bao giờ xử lý trực tiếp giá trị; nó là một định danh, không có gì hơn. Trong những trường hợp đó, tính nhất quán có lẽ quan trọng hơn sự lựa chọn chính xác của chữ ký. Mặt khác, bạn kết thúc với một số cột khóa ngoại được ký và các cột khác không dấu, không có mẫu rõ ràng cho nó - hoặc sự kỳ lạ thú vị đó một lần nữa.

Tôi muốn khuyến nghị rằng các bối cảnh lưu trữ dữ liệu và trao đổi dữ liệu bị hạn chế ngoài không gian, người ta thường nên sử dụng các loại đã ký. Trong hầu hết các trường hợp số nguyên có chữ ký 32 bit quá nhỏ nhưng giá trị không dấu 32 bit sẽ đủ cho ngày hôm nay, sẽ không lâu nữa trước khi giá trị không dấu 32 bit không đủ lớn.

Lần đầu tiên người ta nên sử dụng các loại không dấu là khi một trong hai tập hợp nhiều giá trị thành một giá trị lớn hơn (ví dụ: chuyển đổi bốn byte thành số 32 bit) hoặc phân tách các giá trị lớn hơn thành các giá trị nhỏ hơn (ví dụ: lưu trữ một số 32 bit thành bốn byte ) hoặc khi một người có số lượng dự kiến ​​sẽ "lăn" theo định kỳ và người ta cần phải đối phó với nó (nghĩ về đồng hồ tiện ích dân cư; hầu hết trong số họ có đủ chữ số để đảm bảo rằng họ sẽ không thể cuộn giữa các lần đọc nếu họ đọc ba lần một năm, nhưng không đủ để đảm bảo họ sẽ không lăn lộn trong vòng đời hữu ích của máy đo). Các loại không được ký thường có đủ 'sự kỳ lạ' mà chúng chỉ nên được sử dụng trong trường hợp ngữ nghĩa của chúng là cần thiết.

Tôi sử dụng ints không dấu để làm cho mã của tôi và ý định của nó rõ ràng hơn. Một điều tôi làm để bảo vệ chống lại các chuyển đổi ngầm bất ngờ khi thực hiện số học với cả hai loại đã ký và không dấu là sử dụng một ký hiệu ngắn không dấu (thường là 2 byte) cho các biến không dấu của tôi. Điều này có hiệu quả vì một vài lý do:

• Khi bạn thực hiện số học với các biến và ký tự ngắn không dấu (thuộc kiểu int) hoặc biến kiểu int, điều này đảm bảo biến không dấu sẽ luôn được thăng cấp thành int trước khi đánh giá biểu thức, vì int luôn có thứ hạng cao hơn ngắn . Điều này tránh mọi hành vi không mong muốn thực hiện số học với các loại đã ký và không dấu, giả sử kết quả của biểu thức phù hợp với một int đã ký tất nhiên.
• Hầu hết thời gian, các biến không dấu mà bạn đang sử dụng sẽ không vượt quá giá trị tối đa của một byte ngắn 2 byte không dấu (65,535)

Nguyên tắc chung là loại biến không dấu của bạn phải có thứ hạng thấp hơn loại biến được ký để đảm bảo thăng hạng cho loại đã ký. Sau đó, bạn sẽ không có bất kỳ hành vi tràn bất ngờ. Rõ ràng là bạn không thể đảm bảo điều này mọi lúc, nhưng (hầu hết) thường là khả thi để đảm bảo điều này.

Ví dụ, gần đây tôi có một số vòng lặp như thế này:

const unsigned short cuint = 5;
for(unsigned short i=0; i<10; ++i)
{
    if((i-2)%cuint == 0)
    {
       //Do something
    }
}

Chữ "2" theo kiểu int. Nếu tôi là một số nguyên không dấu thay vì một ký hiệu không dấu, thì trong biểu thức con (i-2), 2 sẽ được thăng cấp thành một số không dấu (vì số nguyên không dấu có mức độ ưu tiên cao hơn số nguyên được ký). Nếu i = 0, thì biểu thức con bằng (0u-2u) = một số giá trị lớn do tràn. Cùng một ý tưởng với i = 1. Tuy nhiên, vì tôi là một dấu ngắn không dấu, nên nó được quảng cáo cùng loại với nghĩa đen là '2', được ký tên int và mọi thứ đều hoạt động tốt.

Để an toàn hơn: trong trường hợp hiếm khi kiến ​​trúc bạn triển khai với nguyên nhân int là 2 byte, điều này có thể khiến cả hai toán hạng trong biểu thức số học được thăng cấp thành int unsign trong trường hợp biến ngắn không dấu không khớp vào int 2 byte đã ký, cái sau có giá trị tối đa là 32.767 <65.535. (Xem https://stackoverflow.com/questions/17832815/c-implicit-conversion-sign-unign để biết thêm chi tiết). Để chống lại điều này, bạn chỉ cần thêm static_assert vào chương trình của mình như sau:

static_assert(sizeof(int) == 4, "int must be 4 bytes");

và nó sẽ không biên dịch trên các kiến ​​trúc trong đó int là 2 byte.