-
Uzylem po raz 1szy clanga zamiast g++ z tymi samymi opcjami: -Wfatal-errors -Wall -Wextra -std=c++14 .
Mam wrazenie ze clang jest bardziej dokladny i skrupulatny, nie pozwala na sukcesy kompilacji na jakie pozwala g++ a przede wszystkim skuteczniej sugeruje co jest nie tak. Czy clang jest lepszy od g++ ? -
https://en.wikipedia.org/wiki/Cfront czy Cfront to transpilator ? https://en.wikipedia.org/wiki/Source-to-source_compiler#Programming_language_implementations
-
Jezeli Cfront to 'tylko' transpilator to w takim razie nie generuje kodu C++ bezposrednio do asemblera, tylko generuje kod C++ bezposrednio do C (a w zasadzie generuje pliki kodu zrodlowego C), a jedynie za pomoca jakiegos kompilatora C generuje kod do asemblera?
a. Jezeli na trzecie pytanie odpowiedz jest 'tak' to jednak Cfront moze zawierac tzw. wstawki asemblera ? -
Czy clang i /lub g++ takze to transpilatory do C a nie kompilatory bezposrednie do asemblera ?
Ad. 1. Tak mówią marketingowcy clanga i LLVM
Ad. 2. IMHO Tak
Ad. 3. Sprawdź w dokumentacji Cfront, ale IMHO kod w C może zawierać wstawki w Asm
Ad. 4 Cfront 4.0 was abandoned in 1993 after a failed attempt to add exception support Z tego co wiem to gcc i clang kompilują bezpośrednio (w sensie że z pominieciem C, Wiem że można wygenerować sobie kod pośredni IR, generowałem :P)
BTW dlaczego chcesz się zajmować oprogramowaniem porzuconym w 1993? Potrzebujesz jakiś kod w C++ dodać do C? Przetłumaczyć do C?
KamilAdam napisał(a):
BTW dlaczego chcesz się zajmować oprogramowaniem porzuconym w 1993? Potrzebujesz jakiś kod w C++ dodać do C? Przetłumaczyć do C?
Zamierzam zostac dobrym programista (niekoniecznie profesjonalista) C, C++ i Javy. Oczywiscie to tylko zamierzenia a co z tego wyniknie to inna sprawa. Aby napisac jakis wiekszy program postanowilem (wzorujac sie na Cfront), ze moze kiedys zaczne pisac transpilator jezyka Java do jezyka C (aby uniknac asemblera i kodu bajtowego) za pomoca C++. Nazwa opisowa: JavaToC_byCpp. Wtedy za pomoca jednego programu "zwiedzilbym" spora czesc informatyki i nie musialbym pisac wielu mniejszych programow (ale czesc takich programow bede musial napisac jako "trening" przed napisaniem tego wiekszego).
Nie ukrywam ze te 3 jezyki wg mnie zawieraja "wielka glebie informatyczna" i jak porownuje je z np. jezykami skryptowymi albo asemblerem to stwierdzam, ze za pomoca tych 3 jezykow lepiej poznam informatyke niz za pomoca innej kombinacji jezykow. Ale to tylko moje zdanie i moge sie mylic.
JavaToC_byCpp
Ciekawy pomysł ale ciekawszy to XToCByX, wtedy jest szansa, że twój transpilator stanie się samotranspilowarny. Poza tym jest to prostsze bo potrzebujesz się nauczyć tylko jednego języka (plus C).
BTW rzadko szukają jednocześnie programisty Javy i C++.
A jak chcesz język programowania który naprawdę zmienia sposób myślenia to polecam Haskella. Uczę się od początku pandemii i to była najlepsza decyzja od dawna
@teofrast:
Czy clang i /lub g++ takze to transpilatory do C a nie kompilatory bezposrednie do asemblera
afaik clang to frontend który generuje intermediate representation (IR), a następnie wchodzi backend (llvm) i to on generuje binarkę.
Cfront 4.0 was abandoned in 1993 after a failed attempt to add exception support
Ja bym przemyślał najpierw, czemu to stanowiło przeszkodę nie do przejścia.
Obecnie, poza wyjątkami, są inne przeszkody. Chociażby korutyny.
To nie jest tak, że kompilator musi generować do assemblera. Kompilator to program, który przekształca program z języka A na język B.
Transpilator to szczególny typ kompilatora, w którym język A i B są na zbliżonym poziomie abstrakcji (przy czym jest to dość mętna / nieścisła definicja).
W sumie nie ma znaczenia, bo zasadniczo, i w kompilatorach, i w transpilatorach, i w interpreterach (!!!) rozwiązuje się podobne problemy.
ad.1 Zależy. One są inne, ale po latach pracy z obydwoma na różnych platformach widzę po prostu różne błędy w różnych, daleki jestem od stwierdzeń X>Y czy odwrotnie. Wynika to z faktu, że C++ to po prostu cholernie skomplikowany język.
ad. 2 tak jak @jarekr000000 napisał.
ad.3 i 3a Pewnych konstruktów charakterystycznych dla platformy typu, nie wiem, mutex czy memory barrier bez asemblera albo platfrom-specific extensions i tak nie opędzisz.
ad. 4 Różnica jest dość rozmyta, padło wyżej.
@teofrast tl.dr: nie chcę umniejszać Twoim ambicjom ani umiejętnościom, ale będąc chyba początkującym rzucasz się w sumie na temat trudny i ogromny i nie wiem czy w ogóle sensowny jednocześnie argumentując, że asembler Cię boli. No wybacz, to brzmi jakbyś w imię strachu przed Niemcami leciał do Hipszanii przez Pekin. Tyle tylko, że w ramach Star Alliance przebukują Cię na Lufthansę. Nie uciekniesz od tego asemblera tak czy siak, a jak chcesz uciec to rób webdev (zaraz ktoś tu przyjdzie i powie, pewnie słusznie, że tam też nie :P).
BTW, niech się wypowie ktoś bardziej w Javie siedzący, ale był już podobny projekt (tzn. java-to-native, nie do C, ale do maszynowego chyba) i zwał się GCJ bodajże. Jak bardzo chcesz, może tam zacząć ;)
alagner napisał(a):
BTW, niech się wypowie ktoś bardziej w Javie siedzący, ale był już podobny projekt (tzn. java-to-native, nie do C, ale do natywnego) i zwał się GCJ bodajże. Jak bardzo chcesz, może tam zacząć ;)
GCJ umarł bo Oracle ogłosił że sam startuje z takim projektem jak GraalVM
W zasadzie to są dwa projekty Graal i GraalVM (nigdy nie pamiętam który jest który) i ich kod się tam jakoś przenika.
- Jeden to nowy kompilator Javy w Javie bo stare (C1 i C2) były w C++ i nikt już nie rozumie ich kodu. Do działania wynikowej aplikacji dalej potrzebna jest JVM.
- Drugi to kompilator Javy do programu/pliku/obrazu (różnie to nazywają) natywnego czyli JVM nie jest potrzebne do uruchomienia aplikacji
Moim zdanie java to c to już jest kompilator. Łatwiej Ci będzie podglądać wyniki niż z asm... ale i tak to gigantyczne przedsięwzięcie.
Dla porównania kompilator do C języka Vala. Vala jest językiem wzorowanym na składni Javy i C#. Ale zamiast Maszyny Wirtualnej używa liczenia referencji (głównie)