Rozszerzenia kompilatorów

Chciałem się zapytać co myślicie na temat rozszerzeń kompilatorów (niezgodnych ze standardem języka)?

Z jednej strony ułatwiają one zazwyczaj pisanie kodu, robią go czytelniejszym (dla twórcy), najczęściej przyśpieszają plik wyjściowy.

Z drugiej strony... No właśnie co? Wiem że rzeczy niezgodne ze standardem są po prostu ZUE i czynią kod nieprzenośnym i/lub nieczytelnym dla kogoś nieobeznanego w rozszerzeniach dla danego kompilatora. Ale czy to znaczy że nigdy nie można ich używać czy że używać, ale w prywatnym kodzie i rzadko.

PS. Pisząc myślę konkretnie o języku C++ ale zastanawiam się ogólnie.
PPS. Mając na myśli rozszerzenia kompilatora mam na myśli coś zgoła innego niż np. atrybuty specyficzne dla kompilatora. W przypadku atrybutów można robić jakieś #define NORETURN __attribute((noreturn)) i w razie potrzeby zmieniać define. W przypadku rozszerzeń cały kod idzie do kosza.

Rozszerzenia to nie tylko nowe funkcjonalności, ale czasami konieczność. javac dorobił się rozszerzenia dla programowania aspektowego. Zazwyczaj też języki JVM np. Scala czy Groovy dostarczają własnych rozszerzeń.

Problem z rozszerzeniami leży nie tyle co w ich "tajemniczości", bo o ile rozszerzenie nie jest komercyjne to można je łatwo zdobyć, ale w komplikowaniu procesu budowania kodu. Zazwyczaj poza główną "linią kompilacji" pojawia się wiele "gałęzi", które warunkują kompilację i czynią cały proces bardziej zamotanym.

Oczywiście jest problem "przenośności" kodu źródłowego, ale jak pisałem o ile rozszerzenie nie jest silnie skomercjalizowane to bez problemu powinieneś móc swobodnie uruchamiać kod wynikowy. Czasami to, że coś nie działa nie jest winą samego kompilatora, ale dzieje się tak ponieważ zapominasz podpiąć jakiejś specyficznej biblioteki bez której twój kod nie będzie działał.

A jeśli chodziłoby o rozszerzenie samego kompilatora (na przykład rozbudowanego pod tym względem GCC)? Wtedy nie ma problemu w komplikowaniu procesu budowania kodu (być może nawet kod jest prostszy) ale inny kompilator tego nie odczyta.

Myślę (tzn to taka szybka myśl) że sposób postępowania przy C/ C++ jest prosty:

• program open source = nie używamy rozszerzeń kompilatora,
• program closed source = używamy rozszerzeń kompilatora,

Ewentualnie używamy rozszerzeń nawet w open source, ale tak, żeby bez nich też działało.

Platforma Java to trochę inna bajka. Tutaj bytecode manipulation/ egzotyczne adnotacje jest/ są bardzo popularne i generalnie jest tyle narzędzi do tego, że raczej nie sprawia to problemu.

Rowniez mysle ze z Java nie ma problemu. Niemal kazdy projekt uzywa mavena / gradle wtf, a na przykladzie mavena mozesz skonfigurowac maven-compiler-plugin dodajac jakiekolwiek dodatkowe jary z pluginami, bierze kod z repo uruchamia mavena i z palcem w dupie sobie buduje (jak pom.xml jest dobrze skonfigurowany).

C++ nie ma standardu, ISO C++ mozesz o kant d**y rozbic jak trzeba kodzic cos naprawde platformowego, uzywasz moze z 10% skladni jezyka ewentualnie sporo preprocesora, obadaj sobie chociazby guide mozzilli lub standardy jak MISRA C.
Co do rozszerzen to imho przydaja sie ale sam kod musi byc starannniej napisany aby mozna bylo go latwo przenosic.

Moje ulubione rozszerzenie:

int a = 5;
int tablica[a];

program open source = nie używamy rozszerzeń kompilatora,

Każdy nietrywialny program i tak się nie skompiluje na żadnym innym kompilatorze, chyba że przedsięwzięte zostaną kosztowne kroki w tym celu.
Już łatwiej o przenośność między różnymi systemami ale w ramach jednego kompilatora, niż między różnymi kompilatorami nawet na tym samym systemie.

Ponieważ wszystkie projekty open source i tak są pisane na konkretny kompilator, więc – w czym problem?

othello napisał(a)

Moje ulubione rozszerzenie:

To już od 10 lat jest w standardzie C. Ale do C++ jeszcze nie trafiło.

cepa napisał(a)

lub standardy jak MISRA C
To ten w którym Hello world nie działa? ;-)

Ponieważ wszystkie projekty open source i tak są pisane na konkretny kompilator, więc – w czym problem?

Ja jestem innego zdania. Poważne projekty OSS są przenośne pomiędzy kompilatorami.