Z.B. optimieren Compiler manchmal, obwohl sie es nicht dürften, weil mehrere Threads verwendet werden. http://nopaste.info/50b1b31f7a.html
Machmal bekommt man auch Probleme mit den Prototypen für Uraltfunktionen. So wird unter gewissen Umständen aus char *strstr(const char *haystack, const char *needle); ein const char *strstr(const char *haystack, const char *needle); so dass, viel Arbeit mit Altsoftware anfällt.
Bei der betreffenden Software hatte ich die Faxen dick und habe das hier gemacht :_) ########################################## // gcc 4.4 workarounds // they modified prototypes of str functions static char *mystrstr(const char *s1, const char *s2) { char *ret; const char *cptr = strstr(s1,s2); memcpy(&ret, &cptr, sizeof(ret)); return ret; }
In C++ könnte man const_cast verwenden. Aber wer in C++ strstr verwendet gehört sowieso entlassen. Und wer in C strstr u.d.G. und keine gescheite String Lib verwendet ist Masochist.
Z.B. optimieren Compiler manchmal, obwohl sie es nicht dürften, weil mehrere Threads verwendet werden. http://nopaste.info/50b1b31f7a.html
Für so etwas gibt's doch volatile. Oder irre ich mich? Jeder würde die Variable a und b im Register halten und nicht immer wieder neu anfordern aus dem Speicher in einer solchen Schleife.
stimmt, genau sowas lernt man schon in der ersten stunde des programmierens nicht wahr?
das also sind datentypen... das sind schleifen... das ist volatile...
ich würd ihm eher vorschlagen einfach die denkweise zu ändern... statt "omg wir brauchen einen workaround" ein gedanke a la "vielleicht haben die leute bei gcc an mich gedacht und es gibt eine lösung des problems" + google. meiner erfahrung nach sind es genau die alteingesessenen coder, die, sobald sie auf neuland stoßen, alles mit ihrem horizont lösen wollen, statt mal ne stunde zu googlen (Selbstbeobachtung ftw). und die anfänger der neuen generation sind die "noob" schreier.
Naja, aber das heißt ja nicht, dass man deswegen nur selbst entwickelte Libs verwenden sollte. Oder wie google / apple, einfach ein freies projekt forken und selber weiter entwicklen, um sich nicht mit den API-Änderungen der anderen rum ärgern zu müssen
Imho. muss man sich lediglich richtig entscheiden: Welche fremde Lib nehme ich? z.B. mal im Web-Umfeld. Nehme ich ein Zend Framework als Fremdbibliothek kann ich mir sicher sein, dass es weitgehend Kompatibel ist - und wenn sich etwas ändert, dann bin ich A) darüber informiert B) Alles gut dokumentiert C) Auch noch vollwertig getestet (UnitTest etc.)
Ich habe nur leider die Erfahrung gemacht, das dass in der C/C++ / Systemprogrammierungs- welt etwas anders aussieht. Da wird Code entwickelt - weitgehend undokumentiert: "Guter Code braucht keine Dokumentation" - und wenn sich dann die Libs ändern: "Uff, erstmal nen Jahr portieren..." - dabei haben die Releasezyklen der Libs auch ein riesen Abstand - so dass bei jeder Major Version Change - sich alles ändert.
Wie wäre es denn mit guter Dokumentation, vielen kleinen Changes und Releasezyklen (monatlich z.B.), automatisierten UnitTests (Test schreiben für jede Funktion, dann automatisiert Testzyklus anwerfen nach einem Lib-Update und schauen wo genau anstatt einem OK ein FAILED steht)?
Dann anstatt einer unhandlichen Mailingliste vielleicht ein gut gepflegtes Wiki, einen öffentlichen Bugtracker und eine Website mit viel guter Dokumentation, wo User ihre eigene Erfahrungen einbringen können.
Probleme? Welche Entwicklungsprobleme? Welche Libraryprobleme?
Es ist nicht alles schlecht, was sich dynamisch und agil entwickelt. Auch wenn es in der Verganhenheit vielleicht oft den Anschein hatte.
Manchmal - und das ist jetzt nicht auf dich bezogen - sondern auf erfahrene Entwickler generell - ist es ganz sinnvoll, Dinge neu zu bewerten. Es ist alles stetig im Wandel...
Ich persönlich mag zwar ein "Jungspung" sein, aber ich verlasse ich A) auf aktuelle und gute Informationen - die ich auch von Google bekomme und B) Bewerte ich alle Informationen mit meinem Verstand und meiner Erfahrung. Aber ich bewerte auch meine Erfahrung immer wieder neu. Oft bildet man sich auch Vorurteile oder "Tatsachen" ändern sich einfach mit der Zeit.
Was ich allerdings wirklich schade finde ist, das viele erfahrene Entwickler ihr Wissen nicht weitergeben und eher "hinter den Kulissen" arbeiten. Da werden dann ganz großartige Dinge entwickelt - von denen auch im tollen Web 2.0 niemand etwas mitbekommt - einfach weil "Alte Hasen" keinen Hype daraus machen.
Ich habe heute ein Interview gesehen was mich grade daran erinnert. Seht euch das mal an, da fällt doch jeder vom Glauben:
Das meine ich mir jahrzehntelanger Erfahrung. Ich kenne mehr so talentierte und erfahrene Entwickler. KnowHow-Transfer? Fehlanzeige. Kann ich bei ihm nicht bewerten - aber generell: Sehr schade, denn nur so können die eigenen Ideen doch in der Zukunft fortbestehen?!
Sehr schön. Das ist es, mal eigene Ideen entwickeln und umsetzen und nicht nur vorgekaute Sachen, die man über google finden kann.
Das haben wir auch probiert/gemacht. http://pvbrowser.org Lange bevor von Ajax die Rede war
Inzwischen nutze ich das nicht nur für die Prozessvisualisierung.
Das ist ein Open Source Projekt und wir bemühen uns um gute Dokumentation und enge Verbindung zu den Benutzern mit frühen Veröffentlichungen. (Doxygen Doku, git Repository ...) Gerade basteln wir an einer verbesserten Doku. In Deutsch ist die schon recht weit, muss aber erst noch von einigen Anwendern Korrektur gelesen und erweitert werden, bevor die englische Übersetzung folgen kann. http://pvbrowser.org/pvbrowser/tar/pvb.pdf
PS: Qt3 -> Qt4 war schon eine fundamentale Änderung. Positiv, wenn man es erst mal gemeistert hat aber problematisch, wenn man viele auf Qt3 basierende Progrämmchen portieren muss. Das erzeugt viel Arbeit bei allen Anwendern der Bibliothek und das darf nicht zu oft gemacht werden. Warum hat KDE4 denn so eine lange Vorlaufzeit gehabt ?
Der Compiler darf hier Optimieren wie er will. Wenn der Nutzer keine Ahnung von Kohaerenz und Nebenlaeufigkeit hat, dann kann der Compiler auch nichts dafuer. Fuer soetwas gibt es Locking und atomic-Operations.
Nur zuer weiteren Erklaerung. a und b sind global definiert. In der Schleife kann nun der Compiler nicht unbedingt wissen, ob a und b irgendwo anders gebraucht werden. Er geht davon aus, dass er alles in einem Register halten kann, bis er auf eine Funktion stoesst ueber deren Zugriffe er nicht Bescheid weiss. Also ob sie pure/const oder aehnliches ist. In dem Fall denkt er einfach, dass er alle in Registern gehaltene Daten zurueckschreiben muss. In dem Fall landen sie mindestens im Cache, aber vielleicht auch im Speicher. Bei deiner Funktion weiss er aber, dass die Funktion nicht auf a oder b zugreift, da er den Funktionskoerper analysieren kann. Somit muss er das Register noch nicht zurueckschreiben. Die Rueckschreibeaktion in den Speicher wuerde nun folgen, wenn die Funktion zu Ende ist. Da hier aber eine Schleife ewig laeuft, wird nur im Register gearbeitet. Wenn man nun in den Speicher schreiben will, dann muss man volatile angeben. Hier wird sozusagen versucht moeglichst alles im Speicher zu machen.... aber das stimmt nur halt. C/C++ bieten keine atomaren Operatoren. Hierfuer muesste man entsprechenden platformabhaengigen Assemblercode schreiben oder auf die Mutexes/Spinlocks/Semaphoren zurueckgreifen. Dies ist besonders wichtig bei Test_Set/-_INC/-_DEC Operationen. Bei komplexeren Operatoren sind sowieso Mutexes/Spinlocks/Semaphoren notwendig.
Auf dem M68000 gab es z.B. TAS (Test and Set) Assemblerbefehle. Oder den Software Interrupt TRAP
Den x86 kenne ich jetzt nicht so auf Assemblerebene.
Ansonsten sind die pthread Routinen ja schon mal die halbe Miete. Aber die sind unter Windows nicht verfügbar, weshalb wir hier wieder einen Wrapper brauchen, wenn wir portabel sein wollen. Bei uns sieht das so aus: http://pvbrowser.de/pvbrowser/sf/manual/rllib/html/classrlThread.html
Jetzt wird von pthread aber nicht auf allen Plattformen PROCESS_SHARED unterstützt. Weshalb wir bei portabler Programmierung doch unseren eigenen Spin-Lock programmieren müssen
Außerdem bleiben uns alten Transputer-Fans ja noch die Kommunizierenden Sequentiellen Prozesse. Nur eben über TCP / UDP / Mailbox und nicht über Transputer Links oder Channels.
- Wir wollen auch OpenVMS unterstützen. - Wir wollen den Footprint möglichst gering halten. - Im Falle eines Falles wollen wir die volle Kontrolle behalten. - In unserer Library brauchen wir viele Funktionen, die nicht in Boost drin sind (Bereich Automatisierungstechnik SPS/Feldbus) - Wir wollen Klassen, die so einfach zu benutzen sind, wie wir es von Qt gewohnt sind.
> Qt hat ja auch threads und locks u.d.G. Wenn ihr eh Qt verwendet, warum nicht deren thread Dinge? Tun wir ja auch, aber eben nur im Client. Im Server verwenden wir NUR eigene Bibliotheken.
Das ist unser Projekt: http://pvbrowser.org
PS: In Qt sind inzwischen auch gewisse Sachen für Server Anwendungen drin. Das war Anfangs aber nicht so und von OpenVMS kann bei Qt keine Rede sein.
> und von OpenVMS kann bei Qt keine Rede sein. Kleine Anekdote von 1998
Ich hatte Qt2 auf OpenVMS portiert. Der Drucker hat allerdings nur Postscript fähige Drucker unterstützt.
Das Haupt Problem war damals, dass VMS eine total andere Syntax in Directory Namen hat und die Syntax an zig Stellen in Qt relevant war und bearbeitet wurde. Da hab ich einen grauenhaften Hack gebaut Aber es hat funktioniert.
Eric Avitsland von Trolltech war Anfangs an dem Port interessiert, hat dann aber die Hände über dem Kopf zusammen geschlagen
Dir ist aber schon klar, dass die Implementierung von Spinlocks streng architekturabhaengig ist? Sobald eine andere Cache-Kohaerenz benutzt wird, kann man sich im Mehrprozessor/Multicore nicht nur ins Bein schiessen.
> Dir ist aber schon klar, dass die Implementierung von Spinlocks streng architekturabhaengig ist? > Sobald eine andere Cache-Kohaerenz benutzt wird, > kann man sich im Mehrprozessor/Multicore nicht nur ins Bein schiessen. Man muss nur sicherstellen, dass der Lock im RAM liegt und NICHT im Cache oder Register. Der RAM Controller kann ja nur einem Core/CPU Lesen oder Schreiben gestatten. Der Memory Zyklus ist immer unteilbar. Dann klappt das auch auf Multi Prozessor Systemen.
Ok, und das sicherstellen, dass es ohne Umwege im Speicher landet ist also ein einfacher losbaeres Problem, dass ultra portabel ist. Frag mal die GLIBC-pthreads Leute, die sich da hinten in der Ecke gerade vor Lachen auf dem Boden rumrollen.
>Machmal bekommt man auch Probleme mit den Prototypen für Uraltfunktionen. >So wird unter gewissen Umständen aus >char *strstr(const char *haystack, const char *needle); >ein >const char *strstr(const char *haystack, const char *needle); >so dass, viel Arbeit mit Altsoftware anfällt.
Du meinst sicher was anderes. Siehe unter C++-Compliance: http://udrepper.livejournal.com/
Ich verstehe Dein Problem nicht. Du hast doch nur dann Stress, wenn Du die C++-Varianten benutzt. Und selbst dann hast Du kein Problem, wenn haystack und Return-Wert bei Dir den gleichen Typ (incl. const-Modifier) haben.
Es sollte doch eine Kleinigkeit sein, den Code daran anzupassen, so da tatsächlich noch solche Konstrukte drin sind.
Und FreeBSD verwendet leider immer noch 4.2.1, was sich in Zukunft auch nicht so schnell ändern wird (siehe GPL3 Vs BSDL). Die binutils sind noch älter, ein aktuelles x264 mit dem dortigen Inlineassembler läßt sich nur noch mit Einschränkungen kompilieren.Schon heute kann man die Performance-Unterschiede seitens einiger Applikationen in puncto Compiler beobachten.
Von Ist wer über GCJ im Bilde? am Do, 3. Dezember 2009 um 14:07 #
Damit müßte man ja aus .java Code native Anwendungen kompilieren können. Ist dies auch mit Swing möglich? Hätte hier eine Anwendung mit Swing die ich gerne als .exe hätte ohne die JRE. Danke mike
Ja aber schneller wirds damit auch nicht unbedingt (in der tat scheint der JIT von Sun deutlich besser zu sein, gefühlter Weise). Auch geht dann kein dynamic class loading.
und vor allem so schätz ich mal, die laufzeitoptimierung der VM, was ein großer vorteil bei java servern ist... nicht zu sprechen von der security einer VM...
dynamic class loading wird teilweise so extensiv in der serverentwicklung benutzt, dass man zumindest den devserver ohnehin in java rennen lässt. und normalerweise brauch ich genau dort kein swing.
aber in kleinen bis mittelgroßen nativen gui anwendungen dürfte dynamic class loading wiederum kein problem sein, ausser man arbeitet an einer java-ide... die frage ist also wirklich: ist swing auf basis von gnu classpath compilierbar / enthalten?
es gab mal vor einigen jahren im fedoraprojekt vergleiche mit einer (teilweise) nativen umsetzung von eclipse und der reinen java version. soweit ich weiss schnitt da die native eclipse schon etwas besser ab in sachen speed, man musste aber auf viele funktionen verzichten.
Es gibt aber kaum einne Sinn für Native Java Anwendungen. Die sind auch so fett wie die Java Anwendung + JRE und genauso langsam da das Java Performance Problem ein Problem der Sprache des Entwicklungsprocesses und der Libs sind und nicht die des Compilers.
Java ist nicht so lahm wie man denken mag. Es kommt immer ein wenig auf die Programmierweise an. (myths)
Das man eine JRE benötigt die etwas Speicher in Anspruch nimmt ist auch nicht so verwerflich wie oft angemerkt. Denn schließlich muss ich auch die Bibliotheken die ich in C Programmen verwende auf dem System, auf dem das Programm laufen soll, zur Verfügung haben. Als Beispiele boost, Qt, Gtk usw. Die auch nicht immer klein sind.
Einen Sinn ergibt das Übersetzen von Java zu nativem Maschinencode wohl wirklich kaum, denn die Sun Java VM optimiert richtig stark. Da kann ein Quicksort in Java schon mal schneller als in C sein.
Von TherealPartykracher am Fr, 4. Dezember 2009 um 08:21 #
Gedulde dich noch ein kleines bisschen bis der Vertrag zwischen Intel und HP als quasi einzigem Abnehmer von Itanium-Prozzis in knapp 2 Jahren ausläuft, dann ist das Thema gegessen und zwar final.
Ja ich warte und dann kriegen wir wohl endlich VMS für Intel ET64 Denn solange das nicht woanders läuft kriegt Intel von Obama nicht die Erlaubnis das einzustellen.
http://nopaste.info/50b1b31f7a.html
Machmal bekommt man auch Probleme mit den Prototypen für Uraltfunktionen.
So wird unter gewissen Umständen aus
char *strstr(const char *haystack, const char *needle);
ein
const char *strstr(const char *haystack, const char *needle);
so dass, viel Arbeit mit Altsoftware anfällt.
> ein
> const char *strstr(const char *haystack, const char *needle);
Bei der betreffenden Software hatte ich die Faxen dick und
habe das hier gemacht :_)
##########################################
// gcc 4.4 workarounds
// they modified prototypes of str functions
static char *mystrstr(const char *s1, const char *s2)
{
char *ret;
const char *cptr = strstr(s1,s2);
memcpy(&ret, &cptr, sizeof(ret));
return ret;
}
static char *mystrchr(const char *s1, int c)
{
char *ret;
const char *cptr = strchr(s1,c);
memcpy(&ret, &cptr, sizeof(ret));
return ret;
}
static char *mystrrchr(const char *s1, int c)
{
char *ret;
const char *cptr = strrchr(s1,c);
memcpy(&ret, &cptr, sizeof(ret));
return ret;
}
Oder noch einfacher
#define mystrstr(s1,s2) ((char*) strstr(s1,s2))
Also ich hab's jetzt nicht getestet, aber es kam mir nur halt komisch vor...
http://nopaste.info/50b1b31f7a.html
Für so etwas gibt's doch volatile. Oder irre ich mich?
Jeder würde die Variable a und b im Register halten und nicht immer wieder neu anfordern aus dem Speicher in einer solchen Schleife.
Leider ist das dem Benutzer unserer Lib und auch mir nicht bewusst gewesen
http://www.imb-jena.de/~gmueller/kurse/c_c++/c_volat.html
das also sind datentypen... das sind schleifen... das ist volatile...
ich würd ihm eher vorschlagen einfach die denkweise zu ändern... statt "omg wir brauchen einen workaround" ein gedanke a la "vielleicht haben die leute bei gcc an mich gedacht und es gibt eine lösung des problems" + google.
meiner erfahrung nach sind es genau die alteingesessenen coder, die, sobald sie auf neuland stoßen, alles mit ihrem horizont lösen wollen, statt mal ne stunde zu googlen (Selbstbeobachtung ftw). und die anfänger der neuen generation sind die "noob" schreier.
Der studiert zur Zeit Informatik.
Mit Google kommen die "Jungspunde" schon recht weit.
Auch kenne Google
Aber manchmal verlasse ich mich auch noch auf den eigenen Verstand / Erfahrung.
Z.B. weiß ich, dass die API's ALLER fremden Bibliotheken sich irgendwann ändern werden.
Siehe Qt3 -> Qt4, was uns ca. 1 Jahr gekostet hat.
Oder wie google / apple, einfach ein freies projekt forken und selber weiter entwicklen,
um sich nicht mit den API-Änderungen der anderen rum ärgern zu müssen
Imho. muss man sich lediglich richtig entscheiden: Welche fremde Lib nehme ich?
z.B. mal im Web-Umfeld. Nehme ich ein Zend Framework als Fremdbibliothek kann ich mir
sicher sein, dass es weitgehend Kompatibel ist - und wenn sich etwas ändert, dann bin
ich A) darüber informiert B) Alles gut dokumentiert C) Auch noch vollwertig getestet (UnitTest etc.)
Ich habe nur leider die Erfahrung gemacht, das dass in der C/C++ / Systemprogrammierungs-
welt etwas anders aussieht. Da wird Code entwickelt - weitgehend undokumentiert:
"Guter Code braucht keine Dokumentation" - und wenn sich dann die Libs ändern:
"Uff, erstmal nen Jahr portieren..." - dabei haben die Releasezyklen der Libs auch ein
riesen Abstand - so dass bei jeder Major Version Change - sich alles ändert.
Wie wäre es denn mit guter Dokumentation, vielen kleinen Changes und Releasezyklen (monatlich z.B.),
automatisierten UnitTests (Test schreiben für jede Funktion, dann automatisiert Testzyklus anwerfen
nach einem Lib-Update und schauen wo genau anstatt einem OK ein FAILED steht)?
Dann anstatt einer unhandlichen Mailingliste vielleicht ein gut gepflegtes Wiki,
einen öffentlichen Bugtracker und eine Website mit viel guter Dokumentation, wo
User ihre eigene Erfahrungen einbringen können.
Probleme? Welche Entwicklungsprobleme? Welche Libraryprobleme?
Es ist nicht alles schlecht, was sich dynamisch und agil entwickelt.
Auch wenn es in der Verganhenheit vielleicht oft den Anschein hatte.
Manchmal - und das ist jetzt nicht auf dich bezogen - sondern auf
erfahrene Entwickler generell - ist es ganz sinnvoll, Dinge neu zu
bewerten. Es ist alles stetig im Wandel...
Ich persönlich mag zwar ein "Jungspung" sein, aber ich verlasse
ich A) auf aktuelle und gute Informationen - die ich auch von
Google bekomme und B) Bewerte ich alle Informationen mit meinem
Verstand und meiner Erfahrung. Aber ich bewerte auch meine Erfahrung
immer wieder neu. Oft bildet man sich auch Vorurteile oder "Tatsachen"
ändern sich einfach mit der Zeit.
Was ich allerdings wirklich schade finde ist, das viele erfahrene
Entwickler ihr Wissen nicht weitergeben und eher "hinter den Kulissen"
arbeiten. Da werden dann ganz großartige Dinge entwickelt -
von denen auch im tollen Web 2.0 niemand etwas mitbekommt -
einfach weil "Alte Hasen" keinen Hype daraus machen.
Ich habe heute ein Interview gesehen was mich grade daran
erinnert. Seht euch das mal an, da fällt doch jeder vom Glauben:
http://www.celemony.com/cms/index.php?id=dna_interview
Das meine ich mir jahrzehntelanger Erfahrung. Ich kenne mehr
so talentierte und erfahrene Entwickler. KnowHow-Transfer?
Fehlanzeige. Kann ich bei ihm nicht bewerten - aber generell:
Sehr schade, denn nur so können die eigenen Ideen doch in
der Zukunft fortbestehen?!
Das ist es, mal eigene Ideen entwickeln und umsetzen und nicht nur vorgekaute Sachen, die man über google finden kann.
Das haben wir auch probiert/gemacht.
http://pvbrowser.org
Lange bevor von Ajax die Rede war
Inzwischen nutze ich das nicht nur für die Prozessvisualisierung.
Das ist ein Open Source Projekt und
wir bemühen uns um gute Dokumentation und enge Verbindung zu den Benutzern mit frühen Veröffentlichungen.
(Doxygen Doku, git Repository ...)
Gerade basteln wir an einer verbesserten Doku. In Deutsch ist die schon recht weit, muss aber erst noch von einigen Anwendern Korrektur gelesen und erweitert werden, bevor die englische Übersetzung folgen kann.
http://pvbrowser.org/pvbrowser/tar/pvb.pdf
PS: Qt3 -> Qt4 war schon eine fundamentale Änderung. Positiv, wenn man es erst mal gemeistert hat aber problematisch, wenn man viele auf Qt3 basierende Progrämmchen portieren muss. Das erzeugt viel Arbeit bei allen Anwendern der Bibliothek und das darf nicht zu oft gemacht werden. Warum hat KDE4 denn so eine lange Vorlaufzeit gehabt ?
Auf dem M68000 gab es z.B. TAS (Test and Set) Assemblerbefehle.
Oder den Software Interrupt TRAP
Den x86 kenne ich jetzt nicht so auf Assemblerebene.
Ansonsten sind die pthread Routinen ja schon mal die halbe Miete.
Aber die sind unter Windows nicht verfügbar,
weshalb wir hier wieder einen Wrapper brauchen, wenn wir portabel sein wollen.
Bei uns sieht das so aus:
http://pvbrowser.de/pvbrowser/sf/manual/rllib/html/classrlThread.html
Jetzt wird von pthread aber nicht auf allen Plattformen
PROCESS_SHARED
unterstützt.
Weshalb wir bei portabler Programmierung doch unseren eigenen Spin-Lock programmieren müssen
Außerdem bleiben uns alten Transputer-Fans ja noch die Kommunizierenden Sequentiellen Prozesse.
Nur eben über TCP / UDP / Mailbox und nicht über Transputer Links oder Channels.
- Wir wollen auch OpenVMS unterstützen.
- Wir wollen den Footprint möglichst gering halten.
- Im Falle eines Falles wollen wir die volle Kontrolle behalten.
- In unserer Library brauchen wir viele Funktionen, die nicht in Boost drin sind (Bereich Automatisierungstechnik SPS/Feldbus)
- Wir wollen Klassen, die so einfach zu benutzen sind, wie wir es von Qt gewohnt sind.
Tun wir ja auch, aber eben nur im Client.
Im Server verwenden wir NUR eigene Bibliotheken.
Das ist unser Projekt:
http://pvbrowser.org
PS: In Qt sind inzwischen auch gewisse Sachen für Server Anwendungen drin. Das war Anfangs aber nicht so und von OpenVMS kann bei Qt keine Rede sein.
Kleine Anekdote von 1998
Ich hatte Qt2 auf OpenVMS portiert.
Der Drucker hat allerdings nur Postscript fähige Drucker unterstützt.
Das Haupt Problem war damals, dass VMS eine total andere Syntax in Directory Namen hat und die Syntax an zig Stellen in Qt relevant war und bearbeitet wurde.
Da hab ich einen grauenhaften Hack gebaut
Aber es hat funktioniert.
Eric Avitsland von Trolltech war Anfangs an dem Port interessiert, hat dann aber die Hände über dem Kopf zusammen geschlagen
> Sobald eine andere Cache-Kohaerenz benutzt wird,
> kann man sich im Mehrprozessor/Multicore nicht nur ins Bein schiessen.
Man muss nur sicherstellen, dass der Lock im RAM liegt und NICHT im Cache oder Register.
Der RAM Controller kann ja nur einem Core/CPU Lesen oder Schreiben gestatten.
Der Memory Zyklus ist immer unteilbar.
Dann klappt das auch auf Multi Prozessor Systemen.
Siehe:
http://dev.laptop.org/~mstone/sources/expanded_srpms/glibc-2.7-2/
glibc-20071017T2029/nptl/sysdeps/alpha/pthread_spin_lock.S
Da gibt es gute Anregungen.
ACHTUNG: Link wieder von den 2 Zeilen zusammenbasteln, weil das Forum zickt.
btw: vielleicht sollte die Zeile mit "Erlaubte HTML-Tags:" im "Kommentar abgeben"-Formular stärker hervorgehoben werden
>So wird unter gewissen Umständen aus
>char *strstr(const char *haystack, const char *needle);
>ein
>const char *strstr(const char *haystack, const char *needle);
>so dass, viel Arbeit mit Altsoftware anfällt.
Du meinst sicher was anderes. Siehe unter C++-Compliance: http://udrepper.livejournal.com/
Ärgerlich ist das, wenn man ältere Software pflegen muss.
Es sollte doch eine Kleinigkeit sein, den Code daran anzupassen, so da tatsächlich noch solche Konstrukte drin sind.
lg
Erik
lang/gcc34
lang/gcc42
lang/gcc43
lang/gcc44
lang/gcc45
Welcher darfs denn sein?
)`:
Ist dies auch mit Swing möglich?
Hätte hier eine Anwendung mit Swing die ich gerne als .exe hätte ohne die JRE.
Danke mike
dynamic class loading wird teilweise so extensiv in der serverentwicklung benutzt, dass man zumindest den devserver ohnehin in java rennen lässt. und normalerweise brauch ich genau dort kein swing.
aber in kleinen bis mittelgroßen nativen gui anwendungen dürfte dynamic class loading wiederum kein problem sein, ausser man arbeitet an einer java-ide... die frage ist also wirklich: ist swing auf basis von gnu classpath compilierbar / enthalten?
es gab mal vor einigen jahren im fedoraprojekt vergleiche mit einer (teilweise) nativen umsetzung von eclipse und der reinen java version. soweit ich weiss schnitt da die native eclipse schon etwas besser ab in sachen speed, man musste aber auf viele funktionen verzichten.
oder kommt da wirklich was neues mit gcc 4.5, was bei gcj jetzt wichtig wäre?
Siehe hier
Das man eine JRE benötigt die etwas Speicher in Anspruch nimmt ist auch nicht so verwerflich wie oft angemerkt. Denn schließlich muss ich auch die Bibliotheken die ich in C Programmen verwende auf dem System, auf dem das Programm laufen soll, zur Verfügung haben. Als Beispiele boost, Qt, Gtk usw. Die auch nicht immer klein sind.
Einen Sinn ergibt das Übersetzen von Java zu nativem Maschinencode wohl wirklich kaum, denn die Sun Java VM optimiert richtig stark. Da kann ein Quicksort in Java schon mal schneller als in C sein.
Grüße
bsel
Denn solange das nicht woanders läuft kriegt Intel von Obama nicht die Erlaubnis das einzustellen.