| |
| |
|
| - page 1 - |
|
 | allô, irgendwie packe je es avec dem aiguille pas de C++(Dev C++).
Es venez ici qui Wert 0 raus, eigentlich voulais je 45 avons.
qui kennt sich là aus avec dem faute, den je avec dem aiguille gemacht habe?
mfg
peter
KompilierenMarqueSéparation |
|
| |
|
|
| |
| |
| - page 2 - |
|
| et encore une For-Boucle dans C++.
Hui, qui allez ab, 10x 10.000.000.
peux je à peine croyons, bestätige cela s'il te plaît la fois.
j'ai 180ms.
Sebastian kannste qui la fois Testen, pas cela qui Variable avec 10.000.000 faux durchlaufen wird.
mfg
peter
KompilierenMarqueSéparation |
|
| |
| |
| |
|
|
| long *pL = (long*)PVAR(ram#);
qui Befehl allez pas .
mfg
peter |
|
| |
| |
| |
|
|
 | | sûrement cela Du pas long pL = (long*)PVAR(ram#) meinst? Hab ne...aucune prf2cpp zur main... |
|
| |
| |
| |
|
|
| Hab ne...aucune prf2cpp zur main...
Wird mais Zeit, cela es chez dir standard wird cet Wunderwaffe ala C++ avec Profan2ccp.
mfg
peter |
|
| |
| |
| |
|
|
| long pL = (long*)PVAR(ram#)
Compilerfehler..
prends cet variante : char* pL = reinterpret_cast<char*>( adrr);
mfg
peter |
|
| |
| |
| |
|
|
Sebastian
König | Peter Bierbachh
long pL = (long*)PVAR(ram#)
Compilerfehler..
prends cet variante : char* pL = reinterpret_cast<char*>( adrr);
Ok, qui reinterpret_cast<>() ist dans qui acte qui sichere variante, là qui Bereichsvariablen im de Profan2Cpp erzeugten Code zunächst la fois ne...aucune Zeigertyp (mais im Grunde simple long) sommes. Manche Compiler rouspéter ensuite den alten C-Style Cast avec (long*) à.
Dein Code sieht richtig aus  . Bien sûr fonctionne cela ensuite très vite. Pour solche Sachen ist Inline-C++ allerdings garnicht notwendig, cela qui XProfan-Code oui aussi pour C++ traduit wird. tu peux zum Beispiel la fois ca ici testen:
KompilierenMarqueSéparation
si je qui Compiler-Optimierungen (avec dem TuneMake-Plug-dans [...]  ) deaktiviere, peux je keinen Geschwindigkeitsunterschied trop Deiner variante avec dem Inline-Code plus feststellen.
MfG
Sebastian |
|
| |
| |
| |
|
|
| Ok, qui reinterpret_cast<>() ist dans qui acte qui sichere variante,
peux du pour encore einmal une Ersatz reinstellen, den ensuite alle Compiler anerkennen?
mfg
peter |
|
| |
| |
| |
|
|
| ici sieht es anders aus.
incorporé im Programme comme C++ et ensuite avec Profan2cpp : 143ms Dev C++ et 135ms avec BCC55
comme normales Programme avec Profan2cpp erstellt : 670ms avec DEV c++ et 390ms avec BCC55
mfg
peter
KompilierenMarqueSéparationcls
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, qui reinterpret_cast<>() ist dans qui acte qui sichere variante,
peux du pour encore einmal une Ersatz reinstellen, den ensuite alle Compiler anerkennen?
qui reinterpret_cast<>() sollte eigentlich de allen Compilern erkannt volonté - il est partie des Standard-C++ Sprachumfangs.... quoi oui c'est ca funktioniert car pas? Generell gilt, dass on sich chez Inline-C++ entier simple à cela tenir muss, quoi qui verwendete Compiler soutenu. je peux seulement beim Übersetzen des XProfan-Codes sicherstellen, dass cela Ergebnis avec allen unterstützten Compilern fonctionne.
Peter Bierbach
ici sieht es anders aus.
incorporé im Programme comme C++ et ensuite avec Profan2cpp : 143ms Dev C++ et 135ms avec BCC55
comme normales Programme avec Profan2cpp erstellt : 670ms avec DEV c++ et 390ms avec BCC55
Ok, ensuite venez es wohl aussi sur den Einzelfall à. Inline-C++ ist naturellement pratique pour très geschwindigkeitskritische Dinge - ähnlich comment Inline-ASM dans C++. Letzteres ginge incidemment aussi dedans des INLINE_CPP-Blocks, mais je travaille zur Zeit aussi à einer direkten Unterstützung de Franks XPIA dans Profan2Cpp .
MfG
Sebastian |
|
| |
| |
| |
|
| |
| |
| - page 3 - |
|
|
| Funktioniert maintenant alles Prima... 
mfg
peter |
|
| |
| |
| |
|
|
Sebastian
König | Peter Bierbachh
Funktioniert maintenant alles Prima...
Super, cela freut mich naturellement! |
|
| |
| |
| |
|
|
| Beide Compiler Dev C++ jusqu'à 4.9.8 et den BCC55 habe je im Test gehabt.
maintenant hat qui BCC55 toujours qui nez vorn gehabt. chez qui Bereichsvariablenüberprüfung/comparaison jusque 3x plus rapide. on soll sich sur den Schleifentest(Whileloop usw) pas sortir de. là était nämlich toujours qui DEv C++ plus rapide, si es mais ins Eingemachte ging était qui BCC55 qui schnellere.
Habe alle mon kritischen Grafikprogramme avec Opengl usw, qui ici im Forum zur Diskussion étions/sommes , correct übersetzten peut.
une erstaunliche Leistung aussi den direkten C++-Code einzusetzen était/est un riesengrosser Erfolg (après que je es verstanden hatte).
Profan2cpp ist unschlagbar. Zumal es qui sous anderem guten einfachen C++-Compiler (Dev C++ et BCC55) correct einsetzen peux.
si ensuite encore qui ASM-Routinen avec XPIA/XPSE là reinkommen,...
Pour mon ASM-Routinen habe je mir une Brücke gebaut.
je nutze qui erstellte DLL de XPIA/XPSE avec dem Def-Aufruf, ne...aucune wesentlicher Aufwand cet reinzusetzen.
mfg
peter |
|
| |
| |
| |
|
(1.174)
Deutsch
English
Français
Español
Italia