Unterschied von VOID,void/BOOL, bool/INT int ?
-
Idee: Um sicherzustellen, dass die vielen Compiler dieses Planeten sich über Datentypen in Quellcodes einig sind, weil für den einen eben "long" 32 bit hat und für den anderen 64. Da macht dann im ersten Fall einfach "typedef long LONG" und im zweiten "typedef int LONG". Da brauch man dann nix zu ändern im Quellcode. Wär meine Idee, kennt jemand andere Gründe?
-
aber VOID finde ich irgendwie lächerlich. das wird sich ja wohl nie ändern
-
soweit ich weiß hat ein bool 1byte speicherverbrauch und ein BOOL 4, je nach umgebung kann das eine oder andere besser sein, das ist meines wissens nach auch der einzige unterschied und auch grund für BOOL. weshalb gerade 4byte? weil das für die cpu optimal ist, einzelne bytes zu lesen ist nicht so gut, weil die erstmal maskiert werden, dafür sind sie kompackter und bringen also auch was.
rapso->greets();
-
rapso: Der Grund dürfte schlicht und einfach sein, dass die 'Erfindung' von BOOL auf Mitte der 80er datiert, und bool erst in den 90ern zu C++ hinzugefügt wurde.
-
Bashar schrieb:
rapso: Der Grund dürfte schlicht und einfach sein, dass die 'Erfindung' von BOOL auf Mitte der 80er datiert, und bool erst in den 90ern zu C++ hinzugefügt wurde.
in dem falle würde niemanden ein typedef bool BOOL stören... aber wie gesagt, BOOL ist optimal für die cpu und bool ist sparsammer.
rapso->greets();
-
rapso schrieb:
weil das für die cpu optimal ist, einzelne bytes zu lesen ist nicht so gut, weil die erstmal maskiert werden, dafür sind sie kompackter und bringen also auch was.
Also benötigt ein mov al,bla mehr Zeit als mox ax, bla?
-
mov al,bla _kann_ mehr zeit benötigen als mov eax,bla.
das war ja das hauptproblem von pentium pro, heutige cpus sind ja auch eher auf 32bit ausgelegt und falls sie mit 16bit/8bit befehlen mal schneller sind, dann liegt das nur an der kleineren datenmenge die vom ram geschaufelt wird. ich bezweifle dass man zwischen bool und BOOL wirklich einen performanceunterschied mißt, aber die cpus müssen nunmal 32bit auslesen und dann die 8bit ausmaskieren und in ein register einmaskieren. das passiert transparent und könnte heutzutage keinen performancehit bringen.mir ist sowat ja auch egal, ich nutze wohl immer bool, aber der angebliche performancegewinn war die erklärung die ich mal irgendwo las. (war von einer kompetenten quelle, sonst hätte ich mir das nicht gemerkt
)rapso->greets();
-
Es gab eine ähnliuche Diskusion im Scherfgen Forum zwar nur speziell über BOOL und bool aber es endete mit einer E-Mail an AMD und folgender Antwort.
Generell laesst sich Ihre Frage kaum beantworten, da es sehr spezifisch auf den Programmcode ankommt. Wenn z.B. 8 bit Programmcode entsprechend optimiert ist (Abarbeitung mehrerer 8 bit Befehle parallel), laeuft er natuerlich auf einem 32 bit Prozessor schneller als auf einem 8 bit Prozessor. Es kann aber auch dazu kommen, dass der Prozessor aufgrund des Programmcodes immer wieder Taktzyklen hat, in denen kein Programmcode abgearbeitet werden kann, da z.B. auf den Speicher gewartet werden muss. In diesem Fall haetten Sie von der Verwendung eines 32 bit Prozessors praktisch keinen Vorteil. Auf jeden Fall muessen Sie bedenken, dass neben dem Prozessor noch andere Faktoren, wie Speicheranbindung, Programmcodegestaltung,... eine Rolle spielen. Schon aus diesem Grund laesst sich eine generelle Antwort im Prinzip nicht geben.
Es ist ein wenig nichtssagend
. Es kann also beides schneller sein. Eine E-Mail an Microsoft mit der Frage wie der Compiler optimiert wird sicherlich auch nicht eindeutig beantwortet werden können. Also wird es immer heißen ausprobieren oder einfach nur dran glauben das man das richtige tut.
-
Tobiking schrieb:
Es gab eine ähnliuche Diskusion im Scherfgen Forum zwar nur speziell über BOOL und bool aber es endete mit einer E-Mail an AMD und folgender Antwort.
Generell laesst sich Ihre Frage kaum beantworten, da es sehr spezifisch auf den Programmcode ankommt. Wenn z.B. 8 bit Programmcode entsprechend optimiert ist (Abarbeitung mehrerer 8 bit Befehle parallel), laeuft er natuerlich auf einem 32 bit Prozessor schneller als auf einem 8 bit Prozessor. Es kann aber auch dazu kommen, dass der Prozessor aufgrund des Programmcodes immer wieder Taktzyklen hat, in denen kein Programmcode abgearbeitet werden kann, da z.B. auf den Speicher gewartet werden muss. In diesem Fall haetten Sie von der Verwendung eines 32 bit Prozessors praktisch keinen Vorteil. Auf jeden Fall muessen Sie bedenken, dass neben dem Prozessor noch andere Faktoren, wie Speicheranbindung, Programmcodegestaltung,... eine Rolle spielen. Schon aus diesem Grund laesst sich eine generelle Antwort im Prinzip nicht geben.
Es ist ein wenig nichtssagend
. Es kann also beides schneller sein. Eine E-Mail an Microsoft mit der Frage wie der Compiler optimiert wird sicherlich auch nicht eindeutig beantwortet werden können. Also wird es immer heißen ausprobieren oder einfach nur dran glauben das man das richtige tut.klingt wie das geblubber was ich gesagt habe und wenn du wissen möchtest wie der compiler das macht kannst du dir im devstudio das disassemblat anzeigen lassen.
rapso->greets();
-
rapso schrieb:
in dem falle würde niemanden ein typedef bool BOOL stören... aber wie gesagt, BOOL ist optimal für die cpu und bool ist sparsammer.
Ich denke eher, dass typedef bool BOOL nicht gemacht wurde aus dem einfachen Grund, dass sizeof(BOOL) ungleich sizeof(bool) ist und es deshalb Probleme mit altem Code geben kann.
