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:
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
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:
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
bitcheckbits[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.
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
listintmy_numbers;
3
// a.c
4
itemmy_numbers=1;
5
// b.c
6
itemmy_numbersbla=2;
7
// main.c
8
intmain(){
9
printf("list my_numbers has the following %zu items:\n",my_numbers.end-my_numbers.start);
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:
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.
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.
Thread beobachten
Seitenaufteilung abschalten