Hallo, ich verwende in meinem Programm den folgenden Operator:
1
wert_neu=(wert&~maske);
Mit dieser Anweisung wird ein bestimmtes Bit (das Bit, was in der maske
auf 1 steht) in wert_neu "gelöscht".
Wie nennt man diesen Operator? Ich suche eine etwas allgemeinere
Beschreibung, wie das genau funktioniert.
*GAST* schrieb:> Wie nennt man diesen Operator?
Welcher? Das & (bitweise UND), das ~ (bitweise NICHT) oder das =
(Zuweisung)?
> Ich suche eine etwas allgemeinere> Beschreibung, wie das genau funktioniert.
Der Variable wert_neu wird das bitweise UND aus wert und der bitweise
invertierten maske zugewiesen.
Eine Liste der Operatoren findest du hier:
https://de.wikibooks.org/wiki/C-Programmierung:_Liste_der_Operatoren_nach_Priorit%C3%A4t
Noch einer schrieb:> Schönes Beispiel für den Obfuscated C Code Contest.
"Schön", dass C-Compiler solche schwachsinnigen Quellcodeformulierungen
ohne Murren übersetzt, statt solchem verwirrenden Zeugs einen
konsequenten Riegel vorzuschieben.
..oOo.. schrieb:> "Schön", dass C-Compiler solche schwachsinnigen Quellcodeformulierungen> ohne Murren übersetzt, statt solchem verwirrenden Zeugs einen> konsequenten Riegel vorzuschieben.
Das ist Absicht!
Der Gedanke dahinter ist der, daß sich nur halbwegs intelligente Leute
damit auseinandersetzen und die grössten Deppen gar nicht mitspielen.
Leider hat sich diese Hoffnung nicht erfüllt, sie geben trotzdem ihren
Senf dazu.
Was ist denn daran verwirrend?
Das ist ein bitweise_UND und ein bitweise_NICHT.
Für Leute, die oft in C programmieren kann das PHP $name .= $nachname;
genauso verirrend aussehen.
Meine Frau kann mit
int main(void);
nix anfangen.
*GAST* schrieb:> wert_neu = (wert &~ maske);C-hater hater schrieb:> Was ist denn daran verwirrend?GAST meinte wohl, dass "&~" ein Operator ist, den er so nicht in
seinem C-Buch findet...
>GAST meinte wohl, dass "&~" ein Operator ist, den er so nicht in>seinem C-Buch findet...
Das stimmt wohl.
Dann würde ich aber gleich einen Schritt weiter gehen. Wenn ein Ausdruck
nicht gut lesbar ist würde ich ein Makro draus machen
#define CLR_BITsIN(x, bitmask) ...
oder
#define CLR_BIT(x, bitnr) ...
wenn's dann nicht schon irgenwo in <supermakros.h> gibt
Klaus Wachtler schrieb:> ..oOo.. schrieb:> "Schön", dass C-Compiler solche schwachsinnigen Quellcodeformulierungen> ohne Murren übersetzt, statt solchem verwirrenden Zeugs einen> konsequenten Riegel vorzuschieben.>> Das ist Absicht!> Der Gedanke dahinter ist der, daß sich nur halbwegs intelligente Leute> damit auseinandersetzen und die grössten Deppen gar nicht mitspielen.> Leider hat sich diese Hoffnung nicht erfüllt, sie geben trotzdem ihren> Senf dazu.
Was stimmt denn mit dir nicht?
Du musst ein armer, verbitterter Mensch sein wenn du sowas am Feiertag
Vormittag von dir gibst. Warum verbringst du die Zeit nicht mit deiner
Familie, oder entspannst?
Du tust mir leid.
..oOo.. schrieb:> Noch einer schrieb:>> Schönes Beispiel für den Obfuscated C Code Contest.>> "Schön", dass C-Compiler solche schwachsinnigen Quellcodeformulierungen> ohne Murren übersetzt, statt solchem verwirrenden Zeugs einen> konsequenten Riegel vorzuschieben.
Man könnte zwar für alles, was irgendwer als schwer lesbar einstufen
könnte, spezielle Ausnahmeregeln definieren, die das unterbinden, aber
das würde die Sprache komplexer machen, ohne daß Leute, die sowieso
vernünftigen Code schreiben, etwas davon hätten.
Rolf Magnus schrieb:> ..oOo.. schrieb:>> Noch einer schrieb:>>> Schönes Beispiel für den Obfuscated C Code Contest.>>>> "Schön", dass C-Compiler solche schwachsinnigen Quellcodeformulierungen>> ohne Murren übersetzt, statt solchem verwirrenden Zeugs einen>> konsequenten Riegel vorzuschieben.>> Man könnte zwar für alles, was irgendwer als schwer lesbar einstufen> könnte, spezielle Ausnahmeregeln definieren, die das unterbinden, aber> das würde die Sprache komplexer machen, ohne daß Leute, die sowieso> vernünftigen Code schreiben, etwas davon hätten.
Vor allen Dingen sind solche Regeln gar nicht so einfach konsistent zu
definieren.
Ist
1
j=i+-3;
schwer zu lesen? Ist zwar Ansichtssache, aber ich würde mal ja sagen.
Ist es legal? Natürlich ist es das. Wie könnte man es besser schreiben.
Easy
1
j=i+-3;
Ist
1
len=sqrt(x*x+y*y);
schwer zu lesen? Ist zwar auch Ansichtssache, aber den Phythagoras wird
wohl jeder hier erkennen. Habe ich aus dem ersten Beispiel die Lehre
gezogen, dass eine Sprachregel her muss, wonach zwischen Operanden und
Operator bei binären Operationen ein Whitespace stehen muss, dann zwinge
ich damit den Programmierer das so zu schreiben
1
len=sqrt(x*x+y*y);
Jetzt kann man natürlich debattieren, welche Lösung die besser lesbare
sei. Ich würde trotzdem sagen die erste. Denn dort ist der optische
Zusammenhang der Quadrate leichter zu sehen, was in der zweiten Lösung
nicht der Fall ist. Klar, ich kann natürlich auch
1
len=sqrt((x*x)+(y*y));
schreiben. Aber ist diese Version in der Schreibweise wirklich besser
als die erste? Länger ist sie auf jeden Fall.
Fazit: man kann in jeder Sprache unleserliche Programme schreiben. Das
ist keineswegs nur auf C beschränkt. Man kann - aber man muss nicht. Das
es in C natürlich einen Haufen Sonderzeichen gibt, deren Bedeutung man
kennen und lernen muss, ist unbestritten. Aber dazu lernt man ja auch
eine Sprache und geht nicht mit Achtelwissen in reale Projekte rein. Das
muss man schliesslich in jeder Sprache (bis auf die Auswanderer, die
ohne ein Wort Schwedisch zu können nach Schweden auswandern. Aber das
ist nicht das Problem der Schweden und eine andere Geschichte)
Karl Heinz schrieb:> len = sqrt( x * x + y * y );
Der Programmierer aus dem erstem Beispiel würde es wohl so schreiben:
len = sqrt( x * x+y * y );
Wenn man gezielt Leser verwirren will kann man das wohl in jeder
Sprache.
Hi,
Karl Heinz schrieb:> Habe ich aus dem ersten Beispiel die Lehre> gezogen, dass eine Sprachregel her muss, wonach zwischen Operanden und> Operator bei binären Operationen ein Whitespace stehen muss
Whitespaces sind nicht Sprachbestandteil. Die werden durch die
lexikalische Analyse herausgefiltert, der es egal sein muß, wieviele
Whitespaces wo stehen, da sie nur Token zu bilden hat. Es müßte also
bereits vor der lexikalische Analyse eine solche Regel angewendet
werden. Tools zu ihrer Überwachung gibt es, z.B. Checkstyle. Code
Formatter, Beautifier, Pretty Print gibt es auch.
Grüße, Markus
Karl Heinz schrieb:> abe ich aus dem ersten Beispiel die Lehre> gezogen, dass eine Sprachregel her muss, wonach zwischen Operanden und> Operator bei binären Operationen ein Whitespace stehen muss
Wie wäre es damit, die Lehre zu ziehen, dass vor unären Operatoren ein
Leerzeichen stehen sollte (und -3 sollte als unärer Operator angewandt
auf 3 interpretiert werden :-) )
lalala schrieb:> Wie wäre es damit, die Lehre zu ziehen, dass vor unären Operatoren ein> Leerzeichen stehen sollte
Das passt leider auch nicht immer:
1
a=**pointer:
statt
1
a=**pointer:
sieht zumindest für meine Augen sehr ungewohnt aus.
Die Regel, vor und nach binären Operatoren ein Leerzeichen zu schreiben,
ist schon in Ordnung, wenn man in speziellen Fällen (wie bspw. der
obigen Formel des Pythagoras) Ausnahmen im Sinne der besseren Lesbarkeit
zulässt.
Guten Stil kann man nicht mit starren Regeln definieren.
Markus schrieb:> Whitespaces sind nicht Sprachbestandteil.
Doch. Sonst wären folgende Programmzeilen äquivalent:
Lukas K. schrieb:> Auch wunderbar zum Verwirrung stiften geeignet: Der 'downto'-Operator ;)
Der ist hübsch, den kannte ich noch nicht. :) Kann man natürlich
mit einem #define noch würzen:
Hi,
Yalu X. schrieb:> Doch. Sonst wären folgende Programmzeilen äquivalent:> interna = 5;> int erna = 5;>> Sei sind es aber nicht.
mag man so sehen, aber eine Sprache besteht aus Worten. Wie die Worte
gebildet werden, definiert die Sprache m.W.n. aber nicht. Die
Wortbildung setzt m.E. vor dem Punkt an, wo eine Sprache beginnt.
Grüße, Markus
Markus schrieb:> Wie die Worte gebildet werden, definiert die Sprache m.W.n. aber nicht.
Wer denn sonst?
Yalu X. schrieb:> lalala schrieb:>> Wie wäre es damit, die Lehre zu ziehen, dass vor unären Operatoren ein>> Leerzeichen stehen sollte>> Das passt leider auch nicht immer:> a = * *pointer:>> statt> a = **pointer:>> sieht zumindest für meine Augen sehr ungewohnt aus.
Schlimmer wird das noch, wenn man davor eine Multiplikation hat:
1
a=3***pointer;
Man könnte Klammern setzen, aber da stören die Leerzeichen auch eher:
1
a=3*(**pointer);
lalala schrieb:>(und -3 sollte als unärer Operator angewandt auf 3 interpretiert werden :-) )
Das wird es in C sowieso schon.
Yalu X. schrieb:>> Whitespaces sind nicht Sprachbestandteil.>> Doch. Sonst wären folgende Programmzeilen äquivalent:interna = 5;> int erna = 5;>> Sei sind es aber nicht.
Geht auch ohne whitespace. ;-)
Bastler schrieb:>> Stroustrup hatte dazu mal eine Idee ;-)>> http://www.stroustrup.com/whitespace98.pdf> Was hatte der denn geraucht, bevor er das geschrieben hat.
Spätestens beim Einführen von impliziten Whitespace Operatoren und
Variablennamen die aus einem Unicode Zeichen bestehen sollte man
bemerken, dass er das nicht ernst meinen kann.
Sebastian V. O. schrieb:> Spätestens beim Einführen von impliziten Whitespace Operatoren und> Variablennamen die aus einem Unicode Zeichen bestehen sollte man> bemerken, dass er das nicht ernst meinen kann.
Bei den Whitespace-Operatoren hast du recht, aber Unicode-Zeichen in
Variablennamen sind mittlerweile in ziemlich vielen Programmiersprachen
erlaubt (darunter Java, Python, Ruby, Tcl, D, Haskell, Rust, Scala,
Swift und mit Einschränkungen auch C und C++):
http://rosettacode.org/wiki/Unicode_variable_names