Guten Morgen, ich habe eine kleine Frage, habe hier über die Suchfunktion noch keine direkte Antwort finden können aber vielleicht könnt ihr mir was dazu sagen, wäre echt super. Ich habe einen Zähler implementiert, der mir einfach eine unsigned char Variable bei jedem Aufruf hochzählt, nichts aufregendes. Jedoch erreicht diese auch ihren Maximalwert 255. Muss ich die aktiv zurücksetzen oder kann ich einen Overflow zulassen? Sauberer wäre sicher das Zurücksetzen oder was sagt ihr? Gruß Manuel ...Ich Danke Euch!
Manuel schrieb: > Muss ich die aktiv zurücksetzen oder > kann ich einen Overflow zulassen? > Sauberer wäre sicher das Zurücksetzen oder was sagt ihr? Sauberer wäre vermutlich die Verwendung einer für den zu erwartenden Wertebereich ausreichend dimensionierten Variablen.
Lässt sich so pauschal nicht sagen. Was machst du denn mit dieser Zählervariable? Darf sie.bei 0xff stehen bleiben, wird siesporadisch rückgeaetzt um timeouts zu implememtieren oder...? Dem Compiler, der MCU ist der mögliche Overflow jedenfalls egal.
Char ist denkbar ungeeignet, da eine char Variable ein Zeichen enthält. Das kann unter Umständen auch mal 16 Bit breit sein. Ich würde, bei Dingen, wo es darauf ankommt, dass du eine definierte Breite hast immer diese Standarddinger nehmen:
1 | uint8_t
|
2 | uint16_t
|
3 | uint32_t
|
4 | ...
|
Sven H. schrieb: > Char ist denkbar ungeeignet, da eine char Variable ein Zeichen enthält. > achso, wer sagt das? Der Typ char sagt nur aus, dass damit eine Variable mit 1 Byte Länge definiert wird! Ob diese Varaible dann (logisch gesehen) ein Zeichen, eine Zahl zwischen 0...255, eine Bit-Belegung eines 8-Bit-Ports oder ein Keks beinhaltet ist vollkommen egal und dem Programmierer überlassen! Sven H. schrieb: > uint8_t > und was meinst du, was sich hinter diesem Typ verbirgt? Schaue mal in der entsprechenden Header-Datei nach...: 'uint8_t' ist nur eine andere Bezeichnung für 'unsigned char'! Mahlzeit
Manuel schrieb: > Ich habe einen Zähler implementiert, der mir einfach eine unsigned char > Variable bei jedem Aufruf hochzählt, nichts aufregendes. Jedoch erreicht > diese auch ihren Maximalwert 255. Muss ich die aktiv zurücksetzen oder > kann ich einen Overflow zulassen? Sauberer wäre sicher das Zurücksetzen > oder was sagt ihr? Bei Datentypen ohne Vorzeichen ist das Überlaufverhalten sauber definiert. Bei Überschreitung des Wertebereichs geht es wieder bei 0 los. Bei Datentypen mit Vorzeichen ist das Überlaufverhalten nicht definiert.
A. K. schrieb: > Manuel schrieb: > >> Ich habe einen Zähler implementiert, der mir einfach eine unsigned char >> Variable bei jedem Aufruf hochzählt, nichts aufregendes. Jedoch erreicht >> diese auch ihren Maximalwert 255. Muss ich die aktiv zurücksetzen oder >> kann ich einen Overflow zulassen? Sauberer wäre sicher das Zurücksetzen >> oder was sagt ihr? > > Bei Datentypen ohne Vorzeichen ist das Überlaufverhalten sauber > definiert. Bei Überschreitung des Wertebereichs geht es wieder bei 0 > los. > > Bei Datentypen mit Vorzeichen ist das Überlaufverhalten nicht > definiert. Ok, dann weiß ich bescheid! Danke für die Antworten! Ist ein sehr nützliches Forum, konnte schon viel lernen. Gruß
besserwisser schrieb: > achso, wer sagt das? Der Typ char sagt nur aus, dass damit eine Variable > mit 1 Byte Länge definiert wird! Mööp, leider falsch. Zitat aus Wiki ( http://de.wikipedia.org/wiki/Char_(Datentyp) ) Die meisten Programmiersprachen stellen ein Zeichen in einem Byte (8Bit) dar, wobei als Zeichensatz ASCII und dessen Ableitungen wie ISO 8859-1 sowie EBCDIC die verbreitetsten Kodierungen sind. *Neuere Programmiersprachen wie C# oder Java verwenden zwei Byte pro Zeichen (UNICODE) und kodieren Zeichen in UTF-16.* Die etablierten Sprachen wie C und C++ wurden um den mehrbytigen Datentyp wchar_t erweitert.[1] Und, ja, ich weiß sehr wohl, was sich in c hinter dem uint8_t verbirgt tut nur hier nichts zur Sache, da der TO leider keine Programmiersprache angegeben hat.
besserwisser schrieb: > 'uint8_t' ist nur eine andere Bezeichnung für 'unsigned char'! Auch falsch. Siehe die erste Antwort in folgendem Link: http://www.progforum.com/showthread.php?8632-Unterschiede-zwischen-uint8_t-und-char Zitat: die Speichergrößen von char, int, long, etc. sind nicht wirklich fest definiert. Laut C-Standard ist char <= int <= long. Zwar ist im Allgemeinen ein char immer 8 Bit, es besteht aber (auch wenn sehr Unwahrscheinlich) das auf einer anderen Plattform ein char > 8 bit ist. Zudem kann je nach Plattform ein char signed (mit Vorzeichen) oder unsigned (ohne Vorzeichen) sein. Im Allgemeinen ist es aber so das ein char[] einen String definiert, und der ist in C immer mit einem \0 abgeschlossen. Ein uint8_t gibt hingegen direkt die Speichergröße und Typ an (unsigned 8 bit type). Wenn man Arrays zum Ablegen von Daten macht, ist das uint8_t in diesem Fall zu bevorzugen, da es die Größe und Typ fest definiert. Wie gesagt, im Fall des char macht das noch nicht wirklich Sinn, Interresant wird es aber bei anderen Typen, z.B. int. So ist auf PIC's ein int z.B. 16 Bit, während er auf x86 meistens mit 32 Bit definiert ist.
Sven H. schrieb: > Mööp, leider falsch. > MööpMööp..., wenn du schon zitierst, dann bitte den richtigen Abschnitt des Artikels. Über die fachliche Richtigkeit des verlinkten Wikipedia-Artikels lässt sich streiten. Vorallem, wenn ich ich da lese: "Der Datentyp eignet sich grundsätzlich nur zur Zeichendarstellung, nicht zu Berechnungen und nicht für die Indizierung/Adressierung. Hierfür werden numerische Datentypen verwendet, je nach Programmiersprache z. B. short, long, integer etc." Das halte ich für vollkommenden Blödsinn! Wer hintert mich (in C) daran, in einer char-Variablen etwas anderes abzulegen, als wie unbedingt ein Zeichen? Niemand! Und nochmal: der Datentyp char legt nur fest, das die, mit diesem Typ definierte Variable ("i.d.R."; Zitat Wikipedia-Artikel) 8-Bit lang sind. Der Begriff "Zeichkodierung" hat erstmal nichts mit dem Datentyp "char" zu tun! Wenn du Zeichensätze mit mehr als 8-Bit hast, wirst du (i.d.R.) nicht mit dem Datentyp "char" auskommen, sondern wirst dich auf andere Datentypen (z.B. word, uint16_t, ...) ausweichen bzw. dir selbst etwas deklarieren müssen, wenn du auf das Wortfragment "*char*" in der Bezeichnung bestehst! Sven H. schrieb: > Ein uint8_t gibt hingegen direkt die Speichergröße und Typ an (unsigned > 8 bit type). Wenn man Arrays zum Ablegen von Daten macht, ist das > uint8_t in diesem Fall zu bevorzugen, da es die Größe und Typ fest > definiert. > aber nicht, wenn in meiner stdint.h steht:
1 | typedef unsigned char uint8_t |
...und, nach deiner Annahme ein "char" auch 16-Bit sein könnte! Oder habe ich da etwas übersehen? Mahlzeit! PS.: nicht alles was man im Internet findet, sollte man, ohne mal darüber eingehender nachgedacht zu haben, bedenkenlos zitieren. Ich halte mich da lieber an die originale Doku des jeweilig verwendeten Compiler!
besserwisser schrieb: > Oder > habe ich da etwas übersehen? Ein char ist mindestens 8 Bit groß, kann aber auch größer sein (und ist es auch bei manchen Architekturen). Wenn es größer ist, dann existiert auf einem solchen System ein uint8_t schlicht nicht. Wenn die genaue Größe für das Funktionieren des Programms wichtig ist (z.B. weil es sich darauf verlässt, dass die Variable entsprechend überläuft), dann ist es besser unit8_t zu nehmen, denn wenn dann versucht wird, das Programm auf einem char>8Bit-System zu übersetzen gibt es sofort eine Fehlermeldung, dass uint8_t nicht existiert.
besserwisser schrieb: > Wer hintert mich (in C) daran, > in einer char-Variablen etwas anderes abzulegen, als wie unbedingt ein > Zeichen? Niemand! wer hindert dich daran mit einer Maurerkelle den Kuchen zu servieren? klar ist es möglich, aber es gehört nicht zum guten Stil. dito mit char und Daten, die keine Zeichen sind.
char, long etc. sind wirklich nicht definiert. Das hängt von der Busbreite ab. Das ist so. Ein int ist auf einem 32 Bit System nicht gleich gross wie auf einem 64 Bit System. Ein char ist in der Regel 8 Byte (aber nicht zwingend). Das hängt vom Compiler und Architektur ab. Worauf Sven lediglich aufmerksam machen wollte, ist, das in c die Typen uint8_t etc. kompatibler sind zwischen verschiedenen Architekturen. Grüsse, René
> Ein int ist auf einem 32 Bit System nicht > gleich gross wie auf einem 64 Bit System. Doch, meist schon. In 64-Bit Windows ist sogar long noch 32 Bits breit: http://en.wikipedia.org/wiki/64-bit#64-bit_data_models
Sven H. schrieb: > Char ist denkbar ungeeignet, da eine char Variable ein Zeichen enthält. > Mir ist dieser Satz in Svens Posting aufgestossen, der so vollkommen absolu formuliert ist und so nicht stimmt! Die weiteren Zitate, die er dann angebracht hatte, zeigen davon, dass er es auch wirklich so absolut meint... Mahlzeit!
Hmm... hängt das aber nicht auch vom Betriebssystem, Architektur und Compiler ab? Meiner Meinung nach, kann man das so nicht absolut sagen.
> Mahlzeit! Na ja. Du hast dich auch nicht gerade mit Ruhm bekleckert. >> aber nicht, wenn in meiner stdint.h steht: >> typedef unsigned char uint8_t >> > ...und, nach deiner Annahme ein "char" auch 16-Bit sein könnte! > Oder habe ich da etwas übersehen? Du hast übersehen, dass in diesem Fall dann ein uint8_t anders definiert wäre oder gar nicht. Was dich allerdings nichts angeht, weil dir dein Compilerhersteller die stdint.h aufs Auge drückt und einen uint8_t dann eben so definiert, dass er wieder 8 Bit hat. Wie auch immer diese Definition aussieht. Und falls es überhaupt möglich ist, natürlich. Nur weil bei dir, auf deinem jetzigen Compiler ein uint8_t als typedef auf einen unsigned char definiert ist, heißt das nicht, dass das immer und überall so ist.
So, von der Solaris Page über die Portierung von 32Bit nach 64Bit: The 64-bit environment uses a different data type model than the 32-bit environment. The C data-type model used for 32-bit applications is the ILP32 model, so named because ints, longs, and pointers are 32-bit. The LP64 data model is the C data-type model for 64-bit applications. This model was agreed upon by a consortium of companies across the industry. It is so named because longs and pointers grow to 64-bit quantities. The remaining C types int, short, and charare the same as in the ILP32 model. The standard relationship between C integral types still holds true. So, wie ich das verstehe ist die Grösse eine Vereinbarung, was demnach nicht heisst, dass das immer so ist. Zumindest verstehe ich das so. Der Linke zur Seite: http://developers.sun.com/solaris/articles/solarisupgrade/64bit/Convert.html PS: In dem Fall ist es aber so, das int sowohl auf 32Bit als auch 64Bit 4 Byte ist. Grüsse, René
>So, von der Solaris Page über die Portierung von 32Bit nach 64Bit: um es noch "interessanter" zu machen: es gibt ja (wenn man mal nur Intel betrachtet ) 2 Verschiedene 64-bit Architekturen die von Intel (Itanium/IA-64) und die von AMD (x64) für die von AMD (welche in aktuellen CPUs verwendet wird) werden int weiterhin als 32bit definiert (bei Itanium und auch Sparc?? eher 64bit?) andererseits gibt es auch http://www.heise.de/open/artikel/Kernel-Log-x32-ABI-umgeht-Nachteile-des-64-Bit-Betriebs-1341264.html also 32bit Pointer trotz 64Bit Linux Betriebssystem.
Manuel schrieb: > Ich habe einen Zähler implementiert, der mir einfach eine unsigned char > Variable bei jedem Aufruf hochzählt, nichts aufregendes. Jedoch erreicht > diese auch ihren Maximalwert 255. Muss ich die aktiv zurücksetzen oder > kann ich einen Overflow zulassen? Sauberer wäre sicher das Zurücksetzen > oder was sagt ihr? unsigned char counter=0; while(true) //endlos counter++ Das Ding läuft bis zum Maximalwert und wird dann wieder bei 0 gestartet. Absolut kein Problem, du musst dich nicht um Zurücksetzen oder ähnliches kümmern. Beachte aber wie bereits oben erwähnt, dass sizeof(char) nicht zwingend 1 ist. Die Kardinalität von char ist 2^(sizeof(char)*8). Wobei ich sagen muss, dass ich es bis jetzt noch nicht erlebt habe, dass in C/C++ char jemals ungleich 1 byte war. Aber das heißt grundsätzlich mal garnichts ;-) Und noch ein Wort zur Verwendung von char: Niemand schreibt vor, wie ich char in C/C++ verwende. Wenn ich zum Beispiel eine Schleife über 3 Werte mache (z.B. über die 3 Farbkanäle eines Bildes), so verwende ich hierfür unsigned char, ganz einfach deswegen, weil es vom Wertebereich absolut genug ist. Niemand schreibt vor, dass man in char ein Zeichen speichern muss. Grade wenns Richtung low level Sachen geht, auf schwachen Rechnern, verwende ich bei solchen Dingen durchaus char! Anderes Beispiel: digitale Bilder. Jeder Kanal ist mit 1 byte codiert. Klar missbraucht man auch hier unsigned char zum Speichern einer Zahl, anstatt zum Speichern eines Zeichens. Stellt euch mal vor, was es heißt, stattdessen short int zu verwenden. Der Speicherverbrauch verdoppelt sich unnötigerweise.
Mal abgesehen davon, dass ich mich vielleicht wirklich etwas absolut ausgedrückt habe, finde ich es interessant, in welche Richtung sich der Thread entwickelt hat!
Robert L. schrieb: > für die von AMD (welche in aktuellen CPUs verwendet wird) > werden int weiterhin als 32bit definiert (bei Itanium und auch Sparc?? > eher 64bit?) Bis vor kurzem haben wir hier noch auf Solaris SPARC gearbeitet. Zwischen 32/64 Bit hatten sich lediglich die Pointers unterschieden. Integer war auf beiden 4 Byte lang.
besserwisser schrieb: > Sven H. schrieb: >> Char ist denkbar ungeeignet, da eine char Variable ein Zeichen enthält. >> > Mir ist dieser Satz in Svens Posting aufgestossen, der so vollkommen > absolu formuliert ist und so nicht stimmt! Naja, man sollte char nur für Zeichen verwenden, allerdings ist im Ursprungsposting nicht von char, sondern von unsigned char die Rede. > Die weiteren Zitate, die er dann angebracht hatte, zeigen zeugen (Sorry, aber wenn du dich schon "besserwisser" nennst...) > davon, dass er es auch wirklich so absolut meint... Karl Heinz Buchegger schrieb: > Du hast übersehen, dass in diesem Fall dann ein uint8_t anders definiert > wäre oder gar nicht. Was dich allerdings nichts angeht, weil dir dein > Compilerhersteller die stdint.h aufs Auge drückt und einen uint8_t dann > eben so definiert, dass er wieder 8 Bit hat. Wie auch immer diese > Definition aussieht. Und falls es überhaupt möglich ist, natürlich. Speziell uint8_t kann nur existieren, wenn char 8 Bit breit ist. Das ergibt sich einfach daraus, daß sizeof(char)==1 und damit char der kleinste Datentyp ist. Wenn der größer als 8 Bit ist, kann es also keinen 8-Bit-Typ geben. Sven H. schrieb: > besserwisser schrieb: >> achso, wer sagt das? Der Typ char sagt nur aus, dass damit eine Variable >> mit 1 Byte Länge definiert wird! > > Mööp, leider falsch. Nein, das ist absolut richtig. > Die meisten Programmiersprachen stellen ein Zeichen in einem Byte (8Bit) > dar, In C (und auch allgemein) muß ein Byte nicht zwingend genau 8 Bit groß sein. Statt "Byte (8Bit)" wäre in dem Text die in der Netzwerktechnik übliche Bezeichung "Oktett" besser geeignet. ösi schrieb: > Beachte aber wie bereits oben erwähnt, dass sizeof(char) nicht zwingend > 1 ist. Doch, sizeof(char) ist per Definition immer 1. > Die Kardinalität von char ist 2^(sizeof(char)*8). Wieso 8? Das ist nirgends so festgelegt. Die Zahl an Bits in einem char stellt dir der Compiler über das Makro CHAR_BIT zur Verfügung. > Und noch ein Wort zur Verwendung von char: Niemand schreibt vor, wie ich > char in C/C++ verwende. Wenn ich zum Beispiel eine Schleife über 3 Werte > mache (z.B. über die 3 Farbkanäle eines Bildes), so verwende ich hierfür > unsigned char, ganz einfach deswegen, weil es vom Wertebereich absolut > genug ist. Niemand schreibt vor, dass man in char ein Zeichen speichern > muss. char und unsigned char sind zwei verschiedene Typen. Am besten nutzt man ersteren nur für Zeichen und den zweiten, wenn man Platz sparen muß und einen kleinen vorzeichenlosen Integerwert speichern muß.
Rolf Magnus schrieb: > Sven H. schrieb: >> besserwisser schrieb: >>> achso, wer sagt das? Der Typ char sagt nur aus, dass damit eine Variable >>> mit 1 Byte Länge definiert wird! >> >> Mööp, leider falsch. > > Nein, das ist absolut richtig. Ich könnte jetzt zwar behaupten, das es doch falsch ist, führt aber zu nichts, daher die bitte doch nochmal diese Quelle zu prüfen: http://msdn.microsoft.com/de-de/library/x9h8tsay(v=vs.90).aspx Rolf Magnus schrieb: > Speziell uint8_t kann nur existieren, wenn char 8 Bit breit ist. Das > ergibt sich einfach daraus, daß sizeof(char)==1 und damit char der > kleinste Datentyp ist. Wenn der größer als 8 Bit ist, kann es also > keinen 8-Bit-Typ geben. Auch nicht richtig: http://msdn.microsoft.com/de-de/library/5bdb6693(v=vs.90).aspx Es gibt einen 8 Bit breiten Datentyp, obwohl char 16 bit breit ist. Bei diesen Diskussionen muss halt beachtet werden, dass nirgendwo die Rede von C war. Es könnte auch jede andere Programmiersprache gemeint sein.
ösi schrieb: > Beachte aber wie bereits oben erwähnt, dass sizeof(char) nicht zwingend > 1 ist. In C schon. C99 zum sizeof() Operator: "When applied to an operand that has type char, unsigned char, or signed char, (or a qualified version thereof) the result is 1."
Sven H. schrieb: > Rolf Magnus schrieb: >> Speziell uint8_t kann nur existieren, wenn char 8 Bit breit ist. Das >> ergibt sich einfach daraus, daß sizeof(char)==1 und damit char der >> kleinste Datentyp ist. Wenn der größer als 8 Bit ist, kann es also >> keinen 8-Bit-Typ geben. > > Auch nicht richtig: > > http://msdn.microsoft.com/de-de/library/5bdb6693(v... > > Es gibt einen 8 Bit breiten Datentyp, obwohl char 16 bit breit ist. Gibt es in C# denn überhaupt einen Typ namens uint8_t? Schließlich wurde ja darüber diskutiert. > Bei diesen Diskussionen muss halt beachtet werden, dass nirgendwo die > Rede von C war. Es könnte auch jede andere Programmiersprache gemeint > sein. Naja, jede andere vielleicht nicht, aber es stimmt natürlich, daß die Sprache hätte angegeben werden müssen. Sven H. schrieb: > A. K. schrieb: >> In C schon. > > Es geht aber ausschließlich nicht um C. Woraus hast du das gelesen? Du scheinst C# anzunehmen. Gibt es da überhaupt den im Ursprungsposting erwähnten Typ "unsigned char"?
Rolf Magnus schrieb: > Gibt es in C# denn überhaupt einen Typ namens uint8_t? Schließlich wurde > ja darüber diskutiert. Genau wir in C steht es dir frei, einen Datentypen zu definieren. uint8_t ist ja auch ein selbst definierter Typ. (typedef unsigned char)
das Problem ist wohl, dass Sven H. und auch der TO beide die Sprache nicht "definiert" haben (weder bei der Frage, noch bei der/den Antwort(en)) dass dann nur "nonsense" raus kommt, ist doch klar.. so kann sich jeder immer alles so hin-biegen, um bloß nicht zugeben zu müssen, irgendwas falsches geschrieben zu haben.. wobei: zitat: > Standarddinger nehmen: >uint8_t stellt sich schon die frage: gibt es STANDARDmäßig ausser in C das irgendwo ?
Sven H. schrieb: > uint8_t ist ja auch ein selbst definierter Typ Nein. Er wird durch die "Implementierung" (also Compiler oder Standardbibliothek) vorgegeben, über <stdint.h> oder <inttypes.h>. Dadurch wird seine Semantik (für die Sprache C) eindeutig beschrieben und ist nicht irgendwie beliebig interpretierbar. Ob die Implementierung nun über ein typedef erfolgt [was naheliegend ist] oder über ein Pragma oder was auch immer, ist dabei völlig unerheblich und für den Nutzer unwichtig. Ein Compiler könnte sich beispielsweise auch entscheiden, diese Namen als builtins zu implementieren, die dann durch einen Konstrukt wie
1 | #pragma __STDINT_H_included
|
(der in <stdint.h> drin steht) "freigeschaltet" werden. Ob Manuel ggf. was anderes als die Sprache C meinte, hat er uns nicht verraten. Man kann allerdings davon ausgehen, dass er eine obskure Sprache (wie C#) sicher gesondert erwähnt hätte.
Jörg Wunsch schrieb: > eine obskure Sprache (wie C#) Schön wär's ;-) http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Mark Brandis schrieb: > http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html Was auch immer da stehen mag. Leute, bei denen selbst die "Sitemap" leer ist und drüber schreibt "This website requires JavaScript", kann ich in keiner Weise ernst nehmen, und für suspekte Websites schalte ich grundsätzlich kein Javascript ein.
Jörg Wunsch schrieb: > und für suspekte Websites sag bloß, du hast noch nie was vom Tiobe-Index gehört?
Vlad Tepesch schrieb: > sag bloß, du hast noch nie was vom Tiobe-Index gehört? Ja, und? Muss man den kennen? Meine Arbeit ist nicht indiziert. :)
Jörg Wunsch schrieb: > Ja, und? Muss man den kennen? Ich denke, dass viele die professionell in der SW-Entwicklung arbeiten davon schon mal gehört haben > Meine Arbeit ist nicht indiziert. :) ich wäre mir nicht so sicher, ob da nicht doch auch treffer von mir mit einberchnet sind. wenn man bei google nach "c rogramming" "jörg wünsch" eingibt gibts immerhin >800 Treffer, die ja im gesamtergebnis auch mit drinstecken.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.