Dzięki uprzejmości redakcji Programisty, mogę podzielić się tym artykułem.

Co nowego w świecie języka C

C18 – tak najprawdopodobniej będzie brzmiała nazwa nowego standardu języka C. Aby tak się stało, komisja standaryzacyjna musi zakończyć nad nim prace na tyle prędko, aby organizacja ISO mogła go przyjąć jeszcze w w tym roku. W tym artykule opisano wybrane zmiany spośród tych, które mają być wprowadzone.

Brak rozgłosu spowodowany jest tym, że jest to wydanie mające na celu wyłącznie poprawę błędów z poprzednich wersji.
Większość modyfikacji zwiększa precyzję zapisów w samym dokumencie, cofa nieintencjonalne rozmijanie się ze standardem C++ w częściach wspólnych dla obu języków lub usuwa błędy.

Doprecyzowanie inicjalizacji za pomocą designated initializers

C99 wprowadziło możliwość inicjalizacji elementów struktur, unii i tablic w kolejności określonej przez programistę. Dla unii i struktur inicjalizacja odbywa się za pomocą zapisu:

.element = wartość_inicjalizująca

a dla tablic:

[index] = wartość inicjalizująca

Ich przykładowe użycie znajduje się w Listingu 1.

Listing 1. Przykładowe użycie designated initializers

#include <assert.h>
#include <string.h>
 
typedef struct
{
    int num;
    double dbl;
    char const* str;
} foo;
 
int main(void)
{
    foo bar = { .str = "str!", .dbl = 42 };
    assert(bar.num == 0);
    assert(bar.dbl == 42);
    assert(strcmp(bar.str, "str!") == 0);
 
    int arr[3] = { [1] = 42 };
    assert(arr[0] == 0);
    assert(arr[1] == 42);
    assert(arr[2] == 0);
}

Przy takiej inicjalizacji wszystkie niewymienione jawnie elementy inicjalizowane są wartością zero. W bardziej zawiłym przykładzie przedstawionym w Listingu 2. sytuacja nie jest już tak oczywista. Czy wartość l.t.k to 42 (od inicjalizacji .t = x), czy może 0 (od niejawnej inicjalizacji .t podczas inicjalizacji .t.l)?

Listing 2. Przykład z raportu błędu (ang. Defect Report) [1]

typedef struct {
    int k;
    int l;
    int a[2];
} T;
 
typedef struct {
    int i;
    T t;
} S;
 
T x = {.l = 43, .k = 42, .a[1] = 19, .a[0] = 18 };
 
void f(void)
{
    S l = { 1, .t = x, .t.l = 41, .t.a[1] = 17};
}

Wedle komisji uważna lektura standardu pozwala wywnioskować, że jest to 42 – jawna inicjalizacja jest ważniejsza od niejawnej. Pomimo tego odpowiedni paragraf zostanie wzbogacony o przykład wyjaśniający tę wątpliwość.

#elif z niepoprawnym warunkiem

Zamierzeniem twórców języka była ekwiwalencja dyrektywy preprocesora #elif (Listing 3) z dyrektywą #else zawierającą wewnętrzną dyrektywę #if (Listing 4).

Listing 3. Wewnętrzna dyrektywa #if

#if 1
#else
#if EXPR
#endif
#endif
int main(void)
{
}

Listing 4. Dyrektywa #elif analogiczna do #if z Listingu 3

#if 1
#elif EXPR
#endif
int main(void)
{
}

Jeśli jednak EXPR będzie niepoprawnym wyrażeniem, zapis z Listingu 4 powinien spowodować błąd kompilacji – co przedstawiono w Listingu 5.

Listing 5. Program niepoprawny z powodu błędnego warunku w pominiętej ścieżce [2]

#if 1
#elif "
#endif
int main(void)
{
}

Od C18 oba warianty będą miały identyczne znaczenie – wyrażenie #elif będzie miało semantykę zdefiniowaną tak samo jak wyrażenie wewnętrznej dyrektywy #if.

Konwersja liczb zespolonych na _Bool

Zapisy poprzedniego standardu stały ze sobą w sprzeczności. Dla kodu z Listingu 6 jednocześnie aplikowalne są dwa zapisy standardu:

• o konwersji do _Bool – wartość po konwersji jest równa 0, jeśli wartość konwertowana jest równa zero, w przeciwnym wypadku wartość po konwersji jest równa 1,
• o konwersji z liczb zespolonych do typów rzeczywistych – część urojona jest odrzucana, a część rzeczywista konwertowana do typu docelowego według normalnych reguł.

Listing 6. Jaka powinna być wartość foo?

#include <complex.h>
#include <stdbool.h>
 
int main()
{
    _Bool foo = 0. + I;
}

Według pierwszego z wymienionych zapisów foo powinno mieć wartość 1, a według drugiego – 0. Autor nie był w stanie znaleźć wersji kompilatorów clang i gcc, które przejawiałyby drugie zachowanie. W C18 drugi z przytoczonych fragmentów o konwersji liczb zespolonych nie będzie dotyczył konwersji do _Bool, czyli foo będzie miało gwarantowaną wartość 1.

Porzucenie ATOMIC_VAR_INIT

Wprowadzone w C11 obiekty atomic musiały być inicjalizowane za pomocą makra ATOMIC_VAR_INIT (Listing 7), inaczej ich wartość była traktowana jako niezdeterminowana¹.

Listing 7. Inicjalizacja atomic_int z użyciem ATOMIC_VAR_INIT

#include <assert.h>
#include <stdatomic.h>
#include <threads.h>
 
int change(void* ptr)
{
    *(atomic_int*)ptr = 0;
    return 0;
}
 
int main(void)
{
    atomic_int x = ATOMIC_VAR_INIT(42);
    thrd_t thread;
    thrd_create(&thread, &change, &x);
    while(x);
    assert(x == 0);
    thrd_join(thread, NULL);
}

Ponieważ uniemożliwiało to użycie designated initializers, a popularne implementacje i tak implementowały to makro jako no-op², zdecydowano się na porzucenie konieczności inicjalizacji w ten sposób. Od C18 legalna i poprawna będzie inicjalizacja przedstawiona w Listingu 8.

Listing 8. Inicjalizacja atomic_int jak zwykłej zmiennej int

#include <assert.h>
#include <stdatomic.h>
#include <threads.h>
 
int change(void* ptr)
{
    *(atomic_int*)ptr = 0;
    return 0;
}
 
int main(void)
{
    atomic_int x = 42;
    thrd_t thread;
    thrd_create(&thread, &change, &x);
    while(x);
    assert(x == 0);
    thrd_join(thread, NULL);
}

Atomowy żart

Wbrew deklaracjom purystów językowych, w tym autora tego artykułu, C oraz C++ mają dużą część wspólną. Twórcy obu języków starają się też nie wprowadzać zbędnych rozbieżności między nimi. Dlatego też, jeśli jakieś wyrażenie pojawi się w opisie części wspólnej w jednym ze standardów, to z bardzo dużym prawdopodobieństwem zbliżone stwierdzenia można będzie również znaleźć w drugim.

Szkic standardu C++11, znany wtedy pod roboczą nazwą C++0x, zawierał, pośród innych, następujące gry słowne:

• Atomic objects are neither active nor radioactive – obiekty atomic nie są ani aktywne, ani radioaktywne,
• Among other implications, atomic variables shall not decay – pośród innych implikacji zmienne atomic nie powinny się rozpadać (ang. decay).

O ile pierwsze zdanie jest oczywistym żartem i nie zostało przeniesione do C11, to drugie może wyglądać jak typowe stwierdzenie, które można znaleźć w dokumencie standaryzacyjnym. Logicznie nie ma ono jednak sensu – decay oznacza w C niejawną konwersję typu tablicowego we wskaźnik na element. Pomimo tego znalazło się ono w C11. W C18 usunięto ten żart.

Podsumowanie

Choć w artykule przedstawiono wybrane najbardziej znaczące zmiany, to i tak można je traktować co najwyżej jako drobnostki. Gdyby nie kronikarskie zapędy autora, artykuł o C18 – o ile standard ten będzie ostatecznie nosił taką nazwę – mógłby nigdy nie powstać.

Bibliografia:
[1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2148.htm#dr_413
[2]: https://wandbox.org/permlink/gdTcEwoGxkNj8rsr

¹_{Nie dotyczy obiektów statycznych i globalnych.}
²_{Pusta instrukcja, brak jakichkolwiek działań. W tym przypadku oznacza to, że istniejące implementacje i tak implementowały makro ATOMIC_VAR_INIT jako ewaluujące się do swojego argumentu.}