| |
|
|
- Seite 1 - |
|
| Hallo, irgendwie packe ich es mit dem Zeiger nicht von C++(Dev C++). Es kommt hier der Wert 0 raus, eigentlich wollte ich 45 haben.
Wer kennt sich da aus mit dem Fehler, den ich mit dem Zeiger gemacht habe?
mfg peter KompilierenMarkierenSeparieren |
|
|
| |
|
|
|
| |
|
- Seite 2 - |
|
| Und noch eine For-Schleife in C++. Hui, die geht ab, 10x 10.000.000.
Kann ich kaum glauben, bestätige das bitte mal. Ich habe 180ms. Sebastian kannste die mal Testen, nicht das die Variable mit 10.000.000 falsch durchlaufen wird.
mfg peter KompilierenMarkierenSeparieren |
|
|
| |
|
|
|
| long *pL = (long*)PVAR(ram#);
Der Befehl geht nicht .
mfg peter |
|
|
| |
|
|
|
| Sicher das Du nicht long pL = (long*)PVAR(ram#) meinst? Hab kein prf2cpp zur Hand... |
|
|
| |
|
|
|
| Hab kein prf2cpp zur Hand...
Wird aber Zeit, das es bei dir standard wird diese Wunderwaffe ala C++ mit Profan2ccp.
mfg peter |
|
|
| |
|
|
|
| long pL = (long*)PVAR(ram#)
Compilerfehler..
Nimm diese Variante : char* pL = reinterpret_cast<char*>( adrr);
mfg peter |
|
|
| |
|
|
|
Sebastian König | Peter Bierbachh
long pL = (long*)PVAR(ram#)
Compilerfehler..
Nimm diese Variante : char* pL = reinterpret_cast<char*>( adrr);
Ok, der reinterpret_cast<>() ist in der Tat die sichere Variante, da die Bereichsvariablen im von Profan2Cpp erzeugten Code zunächst mal kein Zeigertyp (sondern im Grunde einfach long) sind. Manche Compiler meckern dann den alten C-Style Cast mit (long*) an.
Dein Code sieht richtig aus . Natürlich läuft das dann sehr schnell. Für solche Sachen ist Inline-C++ allerdings garnicht notwendig, das der XProfan-Code ja auch nach C++ übersetzt wird. Du kannst zum Beispiel mal dies hier testen: KompilierenMarkierenSeparieren Wenn ich die Compiler-Optimierungen (mit dem TuneMake-Plug-In [...] ) deaktiviere, kann ich keinen Geschwindigkeitsunterschied zu Deiner Variante mit dem Inline-Code mehr feststellen.
MfG
Sebastian |
|
|
| |
|
|
|
| Ok, der reinterpret_cast<>() ist in der Tat die sichere Variante,
Kannst du dafür noch einmal einen Ersatz reinstellen, den dann alle Compiler anerkennen?
mfg peter |
|
|
| |
|
|
|
| Hier sieht es anders aus. Eingebaut im Programm als C++ und dann mit Profan2cpp : 143ms Dev C++ und 135ms mit BCC55 Als normales Programm mit Profan2cpp erstellt : 670ms mit DEV c++ und 390ms mit BCC55
mfg peter KompilierenMarkierenSeparierencls
declare bildxy#,laenge%,test%,z%
dim bildxy#,65000
laenge%=65000
test%=&GetTickCount
whileloop 1,100,1
z%=rgb_farbe_cpp(bildxy#,laenge%)
endwhile
Print Str$(Int(&GetTickCount-test%))
WaitInput
end
proc rgb_farbe_cpp
parameters bildxy#,laenge%
declare r%,g%,b%
whileloop 0,laenge%-1,4
b%=byte(bildxy#,&loop)
g%=byte(bildxy#,&loop+1)
r%=byte(bildxy#,&loop+2)
if (b%>252) | (g%>252) | (r%>252)
z%=255
break
endif
endwhile
ENDPROC
|
|
|
| |
|
|
|
Sebastian König | Peter Bierbachh
Ok, der reinterpret_cast<>() ist in der Tat die sichere Variante,
Kannst du dafür noch einmal einen Ersatz reinstellen, den dann alle Compiler anerkennen?
Der reinterpret_cast<>() sollte eigentlich von allen Compilern erkannt werden - er ist Teil des Standard-C++ Sprachumfangs.... Was genau funktioniert denn nicht? Generell gilt, dass man sich bei Inline-C++ ganz einfach an das halten muss, was der verwendete Compiler unterstützt. Ich kann nur beim Übersetzen des XProfan-Codes sicherstellen, dass das Ergebnis mit allen unterstützten Compilern läuft.
Peter Bierbach
Hier sieht es anders aus. Eingebaut im Programm als C++ und dann mit Profan2cpp : 143ms Dev C++ und 135ms mit BCC55 Als normales Programm mit Profan2cpp erstellt : 670ms mit DEV c++ und 390ms mit BCC55
Ok, dann kommt es wohl auch auf den Einzelfall an. Inline-C++ ist natürlich praktisch für sehr geschwindigkeitskritische Dinge - ähnlich wie Inline-ASM in C++. Letzteres ginge übrigens auch innerhalb des INLINE_CPP-Blocks, aber ich arbeite zur Zeit auch an einer direkten Unterstützung von Franks XPIA in Profan2Cpp .
MfG
Sebastian |
|
|
| |
|
|
| |
|
- Seite 3 - |
|
|
| Funktioniert jetzt alles Prima...
mfg peter |
|
|
| |
|
|
|
Sebastian König | Peter Bierbachh
Funktioniert jetzt alles Prima...
Super, das freut mich natürlich! |
|
|
| |
|
|
|
| Beide Compiler Dev C++ bis 4.9.8 und den BCC55 habe ich im Test gehabt. Jetzt hat der BCC55 immer die Nase vorn gehabt. Bei der Bereichsvariablenüberprüfung/Vergleich bis zu 3x schneller. Man soll sich auf den Schleifentest(Whileloop usw) nicht verlassen. Da war nämlich immer der DEv C++ schneller, wenn es aber ins Eingemachte ging war der BCC55 der schnellere.
Habe alle meine kritischen Grafikprogramme mit Opengl usw, die hier im Forum zur Diskussion waren/sind , fehlerfrei übersetzten können. Eine erstaunliche Leistung auch den direkten C++-Code einzusetzen war/ist ein riesengrosser Erfolg (nachdem ich es verstanden hatte).
Profan2cpp ist unschlagbar. Zumal es die unter anderem guten einfachen C++-Compiler (Dev C++ und BCC55) fehlerfrei einsetzen kann. Wenn dann noch die ASM-Routinen mit XPIA/XPSE da reinkommen,...
Für meine ASM-Routinen habe ich mir eine Brücke gebaut. Ich nutze die erstellte DLL von XPIA/XPSE mit dem Def-Aufruf, kein wesentlicher Aufwand diese reinzusetzen.
mfg peter |
|
|
| |
|
|