Zitat von jeuneS2

Das Java Memory Model ist kaputt und auf einigen Intel Architekturen nicht implementierbar, aber wie gesagt, es gibt zumindest etwas.)

Wieso das? Und welche Intel-Architekturen meinst du?

Ich hab mich in den letzten Monaten im Zuge meiner Diplomarbeit recht intensiv damit beschäftigt, und mir ist jetzt nichts bewusst, was auf Intel wirklich ein Problem wäre. Und das JMM ist beeindruckend gut durchdacht (da haben sich ja auch ziemlich viele Leute ziemlich lang den Kopf darüber zerbrochen…). In Bezug auf die Zulässigkeit mancher Compilertransformationen herrscht nicht 100% Einigkeit bzw. Zufriedenheit, aber sonst ist das JMM ein Meisterstück ;).

Die einzige Mainstream-Architektur, auf der es wirklich schwierig zu implementieren ist, ist Alpha; und die ist am Aussterben.

Weder noch. Es steht ein Pointer auf eine Virtual Function Table drinnen, und der ist immer vor den Datenfeldern. Natürlich legt der Standard nicht fest, wie das auszusehen hat, aber es gibt wohl kaum eine andere vernünftige Methode.

http://www.joelonsoftware.com/articles/Unicode.html

Ich hoffe, du verstehst überhaupt, worum es geht...

Die Übersetzung "einschließen" für #include gefällt mir :D. Waahhhhhhhhh!

Kann es sein, dass deine DLL noch andere DLLs braucht, die das Java nicht im Pfad hat? Die VC2005 dlls sollten ja eigentlich im Pfad sein, wenn du's installiert hast, aber schau mal genau nach, ob's vielleicht daran liegt. Der Rest sieht eigentlich recht vernünftig aus.

maciek: Nein, das ist nicht das gleiche. Es hat sich nur so angehört. Mittlerweile hab ich auch schon gemerkt, dass unseres ca. 1 1/2 Jahre später begonnen hat.

hal: Ja ich weiß schon, wie das mit dem Pflichtenheft läuft. Wir haben halt anscheinend sehr sture Kunden, die um keinen Preis irgendeinen Punkt aus dem Pflichtenheft streichen wollen, obwohl manche Punkte komplett sinnlos sind.

Ich war am Projektmanagement nicht beteiligt, aber ich habe keinen besonderen Glauben mehr daran. Wenn wir das bauen würden, wovon der Kunde am Anfang meint, dass er es braucht, dann hätten wir wohl keine sehr zufriedenen Kunden. Denn es stellt sich immer im Zuge der Entwicklung heraus, dass man damit überhaupt nichts anfangen kann. Dann werden Pläne geändert; besonders lustige Kunden beharren dann noch auf jedem klitzekleinen Punkt aus dem Pflichtenheft, obwohl sie 50% Funktionalität bekommen, die dort nichtmal erwähnt ist. Aber bitte - je mehr sinnloses Zeug sie aus dem Pflichtenheft haben wollen, umso weniger Zeit bleibt uns für die wichtigen Sachen, die der Kunde dann unweigerlich in einem Change Request bestellen (und bezahlen) wird.

Ich hab schon gedacht, das ist unser Kunde (ein großer Wiener Blumenhändler). Das Projekt hat sich am Anfang auch so ähnlich angehört. Und dann ist es gewachsen, gewachsen, gewachsen und hat wohl so an die 2 Mannjahre verschlungen, weil die Kunden halt in der Regel wirklich nicht wissen, was sie wollen. Aber solange er zahlt, soll's mir recht sein...

Ich komm grad drauf, dass meine Methode falsch ist...

Nachdem hier nichts von asymptotischer Laufzeitbeschränkung steht, würde ich eine rekursive Funktion machen, die ein Quadrat als Input nimmt (Seitenlänge a) und zuerst mal dessen Hauptdiagonale checkt. Danach ruft sie sich rekursiv für alle 4 Teilquadrate mit Seitenlänge a-1 auf und addiert dann alles zusammen. Ganz außen muss man das Ding halt in einer Schleife aufrufen, wenn man ein Rechteck hat.

Nein, für

for(var i=0, len=this.effects.length;i<len;i++) 
      if (this.effects[i]) this.effects[i].loop(timePos);

Ich habe auch gcc 4.0.1 (Tiger).

macbook-3:~/,storage/download/temp/mini/Mini Calculator sr$ gcc -m64 *.c -lm
stack.c: In function 'stackpop':
stack.c:77: warning: cast from pointer to integer of different size

Zitat

Kaum zu glauben das die version so viel ausmacht.

In letzter Zeit (ab 4.0) sind sehr viele Warnungen dazugekommen. Aber in diesem Fall macht die Version anscheinend nichts aus.

Wenn du mit -m64 compilierst, kriegst du im MacOS X auch die Warnung mit der Pointergröße.

Zitat von lowkey

bin mir nicht sicher wie du die stack.c fehlermeldung bekommst, denn die habe ich nicht bekommen.

Wie gesagt: nicht alles, was aussieht wie Linux, ist 32bittig.

Das tut weh: stack.c:77: warning: cast from pointer to integer of different size

Es ist nicht alles 32bittig.

Dieser Pointer/Integer-Vergleich ist schon mal sehr unschön, aber wenn schon, dann brauchst du intptr_t für den cast.

EDIT: Noch was: Wo steht in der Angabe, dass die Zeilen maximal 19 Zeichen lang sind?

Das ist zumindest für die Basics genauso wie unter Windows, nur dass du g++ statt cl schreibst und "-" statt "/".

PS Verwendest du tatsächlich keine Einrückungen?

EDIT: Allgemein, wenn du zwei Module a.cpp und b.cpp hast, machst du:

g++ -c a.cpp
g++ -c b.cpp
g++ -o <executable-name> a.o b.o

Wieso das nächste Mal? Mach's doch gleich! So schaut sich das bestimmt keiner an.

http://www.informatik-forum.at/showthread.php?t=18073

Ich hab die Frage eh nicht verstanden...

Bei welcher Anwendung muss man Tooltips "aktivieren"? Ist mir überhaupt noch nie untergekommen.

Was wäre dir denn sonst vorgeschwebt? Wenn sie nicht schnell genug sind, dann bleiben dir eh keine anderen Möglichkeiten, oder?