Zarówno GCC, oraz inne kompilatory, jak i same standardy języków C/C++, przewidują pewne rozszerzenia języka, które zazwyczaj adresują jakiś problem, bądź też dodają nową funkcjonalność. Tych rozszerzeń jest masa - w zasadzie każdy popularny kompilator ma niemałą listę takich dodatków, i oczywiście nie zamierzam ich wszystkich opisywać w tym poście. Wspomnę natomiast o dwóch: atrybucie init_priority dla globalnych inicjacji obiektów w GCC C++, oraz znaku dolara ($) w nazwach zmiennych - rozszerzeniu pojawiającym się w różnych miejscach. Przy okazji tego ostatniego, zaprezentuje jedno zadanie z tegorocznego testu na Technika Informatyka (który od dwóch dni krąży po sieci).

init_priority

Przeglądając listę extensionów do GCC można się natknąć na atrybut init_priority (patrz 7.7 C++-Specific Variable, Function, and Type Attributes), który adresuje problem kolejności inicjacji obiektów globalnych w C++ (problem, o którym pisał niedawno Xion).

Problem polega na tym, że jeżeli mamy w projekcie tylko jeden plik .cpp z globalnymi obiektami, np:
MojaKlasa A;
MojaKlasa B;
To sprawa jest łatwa - najpierw zostanie zainicjowany (a więc zostanie wywołany konstruktor) obiektu A, a potem obiektu B.
Alee.... jeżeli mamy kilka plików, w których w jednym w powyższy sposób deklarujemy obiekty A i B, a w innym C i D, to niestety nie mamy pewności jaka będzie kolejność wywołań konstruktorów tychże obiektów. W zasadzie są w tym wypadku tylko dwie możliwości:
Możliwość 1: A B C D
Możliwość 2: C D A B
Zakłada się więc, że kolejność inicjalizacji takich obiektów jest przypadkowa, niesprecyzowana i nie dająca się przewidzieć.

Dodam również, że jest to jeden z błędów w miarę często robionych przez programistów C++ (przyznaje się, że parę razy również się na to złapałem ;>).

I tutaj wchodzi init_priority. W skrócie - możemy nadać priorytety inicjalizacji obiektom, globalnie względem projektu. Priorytet w tym wypadku jest wartością od 65535 (najmniejszy) do 101 (najszybciej inicjowane) włącznie. Domyślnym priorytetem (tj. bez zdefiniowanego atrybutu init_priority, jest 65535).

W kodzie wygląda to nastepująco:
Plik 1.cpp
MojaKlasa A __attribute__ ((init_priority (1001)));
MojaKlasa B __attribute__ ((init_priority (1000)));

Plik 2.cpp
MojaKlasa C;
MojaKlasa D;
W tym wypadku kolejność wywoływania obiektów jest znana, i zawsze pozostanie taka sama: B A C D;

Warto zaznaczyć, że jeżeli obiekt ma konstruktor z parametrem, to parametr ten podaje się po atrybucie (tak dziwnie jakoś):
MojaKlasa A __attribute__ ((init_priority (1001))) ("parametr konstruktora", 2, 3, 4);
Szczerze to sobie po prostu makro na to zrobiłem (dużo wygodniejsze niż pisać to całe __atrijużmisueznudziłopisanie):
#define INIT_PRIO(a) __attribute__ ((init_priority (a)))

Oczywiście, jeżeli kilka obiektów w różnych plikach ma ten sam priorytet, to, w obrębie własnej grupy, nadal ich kolejność inicjalizacji nie jest przewidywalna.

Niestety, jak większość rozszerzeń kompilatorów, powyższe dostępne jest jedynie dla kompilatora o którym mówię, czyli GCC. Jeżeli kojarzysz podobne rozwiązanie w innym kompilatorze, zachęcam do wspomnienia o nim w komentarzu :)

Dolar w nazwie zmiennej

Zacznę od screenshota z krążącego po sieci testu teoretycznego na Technika Informatyka sprzed paru dni:


(pomińmy brak średnika w 3ciej linii - to jakiś błąd skanu pewnie)

Narzucającą się odpowiedzią na powyższe pytanie jest odpowiedź C. PHP - każdy kto widział PHP na oczy wie, że nazwy zmiennych rozpoczynają się tam od dolara, i mogę się domyślić, że taka jest też prawidłowa odpowiedź na to pytanie.

W rzeczywistości natomiast, odpowiedzi B, C oraz D są prawidłowe :)

Zacznijmy od języka Java. W trzecim rozdziale książki The Java Language Specification, a konkretniej w paragrafie 3.8 Identifiers możemy znaleźć następujące informacje:
An identifier is an unlimited-length sequence of Java letters and Java digits, the first of which must be a Java letter.
[...]
The Java letters include uppercase and lowercase ASCII Latin letters A-Z  (\u0041-\u005a), and a-z  (\u0061-\u007a), and, for historical reasons, the ASCII underscore (_, or \u005f) and dollar sign ($, or \u0024). The $  character should be used only in mechanically generated source code or, rarely, to access preexisting names on legacy systems.
W wolnym tłumaczeniu - identyfikatory (nazwy zmiennych, funkcji, etc) w Javie muszą zaczynać się od "Liter Java", do których zalicza się m.in. znak dolara. Co prawda zaznaczone jest, że jest on tam w celach zapewnienia wstecznej kompatybilności i że sugeruje się używanie go jedynie w generatorach kodu, ale nie zmienia to faktu, iż kod z obrazka jest poprawnym fragmentem kodu Java. Czyli odpowiedź D również jest prawidłowa.

Jeśli zaś chodzi o odpowiedź B, czyli języki C/C++, to posłużę się dwoma cytatami.
Pierwszy pochodzi z, cytowanej już wcześniej, dokumentacji GCC:

4.26 Dollar Signs in Identifier Names

In GNU C, you may normally use dollar signs in identifier names. This is because many traditional C implementations allow such identifiers. However, dollar signs in identifiers are not supported on a few target machines, typically because the target assembler does not allow them.
W wolnym tłumaczeniu: znak dolara jest dozwolony na większości architektur, ponieważ większość implementacji C go obsługuje (taki trochę reverse-extension ;p), oprócz architektur w których w assemblerze (bo gcc/g++ kompilują do assemblera) nie można używać znaku $ w identyfikatorach.

Drugi cytat pochodzi ze standardu języka C99 (a konkretniej z draftu numer n1336) z sekcji Common extensions:
J.5.2 Specialized identifiers
Characters other than the underscore _,letters, and digits, that are not part of the basic
source character set (such as the dollar sign $,orcharacters in national character sets)
may appear in an identifier (6.4.2).
Czyli, w wolnym tłumaczeniu: niektóre niestandardowe znaki, takie jak np. znak dolara, mogą występować w identyfikatorach.

Do powyższych cytatów dorzucę, że wg moich testów, $ na początku zmiennej kompiluje się zarówno w GCC (gcc/g++) jak i w MS C/C++ Compiler (używanym m.in. w pakiecie Visual C++).

Tak więc można spokojnie uznać, że kod z obrazka jest również prawidłowy w C/C++, a więc odpowiedź B jest również prawidłowa.

Podsumowując, jak pisałem wcześniej, odpowiedzi B, C oraz D są w tym zadaniu prawidłowe, Q.E.D. :)


Na koniec ciekawostka! Jeżeli zastanawiacie się, czy zdalibyście test na Technika Informatyka, to zachęcam do zmierzenia się z poniższym pytaniem :)))



I tyle :)