ein Bit im Byte auf 0 prüfen

wenn ich groß bin schrieb:
> Hallo, für nen PIC16 soll wenn Bit 1 in mybyte auf 0 ist Aktion
> ausgelöst werden. Richtig so? oder besser anders?if (~mybyte & 0x02)
> alarm()

Geht so. Ich würde es anders schreiben:

1

if (~(mybyte & 2) 

2

{

3

  alarm()

4

}

Die Zusätzliche Klammer macht es für mich leichter lesbar. Wenn ich zwei 
Bits anteste, dann so:

1

if (~(mybyte & (2 | 4)) 

2

{

3

  alarm()

4

}

oder

1

if (~(mybyte & ((1<<1) | (1<<2)) 

2

{

3

  alarm()

4

}

(1<<2) bedeutet für mich so viel wie "bit 2". Ich habe mich an diese 
Darstellungsform gewöhnt.

Stefanus F. schrieb:
> Geht so. Ich würde es anders schreiben:
> if (~(mybyte & 2)

Eine Dezimalzahlen ist nun wirklich die übelste Schreibweise für eine 
Bitmaske. Oder möchtest du, falls das oberste Bit getestet werden soll, 
etwa (mybte & 128) schreiben?

Klarer als die Hexschreibweise wäre wohl noch (mybyte & (1<<7)), wenn 
man z.B. das siebte Bit prüfen möchte.

Wolfgang schrieb:
> Oder möchtest du, falls das oberste Bit getestet werden soll,
> etwa (mybte & 128) schreiben?
> Klarer als die Hexschreibweise wäre wohl noch (mybyte & (1<<7)), wenn
> man z.B. das siebte Bit prüfen möchte.

Erst lesen, dann meckern. Ich habe genau das so empfohlen.

Rufus Τ. F. schrieb:
> d.h. den logischen und nicht den bitweisen Negationsoperator zu
> verwenden.

Oh ja, das wollte ich eigentlich schreiben. Danke Rufus.

> Die "Verbesserung" von Stefanus ist FALSCH!

Daran ist gar nichts falsch. Au ch nicht an dem, was ich eigentlich 
schrieben wollte:

> if (!(mybyte & 2)

> ~(mbyte & 2)

> Was ist daran "falsch"?

Der Ausdruck ist immer wahr: (mbyte&2) ist 0 oder 2 und sowohl ~0 als 
auch ~2 ist != 0.


PS: Btw, für einzelne Bits benutze ich immer die vom OP benutzte 
Schreibweise ~mbyte & 2, sie hat am wenigsten visuellen Ballast.

foobar schrieb:
> Der Ausdruck ist immer wahr: (mbyte&2) ist 0 oder 2 und sowohl ~0 als
> auch ~2 ist != 0.

Facepalm. Jetzt habe ich es auch geschnallt. Das ist mir jetzt peinlich.

wenn ich groß bin schrieb:
> Hallo, für nen PIC16 soll wenn Bit 1 in mybyte auf 0 ist Aktion
> ausgelöst werden. Richtig so? oder besser anders?

1

if (~mybyte & 0x02)  alarm()

Logische Bedingungen sollten generell auch solche sein. Es funktioniert 
so wie du es geschrieben hast zwar, aber schöner (und auch richtiger) 
ist m.M.

1

if((mbyte & 0x02U) == 0U) { alarm(); }

oder

1

if((mbyte & 0x02U) != 0U) { alarm(); }

Je nachdem ob das bit gesetzt oder nicht gesetzt sein soll.
Hat auch den Vorteil, dass nicht versehentlich falsche Bits durch 
falsches negieren rausgepickt werden. Wie schnell das geht sieht man ja 
weiter oben im Thread. So sieht man sofort in der Klammer weleches Bit 
(oder auch mehrere) gemeint ist und rechts davon auch sofort, ob es 
gesetzt oder nicht gesetzt sein soll.

Stefanus F. schrieb:

> foobar schrieb:
>> Der Ausdruck ist immer wahr: (mbyte&2) ist 0 oder 2
>> und sowohl ~0 als auch ~2 ist != 0.
>
> Facepalm. Jetzt habe ich es auch geschnallt. Das ist
> mir jetzt peinlich.

Was genau ist Dir jetzt peinlich?

Dass Du Dich dem 1337 haxor kid im C Obfuscation
Contest geschlagen geben musstest?

Oder dass es selbst im 3. Jahrtaustend IMMER NOCH
NICHT zur Normalität geworden ist, logische Bedingungen
vollständig hinzuschreiben?

Egon D. schrieb:
> Was genau ist Dir jetzt peinlich?

Dass ich behauptet hatte, es würde mit "~" ebenso funktionieren, wie mit 
"!".

> if (~(mybyte & 2)
> if (!(mybyte & 2)

> Dass Du Dich dem 1337 haxor kid im C Obfuscation
> Contest geschlagen geben musstest?

:-)

Ich hätte das einfach vorher in eine IDE eintippen sollen, bevor ich es 
veröffentliche. Dann hätte ich wenigstens die abschließenden Klammern 
nicht vergessen. Ich habe mich zu sehr an die automatische 
Eingabe-Ergänzung der IDE gewöhnt.

Das ist genau so ein Thema wie Rechtschreibkorrektur, Taschenrechner für 
triviale Aufgaben, Google für jeden Quatsch benutzen usw. Wir werden 
stroh-dumm zugrunde gehen, wenn wir uns zunehmend auf unsere Computer 
verlassen und dabei unser Hirn erweichen lassen.

Aber stroh-summ sein und den Computer nicht zu nutzen, das ist eine 
richtig peinliche Kombination.

wenn ich groß bin schrieb:
> Richtig so? oder besser anders?if (~mybyte & 0x02) alarm()

Alternativen:

a) Straight forward

1

if (0U == (mybyte & (1U << 1)))

2

{

3

   // do something

4

}

b) Macro

1

#define BIT(x, n) ((0U != ((unsigned)(x) & (1U << (n)))) ? 1U : 0U)

2

3

if (0U == BIT(mybyte, 1))

4

{

5

   // do something

6

}

c) Bitfeld

Für Register kann auch ein Bitfeld in einer union überlagert werden. Das 
Mapping von LSb/MSb auf den zu Grunde liegenden Datentyp im Bitfeld ist 
architekturabhängig, muss also entsprechend der Architektur gewählt 
werden.

1

struct bitfeld_bit

2

{

3

   uint8_t bit0 : 1;

4

   uint8_t bit1 : 1;

5

   // ...

6

   uint8_t bit31 : 1;

7

};

8

9

union bitfeld_all

10

{

11

   uint8_t all;

12

   union bitfeld_bit bit;

13

};

14

15

typedef union bitfeld_all bitfeld;

16

17

void f(bitfeld mybyte)

18

{

19

   if (0U == mybyte.bit.bit1)

20

   {

21

      // do something

22

   }

23

}

Stefanus F. schrieb:

> Egon D. schrieb:
>> Was genau ist Dir jetzt peinlich?
>
> Dass ich behauptet hatte, es würde mit "~" ebenso
> funktionieren, wie mit "!".

Du beantwortest meine spöttische Frage sachlich.
Respekt.


>> if (~(mybyte & 2)
>> if (!(mybyte & 2)
>
>> Dass Du Dich dem 1337 haxor kid im C Obfuscation
>> Contest geschlagen geben musstest?
>
> :-)
>
> Ich hätte das einfach vorher in eine IDE eintippen sollen,
> bevor ich es veröffentliche. Dann hätte ich wenigstens
> die abschließenden Klammern nicht vergessen. Ich habe
> mich zu sehr an die automatische Eingabe-Ergänzung der
> IDE gewöhnt.
>
> Das ist genau so ein Thema wie Rechtschreibkorrektur,
> Taschenrechner für triviale Aufgaben, Google für jeden
> Quatsch benutzen usw. Wir werden stroh-dumm zugrunde
> gehen, wenn wir uns zunehmend auf unsere Computer
> verlassen und dabei unser Hirn erweichen lassen.

Okay, den Teil verstehe ich; das sehe ich in vielen
Punkte ähnlich.

Was ich aber nicht verstehe, das ist: Warum schreibt man
die Bedingung nicht einfach vollständig?

1

if((mybyte & (1<<1)) == 0) { 

2

  alarm(); 

3

}

Woher kommt die unausrottbare, nachhaltige, tief ver-
wurzelte Aversion der C-Programmierer gegen klare,
vollständige Schreibweisen?
Das betrifft ja auch den TO, denn irgendwo muss er
ja gelernt haben, dass es angeblich guter Stil ist,
einen arithmetischen Ausdruck als logische Bedingung
zu verwenden.

Ich frage das nicht primär, weil ich stänkern will,
sondern weil es mich wirklich interessiert.

Ich kann mir nämlich -- trotz ansonsten halbwegs durch-
schnittlicher Intelligenz -- um's Verrecken nicht merken,
wie "true" und "false" in C genau codiert werden, und was
noch viel schlimmer ist: Ich sehe inzwischen auch nicht
mehr ein, warum ich mein Hirn mit solchem Mist belasten
soll.

Warum machen sich C-Programmierer so gern von solchen
eigentlich irrelevanten Interna abhängig?

Ihr habt hier ja mehrere mögliche Lösungsvorschläge vorgestellt.

x^y schrieb:
> #define BIT(x, n) ((0U != ((unsigned)(x) & (1U << (n)))) ? 1U : 0U)

Ist es nicht besser für solche Ausdrucke eine inline-Funktion zu 
benutzen?

Oder ist diese Idee hier (im embedded Bereich) fehl am Platze?

Falk B. schrieb:

> Egon D. schrieb:
>> Woher kommt die unausrottbare, nachhaltige, tief
>> verwurzelte Aversion der C-Programmierer gegen
>> klare, vollständige Schreibweisen?
>
> Weil die Auswertung logischer Ausdrücke immer
> implizit ist

Verstehe ich nicht. Was soll das bedeuten?


> und Programmierer schreibfaul sind.

Hier verstehe ich zwar die Worte und ihren Sinn,
nicht aber die Realität, die sie beschreiben. Meine
Frage ist ja gerade: Wieso lassen C-Programmierer
ums Verrecken nicht von ihrer Schreibfaulheit ab,
selbst wenn sie erwiesenermaßen Fehler verursacht?


> Nicht umsonst werden diverse Sprachen ala Pascal,
> VHDL etc. als "geschwätzig" bezeichnet.

"Nicht umsonst" ist aber etwas ganz anderes als
"völlig zu Recht".

Pascal IST geschwätzig -- aber ganz sicher ist nicht
die Existenz eines booleschen Datentyps die Ursache.


>> Das betrifft ja auch den TO, denn irgendwo muss er
>> ja gelernt haben, dass es angeblich guter Stil ist,
>> einen arithmetischen Ausdruck als logische Bedingung
>> zu verwenden.
>
> Das ist in C auch vollkommen legitim.

Es ist auch im Alltag völlig legitim, sich mit der
Axt in den Fuß zu hauen.

Es ging mir aber nicht darum, ob es legitim oder
illegitim ist, sondern darum, dass es schlechter
Stil ist.


>> noch viel schlimmer ist: Ich sehe inzwischen auch
>> nicht mehr ein, warum ich mein Hirn mit solchem
>> Mist belasten soll.
>
> Dein Problem.

Durchaus nicht. Wenn C-Programmierer ihr Hirn mit
großen Mengen irrelevanten Mistes belasten, kann man
daraus folgern, dass sie deutlich weniger Kapazität
für Relevantes haben.


>> Warum machen sich C-Programmierer so gern von solchen
>> eigentlich irrelevanten Interna abhängig?
>
> Es ist elementarer Bestandteil der Sprache. Das muss
> man nicht mögen, ist aber so.

Du demonstrierst exemplarisch das, was ich nicht verstehe:

Es ist doch absolut irrelevant , ob die Sprache die
Kurzschreibweise erlaubt oder nicht. Es besteht doch
keinerlei Zwang, jede auch noch so idiotische Abkürzung
auch zu benutzen!


> Nimm halt Pascal oder was ähnliches ;-)

Och bitte, nicht schon wieder "Geh' doch nach drüben!"
Wenn das ginge, würde ich es tun.

zitter_ned_aso schrieb:
> Ist es nicht besser für solche Ausdrucke eine inline-Funktion zu
> benutzen?
>
> Oder ist diese Idee hier (im embedded Bereich) fehl am Platze?

Doch, das kann man machen. Evtl. sowas hier:

1

static inline uint32_t BIT32(uint32_t x, size_t n)

2

{

3

   if (n >= 32)

4

      return 0;

5

   return BIT(x, n);

6

}

7

8

static inline uint16_t BIT16(uint16_t x, size_t n)

9

{

10

   if (n >= 16)

11

      return 0;

12

   return BIT(x, n);

13

}

14

15

static inline uint8_t BIT8(uint8_t x, size_t n)

16

{

17

   if (n >= 8)

18

      return 0;

19

   return BIT(x, n);

20

}

Es ist lediglich zu beachten, dass trotz "inline" es dem Compiler 
überlassen ist, ob er tatsächlich ein Inlining vornimmt. Beim GCC kann 
man den Holzhammer holen und mit __attribute__((inline)) nachhelfen.

Templates würden sich theoretisch noch anbieten, diese können aber 
natürlich nur in C++ Code eingebunden werden.

Haben die Forentrolle von der Arge jetzt ne Umschulung zum C Basher 
bezahlt bekommen?

Udo S. schrieb:
> Komm bleib einfach bei deinem BASCOM. Wenn man von etwas keine Ahnung
> hat einfach die Finger mal still halten.

Kannst du dich entscheiden? Bleiben oder kommen?

Von jemanden, der über 30 Jahre seine Brötchen mit Programmieren 
verdient hat:

Der meiste Zeit beim Programmieren besteht darin, Code zu lesen - 
geschätzt würd ich sagen: <5% schreiben, >95% lesen.  Man gewöhnt sich 
an, den Code so zu schreiben, dass er, von einem erfahrenen 
Programmierer, möglichst schnell gelesen und verstanden wird.  Ein "if 
(a)" ist sofort zu erkennen; wenn da noch ein "!=0" hinter hängt, dauert 
es länger ("da kommt noch was, was denn, ah nix").  Ebenso beim "if 
(~foo & 2)", das erste Zeichen signalisiert sofort "negieren", keine 
überflüssigen Klammern, die man erst außereinanderklamüsern muß ("meint 
er vielleicht doch was anderes als das offensichtliche?"). Eine 
Laufvariable i, j, k ist schneller zu erkennen als IndexI, IndexJ, 
IndexK.  Usw.

Bei natürlichen Sprachen haben wir doch auch Pronomen, Wortbeugungen etc 
um den Sprachfluß kompakt und flüssig zu halten - unnützer Ballast wird 
weggelassen oder verkürzt; Marker werden früh gesetzt, um das 
Verständnis in die richtige Richtung zu lenken.  (Wie das aussieht, wenn 
man es nicht macht, mal in Patentschriften reinschauen g)

Anfänger mögen sagen: das ist zu schwer (z.B. Groß-/Kleinschreibung, 
Satzzeichen, implizite Typenumwandlung, Operatorpräzedenz).  Da müssen 
sie halt durch - das meiste davon hat seine Berechtigung.  Irgendwann 
werden sie merken, dass sie damit effizienter werden. Und mit den paar 
Ecken und Kanten, die übrigbleiben, lernt man zu leben :-)

Falk B. schrieb:

>> Frage ist ja gerade: Wieso lassen C-Programmierer
>> ums Verrecken nicht von ihrer Schreibfaulheit ab,
>> selbst wenn sie erwiesenermaßen Fehler verursacht?
>
> Das tun sie nicht, das ist nur deine Interpretation.

Das sehe ich zwar (naturgemäß) anders, aber das sei
jetzt mal wurscht.


> Und nur weil es mal wieder einer verhauen hat, ist
> das kein Beweis eines allgemeinen Problems.

Ein Beweis nicht -- ein Indiz ist es schon. Ein
weiteres Indiz ist für mich, dass MISRA ganz
zufällig zahlreiche DER Konstruktionen verbietet,
mit denen auch ich mentale Probleme habe.

(Dass dieser Fakt auch alternative Interpretationen
zulässt, ist mir bewusst. :)


> Und nein, ich will jetzt nicht über die grundlegenden
> Haken und Ösen von C diskutieren ;-)

Das glaubt mir jetzt zwar niemand, aber: Das wollte ich
eigentlich auch nicht. Ich wollte EIGENTLICH nur von
Stefan wissen, warum er die Kurzschreibweise verwendet,
wenn es eine Langform gibt, die den Fehler vermeidet.


>> Es ging mir aber nicht darum, ob es legitim oder
>> illegitim ist, sondern darum, dass es schlechter
>> Stil ist.
>
> Nö.

Gut -- wir müssen in dem Punkt ja nicht einer Meinung
sein.

Aus meiner Sicht sind diese unsinnigen Abkürzungen
genau so eine Pest wie die zugeschnittenen Gleichungen,
die früher so groß in Mode waren.


>> Durchaus nicht. Wenn C-Programmierer ihr Hirn mit
>> großen Mengen irrelevanten Mistes belasten, kann man
>> daraus folgern, dass sie deutlich weniger Kapazität
>> für Relevantes haben.
>
> Geschwätz.

Durchaus nicht :)
Führt aber wohl doch zu weit vom Thema weg.


> Wenn du dir nicht True und False merken kannst, IST
> das dein Problem.

Nein, überhaupt nicht.
Ich schreibe einfach die Langform hin und bin glücklich.
Wozu sollte ich mir irgendwelchen irrelevanten Mist über
Compiler-Interna merken müssen?


>> Du demonstrierst exemplarisch das, was ich nicht
>> verstehe:
>>
>> Es ist doch absolut irrelevant , ob die Sprache die
>> Kurzschreibweise erlaubt oder nicht. Es besteht doch
>> keinerlei Zwang, jede auch noch so idiotische Abkürzung
>> auch zu benutzen!
>
> Wer redet denn von Zwang?

Na Rufus zum Beispiel, wenn er behauptet, bei Benutzung
der Langform würde man "an wesentlichen Eigenschaften
der Programmiersprache vorbeiprogrammieren". Ihm zufolge
wäre man also ein schlechter C-Programmierer, wenn man
z.B. den MISTRA-Standard einhält !

Oder ich, wenn ich meinen Eindruck wiedergebe:
Kein "echter C-Programmierer" würde, wenn ein entsprechendes
Problem auftritt, zugeben: "Mist. Verfluchte Tippfaulheit.
Richtig ist natürlich ...", und dann die Langform schreiben.
Das kommt nicht vor. Das macht man einfach nicht! -- Was ist
denn das sonst, wenn nicht zwanghaftes Verhalten?


> Warum gibt es Abkürzungen für lange Begriffe?

Was C angeht, so kenne ich die Antwort inzwischen: Weil
Speicher früher knapp und optimierende Compiler unbekannt
waren.


> Weil sie kürzer und damit bequemer sind!

Das ist, soweit es C angeht, zu weiten Teilen eine Legende.

Egon D. schrieb:
> Warum schreibt man die Bedingung nicht einfach vollständig?

Ich habe nicht dagegen.
Ich mag auch Binärzahlen, wenn man sie denn kommentiert

1

// if red or yellow button is pressed, then ...

2

if ((PINB & 0b00110000)==0) {...}

Am liebsten habe ich aber sowas:

1

#define BUTTON_RED (!(PINB & (1<<PB5)))

2

#define BUTTON_YELLOW (!(PINB & (1<<PB4)))

3

4

if (BUTTON_RED||BUTTON_YELLOW) {...}

Das sind aber alles Kleinigkeiten, über die sollte man sich nicht 
streiten. Ich programmiere beruflich seit Jahren im Team, da kommt man 
weiter, wenn man andere Leuten einen anderen Stil erlaubt (in gewissen 
Grenzen). Unsere gesamten Entwicklungsrichtlinien passen auf zwei Din-A4 
Seiten, der Rest ergibt sich aus Erfahrung und Vernunft. Wir 
kontrollieren unsere Arbeiten gegenseitig. Wenn da mal was ganz 
schlechtes bei ist, reden wir miteinander.

Rufus Τ. F. schrieb:

> Egon D. schrieb:
>> Ihm zufolge wäre man also ein schlechter C-Programmierer,
>> wenn man z.B. den MISTRA-Standard einhält !
>
> Nö. Aber MISRA wird sicher nicht ein if (a) durch ein
> if (a == TRUE) ersetzen wollen.

Häh?!

Sollen wir vielleicht mal eine Nacht darüber schlafen und
morgen fortsetzen?

Es ging in der Diskusion bisher nie und nirgendwo darum,
dass eine Variable -- sie heiße beispielsweise "a" --, die
bereits einen Wahrheitswert enthält, mittels

1

if (a==TRUE) {...}

abfragen soll.


Es ging, zumindest soweit ich mich an der Diskussion
beteiligt habe, immer nur darum, dass man einen beliebig
komplexen arithmetischen Ausdruck , der ein ganzzahliges
Ergebnis liefert, nicht mit

1

if(ausdruck) {...}

abfragen soll, sondern mit

1

if(ausdruck==0) {...}

und das ist genau das, was MISRA:2004, Regel 13.2 sagt.

Mein Verweis auf MISRA war zwar ursprünglich nur geraten,
aber Nachschlagen bestätigte mir jetzt, dass ich gut
geraten hatte.

Stefanus F. schrieb:

> Egon D. schrieb:
>> Warum schreibt man die Bedingung nicht einfach
>> vollständig?
>
> Ich habe nicht dagegen.

Ich wollte niemanden angreifen, weder Dich noch den
Fragesteller.

Meine Frage hat sich mir nur deshalb aufgedrängt, weil
der TO seine Kurzform ohne Vergleichsoperator ja irgendwo
gelernt haben wird -- schätzungsweise aus irgendeinem
Lehrbuch oder ähnlichem. Ich wäre aus eigener Kraft
nicht im Traum darauf gekommen, etwas mit einer Negation
auszudrücken, was inhaltlich ein Vergleich mit Null sein
soll.

Rufus Τ. F. schrieb:
> Nö. Aber MISRA wird sicher nicht ein if (a) durch ein if (a == TRUE)
> ersetzen wollen.

Das ist auch nicht das Selbe, wäre ja quatsch so so zu fordern.

Wenn TRUE mit 1 definiert ist, dann sind diese beiden Ausdrücke positiv, 
wenn a mit 1 beschrieben wurde:

1

if(a)

2

3

if(a == TRUE)

Die hier sind auch positiv, wenn a mit 2 beschrieben wurde:

1

if(a == 2)

2

3

if(a)

Nur ist jetzt das (a == TRUE) nicht mehr positiv.

Das if(a) ist positiv, sobald a etwas anderes als 0 ist.

Ich würde klar gegen Schreibfaulheit argumentieren. Es ist nicht immer 
klar, ob ein Autor gewisse Dinge wußte oder ob er unabsichtlich ein 
Problem erzeugt hat. Beispiel Klammersetzung:

1

// ??? bittest of BIT #3 or Bit #0 shifted into 3rd bit

2

b = a & 1 << 3;

3

4

if (a && b || c)

5

{

6

   // ??? (a AND b) OR c != a AND (b OR c)

7

}

Frank M. schrieb:

> Egon D. schrieb:
>> nicht mit if(ausdruck) {...}
>>
>> abfragen soll, sondern mit if(ausdruck==0) {...}
>
> Fipptehler?

Klar. Danke. Im Standard steht's auch richtig.


> Dein zweites if dreht die Bedingung komplett rum.

Ja.
Also nochmal. Die korrigierte Fassung:


  "Es ging, zumindest soweit ich mich an der Diskussion
   beteiligt habe, immer nur darum, dass man einen
   beliebig komplexen arithmetischen Ausdruck , der
   ein ganzzahliges Ergebnis liefert, nicht mit

1

   if(ausdruck) {...}

   abfragen soll, sondern mit

1

   if(ausdruck!=0) {...}

   und das ist genau das, was MISRA:2004, Regel 13.2 sagt."

Ich hoffe, jetzt stimmt's.

foobar schrieb:

> Der meiste Zeit beim Programmieren besteht darin,
> Code zu lesen - geschätzt würd ich sagen: <5%
> schreiben, >95% lesen.  Man gewöhnt sich an, den
> Code so zu schreiben, dass er, von einem erfahrenen
> Programmierer, möglichst schnell gelesen und
> verstanden wird.

Ein überraschend aufrichtiges Statement: Wer nicht
zur Elite gehört, soll ausgeschlossen werden.

Danke, dass Du meinen subjektiven Eindruck so klar
bestätigst.

Da Issa wieda schrieb im Beitrag #5767232:
> Das ist keine Programmiersprache -das ist ein Würfelspiel.

Dann guck Dir mal durchschnittliche Perl Programme aus den 90er Jahren 
an. Die sehen nicht selten so aus: 
https://thumbs.dreamstime.com/z/viele-w%C3%BCrfel-%C3%BCber-gr%C3%BCnem-strukturiertem-hintergrund-15777804.jpg

Da Issa wieda schrieb im Beitrag #5767232:

> Das ist keine Programmiersprache -das ist ein
> Würfelspiel.
>
> Dreck.

Schwachsinn. Bitte unterlasse die Beschimpfungen.

Die Sprache ist ein Gesamtkunstwerk; ich beginne
auch zu verstehen, was den Anhängern an dieser
Sprache gefällt.

Es geht hier aber nicht um die Sprache , sondern
um den Umgang der Programmierer mit ihr. Das ist
etwas anderes.

Stefanus F. schrieb:

> Da Issa wieda schrieb:
>> Das ist keine Programmiersprache -das ist ein Würfelspiel.
>
> Dann guck Dir mal durchschnittliche Perl Programme aus
> den 90er Jahren an.

Habe ich getan. Als Folge dessen habe ich Tcl gelernt.

Bernd K. schrieb:

> Egon D. schrieb:
>> Man gewöhnt sich an, den
>>> Code so zu schreiben, dass er, von einem erfahrenen
>>> Programmierer, möglichst schnell gelesen und
>>> verstanden wird.
>>
>> Ein überraschend aufrichtiges Statement: Wer nicht
>> zur Elite gehört, soll ausgeschlossen werden.
>
> Ich glaube nicht daß er damit implizit meinte den
> Code so zu schreiben daß er von weniger erfahrenen
> Programmierern schwerer gelesen werden kann.

Tja, ich weiss es halt nicht...


> Ich denke er meinte einfach den Code so zu schreiben
> daß man ihn gut lesen kann.

Ja... das wäre ja aus meiner Sicht sofort konsensfähig.
Wenn man dann noch dazunimmt, dass der Verzicht auf
die kürzestmögliche Ausdrucksweise den erfahrenen
C-Programmierer kaum behindert, dem Anfänger aber sehr
hilft, ist das Glück schon fast perfekt.

Bleiben wir jedoch mal beim Ursprungsbeispiel: Es soll
ein bestimmtes Bit darauf getestet werden, ob es den
Wert Null hat oder nicht.
Als Pascal/Tcl-Mensch würde ich einfach schreiben:

1

if (((mybyte & (1<<1)) == 0) { 

2

...

3

}

Ob man die Maske ausdrückt als "0x02", "(1<<1)" oder
als Konstantenmakro, das möge hier mal bitte außer
Betracht bleiben.

Wie aber kommt ein normaler Mensch darauf, den
Vergleich eines Bits mit dem Wert "Null" ohne
Vergleichsoperator auszudrücken -- und zwar in
einer Programmiersprache, die den passenden
Operator kennt?

Wo liegt der Gewinn an Lesbarkeit, wenn der inhaltlich
gemeinte Vergleich mit Null durch Konstruktion eines
Ausdruck verschieden von Null ersetzt wird?

Und bitte wie betriebsblind muss man sein, wenn man
das Gegenteil von dem hinschreibt, was man meint, und
dann noch behauptet, dies sie die natürliche und quasi
einzige der Sprache gemäße Ausdrucksweise?

Volker S. schrieb:

> wenn ich groß bin schrieb:
>> Richtig so? oder besser anders?
>
> Eigentlich genial. Wenn ich groß bin, werde ich Troll
> und denke mir so einfache Fragen aus, die zur Folge
> haben, dass alle übereinander herfallen ;-)

Täusch' Dich nicht.
Ein guter Troll zu sein ist schwerer, als Du denkst.

Egon D. schrieb:
> Wo liegt der Gewinn an Lesbarkeit, wenn der inhaltlich
> gemeinte Vergleich mit Null durch Konstruktion eines
> Ausdruck verschieden von Null ersetzt wird?

Das kommt daher, dass die Absicht nicht der Vergleich ist, sondern man 
will etwas tun, wenn die Bedingung nicht erfüllt ist. Daher 
"!bedingung".

if (!taschen_voller_geld()) { geh_arbeiten() };

Ist das Glas halb voll oder halb leer? Man muss darüber keine 
Glaubenskriege führen. Vernünftige Menschen führen nur Krieg, wenn 
zwingende Gründe vorliegen. Gute Menschen tolerieren anders tickende 
Menschen.

Stefanus F. schrieb:

> Die Zusätzliche Klammer macht es für mich leichter lesbar. Wenn ich zwei
> Bits anteste, dann so:
>
>

1

> if (~(mybyte & (2 | 4))

2

> {

3

>   alarm()

4

> }

5

>

Da du den Fehler übersehen hast, ist es nicht leichter lesbar.

wenn ich groß bin schrieb:
> Hallo, für nen PIC16 soll wenn Bit 1 in mybyte auf 0 ist Aktion
> ausgelöst werden. Richtig so? oder besser anders?if (~mybyte & 0x02)
> alarm()

BTFSS mybyte,1
CALL  Action


W.S.

Stefanus F. schrieb:

> Egon D. schrieb:
>> Wo liegt der Gewinn an Lesbarkeit, wenn der inhaltlich
>> gemeinte Vergleich mit Null durch Konstruktion eines
>> Ausdruck verschieden von Null ersetzt wird?
>
> Das kommt daher, dass die Absicht nicht der Vergleich
> ist, sondern man will etwas tun, wenn die Bedingung
> nicht erfüllt ist. Daher "!bedingung".

Nee, das stimmt doch nicht. Was geschrieben wird,
ist nämlich gar nicht "!bedingung", sondern
"arithmetischer_ausdruck", wie eben z.B. in "(~a & 2)".
Nur um den Fall geht es mir.

Und genau das ist die Betriebsblindheit, die ich
meine: Viele C-Leute sind offenbar schon dermaßen
fest auf die Inexistenz von (echten) booleschen
Werten konditioniert, dass sie gar nicht mehr
verstehen, was andere meinen, wenn sie deren Fehlen
beklagen.

Das ist doch genau dasselbe wie bei der Hardware:
Eine Spannung von 4.2V ist NICHT automatisch
eine logische Eins, auch wenn dies, als TTL-Pegel
interpretiert, so stimmt.
Jeder Hardware-Mensch weiss, dass man nicht einfach
ein Analogsignal an einen beliebigen Gattereingang
anlegt, sondern dass man da einen Trigger verwendet.

C-Programmierer kratzt das natürlich nicht.

In der Physik genau dasselbe: Physikalische Größen
bestehen aus Maßzahl und Einheit. Es hat überhaupt
keinen angebbaren Sinn, Kilogramm und Quadratmeter
zu vergleichen, oder Sekunden und Farad zu addieren,
auch wenn die Maßzahlen immer reelle (oder rationale)
Zahlen sind.

Das ist aber einem archetypischen C-Programmierer
offensichtlich nicht vermittelbar: Dass nämlich
ein NIL-Pointer, der Wahrheitswert FALSE und die
Ganzzahl 0 zwar durch das gleiche Bitmuster
dargestellt werden, inhaltlich aber dennoch nicht
dasselbe sind -- weshalb "if(1)" widersinniger
Scheiss ist.
Das ist semantisch genau solcher Mist wie "Diese
Farbe ist drei Sekunden schwer."


> Ist das Glas halb voll oder halb leer? Man muss
> darüber keine Glaubenskriege führen.

Ich möchte niemanden missionieren, also zur
Änderung seiner Gewohnheiten überreden, und ich
möchte übrigens auch niemanden bloßstellen. Das
ist nicht der Punkt.


> Vernünftige Menschen führen nur Krieg, wenn
> zwingende Gründe vorliegen.

Ah geh, wer redet denn von "Krieg führen".


> Gute Menschen tolerieren anders tickende Menschen.

Das tue ich doch -- aber andere Menschen zu tolerieren
heißt bei weitem nicht, alles unwidersprochen
stehenzulassen, was sie von sich geben.

Egon D. schrieb:
> Es hat überhaupt keinen angebbaren Sinn...Sekunden und Farad zu addieren.

Ich brauche mit einem Fahrrad etwa 900 Sekunden zur Arbeit. Mit zwei 
Fahrrädern brauche ich ... misst, das klappt so nicht .-)

Stefanus F. schrieb:

> Egon D. schrieb:
>> Es hat überhaupt keinen angebbaren Sinn...Sekunden
>> und Farad zu addieren.
>
> Ich brauche mit einem Fahrrad etwa 900 Sekunden zur
> Arbeit. Mit zwei Fahrrädern brauche ich ... misst,
> das klappt so nicht .-)

"Schöhler F.! Ihnen fehlt die nöthige sittliche Reife!"

Egon D. schrieb:
> -- weshalb "if(1)" widersinniger
> Scheiss ist.

Du hast C nicht verstanden, Der Standard sagt z.B. bei "if" statement:
"... the first substatement is executed if the expression compares 
unequal to 0."
https://c0x.coding-guidelines.com/6.8.4.1.html

D.h. der Vergleich mit Null/0... ist implzit in C enthalten.

Der Ausdruck "if (1)" ist kurz, praegnant, gut zu lesen und richtig.

leo

leo schrieb:

> Egon D. schrieb:
>> -- weshalb "if(1)" widersinniger Scheiss ist.
>
> Du hast C nicht verstanden,

Nein. Du hast MICH nicht verstanden.


> Der Standard sagt z.B. bei "if" statement: [...]

Was Du sagst, ist sachlich richtig, aber absolut
IRRELEVANT .

Es ist deswegen irrelevant, weil es der Standard
zwar ERLAUBT , solchen Scheiss wie "if(1)" zu
schreiben, dies aber nicht FORDERT !

Es ist GENAUSO standardkonform, "if(a==b)" zu
schreiben.

Aber genau diese sich ständig wiederholende Gebets-
mühle kommt dadurch zu Stande, dass C-Programmierer
(ganz offensichtlich der Erfahrung nach) mental
nicht in der Lage sind, ein syntaktisch zulässiges
Konstrukt mal NICHT zu verwenden.

Sie können es NICHT ertragen, dass da irgendwo
noch ein Quickhack sein könnte, den der Compiler
klaglos frisst, den sie selbst aber nicht anwenden.
Das geht nicht, das ist ein Sakrileg. "Wieso...
das ist doch aus gutem Grund im Sprachstandard!"

Ja -- klar!

Der gute Grund besteht darin, dass das Konstrukt
im Comuter-Pleistozän, also ungefähr vor 50 Jahren,
mal sinnvoll und notwendig war!

Wie krank ist das denn?! Wenn ich einen 20 Jahre
alten Transistortyp verwenden will, dann werde ich
angeguckt wie ein Kalb mit drei Köpfen.

Wenn ich aber dafür plädiere, ein 40 Jahre altes
Programmkonstrukt NICHT anzuwenden, werde ich
angeguckt wie ein Kalb mit fünf Köpfen, das aus
einem Scharfschützengewehr Crack raucht!

Egon, ich häng an Deinem Munde,weiter so!

> Es ist GENAUSO standardkonform, "if(a==b)" zu schreiben.

Aber bitte "if ((a==b)!=0)", sonst bewegst du dich auf dem gleichen 
Niveau wie "if (a & b)" ;-)

foobar schrieb:
> Aber bitte "if ((a==b)!=0)",

Immer diese Abk. Wenn schon, dann:

1

if (((a==b) != 0) == TRUE)

BTW:

1

~/.arduino15 $ ag  '#define\s+\bTRUE' | wc -l

2

8

Die Leute scheinen so unnoetiges Zeug zu lieben.

leo

Rufus Τ. F. schrieb:
> Und so etwas
> for (i = 1; i <= 8; i++)

Ich liebe es...

Egon D. schrieb:
> Wenn ich aber dafür plädiere, ein 40 Jahre altes
> Programmkonstrukt NICHT anzuwenden, werde ich
> angeguckt wie ein Kalb mit fünf Köpfen, das aus
> einem Scharfschützengewehr Crack raucht!

Du wirst komisch angeguckt weil du andere Meinungen nicht tolerierst. Du 
hast alle anders denken mehrfach übelst beschimpft (als krank, 
behindert, drogensüchtig, etc).

Deswegen gehen wir auf Konfrontation!

Alle Vergleiche in den Quelltexten hier kommen an diesen Vergleich in 
Bezug auf Klarheit und auch Schönheit nicht heran:


Egon D. schrieb:

> Wenn ich aber dafür plädiere, ein 40 Jahre altes
> Programmkonstrukt NICHT anzuwenden, werde ich
> angeguckt wie ein Kalb mit fünf Köpfen, das aus
> einem Scharfschützengewehr Crack raucht!

Walter K. schrieb:
> also ich schreibe ne for Schleife bei 7 benötigten Durchläufen immer so:

Ja. Du bist ein Held.

Leute, die Logik im mathematischen Sinne und all das, was in einer 
unlogisch konstruierten Programmiersprache als "gewöhnlich" oder 
"üblich" angesehen wird, sind zwei ganz verschiedene Dinge.

Wir sollten das mal auseinanderhalten.

Stefanus F. schrieb:
> Du wirst komisch angeguckt weil du andere Meinungen nicht tolerierst.
...
> Deswegen gehen wir auf Konfrontation!

..und genau DAS ist etwas grottenschlechtes. Aus so etwas im 
Gesellschaftlichen sind schon die übelsten Kriege entstanden.

Also: frag dich erstmal, warum er eine andere Meinung nicht toleriert. 
Das löst normalerweise das Problem vollständig.

Ich z.B. toleriere ja auch nicht, wen jemand meint, bei ihm sei 3 mal 3 
gleich 7. Nein, das ist falsch und deshalb lasse ich auch keine Meinung 
gelten, die für 7 plädiert.

Und wenn da steht "while(1)", und jemand sagt, das ist unlogisch, dann 
gebe ich ihm Recht, denn es IST unlogisch. Es ist Konvention, aber 
deshalb noch lange nicht logisch. Etwas Logisches wäre, wenn da stünde 
"while(x=1)" - aber das wiederum bricht mit einer anderen Konvention in 
dieser betreffenden Programmiersprache, denn unlogischerweise wurde da 
ja das Gleichheitszeichen zweckentfremdet mißbraucht.

Kommen wir zu der Frage nach der Priorität: Die liegt ganz klar bei der 
Mathematik. Die hat es schon immer gegeben und sie ist der allgemeine 
Maßstab für alles, was mit Zahlen in diesem Universum zu tun hat - und 
irgend eine Programmiersprache mag zwar ihr eigenes Süppchen kochen, 
aber das ist allemal nachrangig gegenüber der Mathematik.

All diese unfruchtbaren Diskussionen könnte man zusammenkürzen, wenn 
sich die Disputanten darauf einigen könnten, logische Dinge nach 
mathematischen Grundsätzen zu betrachten und Ausdrücke in 
Programmiersprachen daran zu messen - und nicht umgekehrt.

Also laßt das mit der Konfrontation lieber bleiben.

W.S.

Stefanus F. schrieb:

> Egon D. schrieb:
>> Wenn ich aber dafür plädiere, ein 40 Jahre altes
>> Programmkonstrukt NICHT anzuwenden, werde ich
>> angeguckt wie ein Kalb mit fünf Köpfen, das aus
>> einem Scharfschützengewehr Crack raucht!
>
> Du wirst komisch angeguckt weil du andere Meinungen
> nicht tolerierst.

Hmm.


> Du hast alle anders denken mehrfach übelst beschimpft
> (als krank, behindert, drogensüchtig, etc).

Ich erbitte mehrere (wörtliche!) Zitate als Beleg.
Das Zitat oben belegt Deine Aussage schonmal nicht.

Vielen Dank im Voraus.

Thomas E. schrieb:
> int Funktion(int para)
> {
>   //blabla
>
>   return ErrorLevel; //0 = success
> }
>
> if(!Funktion(x))
> {
>   printf("Hurra");
> }
>
> Ein bisschen strange ist das manchmal schon. Aber wenn man sich erstmal
> dran gewöhnt hat...

Da ist für mich aber die Grenze überschritten.

"not Funktion" ist sprachlich etwas anderes als "Funktion gleich 0" oder 
"Funktion gleich E_OK".

Vor allem, wenn beide Metaphern vorkommen (0=success und true=success) 
brauche ich eine dazu passende Verwendung von ! und ==0.

Rufus Τ. F. schrieb:

> Egon D. schrieb:
>> Wenn ich aber dafür plädiere, ein 40 Jahre altes
>> Programmkonstrukt NICHT anzuwenden, werde ich
>> angeguckt wie ein Kalb mit fünf Köpfen, das aus
>> einem Scharfschützengewehr Crack raucht!
>
> Nun, das könnte damit zu tun haben, daß der Gebrauch
> von in einer Programmiersprache üblichen Konstrukten
> halt ... üblich ist. Stattdessen ein anderes, zwar
> funktional identisches, aber eben unübliches Konstrukt
> zu verwenden, ist eben ... ungewöhnlich.
>
> Eine Programmiersprache lebt auch von Konventionen.
> Und wenn diese Konventionen gebrochen werden, wird
> man argwöhnisch.

Hmm. Okay. In der Tat. Guter Punkt.

Das stimmt natürlich. Das lässt das ganze Problem
in einem völlig anderen Licht erscheinen.

Ich dachte bis jetzt immer, dass nur Hardwerker das
Problem haben, dass sich die Wissensschwerpunkte
verschieben und auf diese Weise "schöne" Teile der
Elektrotechnik (scheinbar oder tatsächlich)
überflüssig werden. (Die Theorie der LC-Filter ist
da so ein Beispiel.)

Aber natürlich ist das falsch. Sehr offensichtlich
ist das bei der Assemblerprogrammierung -- und noch
viel mehr bei der Programmierung im Maschinencode,
die ja beide weitgehend überflüssig geworden sind.

C selbst hat sich, wie wir ja alle wissen, keineswegs
überlebt.
Allerdings sind die Compiler sehr viel leistungsfähiger
geworden. Die unmittelbare Folge davon ist, dass sich
die Arbeitsteilung zwischen dem Programmierer und dem
Compiler verschiebt -- und zwar verschiebt sich sich
allmählich und schleichend, nämlich in genau dem Maße,
wie die Compiler besser werden und z.B. besser optimieren.

ANSI-C ist heute natürlich immer noch ANSI-C. Man muss
aber davon ausgehen, dass ein aktueller Compiler aus
demselben C-Quelltext einen ganz anderen Maschinencode
zaubern kann als ein Compiler von 1990.

Die logische Konsequenz davon ist, dass die Konventionen
dem Rechnung tragen und sich entsprechend anpassen müssen,
aber Konventionen müssen sich ja auch erst einmal heraus-
bilden.

Danke für den Denkanstoß.


Ach so, Nachtrag: Ich will der Diskussion nicht ausweichen
und kann bei Bedarf natürlich Deinen Beitrag 
Beitrag "Re: ein Bit im Byte auf 0 prüfen"
noch beantworten. Von meiner Seite aus schien das nur
nicht mehr unbedingt notwendig.

W.S. schrieb:

> All diese unfruchtbaren Diskussionen [...]

Also, das mag den Lesern vielleicht anders ergehen,
aber für mich sind diese Diskussionen keineswegs
fruchtlos.

Dirk K. schrieb:

> Die Leute müssten sich nur mal Gedanken darüber
> machen, warum die Programmiersprachen so sind
> wie sie sind:

Ich dachte, Dir sei aufgefallen, dass ich genau
das mache.


> C war quasi eine Ablösung für Assembler, und das
> war eine riesige Erleichterung damals. Aber die
> Sprache ist immer noch tief bei der Hardware
> angesiedelt. Ein Programmierer, der seinem Gürtel
> nicht traut und lieber auch noch Hosenträger
> anzieht, sollte C nicht verwenden.

Das "sollte" suggeriert, man habe eine echte Wahl.

Hat man aber gar nicht. Der Punkt ist ja in den
letzten Monaten (Jahren?) ausführlich hier diskutiert
worden, und das Ergebnis war: Wenn man eine...
- standardisierte
- für Systemprogrammierung geeignete
- auf nahezu allen Plattformen verfügbare
- Hochsprache
sucht, dann bleibt praktisch nur C übrig.

Das hat mit Gefallen oder Nichtgefallen gar nichts zu
tun, und diese Erkenntnis hat mich dazu gebracht, C
zu lernen.


> Die beiden sind nicht vergleichbar. Es gibt aber
> immer wieder Foristen, die meinen, genau das tun
> zu müssen.

"Vergleichen" heißt nicht "die Gleichheit behaupten",
sondern "Gemeinsamkeiten und Unterschiede feststellen".

Ja, und natürlich ist das interessant und völlig
legitim, und, ja, ich mache das gern und ausdauernd.


> Manchmal ist es ja lustig und ich hol mir ein Bierchen
> und 'ne Tüte Popcorn, aber unterm Strich frage ich
> mich, schon, ob die Menschen keine anderen Probleme
> haben.

Doch -- aber eins meiner Probleme ist, zu verstehen, warum
C so ist, wie es ist, und warum C so gelehrt wird, wie es
gelehrt wird.