Frage zu Bitoperation

Shoo

sorry, das ich mit der antwort noch nicht ganz was anfangen kann ... mir sagt "oktale numerale" grad nix .. wie würde sich das in diesem speziellen beipsiel denn auswirken ?

volkard

Shoo schrieb:

sorry, das ich mit der antwort noch nicht ganz was anfangen kann ... mir sagt "oktale numerale" grad nix .. wie würde sich das in diesem speziellen beipsiel denn auswirken ?

http://de.wikipedia.org/wiki/Oktalsystem
printf("%d",020)
zeigt also 16 an.
wegen der 0 am anfang liest der c-compiler das ding oktal.

zusatzübung:
warum geht int i=4711 gut aber int j=0815 nicht?

Shoo

besten dank, habs verstanden

... 0815 geht nicht, weil das zahlensystem nur von 0..7 geht ^^

thx

jule37

hm also kann man die 0 einer ziffer vorangestellt als eine art "tag" betrachten, welche dem compiler sagt -> jetzt folgt eine okt-zahl...?

gibt es dann auch "tags", mit welchen man hex- oder binärzahlen beschreibt?

das würde mich echt interessieren.

mfg & danke

volkard

das hex-tag ist 0x
int x=0xff
es gibt leider kein binärtag.

codefrag

Habe sowas noch nie gebraucht:

Die Syntax "(021 & 020)" bedeutet ? -> damit meine ich die "( & )"

google "bitwise operators"

codefrag

TactX schrieb:

google "bitwise operators"

Alles klar danke

hab zwar kurz gegoogelt find aba nur die funktionsweisen, nicht das warum der bitoperatoren.

Kann die hier jmd ganz kurz erklären?

Wo sind die Anwendungen? bzw Vorteile?

thx

c.rackwitz

es gibt keine vorteile, weil es keine alternativen gibt.

das warum: der computer arbeitet so.

die anwendungen: datenmanipulation auf bitebene.

jox

user89 schrieb:

hab zwar kurz gegoogelt find aba nur die funktionsweisen, nicht das warum der bitoperatoren.
Kann die hier jmd ganz kurz erklären?
Wo sind die Anwendungen? bzw Vorteile?

... das braucht der "richtige" C-Programmierer andauernd, z.B. bei allen möglichen Systemcalls. Als Beispiel sei hier nur aufgeführt open(2):

fd = open("myOutFileName", O_CREAT | O_EXCL);

hier wird die Funktion open() über einen Parameter gesteuert, bei dem die beiden Flag-Bits O_CREAT und O_EXCL gesetzt sind.

Auch zur Speicherung eigener Bits für Statuswerte o.Ä. ist das ein ganz übliches Verfahren. Auf diese Weise kann man mehrere unterschiedliche Zustände in einer Zustandsvariablen abspeichern (d.h. setzen, löschen, prüfen). I.d.R. nimmt man als Konstanten allerdings hexadezimale Werte (die alten Unix-Systemquellen nehmen da aus der Historie bedingt häufig Octal-Werte), die man zweckmäßigerweise in einer Include-Datei definiert, so sind z.B. O_CREAT und O_EXCL in der Datei fcntl.h definiert.
Auch beim Debuggen ist es hilfreich, wenn man Zustandswerte in kompakter Form leicht abfragen, interpretieren und ggf. umsetzen kann.

Im Prinzip kommen die ganzen Bit-Operationen aber vermutlich aus der Historie von C, da mit Hilfe von C auch HW-Komponenten gesteuert werden sollten (und werden). So findet man diese Bit-Flags auch bei allen möglichen HW-Controllern wieder. Um solche Komponenten anzusteuern bzw. abzufragen, waren die entsprechenden Befehle notwendig (sonst hätte man hier Assembler-Code einbauen müssen).

c.rackwitz

mit hardware hats weniger zu tun.
ganz einfach: jeder prozessor (ausser vielleicht witzprozessoren) kann bitweises AND, OR, XOR und NOT, sowie bitshifting und rotationen. diese sind die grundfunktionen auf das bit und somit auch auf das byte.

jox

c.rackwitz schrieb:

mit hardware hats weniger zu tun.
ganz einfach: jeder prozessor (ausser vielleicht witzprozessoren) kann bitweises AND, OR, XOR und NOT, sowie bitshifting und rotationen. diese sind die grundfunktionen auf das bit und somit auch auf das byte.

... das ist zwar wiederum richtig, die unterschiedlichen Prozessoren haben aber mit der Thematik ANSI-C::Bit-Operationen relativ wenig zu tun. Es ging hier, wenn ich mich nicht irre, um das Thema, warum C Bit-Operationen unterstützt, was ja bekanntermaßen nicht alle Hochsprachen tun. Versuch mal, mit einer dieser anderen Hochsprachen (aus der Entstehungszeit von C), einzelne Flags aus einem HW-Statusregister auszulesen. C diente dazu, das Betriebssystem UNIX relativ Prozessor-unabhängig, d.h. mit möglichst wenig direktem Assemblercode, zu entwickeln (... das weißt Du, das weiß ich ...) und Treiber für diverse HW-Komponenten vorzusehen. Das ist aber u.A. einer der Gründe, warum genau C diese Operationen vorgesehen hat.

Nur das habe ich versucht, zu erklären ...