sizeof spinnt

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

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

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.

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.

Wenn du auf solchen Systemen arbeitest, dann mach es. Aber deswegen sind nicht alle Programme schlecht, wenn sie nicht "7bit Kompatibel" sind. Viele Anwendungen binden sich mit einer API an ein bestimmtes System und bekommen nie ein anderes System zu sehen, da ist es einfach total unwichtig, ob sie für so ein "7bit System" geeignet sind.

CStoll

Klar, wenn du genau weißt, für welches System du schreibst, kannst du dessen Eigenheiten berücksichtigen. Aber hier geht's immer noch um ANSI C++ - und da kannst du nicht davon ausgehen, daß ein char genau 8 Bit groß ist oder Bitshift's arithmetisch durchgeführt werden (der ANSI Standard definiert lediglich Mindestgrößen für die Datentypen).

bwbg

... jetzt fühle ich mich, als hätte ich einen Kiesel der Berg runter rollen lassen.

groovemaster

Badestrand schrieb:

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 soll diese unsinnige Polemik? Anfänger werden sich wohl kaum mit Bitmanipulation beschäftigen. Warum sollten die überhaupt wissen, wie viel Bit ein Byte auf dem verwendeten System hat?

Badestrand schrieb:

Dass man da mit Eingrenzungen beengt wird, ist absolut hinderlich!

Tja, damit wirst du wohl leben müssen. Eingrenzungen gibt es in jeder Programmiersprache. C++ hat noch die wenigsten davon.

Badestrand schrieb:

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?

Wüsste nicht, dass das jemand behauptet hat. Die Diskussion ist eher in Richtung Bitmanipulation abgedriftet und den Unterschied, CHAR_BIT zu verwenden, statt einer blanken 8. Oder glaubst du, ich mache mir bei jeder Variablendeklaration Gedanken darüber, wie viel Bits der verwendete Typ benötigt? Das Beispiel des OP hat damit auch nichts zu tun, 777 wollte wohl eher die Länge des Arrays ermitteln, also die Anzahl der Elemente.

Badestrand schrieb:

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

Das Gefühl habe ich eher bei dir. Du scheinst zu glauben, die Grösse eines Typs ist eine Grundsatzfrage. Ist es aber nicht.

kopfschüttel schrieb:

Wenn du auf solchen Systemen arbeitest, dann mach es. Aber deswegen sind nicht alle Programme schlecht, wenn sie nicht "7bit Kompatibel" sind. Viele Anwendungen binden sich mit einer API an ein bestimmtes System und bekommen nie ein anderes System zu sehen, da ist es einfach total unwichtig, ob sie für so ein "7bit System" geeignet sind.

Schön, du hast genau das wiederholt, was ich bereits sagte.

groovemaster schrieb:

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.

Du bringst hier etwas durcheinander. Es geht nicht um Bitkompatibilität, sondern um Stabilität und Robustheit einer Anwendung. Wenn ich eine Anwendung für ein System problemlos übersetzen kann und mir während der Laufzeit alles um die Ohren fliegt, ist das schlecht. Wenn ich eine Anwendung für ein System erst gar nicht übersetzen kann, ist das eventuell ungewollt, verursacht mir aber weitaus weniger Bauchschmerzen, da sich die Problematik auf eine konzeptionelle Ebene verlagert.