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.
Stefanus F. schrieb:> Rufus Τ. F. schrieb:>> d.h. den logischen und nicht den bitweisen Negationsoperator zu>> verwenden.>> Oh ja, das wollte ich eigentlich schreiben. Danke Rufus.
Und du verdienst dein Geld mit Software? Indem du eine richtige
Schreibweise verschlimmbesserst?
Rufus Τ. F. schrieb:> Falk B. schrieb:>> Indem du eine richtige Schreibweise verschlimmbesserst?>> Magst Du das erklären?
Die logische Prüfung des OPs war korrekt, wenn gleich man sich über die
Darstellung streiten kann.
> 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.
Da hast Du dann wohl recht.
Inwiefern aber "meine" Variante eine "Verschlimmbesserung" sein soll,
möge mir Falk doch bitte noch erklären.
Stefanus F. schrieb:>> Die "Verbesserung" von Stefanus ist FALSCH!>> Daran ist gar nichts falsch.
Aber 100%!!!!
der OP wollte
"Hallo, für nen PIC16 soll wenn Bit 1 in mybyte auf 0 ist Aktion
ausgelöst werden. Richtig so? oder besser anders?"
Dein Beispiel tut das NICHT!!!
1
mybyte=0x02;
2
3
if(~(mybyte&2)
4
{
5
alarm();// Fehlalarm!!!
6
}
> Au ch nicht an dem, was ich eigentlich> schrieben wollte:
Das interessiert nicht, meine Kritik bezog sich auf deinen 1. Beitrag!
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.
Rufus Τ. F. schrieb:> Inwiefern aber "meine" Variante eine "Verschlimmbesserung" sein soll,> möge mir Falk doch bitte noch erklären.
Bezog ich mich auf deine Variante? Nö. Meine Kritik bezog sich auf
Stefanus, du bist nur mit ins Zitat reingerutscht.
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?
Stefanus F. schrieb:> Ich würde es anders schreiben:> if (~(mybyte & 2)> {> alarm()> }>> Die Zusätzliche Klammer macht es für mich leichter lesbar
Offenkundig nicht, prompt eine Klammer vergessen.
Wolfgang schrieb:> 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
Im wirklichen Leben gibt es an dieser Stelle weder 128 noch 1<<7, weil
das Bit natürlich einen Namen hat. Dann sieht die vollständige
Schreibweise auch nicht mehr so komisch aus
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.
Bauform B. schrieb:> Im wirklichen Leben gibt es an dieser Stelle weder 128 noch 1<<7, weil> das Bit natürlich einen Namen hat. Dann sieht die vollständige> Schreibweise auch nicht mehr so komisch ausif ((mybyte & ALLES_GUT) ==> 0) {> alarm ();> }
Na wenn schon, dann eher so
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.
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?
Egon D. schrieb:> Was ich aber nicht verstehe, das ist: Warum schreibt man> die Bedingung nicht einfach vollständig?if((mybyte & (1<<1)) == 0) {> alarm();> }>> Woher kommt die unausrottbare, nachhaltige, tief ver-> wurzelte Aversion der C-Programmierer gegen klare,> vollständige Schreibweisen?
Weil die Auswertung logischer Ausdrücke immer implizit ist und
Programmierer schreibfaul sind. Nicht umsonst werden diverse Sprachen
ala Pascal, VHDL etc. als "geschwätzig" bezeichnet.
> 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.
> 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
Das ist dein persönliches Problem.
False = 0
True = !False, bzw. True = ungleich 0
> noch viel schlimmer ist: Ich sehe inzwischen auch nicht> mehr ein, warum ich mein Hirn mit solchem Mist belasten> soll.
Dein Problem.
> 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. Nimm halt Pascal oder was ähnliches ;-)
Egon D. schrieb:> Woher kommt die unausrottbare, nachhaltige, tief ver- wurzelte Aversion> der C-Programmierer gegen klare, vollständige Schreibweisen?
Das ist Deine Interpretation.
Deine "klare, vollständige Schreibweise" ist halt einfach nur
umständlich und überflüssig, und stört den Lesefluss gegenüber dem
gewohnten.
1
if(!a)
2
{
3
}
ist für jemanden, der länger als zwei Monate mit c-artigen Sprachen
arbeitet, die gewohnte und übliche Ausdrucksweise.
1
if(a==0)
2
{
3
}
unterscheidet sich inhaltlich nicht, ist aber mehr Text.
1
if(0==a)
2
{
3
}
macht dasselbe, ist aber ein Vehikel, mit dem Leute, die gerne "==" und
"=" verwechseln, aber die entsprechende Compilerwarnung deaktiviert
haben, sich helfen.
Beides ist einfach nur mehr Text.
Und das sieht im nicht-negierten Fall nicht anders aus.
1
if(a)
2
{
3
}
Macht exakt dasselbe wie
1
if(a!=0)
2
{
3
}
Aber auch das ist einfach nur mehr Text, durch den nichts gewonnen ist.
Spannend wird es, wenn jemand versucht, sich Macros für einen
"bool"-Datentyp zu basteln.
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.
Egon D. schrieb:> Wieso lassen C-Programmierer ums Verrecken nicht von ihrer> Schreibfaulheit ab, selbst wenn sie erwiesenermaßen Fehler verursacht?
Genau das tut sie nicht. Erwiesenermaßen verursacht es Fehler, wenn man
versucht, "klar und deutlich" an der Funktionsweise der
Programmiersprache vorbeizuprogrammieren.
Die "Abkürzungen" sind nicht idiotisch, sondern eine klare und elegante
Form, das auszudrücken, was man will.
Wenn man versucht, das Verhalten anderer Programmiersprachen
nachzubilden, oder, weil man sich weigert, sich mit der Sprache zu
beschäftigen, seine eigene Denkweise nachbildet, kann es zu
interessanten Nebeneffekten kommen.
Wie C mit binären und logischen Operatoren arbeitet und wie Ausdrücke
ausgewertet werden, ist in jedem C-Handbuch in den ersten paar Kapiteln
beschrieben, und wird in jeder Erstsemestervorlesung in den ersten paar
Wochen behandelt.
Das ist elementar. Das muss man halt lernen, so, wie man bei anderen
Programmiersprachen auch lernen muss, wie sie funktionieren.
Egon D. schrieb:>> Weil die Auswertung logischer Ausdrücke immer>> implizit ist>> Verstehe ich nicht. Was soll das bedeuten?
Das, was Rufus schon schrieb.
a hat den gleiche logischen Wert wie (a!=0)
> 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. Und nur weil es mal
wieder einer verhauen hat, ist das kein Beweis eines allgemeinen
Problems.
Und nein, ich will jetzt nicht über die grundlegenden Haken und Ösen von
C diskutieren ;-)
>> Das ist in C auch vollkommen legitim.>> Es ist auch im Alltag völlig legitim, sich mit der> Axt in den Fuß zu hauen.
Nicht alles was hinkt, ist ein Vergleich.
> Es ging mir aber nicht darum, ob es legitim oder> illegitim ist, sondern darum, dass es schlechter> Stil ist.
Nö.
>>> 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.
Geschwätz. Wenn du dir nicht True und False merken kannst, IST das dein
Problem. Genauso könnte ein Hardwerker sagen, er kann sich LOW und HIGH
nicht merken.
> 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? Warum gibt es Abkürzungen für lange Begriffe?
Weil sie kürzer und damit bequemer sind!
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:
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.
Stumpfsinn, oh meine Freude schrieb im Beitrag #5766910:
> Das ist keine Programmiersprache -das ist ein Würfelspiel.
Das seit 40 Jahren weltweit in großer Masse im Einsatz ist.
> Dreck.
Nö, es ist eher ein Rasiermesser, das in Profihände gehört. Nix für
kleine Kinder.
Stumpfsinn, oh meine Freude schrieb im Beitrag #5766910:
> Das ist keine Programmiersprache -das ist ein Würfelspiel.>> Dreck.
Komm bleib einfach bei deinem BASCOM. Wenn man von etwas keine Ahnung
hat einfach die Finger mal still halten.
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:> 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.
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 beliebigkomplexen arithmetischen Ausdruck , der ein ganzzahligesErgebnis 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.
Egon D. schrieb:> nicht mit if(ausdruck) {...}>> abfragen soll, sondern mit if(ausdruck==0) {...}
Fipptehler? Dein zweites if dreht die Bedingung komplett rum.
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
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 , derein 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.
Egon D. schrieb:> 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.
Du Schlingel du.
Du hast unterschlagen, dass 13.2 nicht "required" ist, sondern nur
"advisory"
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.
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. Ich denke er meinte einfach den Code so zu schreiben daß man ihn
gut lesen kann.
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 ;-)
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" ohneVergleichsoperator 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.
Egon D. schrieb:> 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?
Deine Fragestellung impliziert, daß Leute, die nicht Deiner Meinung
sind, keine "normalen Menschen" sind.
Möchstest Du wirklich so argumentieren?
> Und bitte wie betriebsblind muss man sein, wenn man das Gegenteil von> dem hinschreibt, was man meint,
Das ist Deine ganz spezifische Interpretation.
Wenn ich "if (a)" schreibe, schreibe (und meine) ich NICHT das Gegenteil
von "if (a != 0)".
Und wenn ich "if (!a)" schreibe, schreibe (und meine) ich ebenfalls
NICHT das Gegenteil von "if (a == 0)".
Wenn für Dich das jeweils das Gegenteil ist, solltest Du über
"betriebsblind" noch mal sehr, sehr gründlich nachdenken.
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 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.
Wenn ich beispielsweise in C eine so formulierte For-Schleife sehe:
1
for(i=0;i<=7;i++)
sehe, werde ich argwöhnisch. Das macht zwar das gleiche wie
1
for(i=0;i<8;i++)
aber es ist ungewöhnlich formuliert.
Bereits
1
for(i=0;i<8;++i)
ist ungewöhnlich und signalisiert, daß hier erhöhte Aufmerksamkeit nötig
ist, weil da jemand an den Konventionen vorbei operiert.
Und so etwas
> 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)" ;-)
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!
Nur mal so als Anmerkung:
Wenn Du ausschließlich C-Code zitierst, dann verwende
1
[c]...[/c]
Wenn Du jedoch Freitext da mit drin hast, sieht das nicht gerade schön
aus. Die roten Umlaute lassen sich schlecht lesen. Benutze in diesem
Fall besser
1
[pre]...[/pre]
wenn Du es unbedingt vor der forumeigenen Formatierung schützen
möchtest.
Der Tipp gilt auch für Leo, welcher auch schon mal Shell-Kommandos in
C-Tags setzt. Das sieht dann bei den Backslashes suboptimal aus.
Rufus Τ. F. schrieb:> Wenn ich beispielsweise in C eine so formulierte For-Schleife sehe:> for (i = 0; i <= 7; i++)> sehe, werde ich argwöhnisch. Das macht zwar das gleiche wie> for (i = 0; i < 8; i++)
... ich schreibe nach meinen eigenen standard
for (uint8_t i=0; i!=8; i++)
ich denke, ihr seit hier alle krank, wie erklärt sich sonst dieses
rumgesülze?!
mt
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.
W.S. schrieb:> 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.
Das erscheit aber nur denjenigen unlogisch, die mit der Syntax nicht
vertraut sind!
7 + 1 = 10 erscheint Dir unlogisch, weil Du implizit die Zahlen im
Zehnersystem vermutest - ich führe Dich aber aufs Glatteis und nutze das
Oktalsystem!
W.S. schrieb:> 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.
/signed
Die Leute müssten sich nur mal Gedanken darüber machen,
warum die Programmiersprachen so sind wie sie sind:
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.
Pascal z.b. wurde erfunden, um Schülern das Programmieren
beizubringen, also eine Sprache mit Netz und doppeltem Boden.
Die beiden sind nicht vergleichbar. Es gibt aber immer wieder
Foristen, die meinen, genau das tun zu müssen.
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.
merciless
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.
Hallo,
Egon D. schrieb:> ...aber eins meiner Probleme ist, zu verstehen, warum> C so ist, wie es ist,...
C ist so wie es ist weil die "Erfinder" von C keine
Informatikwissenschaftler (wie ein Niklaus Wirth) waren, sondern
pragmatische denkende Ingenieure, die von der damals üblichen,
mühseligen Assemblerprogrammierung weg wollten. Die dazu notwendige
Programmiersprache musste sich aber trotzdem einen möglichst
hardwarenahen Zugriff auf die wenigen zu Verfügung stehenden Resourcen
ermöglichen. Und genau dafür ist C entwickelt worden. Perfektion und
absolute Eleganz des Sprachentwurfs waren sicherlich keine vorrangigen
Ziele.
Das sich diese Sprache so verselbstständigt und dann für praktisch alles
und jedes eingesetzt wurde, war sicherlich nicht die Intention der
Erfinder. Andererseits zeigt das aber auch die enorme Flexibilität von
C.
Mich wundert nur warum so viele "Profis" solche Probleme mit C haben,
obwohl selbst eine Programmieramöbe wie ich mich gut in die
Sprachkonvention von C einfinden kann. Vielleicht liegt das aber auch an
der Tatsache das ich noch gelernt habe einen Rechner/MC in seiner
Maschinensprache zu programmieren. Meiner Meinung nach helfen
Assembler-Kenntnisse viele der (durchaus merkwürdig erscheinende)
Eigenschaften von C besser zu verstehen.
> ...und warum C so gelehrt wird, wie es gelehrt wird.
Was meinst du damit?
rhf
A. S. schrieb:> Da ist für mich aber die Grenze überschritten.
Aber nicht ungewöhnlich. Typisch für Win-API-Programmierung zu Zeiten
von Visual C++ bis Version 7. Also vor .Net.
Roland F. schrieb:> Das sich diese Sprache so verselbstständigt und dann für praktisch alles> und jedes eingesetzt wurde, war sicherlich nicht die Intention der> Erfinder. Andererseits zeigt das aber auch die enorme Flexibilität von> C.
Praktisch alles und jedes? Im Embedded Bereich vielleicht. Dort aber
auch völlig zu recht. Sonst aber praktisch gar nicht mehr.
Früher wurde C ja sogar für Web-Backends (cgi) eingesetzt. Und auch für
Windows Programmierung. Alles längst vorbei.
Cyblord -. schrieb:> Alles längst vorbei.
Oder auch nicht, wenn man mal über das weiße Ding 20cm vor Deiner Nase
hinwegblickt - der Linux-Kernel ist afaik nach wie vor in C geschrieben.
Natürlich: Windows-GUI-Programme schreiben nur Masochisten in C.
Thread beobachten
Seitenaufteilung abschalten