Re: Beitrag "Re: Mikrokontroller Crash Kurs mit ANSI-C, mit ATMega Register Nutzung" Nun, der Kampf gegen Windmühlen war erfolgreich: der Vorschlag ist soeben einstimmig angenommen worden. ;-) C23 wird also binäre Konstanten enthalten.
Beitrag #6443332 wurde von einem Moderator gelöscht.
Larry schrieb: > Die kann der XC8 ja schon ewig. Das ändert nichts daran, dass der C-Standard das bislang nicht spezifiziert hatte. Im GCC ist es seit 2007 drin. Captain Teemo schrieb im Beitrag #6443332: > C++ kann das schon lange.... Sooo lange nun auch wieder nicht. Es ist seit C++14 drin. Allerdings produziert die WG14 nicht so inflationär viele :) Standards wie WG21, der letzte C-Standard ist von 2011 (C17 ist nur ein "bugfix release", also keine inhaltlichen Änderungen). Aber ja, inzwischen können so ziemlich alle anderen relevanten Programmiersprachen das, nur C hinkte hier hinterher - weshalb ich mich ja auch gemüßigt gefühlt habe, das mal dort einzutüten. Wenn's halt sonst keiner macht …
Wird man einfach nur 0b00001111 direkt in den Variablen ablegen könnnen oder kommt noch mehr dazu? (z.B. %b für Format-String bei printf-Funktion - wie %x für die Hex-Zahlen oder %o für die Octal-Zahlen usw.) Sonst macht es ja wenig Sinn PS: Seit wann können die C-Programmierer keine 16 Hex-Zahlen merken? ;-)
naja ;-) schrieb: > Wird man einfach nur 0b00001111 direkt in den Variablen ablegen könnnen > oder kommt noch mehr dazu? Das ist das, was jetzt erstmal angenommen worden ist. Parallel wurde vorgeschlagen, eine Gruppierung von Ziffern vornehmen zu können. Da C++ das schon hat (oder auch gerade im Begriff ist einzuführen), hat sich der Aufgabe jemand angenommen, der das mit WG21 koordiniert. Es wird wohl ein Apostroph werden als Trennzeichen, kein Unterstrich (wie in Rust oder VHDL). Das wurde damit begründet, dass ein Unterstrich ein gültiger Bezeichner im Präprozessor ist, was zu Schwierigkeiten führt, wenn diesen jemand per #define belegt hat. > (z.B. %b für Format-String bei > printf-Funktion - wie %x für die Hex-Zahlen oder %o für die Octal-Zahlen > usw.) Witzigerweise wurde genau diese Frage im Meeting dann gestellt. ;-) Ich habe mich bereit erklärt, dafür einen Vorschlag einzureichen. Was er genau beinhaltet, steht dabei aber noch zur Diskussion. Insbesondere wäre es natürlich interessant zu wissen, ob es bereits irgendwelche existierenden Implementierungen für sowas gibt, denn es ist gängige Praxis, möglichst das zu standardisieren, was es schon gibt. > PS: Seit wann können die C-Programmierer keine 16 Hex-Zahlen merken? ;-) Können sie schon, aber es ist natürlich viel beschreibender, wenn du den Smiley für dein LCD so darstellen kannst:
1 | const uint8_t smiley5x7[] = { |
2 | 0b000000, |
3 | 0b001010, |
4 | 0b001010, |
5 | 0b000000, |
6 | 0b010001, |
7 | 0b001110, |
8 | 0b000000, |
9 | 0b000000, |
10 | };
|
statt:
1 | const uint8_t smiley5x7[] = { |
2 | 0x00, 0x0a, 0x0a, 0x00, 0x11, 0x0e, 0x00, 0x00, |
3 | };
|
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Da C++ das schon hat (oder auch gerade im Begriff ist > einzuführen), hat sich der Aufgabe jemand angenommen, der das mit WG21 > koordiniert. Es wird wohl ein Apostroph werden als Trennzeichen, kein > Unterstrich (wie in Rust oder VHDL). Existiert seit c++14 und ist ein Apostroph
1 | int foo = 0b0010'0100'0010'0011; |
Das wird es dann in C wohl auch werden. Hat ja auch Sinn, dass die beiden da gleichermaßen agieren.
Jörg W. schrieb: > Nun, der Kampf gegen Windmühlen war erfolgreich: der Vorschlag ist > soeben einstimmig angenommen worden. ;-) Dann schlag doch auch mal vor, dass Bit-Arrays unterstützt werden, um Speicherplatz zu sparen.
Dirk F schrieb: > Dann schlag doch auch mal vor, dass Bit-Arrays unterstützt werden, um > Speicherplatz zu sparen. Naja, vorschlagen kann man viel. Akzeptanz findet vor allem das, was allgemein (oder zumindest von einer größeren Nutzergruppe) als nützlich empfunden wird. Insbesondere sollte es entweder extrem wesentlich erscheinen, sowas in der Sprache zu haben, oder aber es sollte vorherige (und erfolgreich etablierte) Implementierung(en) dafür geben. Letzteres habe ich mit binären Konstanten vor 13 Jahren im GCC unterbringen können, und sie sind ganz offenbar seither auch tatsächlich benutzt worden. OK, man hätte vielleicht nicht unbedingt 13 Jahre warten müssen, aber für deinen Vorschlag wäre es wohl der erste Schritt, in einer Beispielimplementierung zu demonstrieren, dass das Ganze mehr als nur Arbeit für den Compilerbauer bringt … Da N-bit Integers bereits als Bestandteil von C23 auf dem Plan stehen, könnte es natürlich sein, dass man in deinem Falle mit einem Array von _ExtInt(1) arbeiten kann … allerdings fürchte ich, dass das nur deshalb, weil der Standard es prinzipiell vorsieht, noch lange nicht von jedem Compiler für jedes Zielsystem unterstützt sein muss. :} Ziel der _ExtInt()-Geschichte ist es nach meinem Verständnis vor allem, dass man für Umgebungen wie FPGAs, die Zahlen in beliebiger Bitlänge darstellen können, dem Compiler überhaupt die passenden Möglichkeiten in die Hand gibt, dafür eine Unterstützung in der Sprache zu implementieren.
Dirk F schrieb: > Jörg W. schrieb: >> Nun, der Kampf gegen Windmühlen war erfolgreich: der Vorschlag ist >> soeben einstimmig angenommen worden. ;-) > > Dann schlag doch auch mal vor, dass Bit-Arrays unterstützt werden, um > Speicherplatz zu sparen. 1.) Warum machst du das nicht selber? 2.) Hast du ne Idee, wie das aussehen soll, ohne die ganze Sprache neu zu definieren?
mh schrieb: > 1.) Warum machst du das nicht selber? > 2.) Hast du ne Idee, wie das aussehen soll, ohne die ganze Sprache neu > zu definieren? Also beim XC8 gibt es ja schon so etwas:
1 | bit Pruefmodus,Debugmodus; // 1 = Prüfmodus |
1 | char Tout[40],Tin[40]; // 40 Soft timer |
Dann wäre es schön, wenn es so etwas geben würde:
1 | bit Tout[40],Tin[40]; // 40 Soft timer |
Ja, wie geschrieben, vermutlich müsste das mit _ExtInt() sogar sprachkonform dann definierbar sein.
1 | _ExtInt(1) checkbits[23]; |
oder von mir aus
1 | typedef _ExtInt(1) bit; |
2 | // ...
|
3 | bit checkbits[23]; |
Nur, inwiefern das ein Compiler dann so umsetzt, wie du dir das gerade auch vorstellst, steht auf einem anderen Blatt … (auf einem AVR „natürlich“ dann am besten über GPIOR<n> Register …)
Jörg W. schrieb: > Ja, wie geschrieben, vermutlich müsste das mit _ExtInt() sogar > sprachkonform dann definierbar sein. > _ExtInt(1) checkbits[23]; > > oder von mir aus > typedef _ExtInt(1) bit; > // ... > bit checkbits[23]; > > Nur, inwiefern das ein Compiler dann so umsetzt, wie du dir das gerade > auch vorstellst, steht auf einem anderen Blatt … (auf einem AVR > „natürlich“ dann am besten über GPIOR<n> Register …) Gibt es dazu ein Paper? Ich konnte nur n2472 finden und das ist nicht wirklich hilfreich. Die Änderungen im Standard dafür müssen gigantisch sein. In einem LLVM Blogpost habe ich auch etwas von C++ gelesen. Wie sich das vertragen soll ist mir nicht ganz klar.
Jörg W. schrieb: > C23 wird also binäre Konstanten enthalten. Danke, auch für den 1. Kampf gegen die gcc-Mühlen: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
Jörg W. schrieb: > mh schrieb: >> Ich konnte nur n2472 finden und das ist nicht wirklich hilfreich. > > n2534 Danke!
Ein fprintf(..,"%b", haette ich gerade gebrauchen koennen. Alles muss man selber machen.
Wie kann man dort einen Vorschlag machen. Ich hätte da auch ein paar Dinge, die ich in C vermisse. Was ich z.B. gerne gehabt hätte: * Mehrere init funktionen. Bei gcc ist das mit dem constructor attribut machbar. * Über mehrere Objekte verteilte listen aus globalen Elementen. Irgend sowas:
1 | // something.h
|
2 | list int my_numbers; |
3 | // a.c
|
4 | item my_numbers = 1; |
5 | // b.c
|
6 | item my_numbers bla = 2; |
7 | // main.c
|
8 | int main(){ |
9 | printf("list my_numbers has the following %zu items:\n", my_numbers.end - my_numbers.start); |
10 | for(int* it=my_numbers.start; it<my_numbers.end; it++) |
11 | printf(" - %d\n", *it); |
12 | }
|
Momentan behelfe ich mich auch da mit dem constructor attribut von gcc.
Dirk F schrieb: > Dann wäre es schön, wenn es so etwas geben würde: > bit Tout[40],Tin[40]; // 40 Soft timer Das hört sich so einfach an, ist es aber nicht. Mach dir mal Gedanken darüber, welche Ergebnisse die folgenden, für klassische C-Arrays wohldefinierten Ausdrücke liefern sollten:
1 | sizeof Tout[0] |
2 | Tout + 1 |
:
Bearbeitet durch Moderator
🐧 DPA 🐧 schrieb: > Wie kann man dort einen Vorschlag machen. http://www.open-std.org/jtc1/sc22/wg14/www/contributing
2#00101010# schrieb: > Danke, auch für den 1. Kampf gegen die gcc-Mühlen: Joseph Myers, der damals (sehr konstruktiv) kommentiert hatte, gehört übrigens der WG14 an. Kann mich gerade nicht dran erinnern, ob er mit dabei war vor 2 Wochen. 🐧 DPA 🐧 schrieb: > Wie kann man dort einen Vorschlag machen. http://www.open-std.org/jtc1/sc22/wg14/www/contributing [Edit: "mh" war schneller.] Aber Vorschläge sollten schon praktikabel und gut durchdacht sein. Attribute gibt es mittlerweile im Entwurf, die Syntax ist allerdings anders als bei GCC. Ggf. kann man auf der Basis natürlich Vorschläge für weitere Attribute einbringen.
:
Bearbeitet durch Moderator
Yalu X. schrieb: > Dirk F schrieb: >> Dann wäre es schön, wenn es so etwas geben würde: >> bit Tout[40],Tin[40]; // 40 Soft timer > > Das hört sich so einfach an, ist es aber nicht. Mach dir mal Gedanken > darüber, welche Ergebnisse die folgenden, für klassische C-Arrays > wohldefinierten Ausdrücke liefern sollten: > sizeof Tout[0] > Tout + 1 Wobei die gleichen Probleme bei Bitfeldern ja schon gelöst oder umgangen worden sind.
Rolf M. schrieb: > Yalu X. schrieb: >> Dirk F schrieb: >>> Dann wäre es schön, wenn es so etwas geben würde: >>> bit Tout[40],Tin[40]; // 40 Soft timer >> >> Das hört sich so einfach an, ist es aber nicht. Mach dir mal Gedanken >> darüber, welche Ergebnisse die folgenden, für klassische C-Arrays >> wohldefinierten Ausdrücke liefern sollten: >> sizeof Tout[0] >> Tout + 1 > > Wobei die gleichen Probleme bei Bitfeldern ja schon gelöst oder umgangen > worden sind. sizeof ist für Bitfelder verboten und Arrays aus Bitfeldern sind nicht möglich.
mh schrieb: >> Wobei die gleichen Probleme bei Bitfeldern ja schon gelöst oder umgangen >> worden sind. > > sizeof ist für Bitfelder verboten und Arrays aus Bitfeldern sind nicht > möglich. Ich wollte damit sagen, dass, wenn man es bei Bitfeldern schon hinbekommen hat, das im C-Standard unterzubringen, sollte es mit Bitarrays auch machbar sein. Man wird aber eben auf bestimmte Funktionalitäten verzichten müssen, wie eben sizeof oder z.B. Zeiger auf die Elemente.
Rolf M. schrieb: > mh schrieb: >>> Wobei die gleichen Probleme bei Bitfeldern ja schon gelöst oder umgangen >>> worden sind. >> >> sizeof ist für Bitfelder verboten und Arrays aus Bitfeldern sind nicht >> möglich. > > Ich wollte damit sagen, dass, wenn man es bei Bitfeldern schon > hinbekommen hat, das im C-Standard unterzubringen, sollte es mit > Bitarrays auch machbar sein. Man wird aber eben auf bestimmte > Funktionalitäten verzichten müssen, wie eben sizeof oder z.B. Zeiger auf > die Elemente. Klar bekommt man das in den Standard wenn man will. Das macht den Standard aber sicher nicht lesbarer. Und ich bezweifle, dass c-Programme lesbarer werden, wenn plötzlich Integer vorkommen, für die keine Integer-Promotion durchgeführt wird (_ExtInt).
Bei den binären Zahlen fehlen mir noch Gleitpunktzahlen, denn hexadezimale Gleitpunktzahlen gibt es seit spätestens C99. Zwei der Anwendungsfelder dafür sind die Verarbeitung von AD-Wandler-Werten und die Verarbeitung von DA-Wandler-Werten. Und sinnvoll wären dabei auch komplexe Gleitpunkt-Binärzahlen (und Gleitpunkt-Hexadezimalzahlen), denn seit spätestens C99 hat C auch komplexe Zahlen und mathematische Funktionen dazu. Hilfreich wären die komplexen hex- und binär-Zahlen beispielsweise bei Wechselstromgrößen. Und auch bei Supraströmen, denn die haben eine zusätzliche Phase, die Phase der makroskopischen Wellenfunktion, durch die man beispielsweise über die Strom-Phasen-Relation den Strom aus der Phasenverschiebung berechnen kann oder umgekehrt die Phasenverschiebung aus dem Strom.
:
Bearbeitet durch User
Du könntest dem Beitrag wenigstens noch einen Smiley spendieren. Die Ironie versteht sonst wohl nicht jeder sofort.
Beitrag #6460843 wurde von einem Moderator gelöscht.
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.