Was hättet ihr denn gern als Erweiterung in C?

[Thomas Koenig]

Hier mal ein paar Punkte von mir:

Früher hätte ich 0b... gesagt, aber das ist ja jetzt drin.
Fehlen tut aber die Ein/Ausgabe über printf/scanf und Verandte.

Zahlen gruppieren. In fixed-form-Fortran konnte man z.B.

A = 1.123 456 789

schreiben, weil Leerzeichen außer in Strings keine Bedeutung
hatten. Leider hat free-form Fortran das aufgebeben, und
C kann es auch nicht. Wäre aber manchmal ganz übersichtlich.

Weitere Punkte?

[olaf]

Thomas Koenig <tko...@netcologne.de> wrote:

>Fehlen tut aber die Ein/Ausgabe über printf/scanf und Verandte.

Das verstehe ich nicht. printf ist doch garkeine C Funktion sondern
ein Programm das du dazu linkst und beliebig selbst schreibst.

Mein printf macht z.B sowas hier:

printf("%2f", 123); ==> 1.23

Ich vermute mal deines ist da anders. Also bau doch einfach deinen
Wunsch in dein printf ein.

>Weitere Punkte?

Mir fehlt nix. Kann alles so bleiben wie es ist.

Olaf

[Thomas Koenig]

olaf <ol...@criseis.ruhr.de> schrieb:

> Thomas Koenig <tko...@netcologne.de> wrote:
>
> >Fehlen tut aber die Ein/Ausgabe über printf/scanf und Verandte.
>
> Das verstehe ich nicht. printf ist doch garkeine C Funktion sondern
> ein Programm das du dazu linkst und beliebig selbst schreibst.

printf ist in Abschnitt 7 des letzten Normentwurfs, den ich habe
(n2596.pdf) beschrieben. Wenn du eine Funktion namens printf
verwendest, verwendest du einen "Reserved identifier" mit external
linkage, und das ist undefined behavior und kann Bruch ergeben.

[Helmut Schellong]

On 11/19/2022 18:08, olaf wrote:
> Thomas Koenig <tko...@netcologne.de> wrote:
>
> >Fehlen tut aber die Ein/Ausgabe über printf/scanf und Verandte.
>
> Das verstehe ich nicht. printf ist doch garkeine C Funktion sondern
> ein Programm das du dazu linkst und beliebig selbst schreibst.
>
> Mein printf macht z.B sowas hier:
>
> printf("%2f", 123); ==> 1.23
>
> Ich vermute mal deines ist da anders. Also bau doch einfach deinen
> Wunsch in dein printf ein.

Wohl Ironie...

Bei der Funktion printf sollte es nicht so wie vorstehend notiert werden.
Der Compiler übergibt dann einen Integer.
Moderne Compiler warnen, weil die den Inhalt des Format-Strings bewerten.


--
Mit freundlichen Grüßen
Helmut Schellong v...@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/math87.htm http://www.schellong.de/htm/dragon.c.html

[Helmut Schellong]

http://www.schellong.de/better_c99.htm

Vor langer Zeit schrieb ich den Inhalt unter dem vorstehenden Link.

[olaf]

Helmut Schellong <r...@schellong.biz> wrote:

>Bei der Funktion printf sollte es nicht so wie vorstehend notiert werden.
>Der Compiler übergibt dann einen Integer.

Ja richtig. Mein printf erwartet da auch einen Integer.

Ich verwende das fuer Mikrocontroller wo ich kein Fliesskomma
verwenden will und stattdessen mit Festkomma arbeite.

Olaf

[Helmut Schellong]

Ich habe für uC eine eigene sprintf_F() entwickelt.
Aber ich habe keinen bekannten Formatbuchstaben %f für neue Formate verwendet, sondern
neue Steuer-Flags vor dem jeweiligen Formatbuchstaben.

[Bonita Montero]

Am 19.11.2022 um 17:53 schrieb Thomas Koenig:

> A = 1.123 456 789

Sowas gibt's in C++, meines Wissens seit C++11, z.B.:
1'000'000'000.

Was auch geil sind sind hexadezimale Floating Point Zahlen:
#define FLT_EPSILON (1.0 - 0x1.FFFFFFFFFFFFFp-1)
Frag mich immer wieder wieso die entsprechenden Header nicht
darauf umgestiegen sind weil solche Definitionen dadurch massiv
beser lesbar werden. Kann man ja dann in bedingt kompilieren,
dass jeder ab C++17 solche Definitionen zu sehen kriegt.

Aber grundsätzlich ist C eigentlich nicht mehr zu retten.
Die Wartbarkeits- und Produktivitäts-Vorteile von Rust und
C++ sind einfach gigantisch.

[G.B.]

On 19.11.22 17:53, Thomas Koenig wrote:

- Einen Schalter im Präprozessor, der #if abschaltet.

[Marcel Mueller]

Am 20.11.22 um 09:32 schrieb G.B.:

> On 19.11.22 17:53, Thomas Koenig wrote:
>
> - Einen Schalter im Präprozessor, der #if abschaltet.

Dann funktioniert kein einziges Standard-Include mehr.


Marcel

[Marcel Mueller]

Am 20.11.22 um 03:16 schrieb Bonita Montero:

> Was auch geil sind sind hexadezimale Floating Point Zahlen:
>     #define FLT_EPSILON (1.0 - 0x1.FFFFFFFFFFFFFp-1)
> Frag mich immer wieder wieso die entsprechenden Header nicht
> darauf umgestiegen sind weil solche Definitionen dadurch massiv
> beser lesbar werden.

Es mag zwar Usus sein, aber IEEE Floats sind nach wie vor nicht
vorgeschrieben und im Besonderen auch nicht die Basis 2.

> Aber grundsätzlich ist C eigentlich nicht mehr zu retten.
> Die Wartbarkeits- und Produktivitäts-Vorteile von Rust und
> C++ sind einfach gigantisch.

Ack.


Marcel

[Marcel Mueller]

Am 19.11.22 um 19:38 schrieb Helmut Schellong:

> http://www.schellong.de/better_c99.htm
>
> Vor langer Zeit schrieb ich den Inhalt unter dem vorstehenden Link.

Kann man machen. Aber am Ende ist es wie Immer Geschmackssache.

Operator ^^ ergibt allerdings nun wirklich keinen Sinn.
Boolsches XOR gibt es in C von Anbegin: ^
Die doppelten Operatoren sind /shortcut/ Operatoren, und das ist bei XOR
niemals möglich.

Interessanter wäre da schon, wenn der Typ erst /nach/ && und || zu einem
logischen Ausdruck werden würde, wie in Perl. Dann könnte man || auch
als Null-Coalescing-Operator verwenden, was so manche if-Kaskade
auflöst, oder mit && den ersten Fehlerrückgabewert abfischen.

Aber würde ich bei alle dem dann C noch verwenden wollen? Ganz klares nein.
Die erste Amtshandlung, wenn ich alten C-Code bekomme ist immer die
Umstellung auf C++, wann immer das in meinem Ermessensspielraum liegt.
Selbst wenn der umgestellte Code mit vertretbarem Aufwand nur ein paar
Prozent der neuen Sprache nutzen kann, ist es das wert.

Kurzum, mir reicht C99. Für alten Code, der oft nicht mal dessen
Funktionsumfang nutzt, ist das völlig OK.


Marcel

[Bonita Montero]

Am 20.11.2022 um 09:57 schrieb Marcel Mueller:

> Am 20.11.22 um 03:16 schrieb Bonita Montero:

>> Frag mich immer wieder wieso die entsprechenden Header nicht
>> darauf umgestiegen sind weil solche Definitionen dadurch massiv
>> beser lesbar werden.

> Es mag zwar Usus sein, aber IEEE Floats sind nach wie vor nicht
> vorgeschrieben und im Besonderen auch nicht die Basis 2.

So ein Quatsch. Natürlich ist das vorgeschrieben, obwohl es auch welche
nach neuerem IEEE-754-Standard mit dezimaler Basis gibt. Außerdem würde
das auch keiner anders akzeptieren weil sich Basen mit weiteren Prim-
faktoren durch einen Computer nur schnarch-langsam implementieren
lassen.

[Bonita Montero]

Am 20.11.2022 um 09:32 schrieb G.B.:

> - Einen Schalter im Präprozessor, der #if abschaltet.

Wozu soll das gut sein ?

[G.B.]

Wozu braucht es #if, im Unterschied zu #ifdef?

(Ich versuche gern, bei intern genutzen "Modulen",
das idiomatische

#ifdef _ICH_SCHLIESSE_ALLES_IMMER_EIN_H
#define _ICH_SCHLIESSE_ALLES_IMMER_EIN_H
...
#endif /* _ICH_SCHLIESSE_ALLES_IMMER_EIN_H */

zu vermeiden. Nicht selten ist dieser Verzicht gut
gegen spaghettimäßige Kopplung gewesen.)


https://9p.io/sys/doc/comp.html

[Bonita Montero]

Am 20.11.2022 um 18:56 schrieb G.B.:

> Wozu braucht es #if, im Unterschied zu #ifdef?

Ich find's besser lesbar und man kann zudem damit auf mehrere Makros
gleichzeitig testen, was bei mir nicht selten vorkommt. Und es gibt
auch überhaupt keine nachvollziehbare Not, weswegen das weg müsste.

> #ifdef _ICH_SCHLIESSE_ALLES_IMMER_EIN_H
> #define _ICH_SCHLIESSE_ALLES_IMMER_EIN_H
> ...
> #endif /* _ICH_SCHLIESSE_ALLES_IMMER_EIN_H */

#pragma once funktioniert bei jedem Compiler, auch wenn's
nicht Teil des Standards ist; hat sich halt durchgesetzt.

[Thomas Koenig]

G.B. <bau...@notmyhomepage.invalid> schrieb:

> On 20.11.22 10:33, Bonita Montero wrote:
>> Am 20.11.2022 um 09:32 schrieb G.B.:
>>
>>> - Einen Schalter im Präprozessor, der #if abschaltet.
>>
>> Wozu soll das gut sein ?
>
> Wozu braucht es #if, im Unterschied zu #ifdef?

#if SIZEOF_LONG > 4

z.B. kann durchaus sinnvoll sein.

[Stefan Kanthak]

"Marcel Mueller" <news.5...@spamgourmet.org> schrieb:

> Am 20.11.22 um 03:16 schrieb Bonita Montero:
>> Was auch geil sind sind hexadezimale Floating Point Zahlen:
>> #define FLT_EPSILON (1.0 - 0x1.FFFFFFFFFFFFFp-1)

AUTSCH: von IEEE-754 hat dieser Dummschwaetzer also auch KEINE Ahnung!

1. Epsilon ist der kleinste Wert, der 1.0(F) bei Addition erhoeht, also
#define FLT_EPSILON 0x1.000000p-23F // = 0x0.000002p+0F

2. FLT_ ist das Praefix fuer float alias binary32; fuer double alias
binary64 lautet es DBL_ und folglich
#define DBL_EPSILON 0x1.0000000000000p-52 // = 0x0.0000000000001p+0

wehret den Anfaengern!
Stefan
--
<https://www.duden.de/rechtschreibung/Kanthaken>

[G.B.]

Ja, aber prüfen werde ich solche Bedingungen zur Übersetzungszeit
mit Hilfe von C-Regeln, ohne #if. (Array-Größe, Eindeutigkeit
von case-Werten, ...)

Software-Konfiguration mit #if in header files andererseits hat mir
zuviel Arbeitszeit geraubt und anderen zuviel bequeme
Halbfertigkeiten verzuckert. Das geordnete Anpassen von Software
an Plattformen, wie z.B. an bestimmte Wortgrößen, leidet m.E.
unter header-Verortung in #if, den die Entwurfs-Aufgabe wird geradezu
negiert. #ifs erzeugen zudem Kopfwissen - "Ich weiß wo's #if steht,
ätsch, und was es im #Entscheidungsbaum bewirkt ;-P" - und diese
Auswirkung von cpp scheint mir was für's kommerzielle Risiko zu sein.

[G.B.]

On 20.11.22 18:59, Bonita Montero wrote:
> Am 20.11.2022 um 18:56 schrieb G.B.:
>
>> Wozu braucht es #if, im Unterschied zu #ifdef?
>

> überhaupt keine nachvollziehbare Not,
Rob Pike schildert eine Not.

Meine Not ist, dass Portieren zum Entschlüsseln von
Ensche#ifdungsdiagrammen in cpp-Form wird, denn die
Programmierer sind das Thema ad-hoc mit #if angegangen.
Also weder mit Abstraktion, noch mit Software-Konfiguration.
Wenn dabei #else ignoriert wird, ist eine Randnotiz,
aber charakteristisch.

>> #ifdef _ICH_SCHLIESSE_ALLES_IMMER_EIN_H
>> #define _ICH_SCHLIESSE_ALLES_IMMER_EIN_H
>> ...
>> #endif /* _ICH_SCHLIESSE_ALLES_IMMER_EIN_H */
>
> #pragma once funktioniert bei jedem Compiler, auch wenn's
> nicht Teil des Standards ist; hat sich halt durchgesetzt.

"Hat wer durchgesetzt?" ist die Frage. Wenn ich compiler an bequeme
Programmierer vermarkten müsste, würde ich auch die Gelegenheit
nicht versäumen, solche features anzubieten.
Schafft in der Wirkung bessere Abhäng^H^H^H^H^H^H Kundenbindung,
#once and for all.

[Bonita Montero]

Am 21.11.2022 um 09:08 schrieb G.B.:

> Meine Not ist, dass Portieren zum Entschlüsseln von
> Ensche#ifdungsdiagrammen in cpp-Form wird, denn die
> Programmierer sind das Thema ad-hoc mit #if angegangen.
> Also weder mit Abstraktion, noch mit Software-Konfiguration.
> Wenn dabei #else ignoriert wird, ist eine Randnotiz,
> aber charakteristisch.

Hä ? Ob da ein #ifdef oder ein #if defined steht ist doch gehupft wie
gesprungen, aber mit dem #if defined hat man in dem Sinne wie besagt
doch mehr Möglichkeiten.

> "Hat wer durchgesetzt?" ist die Frage. Wenn ich compiler an bequeme
> Programmierer vermarkten müsste, würde ich auch die Gelegenheit
> nicht versäumen, solche features anzubieten.

Völlig egal wer das durchgesetzt hat, es funktioniert mittlerweile
mit allen Compilern.

[G.B.]

On 21.11.22 11:01, Bonita Montero wrote:

> Hä ? Ob da ein #ifdef oder ein #if defined steht ist doch gehupft wie
> gesprungen, aber mit dem #if defined hat man in dem Sinne wie besagt
> doch mehr Möglichkeiten.

#if ...
#ifdef ...

Das sind zwei ganz verschieden ergänzbare Anfänge.
Was du Möglichkeiten nennst, nenne ich riskante Möglichkeiten
von #if mit Blick auf den langfristig supportfähigen Softwarebau.


> Völlig egal wer [#once] durchgesetzt hat, es funktioniert mittlerweile
> mit allen Compilern.

Schlimm genug.

[Bonita Montero]

Am 21.11.2022 um 13:57 schrieb G.B.:

> Das sind zwei ganz verschieden ergänzbare Anfänge.
> Was du Möglichkeiten nennst, nenne ich riskante Möglichkeiten
> von #if mit Blick auf den langfristig supportfähigen Softwarebau.

Du hastn Sockenschuss. Nen Entwickler der dem Unterschied nicht
gewachsen ist sollte eigentlich alle 3min beim Programmieren
Probleme kriegen.

>> Völlig egal wer [#once] durchgesetzt hat, es funktioniert mittlerweile
>> mit allen Compilern.

> Schlimm genug.

Ne, daran ist gar nichts problematisch.

[Thomas Koenig]

G.B. <bau...@notmyhomepage.invalid> schrieb:
> On 20.11.22 20:06, Thomas Koenig wrote:
>> G.B. <bau...@notmyhomepage.invalid> schrieb:
>>> On 20.11.22 10:33, Bonita Montero wrote:
>>>> Am 20.11.2022 um 09:32 schrieb G.B.:
>>>>
>>>>> - Einen Schalter im Präprozessor, der #if abschaltet.
>>>>
>>>> Wozu soll das gut sein ?
>>>
>>> Wozu braucht es #if, im Unterschied zu #ifdef?
>>
>> #if SIZEOF_LONG > 4
>>
>> z.B. kann durchaus sinnvoll sein.
>
> Ja, aber prüfen werde ich solche Bedingungen zur Übersetzungszeit
> mit Hilfe von C-Regeln, ohne #if. (Array-Größe, Eindeutigkeit
> von case-Werten, ...)

Wo du gerade Übersetzbarkeit und case erwähnst: Wie würdest du

switch (x) {
case sizeof(int):
...
case sizeof(long):
}

mit Hilfe von C-Regeln machen?

Aber es ist ja nicht unbedingt eine Prüfung zur Übersetzbarkeit.
Aber natürlich kann man stattdessen

#ifdef SIZEOF_LONG_GT_4

von seinem configure-Skript, im Header oder sonstwo auch immer
setzen lassen.

[Bonita Montero]

Am 21.11.2022 um 18:44 schrieb Thomas Koenig:

> Wo du gerade Übersetzbarkeit und case erwähnst: Wie würdest du
>
> switch (x) {
> case sizeof(int):
> ...
> case sizeof(long):
> }
>
> mit Hilfe von C-Regeln machen?

Hälst Du es wirklich für realistisch, dass jemand ein switch auf
die Größen von Ganzzahlen macht ?

In C++ geht das viel geiler mit if constexpr() und std::conditional_t.

[G.B.]

On 21.11.22 18:44, Thomas Koenig wrote:
>>>
>>> #if SIZEOF_LONG > 4
>>>
>>> z.B. kann durchaus sinnvoll sein.
>>
>> Ja, aber prüfen werde ich solche Bedingungen zur Übersetzungszeit
>> mit Hilfe von C-Regeln, ohne #if. (Array-Größe, Eindeutigkeit
>> von case-Werten, ...)
>
> Wo du gerade Übersetzbarkeit und case erwähnst: Wie würdest du
>
> switch (x) {
> case sizeof(int):
> ...
> case sizeof(long):
> }
>
> mit Hilfe von C-Regeln machen?

Die Softwarekonfiguration benutzt das obige dann als Behauptung
im Quelltext. (Es ist dann als Makro gefasst.)

Ziel der Behauptung ist nicht, ein einziges Programm mit Hilfe
von Fallunterscheidungen für verschiedenen Umgebungen zu fertigen.
Vielmehr versuche ich, den Übersetzer so gut wie mögich dafür
zu steuern, dass ich systematisch stimmige Fassungen gestalten
kann (muss). Ein Grund weniger für #if.

Erste Annäherung:

#define ist_neq_sz(t, n)\
switch (n) {\
case n:\
case sizeof(t):\
break;\
}

[Thomas Koenig]

G.B. <bau...@notmyhomepage.invalid> schrieb:

> On 21.11.22 18:44, Thomas Koenig wrote:
>>>>
>>>> #if SIZEOF_LONG > 4
>>>>
>>>> z.B. kann durchaus sinnvoll sein.
>>>
>>> Ja, aber prüfen werde ich solche Bedingungen zur Übersetzungszeit
>>> mit Hilfe von C-Regeln, ohne #if. (Array-Größe, Eindeutigkeit
>>> von case-Werten, ...)
>>
>> Wo du gerade Übersetzbarkeit und case erwähnst: Wie würdest du
>>
>> switch (x) {
>> case sizeof(int):
>> ...
>> case sizeof(long):
>> }
>>
>> mit Hilfe von C-Regeln machen?
>
> Die Softwarekonfiguration benutzt das obige dann als Behauptung
> im Quelltext. (Es ist dann als Makro gefasst.)

Ungefiedert bleibt mir deine Rede. Was ist eine "Behauptung"
im Zusammenhang mit C?

> Ziel der Behauptung ist nicht, ein einziges Programm mit Hilfe
> von Fallunterscheidungen für verschiedenen Umgebungen zu fertigen.
> Vielmehr versuche ich, den Übersetzer so gut wie mögich dafür
> zu steuern, dass ich systematisch stimmige Fassungen gestalten
> kann (muss).

Also verschiedene Varianten des Programms für einen Fall wie oben?

>Ein Grund weniger für #if.
>
> Erste Annäherung:
>
>#define ist_neq_sz(t, n)\
> switch (n) {\
> case n:\
> case sizeof(t):\
> break;\
> }

... was das hier auszudrücken scheint.

[Claus Reibenstein]

Thomas Koenig schrieb am 21.11.2022 um 18:44:

> Wo du gerade Übersetzbarkeit und case erwähnst: Wie würdest du
>
> switch (x) {
> case sizeof(int):
> ...
> case sizeof(long):
> }
>
> mit Hilfe von C-Regeln machen?

Ich würde erst einmal prüfen, of sizeof(int) == sizeof(long) ist. Mit
#if, natürlich ;-)

Die Alternative (ohne #if) wäre, den switch durch eine if-Kaskade zu
ersetzen:

if (x == sizeof(int)) {
...
else if (x == sizeof(long)) {
...
}

Gruß
Claus

[Bonita Montero]

Boah, was für ein Unsinn, wo es um ein Problem geht das sich
so gelöst in der Praxis nicht zeigt.

[Bonita Montero]

Oder einfach C++ nutzen, wo es if constexr() gibt, wo die geprüften
Ausdrücke immer zur Compile-Zeit analysierbar sein müssen. Dadurch
darf man im nicht ausgewerteten Zweig Code schreiben der unter ande-
ren Umständen einen Fehler erzeugen würde.

[G.B.]

On 24.11.22 13:16, Thomas Koenig wrote:

>> Die Softwarekonfiguration benutzt das obige dann als Behauptung
>> im Quelltext. (Es ist dann als Makro gefasst.)
>
> Ungefiedert bleibt mir deine Rede. Was ist eine "Behauptung"
> im Zusammenhang mit C?

Eine assertion, die vom Übersetzer bewertet wird.

>> Ziel der Behauptung ist nicht, ein einziges Programm mit Hilfe
>> von Fallunterscheidungen für verschiedenen Umgebungen zu fertigen.
>> Vielmehr versuche ich, den Übersetzer so gut wie mögich dafür
>> zu steuern, dass ich systematisch stimmige Fassungen gestalten
>> kann (muss).
>
> Also verschiedene Varianten des Programms für einen Fall wie oben?

Ja, genau.

[David Seppi]

G.B. schrieb:

> Wozu braucht es #if, im Unterschied zu #ifdef?

#if 0

... auskommentierter Code ...

#endif

--
David Seppi
1220 Wien

[Bonita Montero]

Am 20.12.2022 um 19:54 schrieb David Seppi:
> G.B. schrieb:
>
>> Wozu braucht es #if, im Unterschied zu #ifdef?
>
> #if 0
>
> ... auskommentierter Code ...
>
> #endif

Das geht auch mit #ifdef gfsdtjresiogjrex

[David Seppi]

Bonita Montero schrieb:

> Am 20.12.2022 um 19:54 schrieb David Seppi:

[...]

>> #if 0
>>
>> ... auskommentierter Code ...
>>
>> #endif
>
> Das geht auch mit #ifdef gfsdtjresiogjrex

Ja, das erkennen Editoren / IDEs aber nicht automatisch als
auskommentiert – wie auch? #if 0 funktioniert aber meistens schon.

[Thomas Koenig]

David Seppi <seppi....@gmx.at> schrieb:

Schade, dass

#define 0 1

nicht funktioniert.

[G.B.]

On 08.01.23 23:37, Thomas Koenig wrote:

> Schade, dass
>
> #define 0 1
>
> nicht funktioniert.

Das wäre etwas politisch. Aber zum Spielen eigenet sich
CPPFLAGS = -D NULL="1"

[Bonita Montero]

Am 08.01.2023 um 21:40 schrieb David Seppi:

> Ja, das erkennen Editoren / IDEs aber nicht automatisch als

> auskommentiert – ...

Meine IDEs (Visual Studio und CLion) können das beide.