Hat ihn schon jemand getestet? Entspricht der neue gcc eher dem letzten ofiziellen gcc-2.95 oder eher RedHats gcc-2.96 ?
Und wie ist es mit der Installation? Da ja noch keine RPMs draußen sind, wird es wohl schwierig sein den neuen gcc zu installieren, wenn man bereits einen auf der Platte hat.
Kannst ja den alten deinstallieren bzw. den neuen nach /usr/local installieren. Ich sehe da keine Schwierigkeit, außer dem vermutlich hohen Platzverbrauch des Quellcodes (He, lacht nicht! Nicht jeder hat ne 21 GB-Platte).
Ich glaube mal, dass er dem 2.95 entsprechen wird, denn von Rathat's gcc haben sich die GCC-Entwickler ja eher distanziert. Werde das aber noch ma verifizieren, sprich ich werd ihn gleich ma downloaden.
Zur Installation: Du macht das ./configure, dann das make bootstap (oder wie es heisst), deinstallierst das alte rpm-Packet vom gcc und macht dein make install. Am besten du hast checkinstall oder instmon um ihn spaeter wieder loeschen zu koennen.
gruss das gnu, das eigentlich ungern grosse Buchstaben verwendet
@Anonymous 14:18 > NEIN... Ok, dann nehm ich das zurueck (steht ja auf der Webpage).
Zu meinem obigen Posting: Nicht die Parameter hinter ./configure vergessen. Ausserdem sollte man nich direkt im gcc-Verzeichnis kompilieren und auch nich als root-user (das make install natuerlich schon als root).
@Jens Instmon ist vergleichbar mit checkinstall. IMHO ist es aber wesentlich einfacher zu bedienen. Es kann ebenfalls tar-, deb- und rpm-Archive aus den installierten Files erstellen, ohne das man Zusatzprogramme benoetigt.
Leider scheint das Project tot zu sein. Die letzte Version (2.0) ist aber praktisch perfekt: http://hal.csd.auth.gr/~vvas/instmon/
Ein einfaches ./configure reicht beim gcc nicht aus, man wird entweder Probleme bekommen oder verzichtet auf wichtige Funktionen wenn man das ganze ohne Parameter startet !
Die neue gcc-3.0 habe ich zwar noch nicht kompiliert (mache ich heut Abend), aber vor 3 Tagen eine 3.0-Pre Version. Das ganze dann mit folgenden Parametern:
Mit der 3.0-pre habe ich es nicht geschafft die glibc-2.2.3 zu kompilieren, meldete einen Fehler in libgcc_s.so. Ich hoffe das wurde in der Release behoben ;)
GCJ can compile Java source or Java bytecodes to either native code or Java class files, and supports native methods written in either the standard JNI or the more efficient and convenient CNI.
Angeblich kann man das oben beschriebene mit dem neuen gcc machen. Ich hatte schon mal ältere gcj-Pakete zum gcc-2.95 nachinstalliert gahabt und habe folgende Erfahrungen gemacht:
> Java sourc files -> Byte code
Geht wunderbar. Der Befehl hierfür lautet gcj. Die verwendeten Klassen sind die Classpath-Klassen (www.classpath.org). Diese Klassen sind jedoch nicht ganz vollständig und schon garnicht zu Java2 kompatibel. Daher kann man auch mit dem Kompiler "nur" Programme erstellen, die (fast) Java 1.1 kompatibel sind.
Angeblich klappt das. Nur bei mir gab es irgendwelche Probleme als ich es testen wollte.
Desweiteren gäbe es dann noch Java byte code -> ausführen
Dafür gibt es das Programm "gij". Bisher kann man jedoch nur textbasierte Programme ausführen. Das heißt, daß AWT/Swing-Programme derzeit noch nicht dadrauf laufen.
Gibt es noch einen grund in c++ zu schreiben?
Ja, denn nicht jeder bevorzugt Java. Mir ist C/C++ beispielsweise weit aus lieber. Außerdem kann man in Java bekanntlich nicht direkt Assemblercode integrieren. Wenn man systemnah programmieren will, dann bleiben einem ohnehin nur zwei möglichkeiten:
1. In C/C++ programmieren und dort die Assemblerroutinen integrieren. 2. In Java programmieren und dort per JNI-Schnittstelle C/C++-Bibliotheken integriren, bei denen wie bei 1. verfahren wurde.
Angeblich kann man das oben beschriebene mit dem neuen gcc machen. Ich hatte schon mal ältere gcj-Pakete zum gcc-2.95 nachinstalliert gahabt und habe folgende Erfahrungen gemacht:
> Java sourc files -> Byte code
Geht wunderbar. Der Befehl hierfür lautet gcj. Die verwendeten Klassen sind die Classpath-Klassen (www.classpath.org). Diese Klassen sind jedoch nicht ganz vollständig und schon garnicht zu Java2 kompatibel. Daher kann man auch mit dem Kompiler "nur" Programme erstellen, die (fast) Java 1.1 kompatibel sind.
Angeblich klappt das. Nur bei mir gab es irgendwelche Probleme als ich es testen wollte.
Desweiteren gäbe es dann noch Java byte code -> ausführen
Dafür gibt es das Programm "gij". Bisher kann man jedoch nur textbasierte Programme ausführen. Das heißt, daß AWT/Swing-Programme derzeit noch nicht dadrauf laufen.
Gibt es noch einen grund in c++ zu schreiben?
Ja, denn nicht jeder bevorzugt Java. Mir ist C/C++ beispielsweise weit aus lieber. Außerdem kann man in Java bekanntlich nicht direkt Assemblercode integrieren. Wenn man systemnah programmieren will, dann bleiben einem ohnehin nur zwei möglichkeiten:
1. In C/C++ programmieren und dort die Assemblerroutinen integrieren. 2. In Java programmieren und dort per JNI-Schnittstelle C/C++-Bibliotheken integriren, bei denen wie bei 1. verfahren wurde.
so wird der gcc fachmännisch gebaut :) angenommen wird: das paket gcc-3.0 wurde ins verzeichnis /usr/src entpackt und es befindet sich dort auch noch genug platz um den build durchzuführen.
mkdir /usr/src/gcc-build && cd /usr/src/gcc-build && ../gcc-3.0/configure --prefix=/usr \ --with-gxx-include-dir=/usr/include/g++ \ --enable-shared --enable-nls \ --enable-languages=c,c++ && make bootstrap && make install
Wenn der Compiler Native-Code erzeugt, der schneller ist, dann wird sich doch auch hoffentlich KDE beschleunigen. Denn bei einem Athlon 800 mit 512 MB Ram finde ich KDE doch noch recht träge.
Nein, vermutlich nicht deutlich. Aber wenn Prelinking implementiert wird (experimentell scheint es zu klappen), dann dürfte der Startup von KDE-Applikationen (und GNOME-Applikationen und von allem, was große Mengen an Symbolen aus Bibliotheken einbindet) wahnsinnig schneller werden. Also auf GCC 3.1 warten
Nein, vermutlich nicht deutlich. Aber wenn Prelinking implementiert wird (experimentell scheint es zu klappen), dann dürfte der Startup von KDE-Applikationen (und GNOME-Applikationen und von allem, was große Mengen an Symbolen aus Bibliotheken einbindet) wahnsinnig schneller werden. Also auf GCC 3.1 warten
Prelinking ist noch lange nicht in den GCC integriert. So wie ich das verstanden habe, erspart man sich das dynamische Linken von Code gegen Bibliotheken, da die Adressen der einzelnen Symbole der Bibliothek schon im Binary stehen. Wenn man die Bibliothek aktualisiert/ändert, muss natürlich auch das Programm neu compiliert werden, aber der Geschwindigkeitszuwachs für Programme, die massenweise Bibliotheken verwenden (wie das insbesondere KDE tut), scheint wirklich enorm zu sein.
Wer lust hat kann prelinking gern mal ausprobieren:
Ist allerdings version 0.0.0a (-; Ausserdem muss man seine Glibc patchen und neu kompilen, seine Binutils patchen und neu kompilen, und kann seine binaries dann prelinken..
Bin grad dabei, bin mal gespannt, wie viel es wirklich bringt...
das sollte auch mozilla helfen! da ist schon ein projekt am laufen, dass sich damit beschäftigt, einen static-build zum laufen zu bekommen, um den start zu beschleunigen...
Sind eigentlich die PGCC Patches integriert? Ein Gcc 3 Snapshot von vor einem Monat erzeugte jedenfalls bedeutend langsamerere bzip2 Binaries als PGCC. Kann es sein, dass die GCC Entwickler sich immer noch zieren, sinvolle Optimierungen in den gcc aufzunehmen? Man muß ja nicht jede als experimentell gekennzeichnete Optimierungsmethode integrieren, könnte aber doch zumindest die stabilen als optionalen Optimierungslevel anbieten.
Naja, wenn du es so siehst hast du natürlich Recht.
Trotzdem ...
Viel tut sich beim pgcc-Projekt derzeit nicht. Auf der Mailingliste gibts maximal 3 Mails pro Monat, der letzte offizielle Patch ist inzwischen gegen die vorletzte Version von gcc ...
Also ich erwarte nicht so schnell einen offiziellen gcc-3.0-pgcc-3.0-Patch. Hoffentlich macht sich noch mal jemand wie Dean Scott die Mühe selber einen Patch zu basteln, dann ist er eben nicht offiziel - solange er funktioniert, kann uns das egal sein.
Java is ok, und hat seine Existenzberechtigung aber es ist NICHT perfekt und ist fuer real-time Programme (simulations-games/programme aller art) ungeeignet, da es zwangsweise einen garbage collector erfordert.
ne, mal erlich, ich hab mich damit abgefunden mehrere sprachen zu können, da es für jeden bereich eine sprache gibt, die grade dafür gut ist, dann abber in anderen bereichen wieder nicht.
aber wenn die java jezt schon richtig übersetzen ist das natür lich schön, weil, wenn das native code ist, braucht man ja nicht immer die VM, die mich mitunter davon abgehalten hat, java zu nehmen. ich gehe nämlich nicht davon aus, das jeder standartmäßig eine hat.( mich eingeschlossen)
aber generel ist es doch wieder ein zeichen, das der open-source kasten brummt. und das freut mich.
Sorry. Hab mich missverstaendlich ausgedrueckt. 'simulation' bezog sich auch auf 'programme', und damit meine ich die programme, die keine idle-time uebriglassen und generell die cpu bis zum Maximum ausnutzen muessen. Da kann man den Collector nur mit einer relativ hohen Prioritaet laufen lassen, damit er ueberhaupt noch mal zum Zug kommt.
Wie gesagt halte ich Java NICHT fuer ueberfluessig. Staroffice rennt bei mir super.
Ja, das StarOffice = Java gerücht hält sich. Das stimmt aber nicht. Es gibt zwar ein StarOffice das in Java geschrieben ist (Suns nettes Web Office Versuch), aber der hat nichts mit dem normalen StarOffice zu tun
@LH Ja wenn die Firma das Geruecht selber verbreitet ist das auch kein Wunder. Auf der Info-seite zu Star Office steht unter Standards: "Java und Java script technologies" von einer anderen Programmiersprache kann ich nichts sehen. Also entweder haben sie die da klammheimlich nicht aufgelistet, oder sie sehen andere Sprachen nicht als standardisiert an.
Worin soll Star Office denn ueberhaupt sonst geschrieben sein?
Hi, Ich frage mich ernsthaft, wie man auf die Idee kommt, dass Staroffice in Java geschrieben sein koennte (O.K. die Arbeitsgeschwindigkeit scheint darauf hinzuweisen ;-)) ABER: Das Einbinden von Java ist OPTIONAL! Es wird maximal benoetigt, um Javascript und Java im S-office eigenen Browser (Ja, mit S-office kann man auch surfen, und das bis vor kurzen gar nicht mal _so_ schlecht)auszufuehren und zum Einbinden von PGP im S-Office eigenen Mailclient einzubinden. StarOffice selber basiert auf Starview einer von (damals noch) Stardivision entwickelten C++Klassenbibliothek fuer betriebssystemuebergreifende Anwendungsentwicklung ("alte" hasen werden sich vieleicht daran erinnern, dass es S-Office auch mal fuer OS/2 (rest in peace ;-)) und fuer MacOS gab). Sarview konnte man uebrigens vor Urzeiten auch kaeflich erwerben. Starview bringt sozusagen alles schon mit selbst die Routinen zum Zeichenen der Oberflaeche. Deshalb sieht es auch ueberall gleich aus (es wird dafuer halt nicht aufs Bertiebssystem zurueckgegriffen).
So, das war ja ein ziemlicher Roman. Hoffentlich liest das auch mal einer.
multi-inheritance? java:nein c++:ja Eiffel: ja (am besten)
default-params? java:nein c++:ja Eiffel: nein templates? java:nein c++:ja Eiffel: ja =>STL? java:nein c++:ja Eiffel: ja
Im übrigen: Weniger ist mehr. C++ ist wirklich eine der kompliziertesten Sprachen der Geschichte (etwas schlimmer als Thailändisch) oder warum gibts ne Tool Industrie die nur von Debugging Tools lebt.
@Smiler Ok, dann ist StarOffice halt nich in Java geschieben mir auch egal. *g*
@Anonymous Ja c++ is sicherlich eine der kompliziertesten Sprachen die ich kenne und man kann sehr viel Unsinn mit ihr Treiben, trotzdem ist es meine Lieblingssprache
Also, ich hab grad den gcc-3.0 kompiliert und gleich mal glibc-2.2.3 rekompiliert. Lief einwandfrei durch ! Wenn so etwas systemnahes wie die glibc ohne Fehler durchläuft, scheint der gcc-3.0 schon recht stabil zu sein. Ich werde es im Laufe des Tages noch mit dem Kernel und Mozilla probieren.
Die neue gcc Version könnte zu keinem günstigeren Zeitpunkt erscheinen. Ich hab mich gestern grad dran gemacht mein Linux From Scratch neu einzurichten
Mich würde mal interessieren, ob das neue Wunderding auch Athlon-optimierten Code generieren kann. Dann würde man sich nämlich das mühsame rumgepatche mit pgcc- und athlon-Patches sparen, was bei mir sowiso nie funktioniert hat. Weiß da jemand genaueres?
soweit ich weiss, wurde nichts derartiges eingebaut. Aber diese Athlon-Patches haben auch nicht wirklich etwas gebracht, höchstens 5% mehr speed.. also ist es glaube ich nicht so wichtig.
Was brauche ich eigentlich genau ? Auf dem Server finde ich:
-r--r--r-- 1 victor victor 17921956 Jun 17 19:23 gcc-3.0.tar.gz -r--r--r-- 1 victor victor 10151488 Jun 17 19:24 gcc-core-3.0.tar.gz -r--r--r-- 1 victor victor 2078671 Jun 17 19:23 gcc-g++-3.0.tar.gz -r--r--r-- 1 victor victor 1482054 Jun 17 19:23 gcc-g77-3.0.tar.gz -r--r--r-- 1 victor victor 3050240 Jun 17 19:23 gcc-java-3.0.tar.gz -r--r--r-- 1 victor victor 226325 Jun 17 19:23 gcc-objc-3.0.tar.gz -r--r--r-- 1 victor victor 934267 Jun 17 19:24 gcc-testsuite-3.0.tar.gz
beide benches mit '-O3 -march=k6 -mcpu=k6 -fstrict-aliasing -funroll-loops -ffast-math -fomit-frame-pointer'(hab einen k6-2/400)
na, also nbench-byte ist nicht das gelbe vom ei, aber insgesmaqt kann man sagen, dass der speed bei vielen speicherzugriffen höher ist, würde ich sagen..
Bei der Kompilierung der Capi-Treiber fuer die Fritzkarte schmiert gcc-3.0 mit einem internen Compiler-Error ab! (2.95.3 geht!) (ASM-PROBLEME). Dito bei der Neu-Kompilierung des Kernels (2.4.5-ac15) Also _VORSICHT_!
Fehlermeldung wurde bereits bei gnu.org abgeliefert... Vorsicht weil: gcc-3.0 Kompilaten wie glibc und Kernel ist vorerst nicht zu trauen ... dennoch danke fuer den Hinweis... ich teste heftig...
Wann wird eigentlich voraussichtlich der gcc-3.1 erscheinen? Das mit dem prelinking tönt ja ganz verlockend. Dann wird mein Konqueror noch eine ganze Stange schneller ;-)
Schaut euch bitte einmal jbuilder an und vor allem, in was der geschrieben ist.
Der hat wirklich alles, was man an Komfort zur Applikationsentwicklung braucht ( inklusive der Hilfe, dass die Memberfunktionen etc. angezeigt werden).
Und : Nach dem x - ten "segment fault" nimmt man gerne zu Gunsten der Stabilität die niedrigere Geschwindigkeit hin.
Das ist dann sowieso bei einem 10 GHz - Prozessor obsolet .
Und eine Applikation unter Windows und Linux gleich laufen zu sehen, ist doch auch schön.
> Schaut euch bitte einmal jbuilder an und vor allem, in was der geschrieben ist.
Ich kenne JBuilder und bin nicht gerade sehr von ihm begeistert. Gerade weil er in Java geschrieben wurde.
[...]
> Und : Nach dem x - ten "segment fault" nimmt man gerne zu Gunsten der Stabilität die niedrigere Geschwindigkeit hin.
Niedrigere Geschwindigkein und Hoher Speicherverbrauch. Letzteres hast Du vergessen gehabt.
> Das ist dann sowieso bei einem 10 GHz - Prozessor obsolet .
1. Wer hat schon einem 10 GHz-Rechner? Wenn man erst einmal so einen hat, dann wird Java wohl noch langsamer und noch hungriger nach Speicher (wie beim Schritt von Java1.1 auf Java2)
2. Auch bei einem 10 GHz-Rechner spielt die Geschwindigkeit und der Speicherverbrauch eine entscheidende Rolle. Es sind doch immer so viele scharf auf immer mehr unterstuetzen Features von Programmen. Und nun druecken wir es einfach mal so aus: Wenn Du ein Programm erstellen willst, dass nur einen festgelegten Maximal-Speicherverbrauch verwenden und eine festgelegte Minimal-Geschwindigkeit nicht unterschreiten darf, so kannst Du hierbei mit C/C++ viel mehr Features in das Programm einbringen als mit Java - ganz gleich wie schnell der Prozessor ist. Java-Anhaenger "argumentieren" dann zwar weiter damit, dass sie einfach die Geschwindigkeit des Prozessors und den Speicher des Computers gegen Unendlich gehen lassen, weil die Computer ja immer leistungsfaehiger werden, doch das ist kein richtiges Argument. Dann koennte ja auch ruhig jeder Programmierer einen langsamen nicht-optimierten Code erstellen. Und wenn der Rechner Tage dafuer braucht um den Code auszufuehren, dann muessen eben leistungsfaehigere Rechner her - am besten Rechnerfarmen.
Fazit: Der Speicher- und Performanceverbrauch von Java ist nicht zu vertreten.
> Und eine Applikation unter Windows und Linux gleich laufen zu sehen, ist doch auch schön.
1. Wenn Du Programme die unter Windows mit Java ausgefuehrt wurden mit denen verglichen haettest, die unter Linux mit Java ausgefuehrt wurden, dann haettest Du festgestellt, dass diese eben nicht gleich aussehen. Das beginnt mit den Fonts die plattformabhaengig sind, geht weiter ueber die Fenstergroesse - wo selbst IBMs Java unter Linux die Fenster wesentlich kleiner erstellt als Suns Java unter Linux - und endet bei den unzaehligen Bugs von Java (Bei Suns Java unter Linux kann man z.B. nicht mit einer deutschen Tastatur "\" oder "~" eingeben.
Und es ist moeglich schnellere Virtuelle Maschinen zu erstellen. Internet C++ (http://www.xmission.com/~icvm) laeuft beispielsweise so schnell wie Native-Code.
Und jetzt nimm noch einmal Java in Schutz. Ich denke dass duerfte schwer fallen, denn alles was Du mit Java machen kannst, das kannst Du auch mit C++ machen.
@Fridolaeos naja, wenn du "ansi c++" gesagt hättest, würde ich dir recht geben. es läuft auf mehr plattformen als java und man kann alles (und noch mehr) als mit java machen.
Fairerweise muss man allerdings sagen, das "internet c++" wohl eher ein realistischer vergeich mit java währe. immerhin handelt es sich um ähnliche konzepte ("VM") und "internet c++" wurde ja als direkte alternative zu java (und deren vielen macken) entwickelt.
Entspricht der neue gcc eher dem letzten ofiziellen gcc-2.95 oder eher RedHats gcc-2.96 ?
Und wie ist es mit der Installation?
Da ja noch keine RPMs draußen sind, wird es wohl schwierig sein den neuen gcc zu installieren, wenn man bereits einen auf der Platte hat.
man lädt das pket runter, entpackt
./configure
make
und dann checkinstall
der ganze sourcentree braucht auch net allzuviel, ca 200MB
und ich hab ihn unter /usr/local, und dank checkinstall kann ich ihn auch wieder runterputzen.
PS
hat vielleicht jemand den 3.o mit mozilla getestet? mit einem ca. 2 wochen alten snapshot stürzte eine mozilla beim start ab...
Zur Installation: Du macht das ./configure, dann das make bootstap (oder wie es heisst), deinstallierst das alte rpm-Packet vom gcc und macht dein make install. Am besten du hast checkinstall oder instmon um ihn spaeter wieder loeschen zu koennen.
gruss
das gnu, das eigentlich ungern grosse Buchstaben verwendet
NEIN!!!
Der GCC 2.96 ist eine Alpha-Version des GCC 3.0.
Aus diesem Grund ist dessen Einsatz unter RedHat Linux 7.0 kritisiert worden!!!
> NEIN...
Ok, dann nehm ich das zurueck (steht ja auf der Webpage).
Zu meinem obigen Posting: Nicht die Parameter hinter ./configure vergessen. Ausserdem sollte man nich direkt im gcc-Verzeichnis kompilieren und auch nich als root-user (das make install natuerlich schon als root).
Ausserdem heisst es make bootstrap ;).
Instmon ist vergleichbar mit checkinstall. IMHO ist es aber wesentlich einfacher zu bedienen. Es kann ebenfalls tar-, deb- und rpm-Archive aus den installierten Files erstellen, ohne das man Zusatzprogramme benoetigt.
Leider scheint das Project tot zu sein. Die letzte Version (2.0) ist aber praktisch perfekt:
http://hal.csd.auth.gr/~vvas/instmon/
Ich wurde den README-file und den INSTALL-file lesen !!!
Ich entwickle immer auf windows mit
borlands C++ 5.5 weil der einfach um ein
vielfaches schneller ist.
Ist gcc 3.0 jetzt noch langsamer geworden ?
Ein einfaches ./configure reicht beim gcc nicht aus, man wird entweder Probleme bekommen oder verzichtet auf wichtige Funktionen wenn man das ganze ohne Parameter startet !
Die neue gcc-3.0 habe ich zwar noch nicht kompiliert (mache ich heut Abend), aber vor 3 Tagen eine 3.0-Pre Version. Das ganze dann mit folgenden Parametern:
./configure --prefix=/usr --with-gxx-include-dir=/usr/include/g++
--enable-shared --enable-languages=c,c++
make bootstrap
make install
Mit der 3.0-pre habe ich es nicht geschafft die glibc-2.2.3 zu kompilieren, meldete einen Fehler in libgcc_s.so.
Ich hoffe das wurde in der Release behoben ;)
ich denke auch, die erste richtige 3.er version wird 3.0.1 sein. der gcc 3.0 hat bestimmt noch ne menge bugs.
der code vom gcc 3.0 ist für C etwas schneller geworden, für C++ etwas langsamer. Aber zum 3.1 ändert sich das evtl. (hoffentlich)
bye
adrian
langsamer bei c++ :(
läuft mozilla dann damit nicht schneller?
hab mich schon so drauf gefreut...
GCJ can compile Java source or Java bytecodes to either native code or Java class files, and supports native methods written in either the standard JNI or the more efficient and convenient CNI.
Kann ich also:
Java source files -> byte code
Java source files -> native code
Java byte code -> native code
complilieren?
Gibt es noch einen grund in c++ zu schreiben?
MfG
Christoph Held
Ich hatte schon mal ältere gcj-Pakete zum gcc-2.95 nachinstalliert gahabt und habe folgende Erfahrungen gemacht:
> Java sourc files -> Byte code
Geht wunderbar. Der Befehl hierfür lautet gcj. Die verwendeten Klassen sind die Classpath-Klassen (www.classpath.org).
Diese Klassen sind jedoch nicht ganz vollständig und schon garnicht zu Java2 kompatibel. Daher kann man auch mit dem Kompiler "nur" Programme erstellen, die (fast) Java 1.1 kompatibel sind.
>Java source files -> native code
>Java byte code -> native code
Angeblich klappt das. Nur bei mir gab es irgendwelche Probleme als ich es testen wollte.
Desweiteren gäbe es dann noch
Java byte code -> ausführen
Dafür gibt es das Programm "gij". Bisher kann man jedoch nur textbasierte Programme ausführen. Das heißt, daß AWT/Swing-Programme derzeit noch nicht dadrauf laufen.
Gibt es noch einen grund in c++ zu schreiben?
Ja, denn nicht jeder bevorzugt Java. Mir ist C/C++ beispielsweise weit aus lieber.
Außerdem kann man in Java bekanntlich nicht direkt Assemblercode integrieren. Wenn man systemnah programmieren will, dann bleiben einem ohnehin nur zwei möglichkeiten:
1. In C/C++ programmieren und dort die Assemblerroutinen integrieren.
2. In Java programmieren und dort per JNI-Schnittstelle C/C++-Bibliotheken integriren, bei denen wie bei 1. verfahren wurde.
Timolo
Ich hatte schon mal ältere gcj-Pakete zum gcc-2.95 nachinstalliert gahabt und habe folgende Erfahrungen gemacht:
> Java sourc files -> Byte code
Geht wunderbar. Der Befehl hierfür lautet gcj. Die verwendeten Klassen sind die Classpath-Klassen (www.classpath.org).
Diese Klassen sind jedoch nicht ganz vollständig und schon garnicht zu Java2 kompatibel. Daher kann man auch mit dem Kompiler "nur" Programme erstellen, die (fast) Java 1.1 kompatibel sind.
>Java source files -> native code
>Java byte code -> native code
Angeblich klappt das. Nur bei mir gab es irgendwelche Probleme als ich es testen wollte.
Desweiteren gäbe es dann noch
Java byte code -> ausführen
Dafür gibt es das Programm "gij". Bisher kann man jedoch nur textbasierte Programme ausführen. Das heißt, daß AWT/Swing-Programme derzeit noch nicht dadrauf laufen.
Gibt es noch einen grund in c++ zu schreiben?
Ja, denn nicht jeder bevorzugt Java. Mir ist C/C++ beispielsweise weit aus lieber.
Außerdem kann man in Java bekanntlich nicht direkt Assemblercode integrieren. Wenn man systemnah programmieren will, dann bleiben einem ohnehin nur zwei möglichkeiten:
1. In C/C++ programmieren und dort die Assemblerroutinen integrieren.
2. In Java programmieren und dort per JNI-Schnittstelle C/C++-Bibliotheken integriren, bei denen wie bei 1. verfahren wurde.
Timolo
angenommen wird: das paket gcc-3.0 wurde ins verzeichnis /usr/src entpackt und es befindet sich dort auch noch genug platz um den build durchzuführen.
mkdir /usr/src/gcc-build &&
cd /usr/src/gcc-build &&
../gcc-3.0/configure --prefix=/usr \
--with-gxx-include-dir=/usr/include/g++ \
--enable-shared --enable-nls \
--enable-languages=c,c++ &&
make bootstrap &&
make install
viel spass beim neuen gcc
Naja, aber so funktioniert es jedenfalls hervorragend.
Xian
und ist das jetzt im 3.0 aktiviert?
Ist allerdings version 0.0.0a (-;
Ausserdem muss man seine Glibc patchen und neu kompilen, seine Binutils patchen und neu kompilen, und kann seine binaries dann prelinken..
Bin grad dabei, bin mal gespannt, wie viel es wirklich bringt...
hups, glatt vergessen (-:
hups, glatt vergessen (-:
Was du da beschreibst wäre dann ja wohl statisches Linken. Das gibts aber nicht erst mit GCC 3.1, sondern schon mit GCC 0.1
Nö, wäre es nicht. Ich habe nirgendwo geschrieben, adss der Bibliotheken-Code in die Anwendung integriert wird. Nur die Adressen stehen schon drin.
die Unixer statt ELF das etwas einfachere
DLL Format übernommen hätten.
Ums mal in Kiddy sprache zu sagen: das rockt.
Man muß ja nicht jede als experimentell gekennzeichnete Optimierungsmethode integrieren, könnte aber doch zumindest die stabilen als optionalen Optimierungslevel anbieten.
Warte mal bis die pgcc-Jungs einen Patch für gcc 3.0 erstellt haben ... kann aber dauern.
Vorerst sollte es pgcc 2.95.2.1 auch tun.
da gibt es einen unoffziellen, relativ neuen pgcc-patch gegen gcc 2.95.3
falls jemand interesse hat...
Relativ neu ?
Das entsprechende Posting auf der pgcc-ML ist vom April (http://www.delorie.com/archives/browse.cgi?p=pgcc/2001/04/15).
Trotzdem könnte der Patch ruhig als offiziell durch gehen - auf einem Rechner habe ich ein LFS-System damit compiliert, ohne Probleme ...
guck doch mal wie alt der pgcc 2.95.2.1 ist, dagegen ist dieser experimentelle patch sehr neu.
Naja, wenn du es so siehst hast du natürlich Recht.
Trotzdem ...
Viel tut sich beim pgcc-Projekt derzeit nicht.
Auf der Mailingliste gibts maximal 3 Mails pro Monat, der letzte offizielle Patch ist inzwischen gegen die vorletzte Version von gcc ...
Also ich erwarte nicht so schnell einen offiziellen gcc-3.0-pgcc-3.0-Patch.
Hoffentlich macht sich noch mal jemand wie Dean Scott die Mühe selber einen Patch zu basteln, dann ist er eben nicht offiziel - solange er funktioniert, kann uns das egal sein.
aber ich hab grade einmal den mozilla mit dem gcc3 kompiliert. läuft rattenschnell.
als optimierung hab ich nur -O2 genommen.
das teil läuft schneller als wenn ich gcc 2.95.3 mit -O3 -march=k6 -mcpu=k6 -funroll-loops -ffast-math -fstrict-aliasing nehme.
also .. nix mit langsamer bei c++ meine meinung!
multi-inheritance? java:nein c++:ja
default-params? java:nein c++:ja
templates? java:nein c++:ja
=>STL? java:nein c++:ja
Java is ok, und hat seine Existenzberechtigung aber es ist NICHT perfekt und ist fuer real-time Programme (simulations-games/programme aller art) ungeeignet, da es zwangsweise einen garbage collector erfordert.
programme aller art) ungeeignet
ahh ja
weiter so, das macht spaß :)
ne, mal erlich,
ich hab mich damit abgefunden mehrere sprachen zu können, da es für jeden bereich eine sprache gibt, die grade dafür gut ist, dann abber in anderen bereichen wieder nicht.
aber wenn die java jezt schon richtig übersetzen ist das natür lich schön, weil, wenn das native code ist, braucht man ja nicht immer die VM, die mich mitunter davon abgehalten hat, java zu nehmen.
ich gehe nämlich nicht davon aus, das jeder standartmäßig eine hat.( mich eingeschlossen)
aber generel ist es doch wieder ein zeichen, das der open-source kasten brummt. und das freut mich.
-[z]
Sorry. Hab mich missverstaendlich ausgedrueckt. 'simulation' bezog sich auch auf 'programme', und damit meine ich die programme, die keine idle-time uebriglassen und generell die cpu bis zum Maximum ausnutzen muessen. Da kann man den Collector nur mit einer relativ hohen Prioritaet laufen lassen, damit er ueberhaupt noch mal zum Zug kommt.
Wie gesagt halte ich Java NICHT fuer ueberfluessig. Staroffice rennt bei mir super.
Ja wenn die Firma das Geruecht selber verbreitet ist das auch kein Wunder. Auf der Info-seite zu Star Office steht unter Standards: "Java und Java script technologies" von einer anderen Programmiersprache kann ich nichts sehen. Also entweder haben sie die da klammheimlich nicht aufgelistet, oder sie sehen andere Sprachen nicht als standardisiert an.
Worin soll Star Office denn ueberhaupt sonst geschrieben sein?
wie langsam is die Java-Version von StarOffice??!?!?!?
@forumsgötter:
hab ich schonmal vorgeschlagen, für die daten name und emain cookies zu verwenden? genau be sowas machen die nämlich sinn...
Ich frage mich ernsthaft, wie man auf die Idee kommt, dass Staroffice in Java geschrieben sein koennte (O.K. die Arbeitsgeschwindigkeit scheint darauf hinzuweisen ;-))
ABER: Das Einbinden von Java ist OPTIONAL! Es wird maximal benoetigt, um Javascript und Java im S-office eigenen Browser (Ja, mit S-office kann man auch surfen, und das bis vor kurzen gar nicht mal _so_ schlecht)auszufuehren und zum Einbinden von PGP im S-Office eigenen Mailclient einzubinden. StarOffice selber basiert auf Starview einer von (damals noch) Stardivision entwickelten C++Klassenbibliothek fuer betriebssystemuebergreifende Anwendungsentwicklung ("alte" hasen werden sich vieleicht daran erinnern, dass es S-Office auch mal fuer OS/2 (rest in peace ;-)) und fuer MacOS gab). Sarview konnte man uebrigens vor Urzeiten auch kaeflich erwerben. Starview bringt sozusagen alles schon mit selbst die Routinen zum Zeichenen der Oberflaeche. Deshalb sieht es auch ueberall gleich aus (es wird dafuer halt nicht aufs Bertiebssystem zurueckgegriffen).
So, das war ja ein ziemlicher Roman. Hoffentlich liest das auch mal einer.
Viele Gruesse und Respekt an das Pro-Linux Team
Smiler
Smiler
Aus StarOffice wird Openoffice und dessen Sourcecode kann man downloaden. Dort kann man dann sehen, daß es in C++ geschrieben ist.
BTW: Ich glaube mich zu erinnern, schon mal ein RT-Java gesehen zu haben..
default-params? java:nein c++:ja Eiffel: nein
templates? java:nein c++:ja Eiffel: ja
=>STL? java:nein c++:ja Eiffel: ja
Im übrigen: Weniger ist mehr. C++ ist
wirklich eine der kompliziertesten Sprachen
der Geschichte (etwas schlimmer als Thailändisch) oder warum gibts ne Tool Industrie die nur von Debugging Tools lebt.
Ich denke, Scriptsprachen werden, durch ihre höhrere Abstraktion, ein Teil der Zukunft gehöhren.
PROGRAM LH;
BEGIN
WRITELN('Wo wir gerade bei den schönsten Sprachen der Welt sind: Das war und ist doch schon immerPascal gewesen :)');
END.
So was musste ja kommen ;)
@Smiler
Ok, dann ist StarOffice halt nich in Java geschieben mir auch egal. *g*
@Anonymous
Ja c++ is sicherlich eine der kompliziertesten Sprachen die ich kenne und man kann sehr viel Unsinn mit ihr Treiben, trotzdem ist es meine Lieblingssprache
Wenn so etwas systemnahes wie die glibc ohne Fehler durchläuft, scheint der gcc-3.0 schon recht stabil zu sein.
Ich werde es im Laufe des Tages noch mit dem Kernel und Mozilla probieren.
Die neue gcc Version könnte zu keinem günstigeren Zeitpunkt erscheinen. Ich hab mich gestern grad dran gemacht mein Linux From Scratch neu einzurichten
-r--r--r-- 1 victor victor 17921956 Jun 17 19:23 gcc-3.0.tar.gz
-r--r--r-- 1 victor victor 10151488 Jun 17 19:24 gcc-core-3.0.tar.gz
-r--r--r-- 1 victor victor 2078671 Jun 17 19:23 gcc-g++-3.0.tar.gz
-r--r--r-- 1 victor victor 1482054 Jun 17 19:23 gcc-g77-3.0.tar.gz
-r--r--r-- 1 victor victor 3050240 Jun 17 19:23 gcc-java-3.0.tar.gz
-r--r--r-- 1 victor victor 226325 Jun 17 19:23 gcc-objc-3.0.tar.gz
-r--r--r-- 1 victor victor 934267 Jun 17 19:24 gcc-testsuite-3.0.tar.gz
ich hab einen kleinen benchmark gemacht, mit nbench-byte 2.1, hier die ergebnisse:
gcc 2.95.3:
2.069(memory)
1.869(integer)
2.260(fp)
gcc 3.0
2.297
1.895
2.184
beide benches mit '-O3 -march=k6 -mcpu=k6 -fstrict-aliasing -funroll-loops -ffast-math -fomit-frame-pointer'(hab einen k6-2/400)
na, also nbench-byte ist nicht das gelbe vom ei, aber insgesmaqt kann man sagen, dass der speed bei vielen speicherzugriffen höher ist, würde ich sagen..
internen Compiler-Error ab! (2.95.3 geht!) (ASM-PROBLEME). Dito bei der Neu-Kompilierung des Kernels (2.4.5-ac15) Also _VORSICHT_!
Testen, testen, testen
(und bug-reports schreiben!)
Nur so gelangt die community
zu einer guten 3.0.1
Mosh
gcc rules
Schaut euch bitte einmal jbuilder an und vor allem, in was der geschrieben ist.
Der hat wirklich alles, was man an Komfort zur Applikationsentwicklung braucht ( inklusive der Hilfe, dass die Memberfunktionen etc. angezeigt werden).
Und : Nach dem x - ten "segment fault" nimmt man gerne zu Gunsten der Stabilität die niedrigere Geschwindigkeit hin.
Das ist dann sowieso bei einem 10 GHz - Prozessor obsolet
.
Und eine Applikation unter Windows und Linux gleich laufen zu sehen, ist doch auch schön.
Viele Grüße
Miko
Ich kenne JBuilder und bin nicht gerade sehr von ihm begeistert. Gerade weil er in Java geschrieben wurde.
[...]
> Und : Nach dem x - ten "segment fault" nimmt man gerne zu Gunsten der Stabilität die niedrigere Geschwindigkeit hin.
Niedrigere Geschwindigkein und Hoher Speicherverbrauch. Letzteres hast Du vergessen gehabt.
> Das ist dann sowieso bei einem 10 GHz - Prozessor obsolet
1. Wer hat schon einem 10 GHz-Rechner? Wenn man erst einmal so einen hat, dann wird Java wohl noch langsamer und noch hungriger nach Speicher (wie beim Schritt von Java1.1 auf Java2)
2. Auch bei einem 10 GHz-Rechner spielt die Geschwindigkeit und der Speicherverbrauch eine entscheidende Rolle.
Es sind doch immer so viele scharf auf immer mehr unterstuetzen Features von Programmen.
Und nun druecken wir es einfach mal so aus:
Wenn Du ein Programm erstellen willst, dass nur einen festgelegten Maximal-Speicherverbrauch verwenden und eine festgelegte Minimal-Geschwindigkeit nicht unterschreiten darf, so kannst Du hierbei mit C/C++ viel mehr Features in das Programm einbringen als mit Java - ganz gleich wie schnell der Prozessor ist.
Java-Anhaenger "argumentieren" dann zwar weiter damit, dass sie einfach die Geschwindigkeit des Prozessors und den Speicher des Computers gegen Unendlich gehen lassen, weil die Computer ja immer leistungsfaehiger werden, doch das ist kein richtiges Argument. Dann koennte ja auch ruhig jeder Programmierer einen langsamen nicht-optimierten Code erstellen. Und wenn der Rechner Tage dafuer braucht um den Code auszufuehren, dann muessen eben leistungsfaehigere Rechner her - am besten Rechnerfarmen.
Fazit: Der Speicher- und Performanceverbrauch von Java ist nicht zu vertreten.
> Und eine Applikation unter Windows und Linux gleich laufen zu sehen, ist doch
auch schön.
1. Wenn Du Programme die unter Windows mit Java ausgefuehrt wurden mit denen verglichen haettest, die unter Linux mit Java ausgefuehrt wurden, dann haettest Du festgestellt, dass diese eben nicht gleich aussehen.
Das beginnt mit den Fonts die plattformabhaengig sind, geht weiter ueber die Fenstergroesse - wo selbst IBMs Java unter Linux die Fenster wesentlich kleiner erstellt als Suns Java unter Linux - und endet bei den unzaehligen Bugs von Java (Bei Suns Java unter Linux kann man z.B. nicht mit einer deutschen Tastatur "\" oder "~" eingeben.
Und es ist moeglich schnellere Virtuelle Maschinen zu erstellen. Internet C++ (http://www.xmission.com/~icvm) laeuft beispielsweise so schnell wie Native-Code.
Und jetzt nimm noch einmal Java in Schutz. Ich denke dass duerfte schwer fallen, denn alles was Du mit Java machen kannst, das kannst Du auch mit C++ machen.
Fridolaeos
naja, wenn du "ansi c++" gesagt hättest, würde ich dir recht geben. es läuft auf mehr plattformen als java und man kann alles (und noch mehr) als mit java machen.
Fairerweise muss man allerdings sagen, das "internet c++" wohl eher ein realistischer vergeich mit java währe. immerhin handelt es sich um ähnliche konzepte ("VM") und "internet c++" wurde ja als direkte alternative zu java (und deren vielen macken) entwickelt.