sizeof spinnt
-
hmm, aber um vernünftig zu programmieren, muss doch jeder vompiler 1 Byte mit 8 bit interpretieren!!
-
warum? oder anders: solange du nicht allzuviel mit bit-shifting spielst, interessiert es dich nicht wirklich, wie groß ein byte auf deiner platform ist, sondern nur wie groß die datentypen sind. da der c und c++ standard aber untergrenzen vorschreiben, kann man sich einfach an die halten und man auch damit keinen streß.
-
ok gut, noch was ! kann ich einen Wert erzeugen welche eine variable anzahl von bits hat!
-
Was meinst du mit "variable Anzahl"? (du könntest einen vector<bool> oder bitset<> verwenden)
-
Gibt übrigens das Makro CHAR_BIT in welchem die Anzahl der Bits pro Byte steht.
-
Ja das ist richtig.
Irgendwo auch logisch
Ich meinte aber, dass es Compiler gibt, die int als 16 Bit-Variable interpretieren.
Andere als 32-Bit Variable?Gibts doch überall Unterschiede...-.-
Zudem muss es doch eine einfache Funktion geben, welche einfach die Objektanzahl eines Arrays zurückliefert.
x.x.cya
David
-
777 schrieb:
Zudem muss es doch eine einfache Funktion geben, welche einfach die Objektanzahl eines Arrays zurückliefert.
Keine Funktion, aber eine triviale Berechnung, die schon zweimal genannt wurde. Gefällt Dir die nicht gut genug?
sizeof(array)/sizeof(*array)oder
sizeof(array)/sizeof(array[0])Oder bau Dir n Template
template< class T, size_t N > inline size_t array_length( T ( &ary )[ N ] ) { return N; }
-
kann der compiler frei definieren
Glaub nicht das das der compiler entscheiden kann

Sondern eher das das vom prozessor kommt ... und ja, es gab prozessoren wo 1 byte = 7 bit.waer doof wenn der Prozessor meint, eine Speicherzelle hat 8 Bit, und der compiler mag nur 7 davon benutzen

dann duerfte der compiler keinerlei erweiterte prozessorbefehle wie multiplikation / division / addition / subtraktion auf registerbasis benutzen wenn ein register mehrere bytes gross ist, weil die operationen ja auf auf ner anderen basis beruhen

Prinzipiell waer sowas vielleicht moeglich, aber praktisch eher unmöglich, rein schon von der performance her ....
<klugscheissmode off>
Ciao ...
-
Das 1 Byte != 8 Bit sein kann ist sowas von egal, ihr wollt nur immer mit eurem wissen angeben. Falls wirklich einer an nem Rechner sitzt, wo das nicht so ist, dann weiß er das. Den Rest verunsichert ihr doch nur.

-
777 schrieb:
Zudem muss es doch eine einfache Funktion geben, welche einfach die Objektanzahl eines Arrays zurückliefert.
x.x.cya
DavidGibts aber nicht. Darum sollst du ja std::vector<> benutzen.
-
kopfschüttel schrieb:
Falls wirklich einer an nem Rechner sitzt, wo das nicht so ist, dann weiß er das.
Toll, und darf etliche Zeit damit verbringen, das Programm anzupassen. Anstatt es einfach durch den entsprechenden Compiler zu jagen und fertig. Was du erzählst, ist Unsinn. Der Standard legt halt einfach nicht fest, dass ein Byte aus exakt 8 Bits besteht. Ende der Geschichte. Wenn du mal ernsthaft programmierst, wirst du lernen, dass dies nur auf zuverlässiger Basis Sinn macht.
-
groovemaster schrieb:
kopfschüttel schrieb:
Falls wirklich einer an nem Rechner sitzt, wo das nicht so ist, dann weiß er das.
Toll, und darf etliche Zeit damit verbringen, das Programm anzupassen. Anstatt es einfach durch den entsprechenden Compiler zu jagen und fertig. Was du erzählst, ist Unsinn.
Na toll, es ist ja nicht genug Arbeit, alle Programme plattformunabhängig zu schreiben, jetzt muss man auch noch mit variabler Bitzahl pro Byte rechnen. Tschuldige, aber das ist auch Unsinn. Meist programmiert man eh nur für ein System (z.B. Standard-Desktop-Windows oder -Linux), wenn's hart auf hart kommt, auch mal für Win, Linux und Mac gleichzeitig. Aber dann noch mit einer variablen Bitzahl zu rechnen, sprengt doch schlicht und ergreifend den Rahmen!
-
Blödsinn. Portabel für unterschiedliche Systeme zu entwickeln, ist teilweise wirklich aufwändig. Das stimmt. Aber CHAR_BIT zu verwenden, anstatt von fixen 8 Bits auszugehen, ist kein Aufwand. Absolut keiner. Und ich habe mittlerweile schon genug Bits malträtiert, um das beurteilen zu können.
IdR kommt man damit sowieso kaum in Berührung, da viele Algos auf feste Bitgrossen setzen. Und dann verwendet man statt ungenauer Typen sowieso eher etwas wie int32.
-
Hm, dann muss ich einfach mal drauf achten

Gut, es ist irgendwie doch kein Problem..
Ich bin aber nach wie vor der Meinung, dass man soetwas einem Anfänger nicht zumuten sollte. Ich persönlich lege mir übrigens in naher Zukunft ein System zu, dessen Byte genau 2 Bits groß ist; tja und damit bist du wohl gezwungen, deine Programme auch kompatibel zu meinem System zu schreiben :p
-
Der prozessor gibt nicht direkt die byte größe an. sonder die word größe, der rest is compiler sache, im c++ std sind der typ ,char, byte (int8) -- gr0ße überaschung immer 8bit groß, also wenn du nen char in den register legst "verschwendest" du bei nem 32bit system 24bit (is aber net so schlimm wie man denkt :))
aber fals mal wer ein betriebsystem proggen will kann einfach
#define MAX_INT ~0machen dann weis man wieviel platz man hat
mfg spjoe
-
groovemaster schrieb:
kopfschüttel schrieb:
Falls wirklich einer an nem Rechner sitzt, wo das nicht so ist, dann weiß er das.
Toll, und darf etliche Zeit damit verbringen, das Programm anzupassen. Anstatt es einfach durch den entsprechenden Compiler zu jagen und fertig. Was du erzählst, ist Unsinn. Der Standard legt halt einfach nicht fest, dass ein Byte aus exakt 8 Bits besteht. Ende der Geschichte. Wenn du mal ernsthaft programmierst, wirst du lernen, dass dies nur auf zuverlässiger Basis Sinn macht.
Ja genau
Es programmiert ja jeder täglich auf irgendwelchen exotischen Systemen, dass da jeder Anfänger darauf achten muss.
-
mal kurz zurück zur Objektanzahl in einem "normalen" Array:
kommt man eigentlich irgendwie an die infos, die 'delete[]' benutzt um das Array wieder zu löschen ...
irgendwie muss delete[] ja wissen wie groß dass Array ist ...
-
wandrer schrieb:
kommt man eigentlich irgendwie an die infos, die 'delete[]' benutzt um das Array wieder zu löschen ...
nein. nicht in standard c++.
irgendwie muss delete[] ja wissen wie groß dass Array ist ...
tja.
-
groovemaster schrieb:
Blödsinn. Portabel für unterschiedliche Systeme zu entwickeln, ist teilweise wirklich aufwändig. Das stimmt. Aber CHAR_BIT zu verwenden, anstatt von fixen 8 Bits auszugehen, ist kein Aufwand. Absolut keiner. Und ich habe mittlerweile schon genug Bits malträtiert, um das beurteilen zu können.
IdR kommt man damit sowieso kaum in Berührung, da viele Algos auf feste Bitgrossen setzen. Und dann verwendet man statt ungenauer Typen sowieso eher etwas wie int32.Aha. Und du glaubst dass es einen 32 Bit Typ auf einer Maschine mit 7 bittigen Bytes gibt?
Viel Spass beim Suchen!
-
kopfschüttel schrieb:
Ja genau
Es programmiert ja jeder täglich auf irgendwelchen exotischen Systemen, dass da jeder Anfänger darauf achten muss.Es ist wichtig, daß man sich von Anfang an daran gewöhnt, daß die C bzw. C++ Norm bestimmte Rahmenbedinungen zusichert. Man darf sich nicht darauf verlassen, daß bestimmte Eigenschaften der Computerplattform, auf welcher man das Programm entwickelt hat, auch von anderen Plattformen erfüllt wird. Leider sieht man immer wieder, daß diese fundamentale Erkenntnis nicht beachtet wird. Das fängt bei so banalen Dinge wie "int" statt "size_t" für das Interieren über Feldern an, und hört auch nicht beim Ignorieren von EBCDIC Plattformen auf.
Wenn man in den Anforderungskatalog hineinschreibt, daß das Programm nur auf UNIX (siehe Single UNIX Spec) und Windows laufen soll, dann braucht man sich um Byte != 8Bit und viele andere Dinge nicht zu kümmern. Aber dann soll man nicht behaupten es handele sich um ein reines C bzw. C++ Programm, dem ist nicht so.