| |
|
|
- 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 - |
|
|
 Jörg Sellmeyer | Mach la fois imprimer ram# Peut-être cela oui déjà qui gesuchte aiguille. |
|
|
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ...  | 13.09.2008 ▲ |
|
|
|
|
 Sebastian König | j'ai es maintenant pas getestet, mais
long *pL = (long*)PVAR(ram#);
sollte eigentlich marcher...
Nachtrag: Jörgs Hinweis allez dans qui gleiche direction, vois je justement  |
|
|
| |
|
|
|
 | merci euch, maintenant ca va. Imprimer ram#, là venez qui aiguille direct , sans dem Befehl : addr.
c'est qui C++-Befehl : char* p = reinterpret_cast<char*>(adrr);
Zum Test habe je qui Adresse 44 et 45 ausgegeben. Es wird qui richtige Wert de qui Adresse 44 et 45 ausgegeben. Beide aiguille attraper chez "0" à.
Puhhh......
mfg peter KompilierenMarqueSéparation |
|
|
| |
|
|
|
 | 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 |
|
|
| |
|
|