W kilku nowoczesnych językach programowania (w tym w C ++, Java i C #) język na to pozwalacałkowitą przepełnienie występować w czasie wykonywania bez wywoływania jakiegokolwiek rodzaju błędu.

Na przykład rozważmy tę (wymyśloną) metodę C #, która nie uwzględnia możliwości przepełnienia / niedomiaru. (Dla zwięzłości metoda nie obsługuje również przypadku, w którym podana lista jest zerowym odwołaniem.)

<code>//Returns the sum of the values in the specified list.
private static int sumList(List<int> list)
{
    int sum = 0;
    foreach (int listItem in list)
    {
        sum += listItem;
    }
    return sum;
}
</code>

Jeśli ta metoda zostanie wywołana w następujący sposób:

<code>List<int> list = new List<int>();
list.Add(2000000000);
list.Add(2000000000);
int sum = sumList(list);
</code>

Przepełnienie wystąpi wsumList() metoda (ponieważint typ w C # jest 32-bitową liczbą całkowitą ze znakiem, a suma wartości na liście przekracza wartość maksymalnej 32-bitowej liczby całkowitej ze znakiem. Zmienna suma będzie miała wartość -294967296 (nie wartość 4000000000); najprawdopodobniej to nie jest to, co zamierzał (hipotetyczny) twórca metody sumList.

Oczywiście, istnieją różne techniki, które mogą być używane przez programistów, aby uniknąć możliwości przepełnienia liczby całkowitej, na przykład przy użyciu typu takiego jak JavaBigInteger, albochecked słowo kluczowe i/checked przełącznik kompilatora w C #.

Jednak pytanie, które mnie interesuje, dotyczy tego, dlaczego domyślnie te języki zostały zaprojektowane tak, aby w pierwszej kolejności mogły występować przepełnienia całkowite, zamiast na przykład zgłaszać wyjątek, gdy operacja jest wykonywana w czasie wykonywania, co skutkowałoby przelewowy. Wygląda na to, że takie zachowanie pomogłoby uniknąć błędów w przypadkach, gdy programista nie uwzględnia możliwości przepełnienia podczas pisania kodu, który wykonuje operację arytmetyczną, która może spowodować przepełnienie. (Te języki mogły zawierać coś w rodzaju „niesprawdzonego” słowa kluczowego, które mogłoby oznaczać blok, w którym przekroczenie liczby całkowitej może wystąpić bez wyjątku, w przypadkach, gdy zachowanie to jest wyraźnie zamierzone przez programistę;ma to.)

Czy odpowiedź po prostu sprowadza się do wydajności - projektanci języków nie chcieli, aby ich odpowiednie języki domyślnie używały „powolnych” operacji arytmetycznych liczb całkowitych, w których środowisko wykonawcze musiałoby wykonać dodatkową pracę, aby sprawdzić, czy wystąpiło przepełnienie w każdej odpowiedniej arytmetyce operacja - a ta ocena wydajności przewyższyła wartość unikania „cichych” awarii w przypadku wystąpienia przypadkowego przepełnienia?

Czy istnieją inne powody decyzji o projektowaniu języka, poza względami wydajnościowymi?