Po co pisać 1000000000 jako 1000 * 1000 * 1000 w C?

W kodzie stworzonym przez Apple jest taka linia:

CMTimeMakeWithSeconds( newDurationSeconds, 1000*1000*1000 )

Czy jest jakiś powód, aby wyrazić 1,000,000,000jako 1000*1000*1000?

Dlaczego nie 1000^3o to chodzi?

Jednym z powodów deklarowania stałych w sposób multiplikatywny jest poprawa czytelności bez wpływu na wydajność w czasie wykonywania. Również po to, by wskazać, że pisarz myślał o liczbie w sposób multiplikatywny.

Rozważ to:

double memoryBytes = 1024 * 1024 * 1024;

Jest wyraźnie lepszy niż:

double memoryBytes = 1073741824;

ponieważ ta ostatnia nie wygląda na pierwszy rzut oka na trzecią potęgę 1024.

Jak wspomniał Amin Negm-Awad, ^operatorem jest binarny XOR. W wielu językach brakuje wbudowanego operatora potęgowania w czasie kompilacji, stąd mnożenie.

Dlaczego nie 1000^3?

Wynik 1000^3to 1003. ^jest operatorem bit-XOR.

Nawet to nie dotyczy samego Q, dodaję wyjaśnienie. x^ynie nie zawsze ocenia się x+ytak jak w przykładzie pytający użytkownika. Musisz wszystko xorować. W przypadku przykładu:

1111101000₂ (1000₁₀)
0000000011₂ (3₁₀)
1111101011₂ (1003₁₀)

Ale

1111101001₂ (1001₁₀)
0000000011₂ (3₁₀)
1111101010₂ (1002₁₀)

Istnieją powody, aby nie używać 1000 * 1000 * 1000.

Z 16-bitowymi int, 1000 * 1000przelewa. Dlatego używanie 1000 * 1000 * 1000ogranicza przenośność.

W przypadku wersji 32-bitowej intnastępuje przepełnienie pierwszego wiersza kodu.

long long Duration = 1000 * 1000 * 1000 * 1000;  // overflow
long long Duration = 1000000000000;  // no overflow, hard to read

Zaproponuj, aby wartość wiodąca odpowiadała typowi miejsca docelowego pod względem czytelności, przenośności i poprawności.

double Duration = 1000.0 * 1000 * 1000;
long long Duration = 1000LL * 1000 * 1000 * 1000;

Można również użyć prostej enotacji dla wartości, które są dokładnie reprezentowane jako double. Oczywiście prowadzi to do wiedzy, czy doublemoże dokładnie reprezentować wartość liczby całkowitej - coś niepokojącego w przypadku wartości większych niż 1e9. (Zobacz DBL_EPSILONi DBL_DIG).

long Duration = 1000000000;
// vs.
long Duration = 1e9;

Dla czytelności.

Umieszczenie przecinków i spacji między zerami ( 1 000 000 000lub 1,000,000,000) spowodowałoby błąd składniowy, a umieszczenie 1000000000w kodzie utrudnia dokładne sprawdzenie, ile jest zer.

1000*1000*1000pokazuje, że jest to 10 ^ 9, ponieważ nasze oczy mogą łatwiej przetwarzać fragmenty. Ponadto nie ma żadnych kosztów wykonania, ponieważ kompilator zastąpi go stałą 1000000000.

Dla czytelności. Dla porównania, Java obsługuje _liczby w celu poprawy czytelności (po raz pierwszy zaproponowane przez Stephena Colebourne jako odpowiedź na PROPOZYCJĘ Dereka Fostera: Binary Literals for Project Coin / JSR 334). 1_000_000_000Tutaj można by pisać .

W przybliżeniu w porządku chronologicznym, od najstarszego wsparcia do najnowszego:

• XPL: "(1)1111 1111"( najwyraźniej nie dla wartości dziesiętnych, tylko dla ciągów bitowych reprezentujących wartości binarne, kwartalne, ósemkowe lub szesnastkowe )
• PL / M: 1$000$000
• Ada: 1_000_000_000
• Perl: podobnie
• Ruby: podobnie
• Fantom (wcześniej Fan): podobnie
• Java 7: podobnie
• Swift: (to samo?)
• Python 3.6.0
• C ++ 14: 1'000'000'000

Jest to stosunkowo nowa funkcja dla języków, aby zdać sobie sprawę, że powinny obsługiwać (a także jest Perl). Jak w doskonałej odpowiedzi chux @, 1000*1000...jest to częściowe rozwiązanie, ale otwiera programistę na błędy wynikające z przepełnienia mnożenia, nawet jeśli wynik końcowy jest duży.

Może być łatwiejsze do przeczytania i skojarzenia z 1,000,000,000formularzem.

Z technicznego punktu widzenia wydaje mi się, że nie ma różnicy między bezpośrednią liczbą a mnożeniem. Kompilator i tak wygeneruje ją jako stałą liczbę miliardów.

Jeśli mówisz o celu-c, to 1000^3nie zadziała, ponieważ nie ma takiej składni dla pow (jest to xor). Zamiast tego pow()można użyć funkcji. Ale w takim przypadku nie będzie optymalna, będzie to wywołanie funkcji wykonawczej, a nie stała wygenerowana przez kompilator.

Aby zilustrować powody, rozważ następujący program testowy:

$ cat comma-expr.c && gcc -o comma-expr comma-expr.c && ./comma-expr
#include <stdio.h>

#define BILLION1 (1,000,000,000)
#define BILLION2 (1000^3)

int main()
{
        printf("%d, %d\n", BILLION1, BILLION2);
}
0, 1003
$

Innym sposobem osiągnięcia podobnego efektu w C dla liczb dziesiętnych jest użycie dosłownej notacji zmiennoprzecinkowej - o ile double może reprezentować żądaną liczbę bez utraty precyzji.

IEEE 754 64-bitowy double może bez problemu reprezentować dowolną nieujemną liczbę całkowitą <= 2 ^ 53. Zwykle długie podwójne (80 lub 128 bitów) może sięgać nawet dalej. Konwersje zostaną wykonane w czasie kompilacji, więc nie ma narzutu czasu wykonywania i prawdopodobnie otrzymasz ostrzeżenia, jeśli nastąpi nieoczekiwana utrata precyzji i masz dobry kompilator.

long lots_of_secs = 1e9;