GCC zacznie używać C++

Bardziej chodziło mi o to, że Clang/LLVM napisany jest w większości w C++.

A konkretnie co jest sztucznego i nieintuicyjnego?

Poza tym argument "nieintuicyjny" jest niepoważny: mechanika kwantowa i teoria względności są bardzo nieintuicyjne, tym niemniej są prawdziwe.

@zk: Chociazby koniecznosc spacji miedzy "> >" w "costam<costam<meh> > foo;".

Konieczność stawiania średnika po definicji klasy/struktury. Składnia szablonów. Ogólnie bzdury pozostawione dla wstecznej zgodności z C. Tego typu "błędy" naprawia D, tylko że zrywa tę zgodność z C.

to<foo > to mały pikuś łatwy do obejścia (i już dziś sygnalizowany przez kompilatory), prosty do poprawienia w nadchodzącym nowym standardzie. Niepojęty jest np. algorytm rozstrzygania przeciążeń. Naprawdę wkurzający jest m.in. brak częściowej specjalizacji szablonów funkcji. Autorom specyfikacji z 1998 r. zabrakło wyobraźni, do czego ludzie mogą chcieć wykorzystywać szablony

C++ jest językiem żywym, o specyfikacji dostosowywanej do potrzeb zaawansowanych użytkowników, którzy programowaniem zarabiają na życie.

Stąd wrażenie bałaganu, ale i niesamowita siła ekspresji tego języka.

Na dobrą sprawę c++ to metajęzyk w którym dopiero tworzy się użyteczne "instancje języka", np. Qt, CUDA, wxWidgets, Managed C++, CLI etc.

Dopóki tego nie zrozumiesz, będziesz uważał C++ za dziwactwo.

Konieczność stawiania średnika po definicji klasy/struktury – odziedziczona po C. Składnia szablonów jest odjazdowa, przyznaję, najbardziej wzruszające są konstrukcje .template i ->template, Domyślam się, że te "rozszerzenia" dodano post factum, gdy okazało się, ze życie przerosło pierwotny projekt. Jezyk D może jest piękny, logiczny, efektywny, ale nie jest zgodny z C. I to kończy dowód. C/C++ mają ogromny support dla kompilatorów, profilerów, debugerów, IDE, valgrind, jądro, manuale, niezliczone biblioteki, setki tysięcy przeszkolonego personelu. TANIEJ jest wymyślić rozszerzenie C/C++ (np. Qt, CUDA, Cg, CLI, MFC) w oparciu o istniejące środowisko niż konstruować WSZYSTKO od nowa. Aby pobić C/C++, język D musiałby być nie trochę, a o KLASĘ lepszy lub startować w innej kategorii (jak np. Python). Lub mieć wsparcie takiego potentata, jak MS, który stworzyłby i utrzymał niezbędną infrastrukturę.

> C++ jest językiem żywym, o specyfikacji dostosowywanej do potrzeb

> zaawansowanych użytkowników, którzy programowaniem zarabiają na życie.

Belkot. Na pythonie tez profesjonalisci zarabiaja na zycie

a jest o lata swietlne przed C++ w temacie czytelnosci.

Nawet java (uwaga, tez profesjonalisci z tego zyja!)

jest czytelniejsza od C++.

Co nie zmienia faktu, że w pewnych zastosowaniach C++ jest bezkonkurencyjny.

Jarek: mało Javy w życiu widziałeś. W szczególności niemożność jasnej deklaracji głębokiej kopii (clone()) lub kontraktu not null powoduje, że Java taka strasznie czytelna nie jest. Szczególnie jak doda się do tego poziom średniego programisty Javy.

W pewnych zastosowaniach COBOL jest bezkonkurencyjny.

W pewnych zastosowaniach nawet assembler okazuje sie bezkonkurencyjny.

Jednak nie powiedzialbym, ze assembler czy C++ to sensowne

jezyki programowania, nalezy ich unikac jak tylko sie da i tyle.

@el.pescado: Podaj przyklad.

@bies: pokaz gdzie napisalem, ze java jest czytelna?

Napisalem, ze jest czytelniejsza niz C++, lapiesz roznice?

@trasz: W przypadku stuletnich aplikacji biznesowych, których nikt już nie rozumie a są kluczowe do działania wszystkiego, COBOL jest niezastąpiony. Po coś się kupuje te wszystkie mainframy od IBM;)

Jaruś: widzę, że Tobie trzeba jak ,,krowie na miedzy'':

void some_function(const some_class &always_exists);

vs.

public static void someFunction(SomeClass theHellIKnowIfItsNotNull);

Łapiesz różnicę czy pojęcie kontraktu (i ogólnie design by contract) jest Ci obce.

@el.pescado: tyle, że te aplikacje są/będą szybciej lub wolniej przepisywane. Czy inaczej, można je bez problemu zrobić w nowszych językach i to by było lepsze od tego co jest. A w Javie, C# czy Pythonie nie napiszesz lepszego FPSa. Przynajmniej ja tak rozumiem bezkonkurencyjność.

Theq: nie będą (przynajmniej tak mi mówi moje doświadczenie). Albo przy okazji jakiejś fuzji/przejęcia będzie migracja na rozwiązanie dominanta albo będą utrzymywane w COBOL-u do końca Świata. Za dużo osobo-lat w nie włożono. Piszesz ,,bez problemu'' i pomijasz olbrzymie koszty.

Poczytaj np. http://www.joelonsoftware.com/articles/fog0000000…

@bies: tu masz sciagawke:

"Nawet java (uwaga, tez profesjonalisci z tego zyja!)

jest czytelniejsza od C++."

No wiec gdzie napisalem, ze java jest czytelna?

Jejku, nawet poziom ,,krowy na miedzy'' jest za wysoki…

Tam powyżej masz przykład dwóch funkcji, w C++ i Javie. I Java, w oczywisty sposób, jest mniej czytelna. Jeszcze raz: Java jest mniej czytelna od C++. I jeszcze raz: Java jest mniej czytelna od C++. I jeszcze raz: Java jest mniej czytelna od C++.

A może potrzebujesz tak: JAVA JEST MNIEJ CZYTELNA OD C++? W licencjach przechodzi…

Nie sądziłem, że ktoś może być aż tak…

@Theq FEAR miał coś w C# napisane nie zgłębiałem się dokładnie co, ale był nawet niezłym fpsem

@Theq: skoro w Haskellu dało się napisać FPS-a (czy dobry, nie wiem, nie gram od dawna), to w C# tym bardziej się powinno.

A że tego się nie robi – to dokładnie tak samo jak z aplikacjami księgowymi w COBOL-u. Istnieje dużo silników w C++, więc taniej jest przystosować istniejący w C++ niż pisać od nowa w C#.

Bzdura, aplikacje w COBOL-u nie mają nic wspólnego z wymagającymi grami. C# się po prostu do tego nie nadaje, nie ma to związku z tym czy "tak jest taniej". O grach na konsolę nawet nie będę wspominał. Co do tego FPSa w Haskellu to pewnie się tnie Poza tym pisanie silnika w języku czysto funkcyjnym to masochizm. Co dalej, kernel? Może za 15-20 lat to się zmieni, ale wątpię.

@bies

pominąłem koszty bo dyskusja tego nie dotyczy i szczerze mało mnie obchodzą cobolowe zabawki na 10 warstwach emulacji Jak nie ma potrzeby rozwijania tego, to mogą sobie utrzymywać. Spolskiego czytam, dziękuje.

@bies: jeżeli brak sprawdzania w trakcie kompilacji NPE to ma być zarzut wobec Javy względem C++, to co powiedzieć o braku sprawdzania poprawności wskaźników przez C++ w trakcie kompilacji **ORAZ** w trakcie wykonania?

class X {

private:

Y* obj;

public:

void doSomething() {

obj->toSegfaultOrNotToSegfault();

}

};

A co do gier, to te mniej wymagające, np. na poziomie Quake 2 w C# na pewno można. Skoro w Javie się dało i NIE WIDAĆ RÓŻNICY*, to w C# tym bardziej.

*) http://bytonic.de/html/benchmarks.html

Królik: skoro chcesz zapewnić, że obj jest zawsze obecny to użyj referencji. A teraz pokaż odpowiednik referencji w Javie.

Czyżby?

int *x = NULL;

int& y = *x;

lub

int *x = new int(7);

int& y = *x;

delete x;

To, że czegoś w języku nie ma, to czasem jest zaleta a nie wada.

Np. semantyka przekazywania argumentów w Javie/Scali jest jedna: pass-reference-by-value. W C++ jest tych semantyk więcej:

- pass-by-value

- pass-by-reference

- pass-by-const-reference

- pass-pointer

- pass-pointer-to-const

Jak pokazują liczne przykłady innych języków, brak tego wyboru oznacza jedno: brak straconego czasu na zastanawianie się, którą z nich wybrać przy projektowaniu API. I brak straconego czasu na późniejsze zmienianie.

@bies: Java 7 będzie mieć @NotNull, Scala not-null nie potrzebuje, bo nie ma nulli i ma type-safe Option[] zamiast tego, a co do głębokiej kopii, to jeśli gdzieś jej potrzebujesz, to znaczy, że masz gdzieś mutowalny współdzielony stan. Czyli wtopiłeś totalnie znacznie wcześniej i powinieneś kod przeprojektować a nie robić prowizorkę na głębokim clone.

Tekst ze strony Bjarne'a wystarcza: http://www2.research.att.com/~bs/bs_faq.html#IEEE ?

No faktycznie, mój błąd. Link dostałem ze źródła które do tej pory uważałem za wiarygodne.

Jako ktoś kto zna dość dobrze C++ muszę powiedzieć, że wywiad wygląda na spreparowany przez jakiegoś sfrustrowanego programistę C.

Argumenty przeciwko C++ są w większości wytłumaczyć słabą znajomością C++ przez autora i jego marnym stylem kodowania.

Dla programistów C++ może bardziej przyjemniejszy okazać się jeżyk D tworzony przez Digital Mars
http://www.digitalmars.com/d/index.html
Zaś dla programistów C powstający GO od google.
http://golang.org/

To nie C++ jest zaśmiecone, tylko życie, samo życie…

Oczywiście nie chodziło mi o tego typu implikacje w zaawansowanych przypadkach (tu oczywiście zgadzam się z tobą), tylko o ten nieszczęsny przełącznik do kodu GCC. =}

Do takich wyjątków zaliczają się też mikrokontrolery.

Jeśli tylko mieści się runtime C++ (nawet obcięty z wyjątków) to na uC używa się C++(*). Naprawdę głupoty typu konstruktory/przestrzenie nazw/proste szablony przydają się wszędzie. Zapytaj na pclc — tam są ludzie którzy to robią.

(*) Przyznaję, ja używałem C ale dlatego, że nie był jeszcze dostępny runtime C++ na dany uC. Jeśliby był nie zastanawiałbym się ani chwili.

@bies

Na upartego uC można programować w Pascalu. Z tego co znalazłem to C++ nie używa się w uC ze względu na braki w porównaniu do C.

W C masz więcej gotowych przykładów, bibliotek itp.

Tak przy okazji możesz mi podać adres strony WWW z jakimś kompilatorem c++ na uC AVR. Szukałem ale nie znalazłem nic na szybko (na elektrodzie piszą o jakimś avr-g++ ale żadnych konkretów, a w repo jest tylko avr-gcc)

Elektroda to jest super forum jak trzeba naprawić pralkę albo zmontować jakąś płytkę drukowaną. Ale, na $DEITY, nie ucz się tam programować bo będą przez Ciebie kłopoty.

A avr-g++ to wynik kompilacji gcc z –enable-languages=c++ na avr.

Mikrokontroler mikrokontrolerowi nierówny. Na PIC, czy AVR pisze się praktycznie tylko w asemblerze i C (co więcej zadziwiająco często w tym pierwszym), C++ nie ma w nich większego sensu – C++ wzbogaca C o rzeczy przydatne na kompach, ale praktycznie bezużyteczne na małych uK. No, ale to są uK 8-bitowe i rządzą się swoimi prawami. Na 32-bitowych to możecie sobie już odpalić Linuksa i właściwie programować w czym chcecie (nawet i w Pythonie jeśli macie taki kaprys).

Sadi: tia…

Przykład (Numeric to klasa/struktura do operowania na liczbach fixed-point):

Numeric a = b * c;

vs.

struct Numeric a

Num_mul(&a, &b, &c);

Jasne, w ogóle nie przydatne…

Wątek chyba dryfuje, choć skądinąd jest ciekawy.

Przypomnę, że chodzi o język kompilatora. W szczególnych przypadkach oczywiście może to interesować programistów kompilujących nim swój kod, ale nie bardzo sobie wyobrażam po co miałby być przełącznik do włączania "mechanizmu C++" w samym kompilatorze (a nie do kodu, który on kompiluje).

@Tomasz Woźniak: Zwykle uczuleniene na badziewnosc. Na PiS tez lubie ponarzekac.

@mikolajs: Ale zdajesz sobie sprawe, ze w jezyku proceduralnym tez mozesz pisac obiektowo, wystarczy troche pomyslec? To nie jest tak, ze jak piszesz w C, to obowiazkowo wychodzi ci spaghetti bez enkapsulacji.

A co do programowania obiektowego – rownie dobrze moznaby stwierdzic, ze pisanie obiektowe bez klikanego IDE nie ma sensu, bo wszyscy uzywaja klikanych IDE.

Programuje w różnych językach C i C++ też. Moje doświadczenia zawodowe w projektach, które przedkładały metodologię nad rzeczywistymi potrzebami czyli generalnie preferującymi C++ nad C bo "C++ jest fajne i obiektowe" sprowadzają się do stwierdzenia, że C++ bardziej szkodzi niż pomaga, szczególnie właśnie w dużych projektach, bo gdy okazuje się, że projektowanie hierarchii klas nie odpowiada realiom (a okazuje się tak prędzej czy później w 90% przypadków, bo nie wszystko można przewidzieć i rzadko jest czas na prototypowanie), to zamiast skupić się na doimplementowaniu albo zmianie problematycznego kodu trzeba się wozić z całym tym bałaganem w niewłaściwie zaprojektowanych interfejsach klas i nierzadko bardziej się opłaca napisać dużą ich część klas od nowa.

Jak ktoś ma czas i pieniądze proszę bardzo, ale mnie argumenty ideologiczne zupełnie nie przekonują. Osobiście bliżej mi do podejścia Data Driven Programming, niż OOP. Podejścia te różnią się w swych założeniach diametralnie. OOP stawia na modelowanie i naśladownictwo, co jest intuicyjne ale często mało efektywne zarówno wydajnościowo jak i implementacyjnie.

DDP stawia na dotarcie do istoty problemu czyli ustalenie jak się mają dane wejściowe do wyjściowych i co w tym wszystkim najistotniejsze, a często zupełnie pomijane w OOP, jaka forma danych na wejściu i wyjściu jest najbardziej efektywna oraz jak powinno być zorganizowane ich przetwarzanie.

Często w praktyce okazuje się, że to co w OOP się rozdziela "bo tak to ładnie można zamodelować" w DDP realizuje się razem, niejako patrząc całościowo na problem, "bo nie ma sensu wprowadzać sztucznych interfejsów powodujących wąskie gardła albo nieefektywny przepływ sterowania".

Wbrew pozorom, zwięzłość tak napisanych aplikacji często też skutkuje dużo łatwiejszym ich utrzymaniem i zrozumieniem.

Nie muszę chyba dodawać, że prostota C w stosunku do C++ dodatkowo temu sprzyja (nie trzeba się np. w każdym miejscu zastanawiać czy aby na pewno "+" jest plusem przy czytaniu kodu).

Podsumowując: nie znasz C++ i pracowałeś z ludźmi którzy C++ nie znają (wnoszę po założeniu: C++ => OOP => hierarchia klas).

,,Prostota C'' tia…

void MTLIB_mul_matrix_3_3(struct MTLIB_Matrix_3_3 *result, const struct MTLIB_Matrix_3_3 *one, const struct MTLIB_Matrix_3_3 *two);

Albo lepiej:

int MTLIB_mul_matrix(void *out, const void *one, const void *two);

To dopiero jest szał…

Jakoś mam wrażenie że niektórym po prostu nie chce się opanowywać C++ i mają do tego prawo, ale dorabiają do tego różne wyjaśnienia.

GObject nie wydaje mi się prosta w porównaniu do C++.

Zapewne też C jest wydajniejsze gdy napisze się optymalnie, ale najpierw trzeba mieć na to czas, a ja zwykle zbyt dużo go nie mam

Niektórym nie chce się tracić 10 lat na naukę jak w C++ obchodzić problemy stworzone przez język, tylko wolą skupić się na rozwiązywaniu realnych problemów.

@bies: cały czas przytaczasz jakieś pierdułki dotyczące "lukru składniowego" mające niewielkie znaczenie przy realizacji dużego projektu. Dużo większe znaczenie ma np. to, czy programiści nawzajem są w stanie zrozumieć swój kod. W przypadku C++ może być problem, bo programistów, którzy znają >80% języka jest bardzo niewielu. W praktyce każdy wybiera sobie jakiś podzbiór (jeden będzie fanem Modern C++ Design, a inny będzie używał jak C z klasami). Łączenie kodu C++ pisanego przez różnych programistów w różnym czasie to masakra. Jak to ktoś powiedział ładnie: "C++ is platform-portable, but not programmer-portable". Dlatego wcale się nie dziwię Linusowi…

void* to dla Ciebie lukier składniowy nie mający znaczenia dla dużych projektów?

Niestety void* to jest broń obosieczna. System typów w C++ jest na tyle nieelastyczny, że programiści albo szaleją z rzutowaniami jawnymi (nawet na void*) albo szaleją z template'ami. Jedno i drugie często kończy się źle.

BTW: Co powiesz o niejawnej konwersji const char* i do char*?

W innym wątku o iPhone było: wolisz mieć brak zabezpieczeń czy zabezpieczenia, które często nie działają? To C i C++ analogia pasuje jak ulał. C++ niby chroni programistę przed samym sobą, oprócz tych momentów, kiedy nie chroni.

Wojenne opowieści Michał, podaj przykład… Kod znaczy się.

@Mikołaj: W stosunku do MacOS – owszem, na przyklad w kwestii GUI. W stosunku do Linuksa trudno byc wtornym, bo ciezko podac przyklad czegos, co w Linuksie bylo wczesniej niz w jakims innym systemie i nie jest bugiem.

.. to podam taki przykład jak pełna przezroczystość okienek, która weszła do Windowsa zdaje się dopiero od wersji Vista. Nota bene działała okropnie. W tym czasie w Linuxie było już milion innych "wodotrysków". Żeby było jasne — ja się tymiż nie podniecam, podaje je jako przykład, który jest dość jaskrawy. Co do MacOSX .. nigdy go nie używałem i nie miałem okazji się zapoznać.. nie wypowiadam się, chociaż szczerze mówiąc.. ciężko mi w to uwierzyć.