sizeof spinnt

[lolz]

Gibt übrigens das Makro CHAR_BIT in welchem die Anzahl der Bits pro Byte steht.

[777]

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

[LordJaxom]

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; }

[RHBaum]

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 ...

[kopfschüttel]

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.

[Tanren]

777 schrieb:

Zudem muss es doch eine einfache Funktion geben, welche einfach die Objektanzahl eines Arrays zurückliefert.
x.x.

cya
David

Gibts aber nicht. Darum sollst du ja std::vector<> benutzen.

[groovemaster]

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.

[Badestrand]

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!

[groovemaster]

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.

[Badestrand]

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

[spjoe_logoff]

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 ~0

machen dann weis man wieviel platz man hat

mfg spjoe

[kopfschüttel]

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.

[wandrer]

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 ...

[queer_boy]

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.

[hustbaer]

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!

[*john 0]

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.

[groovemaster]

hustbaer schrieb:

Aha. Und du glaubst dass es einen 32 Bit Typ auf einer Maschine mit 7 bittigen Bytes gibt?

Zur Not emuliert, ja. Oder was glaubst du, wie C Compiler long long auf x86-32 Systemen realisieren? Aber darum geht es nicht. Wenn Algos fixe Typgrössen verwenden, gibt es auch keine Probleme mit fixen Bitbreiten. Ende der Geschichte. Über mehr zu diskutieren, ist verschwendete Zeit. Dass dadurch letztendlich auch nur eingeschränkte Portabilität möglich ist, sollte klar sein.

kopfschüttel schrieb:

Ja genau Es programmiert ja jeder täglich auf irgendwelchen exotischen Systemen, dass da jeder Anfänger darauf achten muss.

Sry, aber du hast die Thematik einfach nicht verstanden. Oder willst nur weiter trollen. Nur weil Compiler idR signed Werte arithmetisch shiften, setze ich sowas trotzdem nicht voraus. Das ist keine Basis für seriöse Softwareentwicklung. Wenn du mal in Bereichen tätig bist, wo jeder noch so kleine Fehler fatale Folgen haben kann, zB in der Automatisierungstechnik, wirst du anders darüber denken. Ich würde dir empfehlen, zum Thema entsprechende Lektüre durchzuarbeiten.

[Badestrand]

Wundert mich langsam nicht mehr, wenn viele Anfänger von Java so begeistert sind, da scheint man solche Probleme ja nicht zu haben Wenn ich davon gehört hätte, dass man sich noch nicht einmal auf eine 8-Bit-Größe als Byte verlassen kann, hätte ich wahrscheinlich gar nicht mit C++ angefangen. Gut, nun weiß ich es und ich weiß auch, dass es mich einen Scheißdreck tangiert. Ich werds im Hinterstübchen behalten und wenn, nein, falls ich es mal brauchen werde, werde ich mich daran erinnern oder es erfahren.
Mir geht es hierbei nur darum, dass die Anfänger meist krampfhaft überfordert werden. Sie sollen plattform-unabhängigen Code schreiben, keine komplexen Objekte per return zurückgeben, sich nicht darauf verlassen dürfen, dass ein Byte 8 Bit hat, sie dürfen nicht "void main" schreiben obwohl's der Compiler zulässt, sie dürfen keine Threads benutzen weils gefährlich ist, sie dürfen keinen Keyboard-Hook benutzen weil's scheiß Viren-Kiddis sind, sie müssen den Standard im Schlaf vorsingen können sie müssen sie müssen sie dürfen nicht sie dürfen nicht.
Was meinst du eigentlich, warum man Grundschülern nicht die komplexen Zahlen in den Schädel klopft? Weil es schlichtweg überfordert!
Ein Programmieranfänger muss, und das ist das Wichtigste, das Konzept des Programmierens lernen. Dass man da mit Eingrenzungen beengt wird, ist absolut hinderlich! Wenn man bedenkt, dass ein Großteil abspringt oder zu einer anderen Programmiersprache wechselt wo einige dieser Themen einfach keine Relevanz mehr haben, reicht es meiner Meinung nach vollkommen, mal mehr oder weniger oft zu erwähnen, dass es solche Probleme gibt und wie sie zu lösen sind. Wenn man aber dabei ist, ein Hello-World-Programm zu verstehen, warum zur Hölle sollte man beachten, dass ein Byte nicht unbedingt bis 255 zählen kann?
Im Laufe der Jahre wird jeder etliche Fehler begehen und verdammt viele Dinge lernen; sei es die Bedienung der STL, die Tücken der Threadsicherheit oder die Kunst der plattformunabhängigen Programmierung, eines ist für mich aber sicher: Kein Anfänger braucht mit solchen bescheuerten Winzigkeiten geplagt zu werden, es gibt hunderte wichtigere Sachen zu lernen.
~Threadsicherheit nehmen wir bei "Winzigkeiten" aber lieber erstmal mit raus ~

Ich habe mit Sicherheit weniger Programmiererfahrung als du, groovemaster, aber ich denke du verrennst dich da in etwas.

[Tyrdal]

Der Unterschied ist halt, daß C++ auf verschiedenen Plattformen laufen soll während Java auf genau eine definierte beschränkt ist (die JVM). Natürlich ist ersteres komplizierter.

Un nein groovemaster verrennt sich nicht. Ich hab schon öfter Fälle gesehen wo sich deine Denkweise gerächt hat.

[camper]

Man kann mit Portabilität argumentieren, aber eigentlich geht es doch darum, magische Konstanten zu vermeiden. Selbst wenn jedes System dieser Welt mit dem gleichen Wert arbeiten würde, wäre CHAR_BIT gegenüber einer blanken 8 vorzuziehen. Gerade Bitschieberei tut oft nicht ganz offensichtliche Dinge; umso wichtiger ist es, explizit zu sein, wenn der Code verständlich bleiben soll.