Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.alt.folklore.computer > #56302 > unrolled thread

define bool ?

Back to article view | Back to de.alt.folklore.computer

Contents

  define bool ? Sebastian Barthel <naitsabes@freenet.de> - 2026-08-30 11:45 +0000
    Re: define bool ? Arno Welzel <usenet@arnowelzel.de> - 2026-08-30 17:35 +0200
      Re: define bool ? Arno Welzel <usenet@arnowelzel.de> - 2026-08-30 17:38 +0200
        Re: define bool ? Sebastian Barthel <naitsabes@freenet.de> - 2026-08-30 19:24 +0000
      Re: define bool ? Christian Weisgerber <naddy@mips.inka.de> - 2026-08-30 16:58 +0000
    Re: define bool ? Christian Weisgerber <naddy@mips.inka.de> - 2026-08-30 21:05 +0000
      Re: define bool ? Sebastian Barthel <naitsabes@freenet.de> - 2026-08-31 11:51 +0000
        Re: define bool ? Christian Weisgerber <naddy@mips.inka.de> - 2026-08-31 15:20 +0000
          Re: define bool ? "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-31 20:15 +0200
            Re: define bool ? Christian Weisgerber <naddy@mips.inka.de> - 2026-08-31 20:14 +0000
        Re: define bool ? Stefan Reuther <stefan.news@arcor.de> - 2026-08-31 19:10 +0200
          Re: define bool ? Sebastian Barthel <naitsabes@freenet.de> - 2026-09-02 14:17 +0000
            Re: define bool ? "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-09-02 18:23 +0200
            Re: define bool ? Stefan Reuther <stefan.news@arcor.de> - 2026-09-02 18:33 +0200
              Re: define bool ? Thomas Koenig <tkoenig@netcologne.de> - 2026-09-02 20:38 +0000
            Re: define bool ? Christian Weisgerber <naddy@mips.inka.de> - 2026-09-02 22:20 +0000
              Re: define bool ? Thomas Koenig <tkoenig@netcologne.de> - 2026-09-03 17:03 +0000
              Re: define bool ? Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-09-04 10:06 +0200
                Re: define bool ? Thomas Koenig <tkoenig@netcologne.de> - 2026-09-04 20:41 +0000
                  Re: define bool ? Stefan Reuther <stefan.news@arcor.de> - 2026-09-05 12:19 +0200
                    Re: define bool ? "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-09-05 13:13 +0200
                      Re: define bool ? Michael Bäuerle <michael.baeuerle@gmx.net> - 2026-09-05 14:23 +0200
                        Re: define bool ? "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-09-05 14:42 +0200
                      Re: define bool ? Stefan Reuther <stefan.news@arcor.de> - 2026-09-06 10:31 +0200
                        Re: define bool ? "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-09-06 11:32 +0200
                          Re: define bool ? Michael Bäuerle <michael.baeuerle@gmx.net> - 2026-09-06 16:45 +0000
                            %zu in printf (was: define bool ?) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-09-06 20:09 +0200
                              Re: %zu in printf Michael Bäuerle <michael.baeuerle@stz-e.de> - 2026-09-07 10:46 +0200
        Re: define bool ? "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-31 20:04 +0200

Page 1 of 2  [1] 2  Next page →

#56302 — define bool ?

Am Wed, 26 Aug 2026 19:45:15 +0200 schrubte der Humanoide Hermann Riemann:

> braucht gelegentlich Reparaturen wie Umstellung auf utf, Änderungen im C
> Standard ( const in Argumentliste und plötzlich bool Datentyp statt
> #define bool)
> bash Programme ( magick statt convert )
> Python ( kein cgi mehr .. )

Was macht man denn mit #define bool ?

Ich kenne #define TRUE -1 oder sowetwas, aber #define bool ? Ein neuer 
Datentyp entsteht davon schonmal vmtl nicht.

[toc] | [next] | [standalone]

#56305

Sebastian Barthel, 2026-08-30 13:45:

> Am Wed, 26 Aug 2026 19:45:15 +0200 schrubte der Humanoide Hermann Riemann:
> 
>> braucht gelegentlich Reparaturen wie Umstellung auf utf, Änderungen im C
>> Standard ( const in Argumentliste und plötzlich bool Datentyp statt
>> #define bool)
>> bash Programme ( magick statt convert )
>> Python ( kein cgi mehr .. )
> 
> Was macht man denn mit #define bool ?

Man definiert, dass überall, wo der Text "bool" steht, künftig "?" gilt.
Wozu das gut sein soll, erschließt sich mir nicht.

> Ich kenne #define TRUE -1 oder sowetwas, aber #define bool ? Ein neuer 
> Datentyp entsteht davon schonmal vmtl nicht.

Das entsteht mit #define sowieso nie. Das ist in C einfach nur eine
Anweisung für den Präprozessor, der *vor* der Compilierung des Codes
läuft und ein Makro erzeugt, was dann später einfach expandiert wird:

#define <Name> <Einzusetzender Text dafür>



-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#56306

Arno Welzel, 2026-08-30 17:35:

> Sebastian Barthel, 2026-08-30 13:45:
> 
>> Am Wed, 26 Aug 2026 19:45:15 +0200 schrubte der Humanoide Hermann Riemann:
>>
>>> braucht gelegentlich Reparaturen wie Umstellung auf utf, Änderungen im C
>>> Standard ( const in Argumentliste und plötzlich bool Datentyp statt
>>> #define bool)
>>> bash Programme ( magick statt convert )
>>> Python ( kein cgi mehr .. )
>>
>> Was macht man denn mit #define bool ?
> 
> Man definiert, dass überall, wo der Text "bool" steht, künftig "?" gilt.
> Wozu das gut sein soll, erschließt sich mir nicht.
> 
>> Ich kenne #define TRUE -1 oder sowetwas, aber #define bool ? Ein neuer 
>> Datentyp entsteht davon schonmal vmtl nicht.
> 
> Das entsteht mit #define sowieso nie. Das ist in C einfach nur eine
> Anweisung für den Präprozessor, der *vor* der Compilierung des Codes
> läuft und ein Makro erzeugt, was dann später einfach expandiert wird:
> 
> #define <Name> <Einzusetzender Text dafür>

Ergänzung:

Parameter sind auch möglich:

#define CURSOR(top, bottom) (((top) << 8) | (bottom))

Im Quelltext wird dann das hier:

CURSOR(5, 3)

umgewandelt zu:

(((5) << 8) | (3))

Und auch sowas geht:

#define WIDTH       80
#define LENGTH      ( WIDTH + 10 )

-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#56308

Am Sun, 30 Aug 2026 17:38:22 +0200 schrubte der Humanoide Arno Welzel:

> Arno Welzel, 2026-08-30 17:35:
> 
>> Sebastian Barthel, 2026-08-30 13:45:
>> 
>>> Am Wed, 26 Aug 2026 19:45:15 +0200 schrubte der Humanoide Hermann
>>> Riemann:
>>>
>>>> braucht gelegentlich Reparaturen wie Umstellung auf utf, Änderungen
>>>> im C Standard ( const in Argumentliste und plötzlich bool Datentyp
>>>> statt #define bool)
>>>> bash Programme ( magick statt convert )
>>>> Python ( kein cgi mehr .. )
>>>
>>> Was macht man denn mit #define bool ?
>> 
>> Man definiert, dass überall, wo der Text "bool" steht, künftig "?"
>> gilt.
>> Wozu das gut sein soll, erschließt sich mir nicht.
>> 
>>> Ich kenne #define TRUE -1 oder sowetwas, aber #define bool ? Ein neuer
>>> Datentyp entsteht davon schonmal vmtl nicht.
>> 
>> Das entsteht mit #define sowieso nie. Das ist in C einfach nur eine
>> Anweisung für den Präprozessor, der *vor* der Compilierung des Codes
>> läuft und ein Makro erzeugt, was dann später einfach expandiert wird:
>> 
>> #define <Name> <Einzusetzender Text dafür>
> 
> Ergänzung:
> 
> Parameter sind auch möglich:
> 
> #define CURSOR(top, bottom) (((top) << 8) | (bottom))
> 
> Im Quelltext wird dann das hier:
> 
> CURSOR(5, 3)
> 
> umgewandelt zu:
> 
> (((5) << 8) | (3))
> 
> Und auch sowas geht:
> 
> #define WIDTH       80
> #define LENGTH      ( WIDTH + 10 )

Ja, soweit kenn ich das auch. Das ist ja gelegentlich auch ganz 
praktisch. 

Aber das mit dem Fragezeichen ... das war eigentlich nur das Fragezeichen 
vom Satzende, gehörte nicht zur Definition. Ich hatte mich halt gefragt, 
was (Zitat s.o.) eigentlich mit dem #define bool gemeint gewesen sein 
könnte. Das macht in der Form wenig Sinn - IMHO.

VG,
SBn

[toc] | [prev] | [next] | [standalone]

#56307

On 2026-08-30, Arno Welzel <usenet@arnowelzel.de> wrote:

>> Ich kenne #define TRUE -1 oder sowetwas, aber #define bool ? Ein neuer 
>> Datentyp entsteht davon schonmal vmtl nicht.
>
> Das entsteht mit #define sowieso nie. Das ist in C einfach nur eine
> Anweisung für den Präprozessor, der *vor* der Compilierung des Codes
> läuft und ein Makro erzeugt, was dann später einfach expandiert wird:

Wenn wir hier schon C erklären: Vielleicht etwas überraschender
ist, dass das Schlüsselwort typedef ebenfalls keinen eigenen Datentyp
erzeugt, sondern nur einen Alias.

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de

[toc] | [prev] | [next] | [standalone]

#56309

On 2026-08-30, Sebastian Barthel <naitsabes@freenet.de> wrote:

> Was macht man denn mit #define bool ?

$ egrep -R '^#[[:space:]]*define[[:space:]]+bool[[:space:]]' /usr/include
/usr/include/ncurses.h:#define bool NCURSES_BOOL
/usr/include/stdbool.h:#define bool _Bool
/usr/include/stdbool.h:#define bool     bool
/usr/include/sys/types.h:#define bool _Bool

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de

[toc] | [prev] | [next] | [standalone]

#56313

Am Sun, 30 Aug 2026 21:05:01 +0000 schrubte der Humanoide Christian
Weisgerber:

> On 2026-08-30, Sebastian Barthel <naitsabes@freenet.de> wrote:
> 
>> Was macht man denn mit #define bool ?
> 
> $ egrep -R '^#[[:space:]]*define[[:space:]]+bool[[:space:]]'
> /usr/include

> /usr/include /usr/include/ncurses.h:#define bool NCURSES_BOOL
> /usr/include/stdbool.h:#define bool _Bool
> /usr/include/stdbool.h:#define bool     bool
> /usr/include/sys/types.h:#define bool _Bool

OK. Das ist mal eine schöne Suche. Besonders hübsch ist ja das 3te 
Beispiel ... . :)

Bei mir findet sich damit u.a. auch in slcurses.h (zu slang)

/* These have no place in C */
#define TRUE 1
#define FALSE 0
#define bool int

Gruß, SBn

[toc] | [prev] | [next] | [standalone]

#56318

On 2026-08-31, Sebastian Barthel <naitsabes@freenet.de> wrote:

>> $ egrep -R '^#[[:space:]]*define[[:space:]]+bool[[:space:]]'
>> /usr/include
>
>> /usr/include /usr/include/ncurses.h:#define bool NCURSES_BOOL
>> /usr/include/stdbool.h:#define bool _Bool
>> /usr/include/stdbool.h:#define bool     bool
>> /usr/include/sys/types.h:#define bool _Bool
>
> OK. Das ist mal eine schöne Suche. Besonders hübsch ist ja das 3te 
> Beispiel ... . :)

C hat(te) halt von Haus aus keinen boolschen Datentyp. Manche Leute
wollen sowas nachbilden. Obige Suchtreffer sind nur ein Ausgangspunkt
um dann nachzuschauen, wie das eigentlich gelöst wurde, z.B.

    /* `_Bool' type must promote to `int' or `unsigned int'. */
    typedef enum {
            false = 0,
            true = 1
    } _Bool;

    /* And those constants must also be available as macros. */
    #define false   false
    #define true    true

    /* User visible type `bool' is provided as a macro which may be
    redefined */
    #define bool _Bool

> Bei mir findet sich damit u.a. auch in slcurses.h (zu slang)
>
> /* These have no place in C */
> #define TRUE 1
> #define FALSE 0
> #define bool int

Ja, das ist die Billiglösung.

Ich habe spaßeshalber den grep-Aufruf mal über die ausgepackten
Quellen (482 GB) für die Third-Party-Pakete für OpenBSD laufen
lassen, was allerhand zu Tage fördert. Die 1646 Zeilen bzw. 160 kB
poste ich jetzt aber nicht.

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de

[toc] | [prev] | [next] | [standalone]

#56323

On 2026-08-31 17:20, Christian Weisgerber <naddy@mips.inka.de> wrote:
> C hat(te) halt von Haus aus keinen boolschen Datentyp. Manche Leute
> wollen sowas nachbilden. Obige Suchtreffer sind nur ein Ausgangspunkt
> um dann nachzuschauen, wie das eigentlich gelöst wurde, z.B.
>
>     /* `_Bool' type must promote to `int' or `unsigned int'. */
>     typedef enum {
>             false = 0,
>             true = 1
>     } _Bool;

Ist das echter Code oder hast Du den gerade so ad hoc hingeschrieben?

Ich glaube, dass der so nicht korrekt ist:

Als user-geschriebener Code ist er nicht erlaubt, weil Identifier, die
mit einem Underscore und einem Großbuchstaben beginnen, reserviert sind.

Als Teil einer Systemlibrary wäre er IMHO nicht korrekt, weil _Bool ein
Keyword sein muss (seit C99) und man das nicht mit einem typedef faken
kann (für ein Gegenbeispiel müsste ich aber etwas länger nachdenken).

        hjp

[toc] | [prev] | [next] | [standalone]

#56326

On 2026-08-31, Peter J. Holzer <hjp-usenet4@hjp.at> wrote:

>>     /* `_Bool' type must promote to `int' or `unsigned int'. */
>>     typedef enum {
>>             false = 0,
>>             true = 1
>>     } _Bool;
>
> Ist das echter Code oder hast Du den gerade so ad hoc hingeschrieben?

Ein Schnipsel aus /usr/include/stdbool.h auf OpenBSD.

> Als Teil einer Systemlibrary wäre er IMHO nicht korrekt, weil _Bool ein
> Keyword sein muss (seit C99) und man das nicht mit einem typedef faken
> kann (für ein Gegenbeispiel müsste ich aber etwas länger nachdenken).

Er steht im Vor-C99-Zweig.
https://codeberg.org/OpenBSD/src/src/branch/master/include/stdbool.h

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de

[toc] | [prev] | [next] | [standalone]

#56321

Am 31.08.2026 um 13:51 schrieb Sebastian Barthel:
> Am Sun, 30 Aug 2026 21:05:01 +0000 schrubte der Humanoide Christian
> Weisgerber:
>> /usr/include /usr/include/ncurses.h:#define bool NCURSES_BOOL
>> /usr/include/stdbool.h:#define bool _Bool
>> /usr/include/stdbool.h:#define bool     bool
>> /usr/include/sys/types.h:#define bool _Bool
> 
> OK. Das ist mal eine schöne Suche. Besonders hübsch ist ja das 3te 
> Beispiel ... . :)

C99 sagt, dass man mit "#include <stdbool.h>" ein Makro namens "bool"
bekommt.

Offensichtlich hat dann jemand eine Variante des Headers gebaut, die
(für C++?) ebenfalls das Makro bereitstellt, um Leute zu befriedigen,
die "#ifdef bool" schreiben.

Allerdings fordert der C++-11-Standard, dass "#include <stdbool.h>" eben
*kein* bool-Makro definiert, und C++20 sagt dann: lass den Quatsch, kein
Mensch inkludert in C++ <stdbool.h>.


  Stefan

[toc] | [prev] | [next] | [standalone]

#56334

Am Mon, 31 Aug 2026 19:10:57 +0200 schrubte der Humanoide Stefan Reuther:

> Am 31.08.2026 um 13:51 schrieb Sebastian Barthel:
>> Am Sun, 30 Aug 2026 21:05:01 +0000 schrubte der Humanoide Christian
>> Weisgerber:
>>> /usr/include /usr/include/ncurses.h:#define bool NCURSES_BOOL
>>> /usr/include/stdbool.h:#define bool _Bool
>>> /usr/include/stdbool.h:#define bool     bool
>>> /usr/include/sys/types.h:#define bool _Bool
>> 
>> OK. Das ist mal eine schöne Suche. Besonders hübsch ist ja das 3te
>> Beispiel ... . :)
> 
> C99 sagt, dass man mit "#include <stdbool.h>" ein Makro namens "bool"
> bekommt.

Offensichtlich ist das ja auch so. Es ist wohl ein wenig "krude", aber 
sieht so aus als würde es funktionieren.
 
> Offensichtlich hat dann jemand eine Variante des Headers gebaut, die
> (für C++?) ebenfalls das Makro bereitstellt, um Leute zu befriedigen,
> die "#ifdef bool" schreiben.
> 
> Allerdings fordert der C++-11-Standard, dass "#include <stdbool.h>" eben
> *kein* bool-Makro definiert, und C++20 sagt dann: lass den Quatsch, kein
> Mensch inkludert in C++ <stdbool.h>.

Spannend an der Geschichte ist ja irgendwie auch, daß sie (T&R) das 
anscheinend irgendwie gar nicht vorgesehen haben, oder nicht gebraucht. 
Dabei benutzt das C selbst ja eigentlich ständig solche 
"Wahrheitsauswertungen". Und die dazugehörigen Symbole gibt es ja 
allesamt auch ( ==, !=, &&, || etc.) und die Auswertungen werden auch 
rege benutzt (bei jedem if etwa).

[toc] | [prev] | [next] | [standalone]

#56335

On 2026-09-02 16:17, Sebastian Barthel <naitsabes@freenet.de> wrote:
> Am Mon, 31 Aug 2026 19:10:57 +0200 schrubte der Humanoide Stefan Reuther:
>> C99 sagt, dass man mit "#include <stdbool.h>" ein Makro namens "bool"
>> bekommt.
[...]
>> Offensichtlich hat dann jemand eine Variante des Headers gebaut, die
>> (für C++?) ebenfalls das Makro bereitstellt, um Leute zu befriedigen,
>> die "#ifdef bool" schreiben.
>> 
>> Allerdings fordert der C++-11-Standard, dass "#include <stdbool.h>" eben
>> *kein* bool-Makro definiert, und C++20 sagt dann: lass den Quatsch, kein
>> Mensch inkludert in C++ <stdbool.h>.

In C23 ähnlich.


> Spannend an der Geschichte ist ja irgendwie auch, daß sie (T&R) das 
> anscheinend irgendwie gar nicht vorgesehen haben, oder nicht gebraucht. 
> Dabei benutzt das C selbst ja eigentlich ständig solche 
> "Wahrheitsauswertungen". Und die dazugehörigen Symbole gibt es ja 
> allesamt auch ( ==, !=, &&, || etc.) und die Auswertungen werden auch 
> rege benutzt (bei jedem if etwa).

Ja, aber die Operatoren liefern alle ein Ergebnis vom Typ »int«. Und bei
if, while, etc. lautet das Kriterium nicht wahr oder falsch, sondern
nicht null oder null. Entsprechend funktioniert das auch mit allen
Typen, die den Wert 0 annehmen können.

        hjp.

[toc] | [prev] | [next] | [standalone]

#56338

Am 02.09.2026 um 16:17 schrieb Sebastian Barthel:
> Am Mon, 31 Aug 2026 19:10:57 +0200 schrubte der Humanoide Stefan Reuther:
>> Allerdings fordert der C++-11-Standard, dass "#include <stdbool.h>" eben
>> *kein* bool-Makro definiert, und C++20 sagt dann: lass den Quatsch, kein
>> Mensch inkludert in C++ <stdbool.h>.
> 
> Spannend an der Geschichte ist ja irgendwie auch, daß sie (T&R) das 
> anscheinend irgendwie gar nicht vorgesehen haben, oder nicht gebraucht. 
> Dabei benutzt das C selbst ja eigentlich ständig solche 
> "Wahrheitsauswertungen". Und die dazugehörigen Symbole gibt es ja 
> allesamt auch ( ==, !=, &&, || etc.) und die Auswertungen werden auch 
> rege benutzt (bei jedem if etwa).

(ich nehme an, du meinst K&R)

Das dürfte zum Zeitpunkt der Einführung von C Stand der Technik gewesen
sein. Die Microsoft-BASICs hatten auch keinen booleschen Datentyp.

Die Erkenntnis, dass starke Typisierung eine gute Sache ist, kam dann
halt erst mit der Zeit. Ich meine, in den ersten Versionen von C konnte
man auch Pointer beliebig zuweisen, und Struktur-Member-Namen waren eine
globale Angelegenheit (weswegen die Member der 'struct stat' alle mit
'st_' anfangen, um sie von den Membern anderer Strukturen zu
unterscheiden). In C hat man das dann langsam etwas verschärft - aber
über den Umweg über void* kann man immer noch alles zuweisen. In C++ hat
man es weiter verschärft.


  Stefan

[toc] | [prev] | [next] | [standalone]

#56341

Stefan Reuther <stefan.news@arcor.de> schrieb:
> Am 02.09.2026 um 16:17 schrieb Sebastian Barthel:
>> Am Mon, 31 Aug 2026 19:10:57 +0200 schrubte der Humanoide Stefan Reuther:
>>> Allerdings fordert der C++-11-Standard, dass "#include <stdbool.h>" eben
>>> *kein* bool-Makro definiert, und C++20 sagt dann: lass den Quatsch, kein
>>> Mensch inkludert in C++ <stdbool.h>.
>> 
>> Spannend an der Geschichte ist ja irgendwie auch, daß sie (T&R) das 
>> anscheinend irgendwie gar nicht vorgesehen haben, oder nicht gebraucht. 
>> Dabei benutzt das C selbst ja eigentlich ständig solche 
>> "Wahrheitsauswertungen". Und die dazugehörigen Symbole gibt es ja 
>> allesamt auch ( ==, !=, &&, || etc.) und die Auswertungen werden auch 
>> rege benutzt (bei jedem if etwa).
>
> (ich nehme an, du meinst K&R)
>
> Das dürfte zum Zeitpunkt der Einführung von C Stand der Technik gewesen
> sein. Die Microsoft-BASICs hatten auch keinen booleschen Datentyp.

FORTRAN IV (Basis von FORTRAN 66) hatte schon LOGICAL, und
Algol 60 auch.  BCPL, als vereinfachter Algol-Abkömmling,
hatte nur einen "Typ" von Wortgröße, der dann als int oder
pointer oder... verwendet werden konnte.  Da war dann 0 "wahr"
und -1 "falsch", und das wurde dann in B/C zu "nonzero is true"
abgewandelt, vermutlich weil die PDP-11 nach jeder arithmetischen
Instruktion und auch nach jedem Load die Flags gesetzt hat,
auch das Zero-Flag.  Bei so einer Architektur ist auch eine
Nullterminierung von Strings eine sehr gute Idee, spart
Instruktionen.

-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

[toc] | [prev] | [next] | [standalone]

#56343

On 2026-09-02, Sebastian Barthel <naitsabes@freenet.de> wrote:

>> Allerdings fordert der C++-11-Standard, dass "#include <stdbool.h>" eben
>> *kein* bool-Makro definiert, und C++20 sagt dann: lass den Quatsch, kein
>> Mensch inkludert in C++ <stdbool.h>.
>
> Spannend an der Geschichte ist ja irgendwie auch, daß sie (T&R) das 
> anscheinend irgendwie gar nicht vorgesehen haben, oder nicht gebraucht. 

C arbeitet klassischerweise mit den Typen int, unsigned int, long,
unsigned long, double. Mit denen wird gerechnet. Wenn möglich mit
int. Die kürzeren Typen char, short und float sind reine Speichertypen.
Man kann sie zuweisen, aber wenn sie in Ausdrücken auftauchen,
werden sie erstmal zu int bzw. double erweitert. Selbst Zeichenkonstanten
wie 'a' oder '\n' haben Typ int, _nicht_ char.

So gesehen ist es nicht verwunderlich, dass man int auch für boolsche
Logik verwendet. Ich nehme an, es bildet auch die Prozessorbefehle
der PDP-11 ab.

Wenn der Platz ganz knapp ist, gibt es Bitfelder, wo man Felder zu
n Bits in ein struct quetschen kann. Prinzipiell geht das auch mit
1-Bit-Feldern. War zu der Zeit, als man Magnetringe auf Drähte
fädelte, wichtiger als heute.

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de

[toc] | [prev] | [next] | [standalone]

#56346

Christian Weisgerber <naddy@mips.inka.de> schrieb:
> On 2026-09-02, Sebastian Barthel <naitsabes@freenet.de> wrote:
>
>>> Allerdings fordert der C++-11-Standard, dass "#include <stdbool.h>" eben
>>> *kein* bool-Makro definiert, und C++20 sagt dann: lass den Quatsch, kein
>>> Mensch inkludert in C++ <stdbool.h>.
>>
>> Spannend an der Geschichte ist ja irgendwie auch, daß sie (T&R) das 
>> anscheinend irgendwie gar nicht vorgesehen haben, oder nicht gebraucht. 
>
> C arbeitet klassischerweise mit den Typen int, unsigned int, long,
> unsigned long, double. Mit denen wird gerechnet. Wenn möglich mit
> int. Die kürzeren Typen char, short und float sind reine Speichertypen.
> Man kann sie zuweisen, aber wenn sie in Ausdrücken auftauchen,
> werden sie erstmal zu int bzw. double erweitert. Selbst Zeichenkonstanten
> wie 'a' oder '\n' haben Typ int, _nicht_ char.
>
> So gesehen ist es nicht verwunderlich, dass man int auch für boolsche
> Logik verwendet. Ich nehme an, es bildet auch die Prozessorbefehle
> der PDP-11 ab.

Dadurch, dass ein MOV oder MOVB auch das N- und Z-Flag setzt,
war das eine recht naheliegende Entscheidung.  "nonzero is true"
ist da eine logische Wahl.

Z.B. wäre strcpy sowas wie

loop:
	movb	(r1)+,(r0)+
	bne	loop

was die Übersetzung von

	while (*a++ = *b++)
		;

in zwei Assemblerbefehle ist.

> Wenn der Platz ganz knapp ist, gibt es Bitfelder, wo man Felder zu
> n Bits in ein struct quetschen kann. Prinzipiell geht das auch mit
> 1-Bit-Feldern. War zu der Zeit, als man Magnetringe auf Drähte
> fädelte, wichtiger als heute.

Interessanterweise waren die alten Architekturen häufig nicht
nur klein und langsam, sondern auch noch verschwenderisch mit dem
wenigen Platz, den sie hatten.  Fehlte halt jede Menge an Erfahrung
mit der Optimierung.

-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

[toc] | [prev] | [next] | [standalone]

#56347

Am 03.09.26 um 00:20 schrieb Christian Weisgerber:

> Wenn der Platz ganz knapp ist, gibt es Bitfelder, wo man Felder zu
> n Bits in ein struct quetschen kann. Prinzipiell geht das auch mit
> 1-Bit-Feldern. War zu der Zeit, als man Magnetringe auf Drähte
> fädelte, wichtiger als heute.

Wenn ein bit geschrieben wird, wir von der hardware dafür
erst ein Maschinen Wort (1 oder 2 oder 4 byte )geladen,
das Bit in einem ( extra?) Register ersetzt.
und dann das Maschinenwort gespeichert.

Bei extremen Platzsparen wegen cache laden und speichern,
mag das wieder anders aussehen.

Beim Bit Manipulieren ( Farben hantieren ) 3*10 Bit bei Grafik
sieht das anders aus.

-----

Mal sehen wann es short_bool  bool_16t etc gibt.

Ich vermute erhebliche Handarbeit wenn mit char
nicht mehr gerechnet wird wie mit int ( >='a %% <='z')

Darf man in C11 bool addieren und subtrahieren?

( statt a||b a+b verwenden? )


-- 
<https://www.hermann-riemann.de> bzw.:
<https://www.hermann-riemann.eu/de>

[toc] | [prev] | [next] | [standalone]

#56349

Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb:

> Mal sehen wann es short_bool  bool_16t etc gibt.

Bei Fortran gibt es typischerweise verschiedene LOGICAL-Typen,
damit man die mittels EQUIVALENCE mit den verschiedenen INTEGER
oder REAL verheiraten kann.

Bei bool in C habe ich noch keine Implementierung gesehen, die nicht
ein 8-bit-Datum verwendet hat, mit den Werten 0 und 1.

> Ich vermute erhebliche Handarbeit wenn mit char
> nicht mehr gerechnet wird wie mit int ( >='a %% <='z')

In Fortran kann man characters auch direkt vergleichen, aber
nicht direkt mit ihren Zahlenwerten rechnen.

> Darf man in C11 bool addieren und subtrahieren?
>
> ( statt a||b a+b verwenden? )

Kann man. a + b ist ein int, und das wird mit "nonzero is true"
zu 1 umgewandelt.  Allerdings gibt es dann keine "short circuit
evaluation".

-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

[toc] | [prev] | [next] | [standalone]

#56350

Am 04.09.2026 um 22:41 schrieb Thomas Koenig:
> Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb:
>> Mal sehen wann es short_bool  bool_16t etc gibt.
> 
> Bei Fortran gibt es typischerweise verschiedene LOGICAL-Typen,
> damit man die mittels EQUIVALENCE mit den verschiedenen INTEGER
> oder REAL verheiraten kann.
> 
> Bei bool in C habe ich noch keine Implementierung gesehen, die nicht
> ein 8-bit-Datum verwendet hat, mit den Werten 0 und 1.

Na, dann hast du aber noch nicht viel gesehen :-)

'enum bool { false, true }' gibt normalerweise einen 'int', wie groß der
auch immer sein mag.


  Stefan

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | de.alt.folklore.computer

csiph-web