byte + byte = int ... perché?

Guardando questo codice C #:

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

Il risultato di qualsiasi matematica eseguita su byte(o short) tipi viene implicitamente ricondotto a un numero intero. La soluzione è quella di riportare esplicitamente il risultato su un byte:

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

Quello che mi chiedo è perché? È architettonico? Filosofico?

Abbiamo:

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

Quindi perche no:

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

Un po 'di background: sto eseguendo un lungo elenco di calcoli su "piccoli numeri" (cioè <8) e memorizzando i risultati intermedi in un array di grandi dimensioni. L'uso di un array di byte (anziché di un array int) è più rapido (a causa degli accessi alla cache). Ma gli estesi byte cast diffusi attraverso il codice lo rendono molto più illeggibile.

La terza riga dello snippet di codice:

byte z = x + y;

in realtà significa

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

Pertanto, non vi è alcuna operazione + sui byte, i byte vengono prima espressi in numeri interi e il risultato dell'aggiunta di due numeri interi è un numero intero (a 32 bit).

In termini di "perché succede affatto" è perché non ci sono operatori definiti da C # per l'aritmetica con byte, sbyte, short o ushort, proprio come altri hanno già detto. Questa risposta spiega perché questi operatori non sono definiti.

Credo che sia fondamentalmente per motivi di performance. I processori hanno operazioni native per eseguire l'aritmetica con 32 bit molto rapidamente. Fare la parte posteriore di conversione dal risultato a un byte automaticamente poteva essere fatto, ma si tradurrebbe in sanzioni prestazioni nel caso in cui non si vuole realmente che il comportamento.

Penso che questo sia menzionato in uno degli standard C # annotati. Guardare...

EDIT: Stranamente, ora ho guardato attraverso le specifiche annotate ECMA C # 2, le specifiche annotate MS C # 3 e le specifiche CLI delle annotazioni, e nessuno di loro ne parla per quanto posso vedere. Sono sicuro di aver visto il motivo indicato sopra, ma sono colpito se so dove. Scuse, fan di riferimento :(

Ho pensato che avevo visto da qualche parte prima. Da questo articolo, The Old New Thing :

Supponiamo di vivere in un mondo fantastico in cui le operazioni su "byte" hanno portato a "byte".

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

In questo mondo fantastico, il valore di I sarebbe 16! Perché? Poiché i due operandi per l'operatore + sono entrambi byte, la somma "b + c" viene calcolata come un byte, che risulta in 16 a causa dell'overflow dei numeri interi. (E, come ho notato prima, l'overflow dei numeri interi è il nuovo vettore di attacco di sicurezza.)

EDIT : Raymond sta difendendo, in sostanza, l'approccio C e C ++ inizialmente adottato. Nei commenti, difende il fatto che C # adotti lo stesso approccio, sulla base della compatibilità con le versioni precedenti del linguaggio.

C #

ECMA-334 afferma che l'addizione è definita come legale solo su int + int, uint + uint, long + long e ulong + ulong (ECMA-334 14.7.4). Pertanto, queste sono le operazioni candidate da prendere in considerazione rispetto al 14.4.2. Poiché vi sono cast impliciti da byte a int, uint, long e ulong, tutti i membri della funzione di addizione sono membri della funzione applicabili in 14.4.2.1. Dobbiamo trovare il miglior cast implicito dalle regole in 14.4.2.3:

Lanciare (C1) su int (T1) è meglio che lanciare (C2) su uint (T2) o ulong (T2) perché:

• Se T1 è int e T2 è uint o ulong, C1 è la conversione migliore.

Casting (C1) in int (T1) è meglio che casting (C2) in long (T2) perché esiste un cast implicito da int a long:

• Se esiste una conversione implicita da T1 a T2 e non esiste alcuna conversione implicita da T2 a T1, C1 è la conversione migliore.

Quindi viene utilizzata la funzione int + int, che restituisce un int.

Il che è un modo molto lungo per dire che è sepolto molto in profondità nelle specifiche C #.

CLI

L'interfaccia della riga di comando funziona solo su 6 tipi (int32, int nativo, int64, F, O e &). (ECMA-335 partizione 3 sezione 1.5)

Il byte (int8) non è uno di quei tipi e viene automaticamente forzato a un int32 prima dell'aggiunta. (ECMA-335 partizione 3 sezione 1.6)

Le risposte che indicano una certa inefficienza nell'aggiungere byte e nel troncare il risultato in un byte sono errate. I processori x86 hanno istruzioni appositamente progettate per il funzionamento di numeri interi su quantità di 8 bit.

In effetti, per i processori x86 / 64, l'esecuzione di operazioni a 32 o 16 bit è meno efficiente delle operazioni a 64 o 8 bit a causa del byte del prefisso dell'operando che deve essere decodificato. Su macchine a 32 bit, l'esecuzione di operazioni a 16 bit comporta la stessa penalità, ma ci sono ancora codici operativi dedicati per operazioni a 8 bit.

Molte architetture RISC hanno simili istruzioni efficienti word / byte native. Quelli che generalmente non hanno un valore store-and-convert-to-firmato-value-of-some-bit-length.

In altre parole, questa decisione deve essere stata basata sulla percezione di ciò a cui il tipo di byte serve, non a causa delle inefficienze sottostanti dell'hardware.

Ricordo che una volta ho letto qualcosa da Jon Skeet (non riesco a trovarlo ora, continuerò a cercare) su come byte in realtà non sovraccarica l'operatore +. In effetti, quando si aggiungono due byte come nell'esempio, ogni byte viene effettivamente convertito implicitamente in un int. Il risultato è ovviamente un int. Ora per quanto riguarda il PERCHÉ è stato progettato in questo modo, aspetterò che Jon Skeet stesso pubblichi :)

EDIT: Trovato! Grandi informazioni su questo argomento qui .

Ciò è dovuto al troppo pieno e al trasporto.

Se si aggiungono due numeri a 8 bit, potrebbero traboccare nel nono bit.

Esempio:

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

Non lo so per certo, ma suppongo che ints, longse doublessono date più spazio, perché sono abbastanza grandi così com'è. Inoltre, sono multipli di 4, che sono più efficienti da gestire per i computer, poiché la larghezza del bus dati interno è di 4 byte o 32 bit (64 bit sta diventando più diffuso ora). Byte e short sono un po 'più inefficienti, ma possono risparmiare spazio.

Dalle specifiche del linguaggio C # 1.6.7.5 7.2.6.2 Promozioni numeriche binarie converte entrambi gli operandi in int se non è possibile inserirli in diverse altre categorie. La mia ipotesi è che non hanno sovraccaricato l'operatore + per prendere il byte come parametro, ma vogliono che agisca in qualche modo normalmente, quindi usano solo il tipo di dati int.

Linguaggio C # Spec

Il mio sospetto è che C # stia effettivamente chiamando il operator+definito on int(che restituisce un a intmeno che tu non sia in un checkedblocco), e implicitamente lanciando entrambi i tuoi bytes/ shortsa ints. Ecco perché il comportamento appare incoerente.

Questa è stata probabilmente una decisione pratica da parte dei progettisti del linguaggio. Dopotutto, un int è un Int32, un intero con segno a 32 bit. Ogni volta che si esegue un'operazione intera su un tipo più piccolo di int, verrà comunque convertito in un int con segno a 32 bit dalla maggior parte delle CPU a 32 bit. Ciò, combinato con la probabilità di traboccare piccoli numeri interi, probabilmente ha sigillato l'affare. Ti salva dal lavoro di controllo continuo di over / under-flow e quando il risultato finale di un'espressione su byte sarebbe nel range, nonostante il fatto che in qualche stadio intermedio sarebbe fuori range, ottieni un corretto risultato.

Un altro pensiero: il over / under-flow su questi tipi dovrebbe essere simulato, poiché non si verificherebbe naturalmente sulle CPU target più probabili. Perché preoccuparsi?

Questa è per la maggior parte la mia risposta relativa a questo argomento, presentata prima a una domanda simile qui .

Tutte le operazioni con numeri interi inferiori a Int32 vengono arrotondate fino a 32 bit prima del calcolo per impostazione predefinita. Il motivo per cui il risultato è Int32 è semplicemente lasciarlo così com'è dopo il calcolo. Se si controllano i codici operativi aritmetici MSIL, gli unici tipi numerici integrali con cui operano sono Int32 e Int64. È "di progettazione".

Se desideri il risultato nel formato Int16, è irrilevante se esegui il cast nel codice, o il compilatore (ipoteticamente) emette la conversione "sotto il cofano".

Ad esempio, per eseguire l'aritmetica Int16:

short a = 2, b = 3;

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

I due numeri si espanderebbero a 32 bit, verrebbero aggiunti, quindi troncati di nuovo a 16 bit, come MS intendeva che fosse.

Il vantaggio dell'uso di short (o byte) è principalmente l'archiviazione nei casi in cui si disponga di enormi quantità di dati (dati grafici, streaming, ecc.)

L'aggiunta non è definita per i byte. Quindi vengono espressi in int per l'aggiunta. Questo vale per la maggior parte delle operazioni matematiche e dei byte. (nota che era così nelle vecchie lingue, presumo che valga oggi).

Penso che sia una decisione di progettazione su quale operazione fosse più comune ... Se byte + byte = byte forse molte più persone saranno infastidite dal fatto di dover lanciare int quando è richiesto un int come risultato.

Dal codice .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;
}

Semplifica con .NET 3.5 e versioni successive:

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

ora puoi fare:

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

Ho testato le prestazioni tra byte e int.
Con valori 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);
    }
}

Con valori 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);
    }
}

Ecco il risultato:
byte: 3.57s 157mo, 3.71s 171mo, 3.74s 168mo con CPU ~ = 30%
int: 4.05s 298mo, 3.92s 278mo, 4.28 294mo con CPU ~ = 27%
Conclusione:
byte usa più CPU ma costa meno memoria ed è più veloce (forse perché ci sono meno byte da allocare)

Oltre a tutti gli altri grandi commenti, ho pensato di aggiungere un piccolo bocconcino. Molti commenti si sono chiesti perché int, long e praticamente qualsiasi altro tipo numerico non segua questa regola ... restituisce un tipo "più grande" in risposta all'aritmico.

Molte risposte hanno avuto a che fare con le prestazioni (beh, 32 bit è più veloce di 8 bit). In realtà, un numero a 8 bit è ancora un numero a 32 bit in una CPU a 32 bit .... anche se si aggiungono due byte, il blocco di dati su cui la CPU opera sarà 32 bit a prescindere ... quindi l'aggiunta di ints non sta per essere "più veloce" dell'aggiunta di due byte ... è tutto uguale per la cpu. ORA, l'aggiunta di due pollici sarà più veloce dell'aggiunta di due long su un processore a 32 bit, perché l'aggiunta di due long richiede più microops poiché si lavora con numeri più ampi della parola processori.

Penso che il motivo fondamentale per cui l'aritmetica dei byte abbia come risultato ints sia piuttosto chiaro e diretto: 8 bit non va molto lontano! : D Con 8 bit, hai un intervallo senza segno di 0-255. Questo è non un sacco di spazio per lavorare con ... la probabilità che si sta per imbattersi in un byte limitazioni è molto elevato quando li utilizzano in aritmetica. Tuttavia, la possibilità di rimanere a corto di bit quando si lavora con ints, o long, o double, ecc. È significativamente più bassa ... abbastanza bassa che raramente incontriamo la necessità di più.

La conversione automatica da byte a int è logica perché la scala di un byte è così piccola. La conversione automatica da int a long, float in double, ecc. Non è logica perché quei numeri hanno una scala significativa.