byte + byte = int mật tại sao?

Nhìn vào mã C # này:

byte x = 1;
byte y = 2;
byte z = x + y; // ERROR: Cannot implicitly convert type 'int' to 'byte'

Kết quả của bất kỳ phép toán nào được thực hiện trên các loại byte(hoặc short) đều được truyền lại thành một số nguyên. Giải pháp là đưa kết quả rõ ràng trở lại một byte:

byte z = (byte)(x + y); // this works

Điều tôi đang tự hỏi là tại sao? Có phải kiến ​​trúc không? Triết học?

Chúng ta có:

• int+ int=int
• long+ long=long
• float+ float=float
• double+ double=double

Vậy tại sao không:

• byte+ byte=byte
• short+ short= short?

Một chút nền tảng: Tôi đang thực hiện một danh sách dài các phép tính trên "số nhỏ" (tức là <8) và lưu trữ các kết quả trung gian trong một mảng lớn. Sử dụng một mảng byte (thay vì một mảng int) sẽ nhanh hơn (vì các lần truy cập bộ đệm). Nhưng các byte byte rộng rãi trải đều qua mã làm cho nó khó đọc hơn nhiều.

Dòng thứ ba của đoạn mã của bạn:

byte z = x + y;

thực sự có nghĩa là

byte z = (int) x + (int) y;

Vì vậy, không có thao tác + nào trên byte, byte được truyền đầu tiên cho số nguyên và kết quả của việc thêm hai số nguyên là số nguyên (32 bit).

Xét về "tại sao nó lại xảy ra" bởi vì không có toán tử nào được định nghĩa bởi C # cho số học với byte, sbyte, short hoặc ushort, như những người khác đã nói. Câu trả lời này là về lý do tại sao các toán tử không được xác định.

Tôi tin rằng về cơ bản là vì lợi ích của hiệu suất. Bộ xử lý có các hoạt động gốc để thực hiện số học với 32 bit rất nhanh. Làm mặt sau chuyển đổi từ kết quả vào một byte tự động có thể được thực hiện, nhưng sẽ dẫn đến hình phạt hiệu suất trong trường hợp bạn không thực sự muốn hành vi đó.

Tôi nghĩ rằng điều này được đề cập trong một trong các tiêu chuẩn C # có chú thích. Đang nhìn...

EDIT: Thật khó chịu, bây giờ tôi đã xem qua thông số ECMA C # 2 được chú thích, thông số MS C # 3 được chú thích và thông số CLI chú thích, và không ai trong số họ đề cập đến điều này như tôi có thể thấy. Tôi chắc chắn tôi đã thấy lý do được đưa ra ở trên, nhưng tôi bị thổi bay nếu tôi biết nơi nào. Lời xin lỗi, người hâm mộ tham khảo :(

Tôi nghĩ rằng tôi đã thấy điều này ở đâu đó trước đây. Từ bài viết này, Điều mới cũ :

Giả sử chúng ta sống trong một thế giới ảo mộng nơi các hoạt động trên 'byte' dẫn đến 'byte'.

byte b = 32;
byte c = 240;
int i = b + c; // what is i?

Trong thế giới giả tưởng này, giá trị của tôi sẽ là 16! Tại sao? Do hai toán hạng cho toán tử + đều là byte, nên tổng "b + c" được tính là một byte, kết quả là 16 do tràn số nguyên. (Và, như tôi đã lưu ý trước đó, tràn số nguyên là vectơ tấn công bảo mật mới.)

EDIT : Raymond đang bảo vệ, về cơ bản, cách tiếp cận C và C ++ đã thực hiện ban đầu. Trong các bình luận, ông bảo vệ thực tế rằng C # có cùng cách tiếp cận, với lý do tương thích ngược ngôn ngữ.

C #

ECMA-334 nói rằng bổ sung chỉ được xác định là hợp pháp trên int + int, uint + uint, long + long và ulong + ulong (ECMA-334 14.7.4). Như vậy, đây là các hoạt động ứng cử viên được xem xét liên quan đến 14.4.2. Do có các hàm ẩn từ byte đến int, uint, long và ulong, tất cả các thành viên hàm bổ sung đều là các thành viên hàm áp dụng theo 14.4.2.1. Chúng ta phải tìm ra diễn viên ngầm tốt nhất theo quy tắc trong 14.4.2.3:

Đúc (C1) thành int (T1) tốt hơn so với truyền (C2) sang uint (T2) hoặc ulong (T2) vì:

• Nếu T1 là int và T2 là uint hoặc ulong, C1 là chuyển đổi tốt hơn.

Truyền (C1) sang int (T1) tốt hơn so với truyền (C2) sang dài (T2) vì có một truyền ẩn từ int đến dài:

• Nếu một chuyển đổi ngầm định từ T1 sang T2 tồn tại và không tồn tại chuyển đổi ngầm định từ T2 sang T1, thì C1 là chuyển đổi tốt hơn.

Do đó hàm int + int được sử dụng, trả về một int.

Đó là tất cả một cách rất dài để nói rằng nó bị chôn vùi rất sâu trong đặc tả C #.

CLI

CLI chỉ hoạt động trên 6 loại (int32, int int, int64, F, O và &). (Phân vùng ECMA-335 3 phần 1.5)

Byte (int8) không phải là một trong những loại đó và được tự động ép buộc vào int32 trước khi bổ sung. (Phân vùng ECMA-335 3 phần 1.6)

Các câu trả lời chỉ ra một số không hiệu quả khi thêm byte và cắt bớt kết quả trở lại một byte là không chính xác. Bộ xử lý x86 có các hướng dẫn được thiết kế riêng cho hoạt động số nguyên trên số lượng 8 bit.

Trong thực tế, đối với các bộ xử lý x86 / 64, thực hiện các hoạt động 32 bit hoặc 16 bit kém hiệu quả hơn các hoạt động 64 bit hoặc 8 bit do byte tiền tố toán hạng phải được giải mã. Trên các máy 32 bit, thực hiện các hoạt động 16 bit đòi hỏi một hình phạt tương tự, nhưng vẫn có các opcode chuyên dụng cho các hoạt động 8 bit.

Nhiều kiến ​​trúc RISC có các hướng dẫn hiệu quả từ / byte tương tự. Những người thường không có cửa hàng và chuyển đổi thành giá trị đã ký của một số bit.

Nói cách khác, quyết định này phải được dựa trên nhận thức về loại byte dùng để làm gì, không phải do sự thiếu hiệu quả cơ bản của phần cứng.

Tôi nhớ một lần đọc một cái gì đó từ Jon Skeet (không thể tìm thấy nó bây giờ, tôi sẽ tiếp tục tìm kiếm) về cách byte không thực sự quá tải toán tử +. Trong thực tế, khi thêm hai byte như trong mẫu của bạn, mỗi byte thực sự đang được chuyển đổi hoàn toàn thành int. Kết quả của điều đó rõ ràng là một int. Bây giờ là TẠI SAO cái này được thiết kế theo cách này, tôi sẽ đợi Jon Skeet tự đăng bài :)

EDIT: Tìm thấy nó! Thông tin tuyệt vời về chính chủ đề này ở đây .

Điều này là do tràn và mang.

Nếu bạn thêm hai số 8 bit, chúng có thể tràn vào bit thứ 9.

Thí dụ:

  1111 1111
+ 0000 0001
-----------
1 0000 0000

Tôi không biết chắc chắn, nhưng tôi cho rằng ints, longsvà doublesđược cung cấp nhiều không gian hơn, vì họ là khá lớn vì nó là. Ngoài ra, chúng là bội số của 4, hiệu quả hơn cho máy tính để xử lý, do độ rộng của bus dữ liệu bên trong là 4 byte hoặc 32 bit (hiện tại 64 bit đang trở nên phổ biến hơn). Byte và short thì kém hiệu quả hơn một chút, nhưng chúng có thể tiết kiệm không gian.

Từ thông số ngôn ngữ C # 1.6.7.5 7.2.6.2 Các chương trình khuyến mãi số nhị phân, nó chuyển đổi cả hai toán hạng thành int nếu không thể điều chỉnh nó thành một số loại khác. Tôi đoán là họ đã không làm quá tải toán tử + để lấy byte làm tham số nhưng muốn nó hoạt động hơi bình thường để họ chỉ sử dụng kiểu dữ liệu int.

Ngôn ngữ C # Spec

Sự nghi ngờ của tôi là C # là thực sự gọi operator+được xác định trên int(mà trả về một inttrừ khi bạn đang ở trong một checkedkhối), và ngầm đúc cả hai bạn bytes/ shortsđến ints. Đó là lý do tại sao hành vi xuất hiện không nhất quán.

Đây có lẽ là một quyết định thực tế về phía các nhà thiết kế ngôn ngữ. Xét cho cùng, một int là một Int32, một số nguyên có chữ ký 32 bit. Bất cứ khi nào bạn thực hiện một thao tác số nguyên trên một loại nhỏ hơn int, nó sẽ được chuyển đổi thành int 32 bit được ký bởi hầu hết mọi CPU 32 bit. Điều đó, kết hợp với khả năng tràn các số nguyên nhỏ, có thể đã niêm phong thỏa thuận. Nó tiết kiệm cho bạn khỏi công việc liên tục kiểm tra dòng chảy quá mức và khi kết quả cuối cùng của một biểu thức trên byte sẽ nằm trong phạm vi, mặc dù thực tế là ở giai đoạn trung gian nào đó sẽ nằm ngoài phạm vi, bạn sẽ hiểu đúng kết quả.

Một suy nghĩ khác: Dòng chảy trên / dưới của các loại này sẽ phải được mô phỏng, vì nó sẽ không xảy ra một cách tự nhiên trên các CPU mục tiêu có khả năng nhất. Quan tâm làm gì?

Đây là phần lớn câu trả lời của tôi liên quan đến chủ đề này, được gửi đầu tiên cho một câu hỏi tương tự ở đây .

Tất cả các hoạt động với số nguyên nhỏ hơn Int32 được làm tròn lên đến 32 bit trước khi tính toán theo mặc định. Lý do tại sao kết quả là Int32 chỉ đơn giản là để nó như sau khi tính toán. Nếu bạn kiểm tra các opcode số học MSIL, loại số nguyên duy nhất mà chúng hoạt động là Int32 và Int64. Đó là "theo thiết kế".

Nếu bạn mong muốn kết quả trở lại ở định dạng Int16, sẽ không liên quan nếu bạn thực hiện việc truyền mã, hoặc trình biên dịch (theo giả thuyết) phát ra chuyển đổi "dưới mui xe".

Ví dụ: để làm số học Int16:

short a = 2, b = 3;

short c = (short) (a + b);

Hai số sẽ mở rộng thành 32 bit, được thêm vào, sau đó rút ngắn lại thành 16 bit, đó là cách MS dự định.

Ưu điểm của việc sử dụng ngắn (hoặc byte) chủ yếu là lưu trữ trong trường hợp bạn có lượng dữ liệu khổng lồ (dữ liệu đồ họa, phát trực tuyến, v.v.)

Bổ sung không được xác định cho byte. Vì vậy, họ được chọn để int cho bổ sung. Điều này đúng cho hầu hết các phép toán và byte. (lưu ý đây là cách nó được sử dụng trong các ngôn ngữ cũ hơn, tôi giả sử rằng nó giữ đúng ngày hôm nay).

Tôi nghĩ đó là một sự phân rã thiết kế về hoạt động nào phổ biến hơn ... Nếu byte + byte = byte có thể sẽ có nhiều người bị làm phiền hơn khi phải truyền vào int khi yêu cầu int.

Từ mã .NET Framework:

// bytes
private static object AddByte(byte Left, byte Right)
{
    short num = (short) (Left + Right);
    if (num > 0xff)
    {
        return num;
    }
    return (byte) num;
}

// shorts (int16)
private static object AddInt16(short Left, short Right)
{
    int num = Left + Right;
    if ((num <= 0x7fff) && (num >= -32768))
    {
        return (short) num;
    }
    return num;
}

Đơn giản hóa với .NET 3.5 trở lên:

public static class Extensions 
{
    public static byte Add(this byte a, byte b)
    {
        return (byte)(a + b);
    }
}

bây giờ bạn có thể làm:

byte a = 1, b = 2, c;
c = a.Add(b);

Tôi đã kiểm tra hiệu năng giữa byte và int.
Với các giá trị int:

class Program
{
    private int a,b,c,d,e,f;

    public Program()
    {
        a = 1;
        b = 2;
        c = (a + b);
        d = (a - b);
        e = (b / a);
        f = (c * b);
    }

    static void Main(string[] args)
    {
        int max = 10000000;
        DateTime start = DateTime.Now;
        Program[] tab = new Program[max];

        for (int i = 0; i < max; i++)
        {
            tab[i] = new Program();
        }
        DateTime stop = DateTime.Now;

        Debug.WriteLine(stop.Subtract(start).TotalSeconds);
    }
}

Với các giá trị byte:

class Program
{
    private byte a,b,c,d,e,f;

    public Program()
    {
        a = 1;
        b = 2;
        c = (byte)(a + b);
        d = (byte)(a - b);
        e = (byte)(b / a);
        f = (byte)(c * b);
    }

    static void Main(string[] args)
    {
        int max = 10000000;
        DateTime start = DateTime.Now;
        Program[] tab = new Program[max];

        for (int i = 0; i < max; i++)
        {
            tab[i] = new Program();
        }
        DateTime stop = DateTime.Now;

        Debug.WriteLine(stop.Subtract(start).TotalSeconds);
    }
}

Đây là kết quả:
byte: 3.57s 157mo, 3.71s 171mo, 3.74s 168mo với CPU ~ = 30%
int: 4.05s 298mo, 3.92s 278mo, 4.28 294mo với CPU ~ = 27%
Kết luận:
byte sử dụng nhiều CPU hơn nhưng nó chi phí bộ nhớ les và nó nhanh hơn (có thể vì có ít byte hơn để phân bổ)

Ngoài tất cả các bình luận tuyệt vời khác, tôi nghĩ rằng tôi sẽ thêm một mẩu tin nhỏ. Rất nhiều ý kiến ​​đã tự hỏi tại sao int, dài và khá nhiều loại số khác không tuân theo quy tắc này ... trả về một loại "lớn hơn" để đáp ứng với lý thuyết.

Rất nhiều câu trả lời đã được thực hiện với hiệu suất (tốt, 32 bit nhanh hơn 8 bit). Trong thực tế, số 8 bit vẫn là số 32 bit cho CPU 32 bit .... ngay cả khi bạn thêm hai byte, khối dữ liệu mà cpu hoạt động sẽ là 32 bit bất kể ... vì vậy việc thêm ints sẽ không xảy ra là bất kỳ "nhanh hơn" so với việc thêm hai byte ... tất cả đều giống nhau cho cpu. NGAY BÂY GIỜ, việc thêm hai int SILL nhanh hơn so với việc thêm hai độ dài trên bộ xử lý 32 bit, bởi vì thêm hai độ dài cần nhiều vi mạch hơn vì bạn đang làm việc với số rộng hơn từ bộ xử lý.

Tôi nghĩ lý do cơ bản khiến việc tính toán số học byte dẫn đến kết quả là khá rõ ràng và dễ hiểu: 8 bit chỉ không đi quá xa! : D Với 8 bit, bạn có phạm vi không dấu là 0-255. Đó không phải là là toàn bộ để làm việc với ... khả năng bạn sẽ gặp phải giới hạn byte là RẤT cao khi sử dụng chúng trong số học. Tuy nhiên, khả năng bạn sẽ hết bit khi làm việc với ints, hoặc long, hoặc double, v.v ... thấp hơn đáng kể ... đủ thấp để chúng tôi hiếm khi gặp phải nhu cầu nhiều hơn.

Tự động chuyển đổi từ byte sang int là hợp lý vì quy mô của một byte quá nhỏ. Tự động chuyển đổi từ int sang dài, float sang double, v.v. là không hợp lý vì những con số đó có quy mô đáng kể.