Binäre Konstanten in C

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 …

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

};

Das wird es dann in C wohl auch werden. Hat ja auch Sinn, dass die 
beiden da gleichermaßen agieren.

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.

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 …)

mh schrieb:
> Ich konnte nur n2472 finden und das ist nicht wirklich hilfreich.

n2534

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

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.

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.

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.

Du könntest dem Beitrag wenigstens noch einen Smiley spendieren. Die 
Ironie versteht sonst wohl nicht jeder sofort.